Re: Multi-assign
- Posted by DerekParnell (admin) Dec 05, 2011
- 1614 views
I have viewed this thread with dismay.
Good. Not that I agree with you here but its good that we speak up when we have an issue about the direction of the language.
Everyone seems to see only the positive (multi-assignment is good!). Yes it is useful (marginally). It provides a simple swap {a, b} = {b, a} and it allows the dreadful {?, x} = value(Y).
Consider:
integer a, b, c {a,b,c} = f(x) -- 1
A function (presumably) returns one value (sequence or atom).
If you are able to recover a, b & c then the {} are not acting as sequence forming operators in (1). (Otherwise: there would be a complaint about them being used before being initialised.)
I can see how the LHS use of the brace-pair looks like a sequence creation operation when it actually isn't that at all. This is a classic reuse of the limited character set available to use to mean different things depending on the context its used in. There are already a number of such re-uses in Euphoria, such as '=', which can mean an assignment or an equality test depending on where one uses it. Another is the parenthesis-pair, which can delineate a set of function arguments or impose a precedence order for expression evaluation.
We chose the brace-pair for this new feature to hint to the code reader that a sequence is involved, but in this case a sequence is being de-constucted rather than being constructed.
The assumption is that the function will return values appropiate to the types of the LHS. What should those types be? The library functions often return different types (eg gets() returns -1 or a sequence).
The idea is that one would use multi-assign when it makes sense and when it would not fail. So if one uses it for functions that return an atom, you're doing it wrong.
{a,?,c} cannot be a sequence a slice [1..2] - what is its value?, its length?
f(x, ?, y): by the reasoning of {a, ?, c} the ? means 'disregard this value' not 'use the default'.
Disregard this value makes no sense applied to a function parameter.
I like to think of it more as a placeholder. So I regard it more as saying ... 'this position in the list is not being used by me'.
Confusion between {a,b,c} = {d,e,f} as L-value <- R-value and an expression (pure R-value).
{a,b,c} = {1,2,3} -- either a:=1, b:=2, c:=3 or {a=1,b=2,c=3} {1,2,3} = {a,b,c} -- either an error or {a=1,b=2,c=3}
The problem is not that you can't make this work. The problem is that syntactically they are identical. Therefore you cannot distinguish between an erroneous expression and a (correct) assignment and vice versa.
Not quite accurate. The parser can distinguish between the two uses, just as it can with the '=' symbol. The rule is simply when the scanner finds '{' as the first character at the start of a statement, it assumes that as multi-assignment is being written. It then goes on to validate that assumption and if true, generates the appropriate Intermediate Language code.
A multi-assignment LHS list is illegal if it contains any literals. Thus {1,2,3} will fail.
Instead of using {a,b,c} why not use something like < a, b,c > or | a, b, c | for multi-assign? That way it is clear this is not a sequence, but a list of some kind.
As I said earlier, we could have used something else, but we wanted to keep some link to a sequencing sort of operation - in this case a de-sequencing one.
