lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


2012/9/14 Coda Highland <chighland@gmail.com>:
> On Thu, Sep 13, 2012 at 4:47 PM, Hisham <hisham.hm@gmail.com> wrote:
>> On Thu, Sep 13, 2012 at 6:51 PM, Dimitris Papavasiliou
>> <dpapavas@gmail.com> wrote:
>>> Egor does have a point though.  Since the for statement accepts a list
>>> of values one would expect the usual rules about function calls and
>>> adjustment of returned values to apply.  If you can say
>>
>> The usual rules do apply. Whenever a single value is expected and
>> multiple values are returned, the extra values are discarded.
>>
>>> function f() return 2,10 end
>>> function g() return 4,12 end
>>> for a = f(), g() do print(a) end
>> 2
>> 3
>> 4
>>
>> As Dirk said, the comma-separated values are not a "list of values" in
>> the numeric "for" syntax. The fact that it uses "=" and "," just like
>> assignments is a coincidence, just like "(" is used both to
>> parenthesize sub-expressions and to start the list of arguments in a
>> function: two different uses of the same character. The "a = 1, 2"
>> inside "for a = 1, 2 do ... end" is not an assignment. The syntax
>> might as well have been "for a from 1 to 2 do ... end".
>>
>> -- Hisham
>> http://hisham.hm/
>>
>
> Certainly we understand the facts of how it's implemented and how the
> syntax is structured. That's not the point, though. The point is that
> it LOOKS like it ought to work. If Lua patterns were to hold, the
> syntax would be "for <variable> = <exprlist> do" rather than "for
> <variable> = <expr>, <expr>[, <expr>] do". Certainly there's valid
> reasons for this, but it IS different, and that was what they were
> trying to say.
(...)
> /s/ Adam
>

I completely agree. I also first thought - "it's simply the syntax",
but then pondering, I wondered if there is any reasoning why it
shouldn't work the way as Egor expected. I can't think of why it
shouldn't be allowed to work that way (except that it makes it harder
to determine what is going to going on... as a function can variate
the number of returns).

I believe it makes sense to revisit this syntax and check if it
doesn't make sense to change it.

Eike