Next Version of Lua?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
143 messages Options
12345678
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Enrico Colombini
Asko Kauppi wrote:
> It is curious that the number of times I have missed 'continue' exceeds
> the number of times I've needed 'repeat' (which is 0).

Just to level out the average value of 'continue' users, I've never used
it in any language :-)
(though I'll concede that not using 'continue' in a relatively slow
language may have a performance cost)

   Enrico
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Petite Abeille

On Jun 10, 2009, at 8:38 PM, Enrico Colombini wrote:

> Just to level out the average value of 'continue' users, I've never  
> used it in any language :-)

Will add my voice to the "doesn't continue" camp :))

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Jorge Visca
In reply to this post by Asko Kauppi
On Wed, 2009-06-10 at 21:16 +0300, Asko Kauppi wrote:
> It is curious that the number of times I have missed 'continue'  
> exceeds the number of times I've needed 'repeat' (which is 0).
>
> But that's just me. :)

Conversely, i had to write some stuff in python and felt filthy. In my
first programming course (in Pascal) if you used the wrong loop
structure (like a repeat for a for or a while for a repeat) they would
hit your forehead with a ruler. Then you'd yell "but it works!" and they
would hit you again :)
And then there was that secret 4 letter word that would cause a
lightning bolt to incinerate you if only pronounced!

Jorge
 

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Peter Cawley
In reply to this post by Roberto Ierusalimschy
On Wed, Jun 10, 2009 at 7:03 PM, Roberto
Ierusalimschy<[hidden email]> wrote:
> Any comment about this?
>
>  http://lua-users.org/lists/lua-l/2005-09/msg00548.html
>

It appears that the options are the following:

1) Do not support "continue" anywhere.
2) Disallow "continue" within a repeat ... until construct. Next issue
being when a repeat ... until is nested within a for loop, and a
"continue" appears within the repeat ... until construct, is this
invalid behaviour, or does the "continue" apply to the for loop?
3) Have the parser detect if a "continue" statement causes execution
to jump over a local variable declaration, which is then used in the
"until" clause, and throw an error in this case.
4) Have the parser detect if a "continue" statement causes execution
to jump over a local variable declaration, and cause the "continue" to
initialise any variables which it jumps over to nil.
5) A "continue" within a repeat ... until construct causes execution
to jump back to the statement immediately following the "repeat", thus
skipping the "until" clause entirely.

If option 3 could be implemented efficiently, then would it be an
acceptable way of doing things?
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Phoenix Sol
In reply to this post by Enrico Colombini
I'm accustomed to using 'continue' in Python. I haven't written much Lua yet, but I approach it with the expectation of adapting to it's idioms. If it's problematic, and the wizards say it isn't necessary, then I think I'm happy to adapt to life without it.

I really dig Lua's sparse lexis.

Phoenix Sol
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Joshua Jensen
In reply to this post by Peter Cawley
----- Original Message -----
From: Peter Cawley
Date: 6/10/2009 12:45 PM
On Wed, Jun 10, 2009 at 7:03 PM, Roberto
Ierusalimschy[hidden email] wrote:
  
Any comment about this?

 http://lua-users.org/lists/lua-l/2005-09/msg00548.html
    
It appears that the options are the following:

3) Have the parser detect if a "continue" statement causes execution
to jump over a local variable declaration, which is then used in the
"until" clause, and throw an error in this case.

If option 3 could be implemented efficiently, then would it be an
acceptable way of doing things?
  
I was in the process of writing your #3 when your mail came in.  I think that is the best approach.

Josh
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Evan DeMond
In reply to this post by Phoenix Sol
On Wed, Jun 10, 2009 at 2:52 PM, Phoenix Sol <[hidden email]> wrote:
I'm accustomed to using 'continue' in Python. I haven't written much Lua yet, but I approach it with the expectation of adapting to it's idioms. If it's problematic, and the wizards say it isn't necessary, then I think I'm happy to adapt to life without it.

I really dig Lua's sparse lexis.

Phoenix Sol

Second the "when in Rome" approach. I use "continue" often in my C/C++/C# code, but can't say that I've missed it yet in Lua.

I dig Lua's sparse lexis too (nice phrase) but I don't think "continue" would complicate the language much; most programmers already know it. So that isn't my main worry -- I think the focus should be keeping Lua implementations lithe. If "continue" spells any trouble for implementors, maybe it's best to go without it.

Evan
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (continue)

Richard Hundt
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:

>> Every person I train in Lua asks me why 'continue' doesn't work.  I show  
>> them the "equivalent", and it never meets with any kind of satisfaction.
>>
>> [...]
>>
>> I'm in the camp where I see a real need for it in Lua, not only for  
>> clarity, but because it is a very useful loop construct that anyone  
>> coming from another popular (scripting) language will expect to be able  
>> to use.
>
> Any comment about this?
>
>   http://lua-users.org/lists/lua-l/2005-09/msg00548.html
>
> -- Roberto
>

My expectations are that the difference between the `repeat' and `while'
loop constructs should simply be that `repeat' evaluates is block before
testing the condition, whereas `while' does the inverse. I find it
surprising that the variable in the `until' condition is inside the
scope of the loop block.

So my vote would be to add `continue', but hoist the scope of the
`until' condition outside the block to make it behave like `while'.

My tuppence.

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

RE: Next Version of Lua?

Mark Hamburg
In reply to this post by Olivier Hamel
Following up on my earlier post, having to write:

    for v in iter( ... ) do
        -- process varargs
    end

Actually defeats some of the point since it must necessarily allocate storage proportional to the varargs since I might just as easily write:

    SomeGlobal = iter( ... )

(The point to "for v in ..." being to avoid that allocation and just use the existing values on the stack.)

Still it would be good to provide better support for ... in more contexts barring conflicts with existing syntax so that the quadratic tendencies of select could be minimized. One can do some of that now -- e.g., there's nothing stopping one from writing a version of iter -- but it would be good to standardize the mechanisms.

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Sam Roberts
In reply to this post by Petite Abeille
On Wed, Jun 10, 2009 at 11:43 AM, Petite
Abeille<[hidden email]> wrote:
>
> On Jun 10, 2009, at 8:38 PM, Enrico Colombini wrote:
>
>> Just to level out the average value of 'continue' users, I've never used
>> it in any language :-)
>
> Will add my voice to the "doesn't continue" camp :))

I use continue a lot in C, and never use repeat..until or do...while.

Sam
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Javier Guerra Giraldez
On Wed, Jun 10, 2009 at 3:21 PM, Sam Roberts<[hidden email]> wrote:
> I use continue a lot in C, and never use repeat..until or do...while.

same here.

of course the 'correct' lexical scoping in Lua (as different from
'almost' lexical like Python or JS) makes defining extra code blocks
not as ugly as it's on other languages.  so, wrapping the 'skipped
over' block in a proper block is ok in Lua, ugly in C / Python.

IOW, i'd like to have continue, but not at the expense of special cases.

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

Re: Next Version of Lua?

Duncan Cross
In reply to this post by Roberto Ierusalimschy
On Wed, Jun 10, 2009 at 7:03 PM, Roberto
Ierusalimschy<[hidden email]> wrote:

>> Every person I train in Lua asks me why 'continue' doesn't work.  I show
>> them the "equivalent", and it never meets with any kind of satisfaction.
>>
>> [...]
>>
>> I'm in the camp where I see a real need for it in Lua, not only for
>> clarity, but because it is a very useful loop construct that anyone
>> coming from another popular (scripting) language will expect to be able
>> to use.
>
> Any comment about this?
>
>  http://lua-users.org/lists/lua-l/2005-09/msg00548.html
>
> -- Roberto
>

Personally, I would happily go so far as sacrificing the
until-expression-inside-loop scope rule so that continue could be
added, and that's as someone who does use repeat/until loops and can
see the benefit of this scoping rule. (Raising a parse error if and
only if the problem is encountered is better still, of course.)

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

Re[2]: Next Version of Lua?

Alen Ladavac
In reply to this post by Roberto Ierusalimschy
Wednesday, June 10, 2009, 8:03:41 PM, Roberto wrote:
> Any comment about this?
>   http://lua-users.org/lists/lua-l/2005-09/msg00548.html

My take on that is that the scoping of repeat-until is non-orthogonal
to other blocks. Which in my opinion is a much less of a convenience
than having continue statement. If locals wouldn't leak outside of the
inner block or repeat-until, the example from that post would be a
non-issue. It would be detected by the compiler with no additional
code. But I see other people have already noticed this before I
managed to write it down.

Btw, if I may notice something... when discussing whether continue can
be easily simulated, the main poster-child is a plain "for" loop with
"continue" at a top-level "if", which is easily (albeit a bit ugly)
replaced with conditional for the rest of the loop. In reality I see
most needs for a continue in deeper levels of widely and deeply
branched if statements, where it is not possible to simulate it that
way. This leads to very complicated workarounds.

JM2C,
Alen
















Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

David Given
In reply to this post by Duncan Cross
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan Cross wrote:
[...]
> Personally, I would happily go so far as sacrificing the
> until-expression-inside-loop scope rule so that continue could be
> added, and that's as someone who does use repeat/until loops and can
> see the benefit of this scoping rule. (Raising a parse error if and
> only if the problem is encountered is better still, of course.)

I'm with this as well; I find the new until scope counterintuitive. And
I do miss continue.

May I also put in a plea (which I know will be ignored) for arbitrary
goto? Yes it's ugly, yes it's unreadable, yes it's abused, yes there is
nearly always some way around it, but for that tiny corner case where
there *isn't* a way around it it is utterly invaluable. I don't care how
messy or unsafe it is, and am perfectly happy to have jumps over local
statements produce variables full of garbage.

goto is particularly handy for implementing complex state machines;
these particularly tend to be machine generated, so readability isn't a
problem (and adding the logic to decompose the block graph into
traditional call graphs is astonishingly non-trivial and, I believe,
downright impossible in places).

And lastly I also refer you to Flon's Axiom:

  There does not now, nor will there ever, exist a programming language
  in which it is the least bit hard to write bad programs.

- --
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────

│ "People who think they know everything really annoy those of us who
│ know we don't." --- Bjarne Stroustrup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKMDQHf9E0noFvlzgRAkV+AKCKVYlUp+29ExZ/IjMovDjwS80q6ACgm+6s
Ljf78c/RNwm3RXRn/SatoXs=
=mxwB
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Robert Raschke

On Wed, Jun 10, 2009 at 11:30 PM, David Given <[hidden email]> wrote:

goto is particularly handy for implementing complex state machines;
these particularly tend to be machine generated, so readability isn't a
problem (and adding the logic to decompose the block graph into
traditional call graphs is astonishingly non-trivial and, I believe,
downright impossible in places).


If I remember correctly, Lua optimises tail calls. In my experience, using tail calls for state transitions is way easier to understand and code than using goto's. But YMMV, I guess.

Or is your problem, that you've already got lots of machine generated goto-state machines that you'd like to "translate" to Lua?

Robby

Reply | Threaded
Open this post in threaded view
|

RE: Next Version of Lua? (__iter metamethod)

John Hind
In reply to this post by Sam Roberts
I understand that pairs and ipairs is necessary because of the dual nature
of the table type and I am not proposing this should change. But basic Lua
is not object oriented, metatables are a facility to let users add object
orientation. I often use tables in the way you describe too - it is great to
be able to make a table which is its own invert for example. But I cannot
see why (in an object oriented system) you'd want to support both types of
iteration on the same object.

In any case if you want to have "__pairs" and "__ipairs" you can easily do
that yourself - it does not have to be part of the language. "__iter" is a
feature that would have to be part of the basic language definition. Wanting
to re-implement the table data type using userdata seems like a very
minority interest to be decisive in language design compared to ordinary
object oriented design, particularly when it is already possible (easy) to
do this with the current design!

> -----Original Message-----
> From: [hidden email] [mailto:lua-
> [hidden email]] On Behalf Of Sam Roberts
> Sent: 10 June 2009 19:11
> To: Lua list
> Subject: Re: Next Version of Lua? (__iter metamethod)
>
> On Wed, Jun 10, 2009 at 7:41 AM, John Hind<[hidden email]> wrote:
> > Looking at it fundamentally, any object that implements collection
> semantics
> > benefits from iterator functionality. "pairs" is appropriate for
> > dictionary-like collections (whether implemented using tables or
> otherwise)
> > while "ipairs" is appropriate for "list" or "array" like collections
> > (whether implemented using tables or otherwise). With basic Lua
> whether a
> > table is "dictionary-like" or "list-like" is about how you assign the
> keys,
>
> Its not an "or". Its a fairly common lua design idiom for tables to be
> BOTH dictionary-like and list-like.
>
> I've never used another language like this, so
> maybe its unusual, but its fundamental to the flavour of the language,
> and
> used to good effect.
>
> I've built tree-like structures where ipairs() is used to iterate the
> children, and string keys are used for annotations on the node (and
> pairs is used to iterate all keys). There's an example like this in
> _Programming in Lua_, but I can't find it, sorry.
>
> Anyhow, the __pairs and __ipairs allows userdata to be first-class
> citizens, closer to full table-like functionality, not just limited to
> "array EXCLUSIVE-OR dictionary", and a single iteration strategy.
>
> > but with true object orientation (using metatables) you will usually
> decide
> > the structure of the table in the class design. OK sometimes an
> object
>
> Userdata are not required to be used as part of an O-O class design,
> though they can be. Lua is multi-paradigm.
>
> Cheers,
> Sam

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Niklas Frykholm
In reply to this post by Asko Kauppi
Yes, that would work and wouldn't be too tricky. The drawback is that
you would have to increase the size of the Value union to have room
for the biggest value type you wanted to support. Support for Vector3
would triple the size of Value and double the size of TValue. Which
would mean close to doubling the memory footprint of a running lua
application.

I'm targetting game consoles, where increasing the script memory from
30 MB to 50 MB or even 40 MB is a big deal... so I can't really go
that path.

// Niklas

2009/6/10 Asko Kauppi <[hidden email]>:

> About the complex type, LNUM patch allows all Lua numbers to be complex
> (compile with LNUM_COMPLEX defined; C99 required for C complex support).
>
> The approach could of course be extended to making a native 3D vector
> datatype, as well.
>
> -asko
>
>
> Niklas Frykholm kirjoitti 10.6.2009 kello 17:42:
>
>> 2009/6/10 Duncan Cross <[hidden email]>:
>>>
>>> On Wed, Jun 10, 2009 at 2:55 PM, Niklas Frykholm<[hidden email]>
>>> wrote:
>>>>
>>>> 2009/6/10 Olivier Hamel <[hidden email]>:
>>>> Currently, if you want to create Complex or Vector3 type you have to
>>>> do it as a table or a userdata. And if you do a serious ammount of
>>>> processing on them, the ammount of garbage generated by simple
>>>> arithmetic operations will soon put a significant strain on the
>>>> system. (You could use a pool of such objects, but that would mean
>>>> resorting to manual memory management with all its pains - especially
>>>> when you are using it for something as simple as numbers.)
>>>
>>> Perhaps I am misunderstanding, but if the pool is a table that has
>>> been set to have weak values (i.e. its metatable's __mode field is set
>>> to 'v'), you should not have to do any manual memory management -
>>> values that only exist in the pool will be eligible for garbage
>>> collection.
>>
>> My description was a bit short, but the whole point of having a pool
>> was to avoid generating garbage. (By using a free object from the
>> pool, rather than creating a new one, whenever a new object is
>> needed.) But this requires us to manually track which objects in the
>> pool are free or not (i.e., manual memory management).
>>
>> If the objects in the pool are eligible for garbage collection, then
>> the pool doesn't really buy us anything. We will generate the same
>> ammount of garbage with the pool as without it.
>>
>> // Niklas
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

David Given
In reply to this post by Robert Raschke
Robert Raschke wrote:
[...]
> If I remember correctly, Lua optimises tail calls. In my experience,
> using tail calls for state transitions is way easier to understand and
> code than using goto's. But YMMV, I guess.

Tail calls don't let you easily share state using local variables ---
you either have to pass all your state in using parameters, or else put
the whole thing inside a bigger function and use upvalues. Either way,
it's significantly more heavyweight. Still fast (I posted some
benchmarks a little while ago), but considerably less so than a simple
jump from one bytecode location to another.

> Or is your problem, that you've already got lots of machine generated
> goto-state machines that you'd like to "translate" to Lua?

This is my major use case, yes, but it'd also be useful in other places.
Consider this --- most languages provide some sanitised goto to handle
doing this sort of thing:

while a do
   while b do
     while c do
       while d do
         if abort() then
           goto exitloopc
         endif
       end
     end
     exitloopc:
   end
end

--
David Given
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Philippe Lhoste
In reply to this post by Sam Roberts
On 10/06/2009 22:21, Sam Roberts wrote:
> I use continue a lot in C, and never use repeat..until or do...while.

Perhaps I am abnormal, but I use both continue and do ... while (or repeat ... until) in
languages that allow them. Not necessarily together...

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Philippe Lhoste
In reply to this post by Asko Kauppi
On 10/06/2009 19:47, Asko Kauppi wrote:
> Personally, I am of the opinion that bitops are for enums and not for
> numbers.

Why?
Indeed, they are useful to combine flags (DS_MODALFRAME | DS_3DLOOK | DS_FIXEDSYS |
WS_POPUP | WS_CAPTION | WS_SYSMENU) but also to get R, G, B, A components out of a RGBA
number and to parse some binary file formats, for small bit maps, and so on.

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --
12345678