new thought experiment: what would you add to Lua ?

classic Classic list List threaded Threaded
45 messages Options
123
Jim
Reply | Threaded
Open this post in threaded view
|

new thought experiment: what would you add to Lua ?

Jim
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).

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> 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

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
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.

Reply | Threaded
Open this post in threaded view
|

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

Sean Conner
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

Reply | Threaded
Open this post in threaded view
|

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

Sean Conner
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


Reply | Threaded
Open this post in threaded view
|

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

michaelflad
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.


Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-3
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

Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-3
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





Reply | Threaded
Open this post in threaded view
|

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

nobody
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

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
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

Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-3
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
>
>


Reply | Threaded
Open this post in threaded view
|

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

John Hind
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.


Reply | Threaded
Open this post in threaded view
|

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

Alysson Cunha
try-catch and try-finally language sugars for pcall to simplify error handling

Em 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.


Reply | Threaded
Open this post in threaded view
|

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

Peter Hickman-3
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 handling

This 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 quickly

A 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 light

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 pcalled

Otherwise it's still a wonderful language

Reply | Threaded
Open this post in threaded view
|

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

Sam Putman


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 handling

This 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 quickly

A 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 light


This can be adequately faked:

-- try
local success, err = pcall(function()
    -- your chunk goes here
end)
-- catch
if not success then
   -- do stuff with err
end
-- 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 pcalled

Otherwise it's still a wonderful language

Reply | Threaded
Open this post in threaded view
|

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

Peter Hickman-3
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 experience

Thanks

Jim
Reply | Threaded
Open this post in threaded view
|

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

Jim
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.

Reply | Threaded
Open this post in threaded view
|

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

Frank Kastenholz-2
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



Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
>>>>> "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.

Reply | Threaded
Open this post in threaded view
|

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

John Hind
In reply to this post by Jim
>From: Andrew Gierth <[hidden email]>
>Subject: Re: Fwd: Re: new thought experiment: what would you add to
> Lua ?
>To: Richard Green <[hidden email]>
>Cc: [hidden email]
>Message-ID: <[hidden email]>
>Content-Type: text/plain; charset=utf-8
>
>>>>>>"Richard" == Richard Green <[hidden email]> writes:
>
>Richard> 2) Sets -- In page 15 of /Programming in Lua, third edition/
>Richard> you state, "We use tables to represent ordinary arrays,
>Richard> *sets*, records, and ...".  The one thing that I miss from
>Richard> Pascal in modern programming languages is Pascal's set,
>Richard> especially inside an if statement.
>
>A "set" in Lua is simply a table where the keys are the members of the
>set and the values are not significant (any true value will do).
>
>current_month = 'Sep'
>summer_months = { Jun = true, Jul = true, Aug = true }
>if summer_months[current_month] then
>  -- stuff
>end
>
>--
>Andrew.
>
A neat addition to support this (again I have a Powerpatch on the Lua
User WiKi) is to make value default to boolean true in table
constructors. Then you can write:

summer_months = {['Jun']; ['Jul']; ['Aug']}

Due to the need to distinguish keys from values, this does not save much
typing, but it does give 'parity of esteem' to sets with the existing
implementation of lists and maybe makes the intent a bit clearer.

>


123