OpenEuphoria

Returning multiple elements (was RE: Help With My Game of Black J

• Posted by "Boehme, Gabriel" <gboehme at POSTOFFICE.MUSICLAND.COM> Nov 30, 1999
• 487 views

David Cuny wrote:

>[ SOAPBOX ]
>
>In both versions, it would be nice if Euphoria supported the syntax:
>
>   { var list } = expr
>
>For example, the swap could have been written as:
>
>   { deck[card1], deck[card2] } = { deck[card2], deck[card1] }
>
>Drawing a card would be:
>
>   { card, deckOfCards } = removeRandom( deckOfCards )

I realize that this proposal has already been discussed at great length here
on the list, but I think I've come up with a variation on this idea which
may or may not be worthy of consideration -- you decide. 

The main problem with the method proposed above (a method I have endorsed in
the past, BTW) is that the function is forced to pack the return parameters
into a sequence, which would then be un-packed and moved to the named
variables. Given the flexible nature of sequences, "freezing" the return
value in this way can cause run-time problems, and there's no way to catch
this at compile-time.

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.
2) Can cause frustrations in remembering just how many values a function is
supposed to be returning.

In any event, that's my newest little brainstorm on the subject of receiving
multiple values from a function. Feedback is encouraged. 


Hep yadda,
Gabriel Boehme

----------
Welcome the unexpected, but not the arbitrary.

Robert Fripp
----------