Assignment to variables inside braces
My second suggestion for Euphoria would be to allow assignments to
variables as part of a sequence. What I mean here is that I would
like to be able to assign multiple values in a single assignment
statement to a sequence of variables.
As an example, if I had a function which returned multiple values,
then I would like to be able to assign them to individually named
variables instead of needing to assign those values to a sequence.
Thus if I had a function which returned the x & y coordinates of
whatever, then I could call the function as follows:
{ xPos, yPos } = getXY(whatever)
This would result in the variables xPos and yPos being assigned the
resulting values. This would be much clearer than the current
approach which looks like:
tmpSeq = getXY(whatever)
xPos = tmpSeq[1]
yPos = tmpSeq[2]
(If there is a better way than what I've just shown to get these
values assigned to these variables then I'd appreciate whatever
suggestions people might have to offer.)
If we could update the parameters which were passed to the subroutine
(see my other message) then this could be addressed by having getXY
accept three parameters as follows:
getXY(whatever, xPos, yPos)
and this would be fine with me, but I still like my sequence-assignment
suggestion. For one thing, it would allow for multiple variable
assignment in a single statement which would follow Euphoria-like
syntax and would be very convenient for initialization such as:
{ readCtr, writeCtr, loopCtr, doneSw, recordFoundSw } = 0
This would look much like existing Euphoria syntax which allows an
atomic value to be assigned to a sequence with the result of each
existing element of that sequence would be assigned that value.
Similarly, multiple variables could be incremented in one step:
{ readCtr, writeCtr, loopCtr } += 1
I would not recommend this particular example as it makes using
readCtr and writeCtr separately as a sanity check (to verify that
you have written as many records as you have read) useless, but
that was just off the top of my head, I feel confident that this
could be a useful feature.
I understand that within the interpreter the "{" is considered a special
case of a function call which returns (together with its matched "}" )
a sequence containing the data values expressed within the braces.
It seems to me that this could easily be an exception case where instead
of being a function which returns a sequence, instead it becomes a
special case of a procedure where the variables within the braces become
parameters which are passed by address (I keep seeming to come back to
that, don't I?) and are updated by the procedure with the values which
are assigned to the "{}" procedure call (the real variation from
regular procedures comes in allowing assignments to a procedure, but
this is a special case procedure, after all 
.
Syntactically I think that the fact that the braces are the recipient
of an assignment operation could be sufficient to differentiate between
functional usage of braces to create a new sequence and procedural
usage of braces in order to assign values to the variables within the
braces. If that is inadequate for Robert's preferences, then I'd like
to suggest that a variation of something like
\{ x, y } = getXY(z)
Alternatively some other characters such as square brackets
[ x, y ] = getXY(z)
or greater than/less than
< x, y > = getXY(z)
or parens
( x, y ) = getXY(z)
or anything which Robert would prefer. However, personally I prefer to
stick to braces.
I suspect that the more difficult part of supporting something like this
is to check that such code does not allow for literals within the
braces to which a value is being assigned. For instance,
{ x, 9 } = getXY(z)
should generate a compile error since 9 is not an acceptable variable
name. This distinction between literals and variables is contrary to
most aspects of Euphoria where in most locations (except when an object
is being assigned a value via =, +=, etc.) the referenced piece of data
can be a literal, an atom, or a sequence (at least, as far as the
syntax is concerned, passing a sequence to a procedure which is expecting
an atom would already cause problems and I suspect Robert checks for
that), but with both this suggestion and my "pass parameters by address"
suggestion, a special case of parameters (whether to a user defined
routine or to the new {} procedure) which cannot be literals, but
instead must be variables of some type, would be needed. Actually,
this is not contrary to the distinction between variables and literals
because it is still true that the receiving side of the assignment
statement cannot contain a literal value.
A possible complication would be when using such a sequence as a
parameter to a routine which has the new pass by address declaration
for that parameter. In the case of my getXY procedure, suppose
it was called as follows:
getXY( {objectA, objectB}, {posXA, posXB}, {posYA, posYB} )
This almost seems that the routine would naturally assign the xy
positions of objectA to posXA and posYA, and the xy positions of
objectB would be assigned to posXB and posYB. However, this depends
entirely on the code within getXY expecting to get a sequence of
objects. It is just as natural to expect that both posXA and posXB
would be assigned the X postion of the sequence resulting from the
conjoining of objectA & objectB into a new object: {objectA, objectB}.
Furthermore, this usage would require the parameters to getXY to
be used as both functions and procedures in the same declaration.
First they would be used as functions to return sequences with the
values of the sequences shown as parameters above which are in turn
passed as parameters into the routine, then as procedures to
accept the assignment of values back from the procedure. In
fact, the processing within the procedure might have to allow for
processing a sequence of variables as it uses the parameters instead
of a sequence of data elements. This almost starts to look more like
passing the parameters by name instead of by address or value. Maybe
this syntax needs to be disallowed, or at least very clearly
specified. I hope that this conundrum doesn't spell the rejection
of my own suggestion, but I can see it causing some confusion when
combined with allowing parameter passing by address.
It seems to me that this enhancement would retain the elegant feel of
Euphoria without dramatically changing the syntax or appearance of
the language. I don't see it affecting performance significantly
unless there is some overhead in interpreting a series of assignments
which could be reduced to a single assignment statement.
J. Kenneth Riviere (JoKeR)
|
Not Categorized, Please Help
|
|
