1. Re: we need official libs : Swap
Ralf Nieuwenhuijsen wrote:
>We don't need swap. What we need is the ability is sequence 'unbinding' ..
>Many times, people have asked for things such as:
>
>{ status, value } = get (0)
>
>Why does this seem logical ? Because we, humans most of us, can 'unbind'
>things and make the only logical conclusion about the values being assigned
>to the variables.
What happens when I'm returning a sequence of arbitrary size? Or is this only
meant for used when you know exactly how many elements the returned sequence
will be?
I guess you could just say I'm not comfortable with the idea. Maybe it's just
that it doesn't look right. Frankly, I'd rather see:
a,b,c = my_routine ()
Hmmm, but then that might get confused with the concept of assigning all three
variables the same data. Oh well...
>I think the above should work, as well as:
>{ a, b } = { b, a }
Well, this example brings up some thoughts. Are we to assume that the value of
every element of the {b,a} is temporarily stored before assignment? If not, if
we instead assume this breaks down into seperate, literal assignments:
a = b
b = a
then we're still no closer to a real 'swap'; b keeps it's value. And if each
value of each right-hand element IS temporarily stored, it begs the question...
{b, b} = {c, b}
should 'b' retain it's own value after this is executed, or the value of 'c'?
It seems like a somewhat arbitrary decision.
[...]
>As well as:
> a + 1 = 3
>-- sets a to 2
This one is really tricky. Granted, this looks more like natural mathematics.
You describe your equation, and Euphoria solves for the unknown variables. The
problem is, that's not how assignment works in most programming languages. Some
DO handle things that way, but I've never heard of a language that accepted both
x = x - 1
AND
x + 1 = x
Frankly, since Euphoria already uses the former form of those expressions, I
see no reason to add the latter, especially when the two forms are
interchangeable. And heaven help Rob if we all expect the interpreter to
"correctly" handle:
a + c = b
>Surely, situations like this can be confusing:
>(the only problematic situations I can come up with are the use of '=')
>
> ( a = b ) = ( b = c )
>
[...]
>If implemented as I suggested, it would, eventhough a little confusing,
>would assign to a whatever value is needed to make the above true.
>
>The parenthes (sp ?) force the second '=' to be the assignment operator,
>which forces the truth by setting the variable on the left. The left is an
>evalution expression, and the first variable is set.
Would you seriously want to inflict this syntax onto a language as clean as
Euphoria, just to save a few keystrokes? One of the hallmarks of Euphoria, one
of the main reasons I immediately accepted it, was the fact that to a complete
newbie, source code (without even referring to the documentation) is very
clear.
This is not. I'm not even sure how you would expect this to be interpreted;
I assume this breaks down to the following (correct me if I'm wrong):
a = 0
b = 3
c = 3
(a = b) = 1 -- the result of (a = b) = (b = c)
-- a is now assigned 3, so that (a = b) is true
But this isn't just confusing, it's completely ambiguous. Consider:
a = 0
b = 3
c = 1
(a = b) = 0 -- the result of (a = b) = (b = c)
NOW what are we supposed to assign to 'a'? 2 would work. So would -2839.893.
So would just leaving it 0. And for that matter, how does the compiler know
you want to change 'a', and not 'b' (similar to 'a + c = b')? Surely you're
not going to throw in some monstrous exception such as "only currently
undefined variables get assigned a value"?...
I don't understand this desire for such far-reaching, unnecessary changes to
the language, changes that could easily (and much more clearly) be implemented
by current constructs. Euphoria is the closest thing I've seen to a perfect
programming language (but not THE perfect language; there could be more than
one.) I'd think we're better off keeping things pretty much the way they are,
adding functions as necessary rather than new syntax. 
(And incidentally, since a swap function is clearly un-Euphoric, I'd say
we're probably better off without it...)
Rod
