# new thought experiment: what would you add to Lua ?

45 messages
123
Open this post in threaded view
|

## new thought experiment: what would you add to Lua ?

 i would add support for binary and octal integer literals like 0b1001011 or 0o0755 as in Python and Ruby. octal integer literals are helpful when working with unix (file) modes/permissions (which i do frequently).
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 > i would add support for binary and octal integer literals like > 0b1001011 or 0o0755 as in Python and Ruby. > > octal integer literals are helpful when working with unix (file) > modes/permissions (which i do frequently).   function Oo(x) return tonumber(x, 8) end   function Ob(x) return tonumber(x, 2) end   print(Ob"1001011")              --> 75   print(Oo"0755")                 --> 493 :-) -- Roberto
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by Jim Ternary (conditional) operator. Using (x and y or z) has become an idiom, which shows the real demand for such a feature, but the fact that it breaks when y is false or nil makes for a lot of landmines. Something like #... to return the number of varargs without needing to pass them all to another function as in select('#',...). -- Andrew.
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by Jim It was thus said that the Great Jim once stated: > i would add support for binary and octal integer literals like > 0b1001011 or 0o0755 as in Python and Ruby. > > octal integer literals are helpful when working with unix (file) > modes/permissions (which i do frequently).   I would not object to this, but what I would like to add is '_' to literal numbers to aid in comprehension.  Some examples:         x = 4_294_967_295         y = 0xABCD_1234         z = 0b_110_1_0010_1010_01_11   -spc
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by Andrew Gierth It was thus said that the Great Andrew Gierth once stated: > Something like #... to return the number of varargs without needing to > pass them all to another function as in select('#',...).   +1.  And ...[i] to reference them.  Example:         function foo(...)           for i = 1 , #... do             print(i,...[i])           end         end or even         function foo(...)           for i,v in ipairs(...) do             print(i,v)           end         end   Although I think that last one might be difficult to pull off.   -spc
Open this post in threaded view
|

## AW: new thought experiment: what would you add to Lua ?

 In reply to this post by Jim > -----Ursprüngliche Nachricht----- > Von: [hidden email] <[hidden email]> Im Auftrag > von Jim > Gesendet: Freitag, 14. September 2018 21:57 > An: Lua mailing list <[hidden email]> > Betreff: new thought experiment: what would you add to Lua ? > > i would add support for binary and octal integer literals like > 0b1001011 or 0o0755 as in Python and Ruby. > > octal integer literals are helpful when working with unix (file) > modes/permissions (which i do frequently). I know, it's actually not really a langauge feature, but I'd like to say that one of the extremely few things I miss in Lua is an integrated preprocessor to be able to completely remove parts of the code during compilation so it does not create any runtime cost at all. Hardware these days is so fast, it's even quite possible to write reasonably complex games using Lua. But many games (and of course all kinds of other software, but I'm a game developer) have some kind of time critical inner loops where a single function call or a few if/elses are a real burden on the overall performance. F.i. during the last 2 weeks I primarily optimized the maphandling/rendering/sorting of the iso city builder I'm working on, and did so using some reasonably complex implementations where I just need to do lots of stuff per tile for all visible tiles per frame. Especially during optimization, as I rely on some hairy edge cases, I added assertions all over the place, but at some point it's just required to remove/comment them all out as it's simply not an option to not remove them (it's ok to develop new features with small datasets, so performance is not an issue, but with actual realworld data, it is). Of course I can just use any generic preprocessor but this makes things much more complex and even more so, if you're using a premade engine/framework with integrated editors. Also if it's not a standard, it won't be supported by any code editor and will result in all kinds of "problems" caused by the syntax highlighting, autocomplete etc. functionality.
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by Sean Conner On 15/09/2018 02:00, Sean Conner wrote: > It was thus said that the Great Jim once stated: >> i would add support for binary and octal integer literals like >> 0b1001011 or 0o0755 as in Python and Ruby. >> >> octal integer literals are helpful when working with unix (file) >> modes/permissions (which i do frequently). > >   I would not object to this, but what I would like to add is '_' to literal > numbers to aid in comprehension.  Some examples: Yep! This is really something I miss among low-level stuff. I implemented (repeatedly :-) some functions that handle that, together with handling binary numbers (answering to Roberto here), but I find them too "hackish", i.e. they work well for my codebase, but other people may use their own variation and interoperability becomes a nightmare. I think something so basic should be in the bare language. Probably it doesn't even add much weight to the parser. (Not a problem for me now - I'm just wearing my old and dusty professional dev hat :-) > > x = 4_294_967_295 > y = 0xABCD_1234 > z = 0b_110_1_0010_1010_01_11 > >   -spc > > Cheers! -- Lorenzo
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by Andrew Gierth On 15/09/2018 01:00, Andrew Gierth wrote: > Ternary (conditional) operator. Using (x and y or z) has become an > idiom, which shows the real demand for such a feature, but the fact that > it breaks when y is false or nil makes for a lot of landmines. I don't find it so problematic, but I agree that newbies could trip on that. Adding that specific feature could be against the minimalistic nature of Lua (too much restricted a use case). But maybe a more general expression-like construct could be generally useful (dumb syntax below, warning! Just to get the point): x = if (value) then exp1, exp2, ... expN; (I know it is not valid syntax) or maybe: x = ? value : exp1, exp2, ... expN  (shorter but probably more confused) It's semantically like "select", but not a function call, so amenable to more optimization. And moreover is more explicit. > > Something like #... to return the number of varargs without needing to > pass them all to another function as in select('#',...). > Yep!!! This was a pet peeve of mine for ages. I generally hate `select` (but I love its functionalities). And I love varargs: if used with a grain of salt they make the code flexible and still readable. Maybe #@ to indicate the number of varargs and @[i] the i-th vararg ("@" can be read as an "A"/"at", so it makes sense). Unfortunately, I think I remember Roberto "hates" varargs and he wanted to get rid of them. So this "select as operator" has few chances to see the light (I'm still hoping he changes his mind, maybe if people on the list come up with a nice syntax with general application - maybe with expanded semantics... :-) Maybe the two features before could be merged: make "@" a "select" operator, then: x = @[i](exp1, exp2, ...., expN) is the i-th expression in the list x = @[condition](false_expr, true_expr) is like a ternary operator (unintuitive the order of the results, though) This could allow use of varargs like this: x = @[i](...) n = @#(...) number of elements in the list But all this starts to seem like t-uples are added to the language, but Roberto don't like this either (IIRC). Maybe everything could be simplified if Lua provided a way to "declare" fixed-length array tables, so that: {...} could be optimized and "#" could be made return exactly the number of elements ("holes" included) and normal table access with "[i]" would do the rest. But now I'm just rambling. :-) Cheers! --Lorenzo
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by Lorenzo Donati-3 On 2018-09-15 10:18, Lorenzo Donati wrote: > On 15/09/2018 02:00, Sean Conner wrote: >> It was thus said that the Great Jim once stated: >>> i would add support for binary and octal integer literals like >>> 0b1001011 or 0o0755 as in Python and Ruby. >>> >>> octal integer literals are helpful when working with unix (file) >>>  modes/permissions (which i do frequently). >> >> I would not object to this, but what I would like to add is '_' to >> literal numbers to aid in comprehension.  Some examples: > > Yep! This is really something I miss among low-level stuff. Yip yip yip! ^^ Underscores in number literals kill most of the accidental off-by-(power of \$base) typos. > I implemented (repeatedly :-) some functions that handle that, > together with handling binary numbers (answering to Roberto here), > but I find them too "hackish", i.e. they work well for my codebase, > but other people may use their own variation and interoperability > becomes a nightmare. Problem with those (I use them too…) is that they don't get the compile time evaluation treatment that plain literals get.  Which means you get to choose between fast XOR readable, which is always a bad pairing… (Guess what I'll usually choose… =/) > I think something so basic should be in the bare language. Probably > it doesn't even add much weight to the parser. (Not a problem for me > now - I'm just wearing my old and dusty professional dev hat :-) IIRC you don't need to touch the parser at all, just the lexer. -- nobody
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by michaelflad > Especially during optimization, as I rely on some hairy edge cases, I added assertions all over the place, but at some point it's just required to remove/comment them all out as it's simply not an option to not remove them One of the examples in my ltokenp, a token processor for Lua, is for removing assertions: http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#ltokenp
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by nobody On 15/09/2018 11:03, nobody wrote: [...] > > IIRC you don't need to touch the parser at all, just the lexer. For the underscore thing, I agree. For supporting literals in other bases I think you need to modify the parser. Anyway I don't know the internals of Lua too much, so mine is just an educated guess. > > -- nobody > >
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by Jim At risk of the ire of the old-timers, I'll try bouncing my enhanced generic 'for' powerpatch again. The Lua Users WiKi now has a full implementation with both code and documentation patches and I have been using it myself for years now. In summary, at present a function is expected after 'for', followed by two optional state variables, conventionally supplied by a call to 'pairs' (or to the 'ipairs' bloat alternative), but you can also write your own either on the 'pairs' pattern or as a direct iterator function which stores its state in upvalues. My patch provides fallback behaviour if presented with a non-function and no further variables. First it looks for a metamethod '_iter' and failing that it uses an internal implementation of 'pairs'. This enables iteration of objects directly. The 'iter' metamethod allows supply of a default iteration method for tables and userdata used to implement the OO paradigm while the 'pairs' substitute enables quick and easy iteration of anything that can be iterated which always works regardless of any messing about with the globals (particularly useful in debugging). With this change, we support a simpler alternative construct which is more intuitive and familiar from other languages: 'for my_item in my_collection do print(my_item) end' whilst preserving Lua's more sophisticated and extensible multi-iterator capability. To those who object on 'bloat' grounds, combine with removal of 'ipairs' and the 'pairs' and 'ipairs' metamethods and you actually have a simplification both conceptually and in implementation. In all the years I've been pushing this change, I've never seen a convincing objection.
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 try-catch and try-finally language sugars for pcall to simplify error handlingEm Sáb, 15 de set de 2018 07:54, John Hind <[hidden email]> escreveu:At risk of the ire of the old-timers, I'll try bouncing my enhanced generic 'for' powerpatch again. The Lua Users WiKi now has a full implementation with both code and documentation patches and I have been using it myself for years now. In summary, at present a function is expected after 'for', followed by two optional state variables, conventionally supplied by a call to 'pairs' (or to the 'ipairs' bloat alternative), but you can also write your own either on the 'pairs' pattern or as a direct iterator function which stores its state in upvalues. My patch provides fallback behaviour if presented with a non-function and no further variables. First it looks for a metamethod '_iter' and failing that it uses an internal implementation of 'pairs'. This enables iteration of objects directly. The 'iter' metamethod allows supply of a default iteration method for tables and userdata used to implement the OO paradigm while the 'pairs' substitute enables quick and easy iteration of anything that can be iterated which always works regardless of any messing about with the globals (particularly useful in debugging). With this change, we support a simpler alternative construct which is more intuitive and familiar from other languages: 'for my_item in my_collection do print(my_item) end' whilst preserving Lua's more sophisticated and extensible multi-iterator capability. To those who object on 'bloat' grounds, combine with removal of 'ipairs' and the 'pairs' and 'ipairs' metamethods and you actually have a simplification both conceptually and in implementation. In all the years I've been pushing this change, I've never seen a convincing objection.
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 On Sat, 15 Sep 2018 at 11:58, Alysson Cunha <[hidden email]> wrote:try-catch and try-finally language sugars for pcall to simplify error handlingThis is the one thing that would make things much easier for me. I know we should wrap things in pcall incase they fail but there are so many things that *could* fail the resulting code becomes unreadable very quicklyA few judicious try-catch blocks can provide much robustness without obscuring the code. I tend to write code in a more iterative fashion with a few large scoped try-catch blocks (or begin-rescue-end as I'm actually a Ruby programmer) until the part of the code that is fragile comes to lightI understand that this may be more a case of "trying to write Ruby in Lua" but I miss this more I miss OOP. I have no problem with Lua not being an OOP language, it's easy to adapt to. But catching errors seems to require chopping up the code in unnatural ways so that it can be stuffed into a function that can be pcalledOtherwise it's still a wonderful language
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 On Sat, Sep 15, 2018 at 3:00 PM Peter Hickman <[hidden email]> wrote:On Sat, 15 Sep 2018 at 11:58, Alysson Cunha <[hidden email]> wrote:try-catch and try-finally language sugars for pcall to simplify error handlingThis is the one thing that would make things much easier for me. I know we should wrap things in pcall incase they fail but there are so many things that *could* fail the resulting code becomes unreadable very quicklyA few judicious try-catch blocks can provide much robustness without obscuring the code. I tend to write code in a more iterative fashion with a few large scoped try-catch blocks (or begin-rescue-end as I'm actually a Ruby programmer) until the part of the code that is fragile comes to lightThis can be adequately faked:-- trylocal success, err = pcall(function()    -- your chunk goes hereend)-- catchif not success then   -- do stuff with errend-- finally I understand that this may be more a case of "trying to write Ruby in Lua" but I miss this more I miss OOP. I have no problem with Lua not being an OOP language, it's easy to adapt to. But catching errors seems to require chopping up the code in unnatural ways so that it can be stuffed into a function that can be pcalledOtherwise it's still a wonderful language
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 On Sat, 15 Sep 2018 at 14:40, Sam Putman <[hidden email]> wrote:This can be adequately faked:I am such an idiot, I completely forgot about anonymous functions :(Ah well, life is a learning experienceThanks
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by Roberto Ierusalimschy On Fri, Sep 14, 2018 at 10:22 PM, Roberto Ierusalimschy <[hidden email]> wrote: >   function Oo(x) return tonumber(x, 8) end >   function Ob(x) return tonumber(x, 2) end yes, i know that tonumber() can be used for this. i also added a c function to my library that parses a given string arg (containing an octal integer literal) with sscanf() (btw: what is more efficient: tonumber or the c function approach ?). but there should be direct support for those integer literals by the language itself, as is usual in other languages. this would also be more efficient as it does not need a string to hold an integer literal and saves the function call to convert this very string to an integer which seems highly inefficient to me. do c or fortran handle that situation the same way ? given the case that the literal is illegal, direct language support would detect it at compile time, while the string converting approach would only detect it at runtime. omiiting integers (and direct bit operations) and using floats exclusively was also no good design decision, especially for cpus that lack a fpu.
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 In reply to this post by Jim First, it seems to me that Lua is really complete - I can do anything/everything I want.  So i don’t see anything as missing (in the sense of “I can not write a program to do X because Lua just doesn’t do Y” That said, there are a lot of things that could be done as conveniences to the programmer, maybe making the code more concise, cleaner, easier to read, etc. several have been mentioned. One that i would like is a more concise way to append to a list.  Instead of “list[#list+1]=...” how about something like “list[++]=...”? os.setenv, as a counterpart to os.getenv? I like the idea that someone else posted about a preprocessor I also like the idea of a switch statement (maybe taking bash’s notion of patterns in the cases :-) But none really are critical (to me) Thanks Frank
Open this post in threaded view
|

## Re: new thought experiment: what would you add to Lua ?

 >>>>> "Frank" == Frank Kastenholz <[hidden email]> writes:  Frank> os.setenv, as a counterpart to os.getenv? There's a reason for that not to exist - getenv() is part of ISO C, but there is no standard C function to _set_ environment vars, because that is platform-dependent territory. -- Andrew.