Re: newbie to lua :-) a trivial question...

[RJ Russell <russellsprouts2@...>]

On Thu, Nov 25, 2010 at 9:53 PM, Miles Bader <miles@gnu.org> wrote:
> starwing <weasley.wx@gmail.com> writes:
>> now we changed the standard library in Lua 5.2(the set/getfenv
>> are deprecated. so change the ... semantics is not a unacceptable change in
>> new version of lua. if we makes f() return its all return value in all
>> situation, and  (f()) just return its first return value, we will get
>> the consistency behavior then we process return value. I think thus is
>> important than portability.
>
> It's not as simple as you imply.
>
> There's a very good reason that only one return value from "f" is used
> in the following case:  g (x, y, f(), p, q) -- it's predictable.
>
> For table constructors, e.g. {x, y, f(), p, q}, perhaps it would be less
> of an issue, as tables are often treated as simple sequences where
> precise position is less important.  However I think it's arguable that
> for consistency with the function-argument case, MRV in
> table-constructors should be treated the same.
>
> Since a new explicit syntax (e.g., {x,y,f()...,p,q}) resolves the above
> issues, and avoids incompatibility with existing code, it's preferable
> to changing the meaning of the existing syntax.
>
> -Miles
>
> --
> Admiration, n. Our polite recognition of another's resemblance to ourselves.
>
>

The other problem is how to denote expanding a vararg
example:
function doublearray(...) --takes an array like {1,2,3} and returns
{1,2,3,1,2,3}
  return{......,...}  --too many dots!
end

Possible solution: Change the vararg expression to two dots ".."
e.g. function(..)end
But two dots works as an unexpanded version, three dots expands all the way.
function fun(..)
  a={..} --the first non-nil argument as an array
  b={...} --all the non-nil arguments in an array
end
example:
fun(1,2,3)-->a={1}, b={1,2,3}
This would break a lot of code, of course. The numbering could be
reversed, so ... is unexpanded, and .. is expanded, but that seems
unintuitive and backwards.

Another possible solution: Named varargs. We don't use the vararg
expression in the actual function. Then of course it would be nice to
have a first class tuple type.
function fun(args...)
  a={args} --the first non-nil argument as an array
  b={args...} --the first non-nil argument in an array
  --Tuple type: What would type(args) return? Can we assign local
temp=args? That would be nice.
end
example:
fun(1,2,3)-->a={1}, b={1,2,3}

Plus, would the end of an array automatically expand without a "..."?
After making the change:
function numbers()
  return 1,2,3,4,5,6,7,8,9
end

a={numbers()...} --automatically expanded.
b={numbers()} --would this be {1,2,3,4,5,6,7,8,9} or {1}?

For backwards compatibility, returning all makes sense, but it is
easier to understand if the dots are required.