1. Re: Returning multiple elements (was RE: Help With My Game of
Boehme, Gabriel wrote:
>David Cuny wrote:
>
>>[ SOAPBOX ]
>>
>>In both versions, it would be nice if Euphoria supported the syntax:
>>
>> { var list } = expr
>>
>However, Euphoria can and does verify the number of parms passed TO a
>function -- by putting them between parentheses:
>
>-- EXAMPLE_1
>procedure this(integer that, object the_other_thing)
>-- code
>end procedure
>
>this(35) -- causes precompile error, not enough arguments
>-- end EXAMPLE_1
>
>So, with this thought in mind, why don't we create a new method for
>returning/receiving multiple values from a function -- putting them between
>parentheses.
>
>-- EXAMPLE_2
>global function swap(object x, object y)
> return (y, x) -- parentheses, not braces
>end function
>
>(x, y) = swap(x, y) -- all parentheses, no braces
>-- end EXAMPLE_2
>
>I realize that this is a somewhat basic example, yet it captures the essence
>of the idea I'm proposing here. This method of using parentheses would have
>several benefits:
>
>1) Compile-time verifiable -- errors in receiving the wrong number of
>elements could be caught at the precompile stage, rather than during
>run-time.
>2) It's very clear from looking at the source code how many values a
>function is returning. Likewise, it's very clear how many values are being
>received from a function.
>3) It preserves the readability of the code by allowing you to use
>meaningful variable names instead of names like "tmp[2]".
>
>Of course, there are drawbacks:
>
>1) Not backwards-compatible -- if implemented, no previous version of
>Euphoria will be able to run the new code.
Who cares... it breaks no existing code that I can see...and we already
have that situation for several items and even more, situations where
previous code is broken.
>2) Can cause frustrations in remembering just how many values a function is
>supposed to be returning.
Clearly documented by the format that you suggest, so no problem. However,
there is one little problem. What happens with multiple return statements?
All return statements from a particular function must have the same form.
I don't have a problem with this as it saves both code and errors. If their is
a problem it can be solved by using a sequence as one of the targets.
>In any event, that's my newest little brainstorm on the subject of receiving
>multiple values from a function. Feedback is encouraged. 
Anything that puts named variables in place of indexes is a positive thing
for readability of code. Indexes only document when they refer to repeated
data or groups of data. An index that refers to data whose only relationship
to the data next door is position invites error. When field[3] is price and
field[4] is street address, the index tells us nothing logical.
Everett L.(Rett) Williams
rett at gvtc.com
