1. Re: we need official libs : Swap
Boehme, Gabriel wrote:
>With this as a given, how can we then allow {a,b} = foo() to be legal, if
>expressions are only allowed on the right? The solution would be to
>re-define how the sequence "operators" are viewed by the interpreter, in
>such a way that {a,b} is not *solely* viewed as an expression. Euphoria
>already contains some precedents where symbols used in expressions can have
>additional, non-expression meanings.
Perfectly logical. Were the construct added, it would be best to have it
added as a syntax addition, not an allowance of a lexical <EXPRESSION> on
the left-hand side of an assignment (just the thought of
append (s,x) = {1,2,3}
gives me nightmares...)
<snip good "=" example>
>{a,b} = foo() seems
>pretty clear from context, don't you think?
Yes, once I'm told that the {} in such cases acts as a multiple-assignment
indicator. Otherwise, it would have made (and would make) as much sense
to me as: 3 = foo()
(But concerning the equal sign, I must say that this is one of the few
ambiguity "stretches" I've found in Euphoria. I was expecting the language
to have something closer to Pascal's ":=", since "=" was allowed as part of
a logic expression. But, the single fact that expressions aren't allowed on
the left-hand side of an assignment prevents ambiguity--otherwise, we'd have
to decipher the then-ambiguous: a = b = c)
>Additionally, sequence slicing is one feature of Euphoria which *looks* like
>an expression, but which also functions perfectly well at the receiving end
>of an assignment:
<snip slicing examples>
Hmm, you know, I think this is the closest to an ambiguous syntax element
Euphoria has (closer than the "=" stretch). I may also need to apologize
to Ralf here... I had said that I had no difficulty learning Euphoria's
basic constructs. The fact is I think I almost ignored left-hand slices.
Up until recently, had you asked me what the result of
s[i..j] = 2
would have been, I don't think I would have remembered. But I've never
run into trouble with it since I've NEVER even been close to a situation
where I've needed or desired anything like it, or where I've had to work
with it in someone else's code. (Which makes me wonder exactly when the
construct was introduced into the language. I strongly suspect it wasn't
in the original design...)
I also think it's worth noting that left-hand slicing isn't often used--
I've never noticed it in libraries or code I've downloaded from the
website, or code that has been posted to the list (not that it wasn't
there, but rather the code apparently wasn't littered with uses, or I
would have seen it.) At least "+=" gets a fair share of use.
If left-hand slices were currently not implemented, I think I would be
opposed to THEM, too.
>So then, what must be done to allow us to code {a,b} = foo()?
[...]
Oh boy... these look well thought-out, but rather than debate them (I'm
largely in agreement with them,) I think I'll just point out that this
construct does have an ideal. Ideally, I should be able to put any
variable, or anything that can be used in place of a variable, into any
position within the {}. Why? Because the fact that it's a single
construct implies a non-sequential, wholistic operation (whether or not
the actual implementation is sequential.) When I add 2 to a grouping--a
sequence--it doesn't matter how it gets done (left-to-right, right-to-
left, etc.) It just happens. Ideally, {a, b, c} = {1, 2, 3} would work
the same way and so, in theory, {a, a, a} = {1, 2, 3} shouldn't present
a problem.
This is, of course, much of the problem with the construct. We know that
trying to resolve that results in ambiguity. And obviously, not
everything can be ideal (although much of this language is); but I just
thought I'd mention that limits to the ideal are all usually somewhat
arbitrary. Although there are benefits to disallowing it, who's to say
that letting
{junk, junk, x, y, junk, z} = process_data ()
be legal is the wrong choice, especially when disallowing it is done
for implementational reasons? Similarly, making
{a[x], a[y]} = {a[y], a[x]}
illegal when x and y are equal will prevent the use of a number of
algorithms with the construct, algorithms that infrequently perform
redundant computations, but are relatively simple, fast and efficient.
Just food for thought.
Rod
