Next Version of Lua?

classic Classic list List threaded Threaded
143 messages Options
12345 ... 8
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Duncan Cross
On Wed, Jun 10, 2009 at 11:24 AM, Luiz Henrique de
Figueiredo<[hidden email]> wrote:
>> local tbl = {ReturnSixIncrementalValuesFromZeroToSix(), 7, 8, 9} -- this
>> would equate to doing {1, 2, 3, 4, 5, 6, 7, 8, 9}
>
> This is a bad idea.

I had an idea for an explicit syntax for this, that overloads the ... operator:

local tbl = {SixValues()..., 7, 8, 9}

- so that, if the "..." keyword immediately follows an expression that
could resolve to multiple values within a comma separated list, they
are expanded. I can't see any way that this could be ambiguous, but I
haven't thought about it all that much, so maybe I am wrong. It also
kind of makes sense as "..." already means "accomodate a variable
number of values", but in this case it would mean a variable number of
*return* values rather than arguments.

-Duncan
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
Duncan Cross wrote:

> I had an idea for an explicit syntax for this, that overloads the ... operator:
>
> local tbl = {SixValues()..., 7, 8, 9}
>
> - so that, if the "..." keyword immediately follows an expression that
> could resolve to multiple values within a comma separated list, they
> are expanded. I can't see any way that this could be ambiguous, but I
> haven't thought about it all that much, so maybe I am wrong. It also
> kind of makes sense as "..." already means "accomodate a variable
> number of values", but in this case it would mean a variable number of
> *return* values rather than arguments.
>
> -Duncan
>  
Probably best solution I've heard so far, though I'll have to spend more
time digging in the wiki as Patrick Donnelly kindly pointed out (thanks
for the link though!). Only bad thing is that it look rather odd, but we
can/will adapt I guess.

Olivier Hamel
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Henk Boom-2
In reply to this post by Duncan Cross
2009/6/10 Duncan Cross <[hidden email]>:

> On Wed, Jun 10, 2009 at 11:24 AM, Luiz Henrique de
> Figueiredo<[hidden email]> wrote:
>>> local tbl = {ReturnSixIncrementalValuesFromZeroToSix(), 7, 8, 9} -- this
>>> would equate to doing {1, 2, 3, 4, 5, 6, 7, 8, 9}
>>
>> This is a bad idea.
>
> I had an idea for an explicit syntax for this, that overloads the ... operator:
>
> local tbl = {SixValues()..., 7, 8, 9}
>
> - so that, if the "..." keyword immediately follows an expression that
> could resolve to multiple values within a comma separated list, they
> are expanded. I can't see any way that this could be ambiguous, but I
> haven't thought about it all that much, so maybe I am wrong. It also
> kind of makes sense as "..." already means "accomodate a variable
> number of values", but in this case it would mean a variable number of
> *return* values rather than arguments.
>
> -Duncan
>

local tbl = {... ..., 7, 8, 9}

would be a bit strange, no?

    Henk
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (again, \x## notation)

Ralph Hempel
In reply to this post by Olivier Hamel
Olivier Hamel wrote:

> Would it be possible some more documentation in-code? So far the only
> comments I've really found are the copyright notices and a bunch of
> artistically placed notes-to-self-this-is-what-I-did with some
> semi-cryptic (totally cryptic in worse cases, and not at all in best,
> but there are few best cases) one or two liners. Would it be possible to
> add some more explanations for those less enlightened such as myself?

That takes all the fun out of digging through old IBM tech notes
and my Knuth books for references to Brent's Algorithm for
implementing hashes....

On a more serious note, if you have some spare time you might
start reading the code before falling asleep. It will help with
falling asleep and eventually the code will comment itself.

It does eventually fall into place so that you can read it without
comments.

Ralph
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Duncan Cross
In reply to this post by Henk Boom-2
On Wed, Jun 10, 2009 at 12:40 PM, Henk Boom<[hidden email]> wrote:

> 2009/6/10 Duncan Cross <[hidden email]>:
>> On Wed, Jun 10, 2009 at 11:24 AM, Luiz Henrique de
>> Figueiredo<[hidden email]> wrote:
>>>> local tbl = {ReturnSixIncrementalValuesFromZeroToSix(), 7, 8, 9} -- this
>>>> would equate to doing {1, 2, 3, 4, 5, 6, 7, 8, 9}
>>>
>>> This is a bad idea.
>>
>> I had an idea for an explicit syntax for this, that overloads the ... operator:
>>
>> local tbl = {SixValues()..., 7, 8, 9}
>>
>> - so that, if the "..." keyword immediately follows an expression that
>> could resolve to multiple values within a comma separated list, they
>> are expanded. I can't see any way that this could be ambiguous, but I
>> haven't thought about it all that much, so maybe I am wrong. It also
>> kind of makes sense as "..." already means "accomodate a variable
>> number of values", but in this case it would mean a variable number of
>> *return* values rather than arguments.
>>
>> -Duncan
>>
>
> local tbl = {... ..., 7, 8, 9}
>
> would be a bit strange, no?
>
>    Henk
>

Er, yes. Good point.

Maybe it could expand parenthesised expressions as well, so (...)... ?
Is that not quite as bad?

-Duncan
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
In reply to this post by Henk Boom-2
Henk Boom wrote:
> local tbl = {... ..., 7, 8, 9}
>
> would be a bit strange, no?
>
>     Henk
>  
(I've just realized I wrote ReturnSixIncrementalValuesFromZeroToSix()
instead of ReturnSixIncrementalValuesFromOneToSix(), oops!)

Well, we need a way to expand and insert all the args of the cmd into a
table, it's a very useful feature IMHO, and I was bitten quite a few
times when I started working with Lua tables for the first time.
Personally I think it makes more sense for all the arguments to be pass
out, but then it makes it very hard I guess to handle cases like:

local varA, varB = FooTwoNums() + 5

Do you add five to the first or the second number? Or both? What happens
if there are more returns then there are allocations? Do we do a mass
additional on all of them SIMD style (though obviously not actual SIMD
code)? What if the type of the values aren't a number? Do we move on to
the next return value? Do we error? Or do we do nothing?

Although I guess that SIMD thing could be nifty in some cases, you know,
mass applying a set of ops on multiple values at once. If the parser
could take that into account I'm all but certain it would be possible to
do a micro-optimization at that point. Then again, the vanilla Lua
compiler isn't an optimizing compiler according to the wiki.

Olivier
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Peter Cawley
In reply to this post by Henk Boom-2
On Wed, Jun 10, 2009 at 12:40 PM, Henk Boom<[hidden email]> wrote:
> local tbl = {... ..., 7, 8, 9}
>
> would be a bit strange, no?

I don't know, I could grow to like it.

Consider the following two hypothetical code lines:

local tbl = {1, 2, 3, ..., 7, 8, 9}

local tbl = {1, 2, 3, ... ..., 7, 8, 9}

The double ellipsis can be read as a larger insertion (i.e. not just
one element) into the list than the single ellipsis.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (again, \x## notation)

Olivier Hamel
In reply to this post by Ralph Hempel
Ralph Hempel wrote:

> That takes all the fun out of digging through old IBM tech notes
> and my Knuth books for references to Brent's Algorithm for
> implementing hashes....
>
> On a more serious note, if you have some spare time you might
> start reading the code before falling asleep. It will help with
> falling asleep and eventually the code will comment itself.
>
> It does eventually fall into place so that you can read it without
> comments.
>
> Ralph

I would... not do that... I have enough problems falling asleep because
I can't stop my head from working on problems as it is. Reading and
trying to understand Lua's guts would only make things worse. But you're
right, and I will, since I can't sleep recently anyways.

Olivier
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (again, \x## notation)

Luiz Henrique de Figueiredo
In reply to this post by Ico Doornekamp
> Indeed. But you still can not do "foo\x0f\x00\x1c\xe0bar".
 
> I am still very curious to hear if the Lua developers have managed to
> form an official opinion on wether this is a feature likely to be added
> to future Lua versions ?

Yes, likely.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
In reply to this post by Duncan Cross
Duncan Cross wrote:
> Er, yes. Good point.
>
> Maybe it could expand parenthesised expressions as well, so (...)... ?
> Is that not quite as bad?
>
> -Duncan
>  
Doesn't really help, maybe a C-style typecast-ish approach?
(...)FunctionThatReturnsARidiculousNumberOfValues()

I think that looks somewhat better, what do you think?

Olivier
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Luiz Henrique de Figueiredo
In reply to this post by John Hind
> I'd vote for a '__iter' metamethod so you could provide a customised
> iterator factory for an object class. This would allow syntax:
>
> for k,v in obj do ... end

As you have noticed, you can use __call for that:

    t={10,20,name="hello",size=45}

    setmetatable(t,{
            __call = function (x,y,z) return next(x,z) end
    })

    for k,v in t do print(k,v) end

No parentheses needed.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (again, \x## notation)

Ralph Hempel
In reply to this post by Olivier Hamel
Olivier Hamel wrote:

> I would... not do that... I have enough problems falling asleep because
> I can't stop my head from working on problems as it is. Reading and
> trying to understand Lua's guts would only make things worse. But you're
> right, and I will, since I can't sleep recently anyways.

Don't take your computer to bed. Print out a few pages of Lua
source, from one file and read them. You might try starting with
some lower level routines so that you know what they do when
called by the higher level ones.

Trust me, you'll be asleep in 30 mins or less.

[OT] you can also try pzizz.com for a random soundtrack that can
      be generated on your computer and downloaded to an MP3
      player. Works like a charm

Ralph
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Duncan Cross
In reply to this post by Olivier Hamel
On Wed, Jun 10, 2009 at 12:58 PM, Olivier Hamel<[hidden email]> wrote:

> Duncan Cross wrote:
>>
>> Er, yes. Good point.
>>
>> Maybe it could expand parenthesised expressions as well, so (...)... ?
>> Is that not quite as bad?
>>
>> -Duncan
>>
>
> Doesn't really help, maybe a C-style typecast-ish approach?
> (...)FunctionThatReturnsARidiculousNumberOfValues()
>
> I think that looks somewhat better, what do you think?
>
> Olivier
>

One problem with that is that it would be odd if it didn't work with a
literal list of values (logically, I mean - there would be no actual
reason to, if you have a literal list of values you should just insert
them into the enclosing list directly), but:

(...)(a,b,c)

- already means something, it is a function call to the first value in
the vararg list, taking the parameters a,b,c.

-Duncan
Reply | Threaded
Open this post in threaded view
|

RE: Next Version of Lua? (__iter metamethod)

John Hind
In reply to this post by Luiz Henrique de Figueiredo
Could I push my luck by asking if there is a position on '__iter'? I really
cannot see any downsides of this (except of course for the usual concerns
about any change) and it does seem to offer an 'easy gain' in terms of
end-user simplification.

> -----Original Message-----
> From: [hidden email] [mailto:lua-
> [hidden email]] On Behalf Of Luiz Henrique de
> Figueiredo
> Sent: 10 June 2009 12:57
> To: Lua list
> Subject: Re: Next Version of Lua? (again, \x## notation)
>
> > Indeed. But you still can not do "foo\x0f\x00\x1c\xe0bar".
>
> > I am still very curious to hear if the Lua developers have managed to
> > form an official opinion on wether this is a feature likely to be
> added
> > to future Lua versions ?
>
> Yes, likely.

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Olivier Hamel
In reply to this post by Duncan Cross
Duncan Cross wrote:

> On Wed, Jun 10, 2009 at 12:58 PM, Olivier Hamel<[hidden email]> wrote:
>  
>> Duncan Cross wrote:
>>    
>>> Er, yes. Good point.
>>>
>>> Maybe it could expand parenthesised expressions as well, so (...)... ?
>>> Is that not quite as bad?
>>>
>>> -Duncan
>>>
>>>      
>> Doesn't really help, maybe a C-style typecast-ish approach?
>> (...)FunctionThatReturnsARidiculousNumberOfValues()
>>
>> I think that looks somewhat better, what do you think?
>>
>> Olivier
>>
>>    
>
> One problem with that is that it would be odd if it didn't work with a
> literal list of values (logically, I mean - there would be no actual
> reason to, if you have a literal list of values you should just insert
> them into the enclosing list directly), but:
>
> (...)(a,b,c)
>
> - already means something, it is a function call to the first value in
> the vararg list, taking the parameters a,b,c.
>
> -Duncan
>
>  
Ironically I thought of doing exactly that, but I decided that the extra
parentheses were excessive and didn't put them in. But now that I look
at your sample & argument I'm more then willing to accept that as a
syntax change to Lua. Seems elegant enough to me, no?

Olivier
Reply | Threaded
Open this post in threaded view
|

RE: Next Version of Lua?

John Hind
In reply to this post by Luiz Henrique de Figueiredo
I did not realise you could avoid the empty parentheses in this case,
however it is still a bodge since it precludes using "__call" for what it is
intended for. For example I have a "delegate_list" class which maintains a
list of callback functions. I use a call override to allow the object to act
as a true proxy for the functions. However this precludes also providing a
"self-iterator" and breaks the consistency of the library.

Surely it would be trivial to provide a second metamethod which worked just
like "__call" but only in the scope of the generic for statement?

> -----Original Message-----
> From: [hidden email] [mailto:lua-
> [hidden email]] On Behalf Of Luiz Henrique de
> Figueiredo
> Sent: 10 June 2009 12:59
> To: Lua list
> Subject: Re: Next Version of Lua?
>
> > I'd vote for a '__iter' metamethod so you could provide a customised
> > iterator factory for an object class. This would allow syntax:
> >
> > for k,v in obj do ... end
>
> As you have noticed, you can use __call for that:
>
>     t={10,20,name="hello",size=45}
>
>     setmetatable(t,{
>    __call = function (x,y,z) return next(x,z) end
>     })
>
>     for k,v in t do print(k,v) end
>
> No parentheses needed.

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Luiz Henrique de Figueiredo
> Surely it would be trivial to provide a second metamethod which worked just
> like "__call" but only in the scope of the generic for statement?

That's not possible with the current syntax for the generic for statement.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (__iter metamethod)

Luiz Henrique de Figueiredo
In reply to this post by John Hind
> Could I push my luck by asking if there is a position on '__iter'?

There'll be metamethods __pairs and __ipairs. See
        http://lua-users.org/wiki/LuaFiveTwo
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (__iter metamethod)

Peter Cawley
In reply to this post by Luiz Henrique de Figueiredo
On Wed, Jun 10, 2009 at 1:10 PM, John Hind<[hidden email]> wrote:
> Could I push my luck by asking if there is a position on '__iter'? I really
> cannot see any downsides of this (except of course for the usual concerns
> about any change) and it does seem to offer an 'easy gain' in terms of
> end-user simplification.

Lua 5.0 had a TFORPREP opcode, which was inserted in the bytecode
stream prior to a generic for loop. It would effectively replace "t"
with "next, t" for generic for loops over tables. This opcode was
marked as "for compatibility only" in the 5.0 sources, and is
completely removed in 5.1, so adding something similar back in for 5.2
would seem unlikely.

The 5.1 documentation lists the following as psuedo-code for a generic for loop:
do
  local f, s, var = explist
  while true do
    local var_1, ···, var_n = f(s, var)
    var = var_1
    if var == nil then break end
    block
  end
end

The 5.0 behaviour was something more akin to:
do
  local f, s, var = explist
  if type(f) == "table" then f, s = _G.next, f end
  while true do
    local var_1, ···, var_n = f(s, var)
    var = var_1
    if var == nil then break end
    block
  end
end

Your proposed behaviour would be similar to:
do
  local f, s, var = explist
  local mt = getmetatable(f)
  if mt and mt.__iter then f, s, var = mt.__iter(f) end
  while true do
    local var_1, ···, var_n = f(s, var)
    var = var_1
    if var == nil then break end
    block
  end
end

To some people, the 5.0 behaviour and proposed behaviour make a for
loop less readable rather than more readable. With the 5.1 behaviour,
it is simple to see what the iterator function, iterator state and
initial variable will be when reading a for loop. With other
behaviour, you cannot tell what they will be, as what looks like the
iterator function may turn out to be an object with an __iter
metamethod which supplies the iterator function, iterator state and
initial variable.

>From a performance point of view, the proposed behaviour would add an
extra bytecode instruction to each generic for loop, even for those
which don't go on to use __iter. It also adds another opcode to the
VM's central switch statement, and a small central switch statement is
a nice thing.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Henk Boom-2
In reply to this post by Duncan Cross
2009/6/10 Duncan Cross <[hidden email]>:
> Er, yes. Good point.
>
> Maybe it could expand parenthesised expressions as well, so (...)... ?
> Is that not quite as bad?

In all other contexts parentheses have the effect of discarding all
but the first value, so this seems counter-intuitive IMO.

    Henk
12345 ... 8