1. 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)
2. Re: Assignment to variables inside braces
If you read the past 2 years of messages on the list
you will find that Rob is not interested in changing the langauge
to any extent as has been suggest by many past users. Maybe when the
compiler comes out you will be able to modify the langauge a little easier.
3. Re: Assignment to variables inside braces
On Wed, 16 Aug 2000 16:41:18 -0400, Bernie <xotron at PCOM.NET> wrote:
>If you read the past 2 years of messages on the list
>
> you will find that Rob is not interested in changing the langauge
>
> to any extent as has been suggest by many past users. Maybe when the
>
> compiler comes out you will be able to modify the langauge a little
easier.
That's why I'm starting the threads now. He said that he was just
about finished with the compiler and then he'd get busy with some
work on the next version. I figured it would be better to make
suggestions before he started updating it rather than after he
releases the update. Beyond that, I'm trying to suggest changes that are
somewhat in keeping with the spirit of the language as I perceive it,
novice though I am, rather than suggesting wholesale changes.
I have read some of the past messages, but the value of the msgs seemed
less and less the further back I went as the amount of repetition of
frequent topics, questions about bugs which have since been addressed, etc.
meant that there was less I was learning for the amount of time I was
spending reading. If there were months which were particularly profound
that you can recall, then I'd be interested in reviewing it.
Thanks for your response.
-J. Kenneth Riviere (JoKeR)
4. Re: Assignment to variables inside braces
> If you read the past 2 years of messages on the list
Where can i do that, for 2 years?
5. Re: Assignment to variables inside braces
J. Kenneth Riviere wrote:
> My second suggestion for Euphoria would be to
> allow assignments to variables as part of a
> sequence.
That's been on my wishlist since I saw it in ABC (a precursor to Python).
-- David Cuny
6. Re: Assignment to variables inside braces
On Wed, 16 Aug 2000, you wrote:
> > If you read the past 2 years of messages on the list
>
> Where can i do that, for 2 years?
http://listserv.muohio.edu/archives/euphoria.html
The list actually goes back 4 years, beginning in June 1996
Irv
7. Re: Assignment to variables inside braces
- Posted by Undetermined origin c/o LISTSERV administrator
Aug 17, 2000
-
Last edited Aug 18, 2000
how do i get off this list?
pls email me
ragnarok at iinet.net.au
> ** Original Subject: RE: Assignment to variables inside braces
> ** Original Sender: Irv Mullins <irv at ELLIJAY.COM>
> ** Original Date: 17 Aug 2000 12:52:38 -0000
> ** Original Message follows...
>
> On Wed, 16 Aug 2000, you wrote:
> > > If you read the past 2 years of messages on the list
> >
> > Where can i do that, for 2 years?
>
> http://listserv.muohio.edu/archives/euphoria.html
>
> The list actually goes back 4 years, beginning in June 1996
>
> Irv
>** --------- End Original Message ----------- **
>
8. Re: Assignment to variables inside braces
On Wed, 16 Aug 2000 23:02:56 +0200, =?iso-8859-2?B?qWtvZGE=?=
<tone.skoda at SIOL.NET> wrote:
>> If you read the past 2 years of messages on the list
>
>Where can i do that, for 2 years?
GO HERE: http://listserv.muohio.edu/SCRIPTS/WA.EXE?A0=euphoria&D=1&O=D
