Re: Lua5.0 new "For" question

["Peter Hill" <corwin@...>]

Björn De Meyer:

>> Why do we write:
>>     for i,v = pair(a) do print(v) end
>> Wouldn't it be just as fine to say:
>>     for i,v = next,a do print(v) end

> First of all, you don't seem to know the correct syntax of the
> for loop. In Lua 5, for a non-numerical foo, it's not "=" but "in".
> You make this error consistently, so I assume you haven't even tried
> to use Lua 5.

My mistake. I've been programming a lot in Basic recently :-)

No, I haven't tried to use Lua5.0 since it currently doesn't come with a
windows executable. I have, however, been looking through the documentation
trying to understand the changes and their ramifications.


> But you are right, the construct
> for i,v in pairs(a) do end
> is basically equivalent to
> for i,v in next, a do end
> I think pairs() is used for syntactic sugar, mostly.

Fair enough. Question answered.


>> The generally solution would be to have some sort of return-value
>> compiler directive. Eg, let's use "#" (being the "number" sign) which we
>> define as:
>>     n # f() -- truncate (or expand with "nil") to n values.
>>     # f() -- use all return values
>>     f() -- use one return value... same as 1#f()

> Sorry, but I think this is so ugly it almost makes me weep.

I see our aesthetic senses differ here. What do other people think?


> Besides, you can already do what you want to do here in Lua 5,
> like this:
>
> function nres(n,
> ...)
>    local res = {};
>    if(n>arg.n) then n = arg.n; end;
> -- Make sure n is not greater than the amount of arguments received.
>    for i = 1, n do res[i] = arg[i] end
> -- Copy the first n arguments in a temporary table.
>    return unpack(res);
> -- Unpack the table, so we only leave n arguments on the stack
> end

Actually, no, you've completely missed the point. What I'm wanting is
something like:
   function two() return 11,22 end
    a, b, c, d = #two(), 3, 4

which sets
    a==11, b==22, c==3, d==4

Ie, the "#" directive relates to the compiler operation of assembling
arguments on the stack. The "#" overrides the natural "exp1" behaviour of
truncate-to-1, something that can't currently be done.

The "nres(2,blah)" expression will return two arguments which will then
simply be discarded down to ONE argument for the assignment. So:
    a, b, c, d = nres(2,two()), 3, 4

will simply set
    a==11, b==3, c==4, d=nil


> Ugh! Sorry to say this, but I think you need to read the manual  more
> carefully.

I shall keep doing so, of course.


> The problems you have can all be solved in Lua 5.0, without having to
> change the language. You just need to get aquiainted a bit more with the
> functional programming  aspect and the flexibility of Lua.

nres() didn't give the desired results. So what Lua5.0 construct will?


> I want to keep Lua pure and simple.

"Pure" is a very loaded term (with some nasty connotations I won't go into).
As for "pure Lua", a language which regularly undergoes notable revisions
can hardly claim (or even want) to be pure. The disappearance of upvalues
and the new lexical scope thing (which I'm still coming to grips with) is
hardly "language purity" from the point of view of a Lua4.0 vetran.

As to "simple"... I agree that is an excellent goal to have. But, once
again, exactly what is simple is not always black and white.

I consider
    for i,v in next,t do end
to be much simpler than the rather extraneous
    for i,v in pair(t) do end

Likewise... why even have the unneeded notation:
    function f(a) end
when
    f = function(a) end
is so much clearer?

So how "unsimple" is the suggested '#'? Lua already provides both the "exp1"
(discard down / pad up to a single value) and "exp" (keep all values)
actions. It's just that only the final element of an expression list can be
an "exp", while the others all have to be "exp1". That asymmetry is rather
non-obvious to the novice programmer (hence I wouldn't call it "simple") and
it also limits the programmer's options.

I personally consider it more "simple" (and symmetrical) having all elements
of an expression list dealt with in the same way - defaulting to the "exp1"
action, with a single character "exp" override.


> The changes to the language you propose are unneeded, not to mention very
> un-Lua like. I'm sorry if I sound stuck-up,

Yah, that does sound stuck up. Comments like "this is so ugly it almost
makes me weep" about somebody's suggestions do not exactly endear them to
open discussion.

When I first encountered Lua a year or two ago I was quite enthused by it;
it is a lovely language. I joint the List but, after making a reasonably
educated suggestion and being cut off at the knees, I was so disgusted that
I gave up on Lua completely for a while (a rather sad outcome).

You think it is "ugly"? I don't think so. And an off-the-cuff aesthetic
judgement is hardly a reason to unilaterally silence the issue without
discussion, especially when your proposed "fix" doesn't work.

A discussion list should be a place to present ideas... not stifle them.

*cheers*
Peter Hill.