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

[RJ Russell <russellsprouts2@...>]

On Sat, Nov 27, 2010 at 9:51 PM, RJ Russell <russellsprouts2@gmail.com> wrote:
> 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.
>

One addition, in the "Possible Solutions" part, assume that the last
part of a table is unexpanded by default.