1. Re: we need official libs : Swap
Roderick Jackson 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?
The latter, definitely.
I'm thinking of writing a preprocessor to handle this kind of thing, and
here's what the translated Euphoria code might look like:
-- [NOTE: 's' represents the preprocessor's internally-used sequence
variable]:
s = get(0) s={0,0}+s status = s[1] value = s[2]
The "s={0,0}+s" would enforce the sequence length at runtime, insuring that
the value returned from get(0) is always a sequence of length 2. If you were
to try something like this...
{status, value, oopsie} = get(0)
..it would translate into this...
s = get(0) s={0,0,0}+s status = s[1] value = s[2] oopsie = s[3]
..and the program would abend. The "s={0,0,0}+s" would give you a "sequence
lengths are not the same (3 != 2)" error message, which would fit with the
way the code looks before preprocessing (length-3 on the left, length-2 on
the right).
This approach could also work for more complicated situations:
{{is,this,{maybe,just},a,bit},too,complicated} = perhaps()
-- translated code
s = perhaps() s={{0,0,{0,0},0,0},0,0}+s is = s[1] ... -- you get the gist
This way, the bracket structure forces the function to return a value which
fits perfectly, or else the program will abend. As with get(), there are
probably situations where this kind of thing would prove to be very useful.
>>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? [snip]
Yes. Again, translated code:
s = { b, a } a = s[1] b = s[2]
[NOTE: "s={0,0}+s" can be omitted in this case, since it's obvious from the
source code what the length of 's' is going to be.]
So, yes, we *do* get swap functionality as a result of this idea.
> {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.
Hmm, good point. There'd have to be some mechanism preventing the same
variable from appearing more than once on the left-hand side of this kind of
assignment -- the above example could be caught as an error by the
preprocessor (or the compile stage, if it's implemented into Euphoria 
).
>>As well as:
>> a + 1 = 3
>>-- sets a to 2
>
>This one is really tricky. [snip]
Agreed, and it has nothing to do with the swap idea or assignment to
sequences of variables as explained above.
>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...)
If you're merely referring to code like "swap(a,b)", then I'd agree with
you. But I'd certainly rather code "{a,b}={b,a}" than "junk=a a=b b=junk",
wouldn't you?
Be seeing you,
Gabriel Boehme
