1. Re: we need official libs : Swap
Ralf Nieuwenhuijsen wrote:
>> >I don't care how the above is handled. Illegal, legal ( s[i/j] becomes
>2nd
>> >element as if it was written out. )
>>
>> Ralf, that's part of the problem. Euphoria was designed to be a wholistic
>> programming language. It was meant to be consistent, not a collection of
>> unrelated ideas and constructs. You can't continue with that paradigm by
>> just throwing in new things to ease one particular situation without
>> caring about what it leads to.
>
>First of all, being able to format using sequences is more consistented.
>Secondly, it would make Euphoria more whole, because it gives native support
>for multiple return values, something still lacking. (the sequence part
>currently, in my eyes is a trick, you aren't checking length, format nor
>types with the current 'trick' we're pulling )
But this assumes that multiple-assignment IS lacking. On what is that
observation based? Because it's not in the language? That applies to a
lot of things: complex numbers, multithreading, passing values by
reference, error-handling traps, even a "++" operator. Are you suggesting
that Euphoria should gradually grow until it eventually encompasses
every feature of potential use to a programmer? Or if not, where do you
think the line should be drawn?
[...]
>It is more consistent, then it currently
>is. I and many others, i'm sure, in the beginning, being introduced to
>Euphoria, at least tried if this was possible, assuming the odds were high
>it would work.
Mmm, I don't know about this. Were you already familiar with some other
language that incorporates this idea, before you discovered Euphoria? I've
never even considered anything like that.
>> >Thirdly, although, you may have been taught differently, as most. Just
>> >because something is there and others use it, doesn't mean you have to
>use
>> >it.
>>
>> Yes, the "if you don't like it, don't use it" argument. It's not credible.
>
>You aren't even using arguments to explain why you think its not credible.
Because solid refutations have been presented before. But rather than hash
through all of that, perhaps I can illustrate this through analogy...
I'm sure many people aren't interested in this discussion. Let's assume,
for some insane reason, that we decide to continue it forever; we plan to
make the discussion a permanent part of the list. If others found out about
this plan, and balked, would it solve their problem if I told them, "If
you don't like it, don't read the posts"?
One more example. I'll bring up the "Forbidden Comparison" via a question
(drum roll, please...):
Why is it more difficult to read and write C code, even when experienced in
C, than it is to read and write Euphoria code?
Somehow, I find it hard to answer that question without making reference to
C's numerous jumbles of not-well-related syntax elements, constructs and
even function behaviors...
[...]
>About consistentcy. People have an idea of what good and bad is, (most do
>anyway 
.. they see a big picture of right and wrong, and create rules so
>they can apply and judge situations much more clearly. One could even define
>a rule as a generalization, actually it is.
Yes, we finally agree!... for the most part. 
>These rules serve a higher purpose. A goal. Rules should be consistent and
>should be kept to a bare and powerfull minimum, I totally agree. But it is
>ok, to have lesser rules as well. Some things need to be handled more within
>the context and some exceptions are better not generalized away.
Right, but like I said, that's where we differ. Apparently, I feel that
there should be far fewer exceptions than you feel are acceptable. My
thoughts, when it comes to Euphoria (I DON'T feel this way about every
programming language,) are that NOTHING that isn't an obvious flaw, or
that doesn't cause serious inconvenience or inefficiency, should be added
or changed.
>Just as you are not allowed to multiple two sequences of different lengths.
>Is this consistent ? No, it would be more consistent if each element was
>multiplied with each element of the other sequence.
I disagree here. That almost sounds like a matrix operation, not a simple
'mapping' of the operator. It's a somewhat complex computation, and one many
people would have to sit down and think through everytime they saw it (I
would.) Euphoria's operators are simple arithmetic, (and are always, once
broken down, performed one atom with one other atom); not-so-simple math,
like sqrt(), power(), sin(), etc., are reserved for functions. But anyway...
>But before you all balk with, not friendly enough for new users, not .. bla
>bla bla..
>I want to make one thing clear, the construct is, in my eyes, allowed to be
>as confusing as any construct in Euphoria currently is. It is allowed to be
>as user-unfriendly as any of those constructs, etc. .. you get the point,
>I'll be comparing it to current parts of Euphoria.
Ah, here may be the key. I'm not trying to say that the LOOK, or the
CONCEPT, of this one code snippet:
{x, y} = location()
would be much (if any) worse than
a = ({1,2,3,4} = 1)
But what I am saying is, it still harbors ambiguity. It doesn't look like it
does from that ONE instance, since the resolution of what's going on doesn't
cause any problems. But by no amount of topological magic can I twist the
second example into one where I won't know EXACTLY what will happen without
needing knowledge of some odd exception. With the first example, it doesn't
even take magic:
{s[i], s[j]} = {1, 2}
{a, b, a} = {1, 2, 3}
{s[i..j]} = my_func () -- returns arbitrary-length sequence
{a, b} = {b, a}
Each of the those cases is ambiguous, requiring some specific change in the
nature of the construct to address it (or requiring a literal a=b, b=a
translation that users must know about.) We don't wind up with a pure,
powerful new construct; we wind up with one that has been hacked to fit
what we want it to do in one specific case. This is as bad as making an
exception in the use of sequence logic operators, just so we can do:
if ("Hello" = input_string) then
Again, an example. Flip back quickly through the Euphoria manual, or
through the pages of your memory. Look for some construct or syntax
element (ignore compiler directives, like "with") that can lead to an
ambiguous situation. Where several exceptions must be tossed in, and a
knowledge of the implementation is almost necessary to grasp it. Can you
find one? I can't. (And even if by some miracle you can... look at it
closely. Would you really want to start filling Euphoria with any more
such oddities?)
To corrupt a common quote:
"If it's not broke, (or at least causing trouble,) why 'fix' it?"
Rod
