Re: wrapping functions

[Jean-Claude Wippler <jcw@...>]

On Fri, May 4, 2001, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

[...]
>About the "compress" function, we intend to change a little the semantics 
>of the language, so that {..., f(x)} will put all returns of the last call 
>into the list. This will create a small incompatibility, but it is much 
>more coherent with the current semantics for function calls and returns. 
>Now, every place that accepts a list of expressions will also accept a list 
>of return values from the last expression. (And "compress(f(x))" will be 
>simply "{f(x)}".) 

Perfect!  It can be summarized as: f(x) returns "values and commas".

>We are also thinking about the proposal (by ET, I guess) of using "(exp)"
>as a way to force "exp" to have exactly one value, so that {(f(x))} will
>always create a list with exactly one element.

The feature would definitely be most welcome (it's what I tried first
when I wanted this capability).  But there is a slight visual
inconsistency: "x=f(g())" vs. "x=(g())" when g returns multiple values. 
In the first they all go through, in the latter only the first does.  So
overloading () for function arg passing and for single-value extraction
could be somewhat confusing.

How about the following (gleaned from the Icon language):
    - in "x=(...)", comma's are passed through when the context allows it
    - to prevent this, use "x=1(...)"
    - that can then be generalized to "x=<N>(...)"
I have no idea whether this fits into the language.  It basically says
that numbers can act as extraction/projection functions.

-jcw