Desired Lua Features

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

Desired Lua Features

Paige DePol
Dibyendu recently started a discussion about wether or not Lua has reached
perfection. Of course, this will be a subject highly dependant on the need
and opinions of each user of Lua.

On that same discussion topic the desire for a switch/case like construct
in Lua came up... so I thought I would start a new discussion thread to
see what features people would like to see added to vanilla Lua.

So, if you could add any one feature to Lua right now, what would that
feature be and why would you want to see it added? Please note that this
discussion is in no way meant to be interpreted as pressuring Team Lua to
add any features to Lua, I am genuinely curious what features people want
to see added to Lua and why.

My interest in this subject isn't just academic, however, I may take some
of these ideas on board to add to my hard fork of Lua. If so, I would also
create patches for vanilla Lua as well! :)

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

KHMan
On 1/28/2018 11:02 PM, Paige DePol wrote:
> Dibyendu recently started a discussion about wether or not Lua has reached
> perfection. Of course, this will be a subject highly dependant on the need
> and opinions of each user of Lua.
>
> On that same discussion topic the desire for a switch/case like construct
> in Lua came up... so I thought I would start a new discussion thread to
> see what features people would like to see added to vanilla Lua.

To elaborate a bit on my previous postings: I was reading Peter's
posting and switch/case was the first thing that popped into my
head, so I used that as an example for the topic under discussion.
The size of the SwitchStatement page on the Lua wiki leads one to
think, why? It's a kind of "rumblings of discontent", hence
imperfection.

I think certain thinking processes when coding translates well to
a switch/case kind of construct, but it doesn't happen often
(well, depends). When it happens, the coder stops and asks, why
can't I use switch/case here?

Perhaps C/Pascal switch/case came historically somewhere at the
point where a full set of control structures has materialized, and
so C is being used as a useful baseline for feature comparison.

It's true that in Lua there are many alternatives to C/Pascal
style switch/case, and we can get by without it, but the main
thing that bugs me today is that the intent of the coder was not
expressed in the clearest possible way.

> So, if you could add any one feature to Lua right now, what would that
> feature be and why would you want to see it added? Please note that this
> discussion is in no way meant to be interpreted as pressuring Team Lua to
> add any features to Lua, I am genuinely curious what features people want
> to see added to Lua and why.
>
> My interest in this subject isn't just academic, however, I may take some
> of these ideas on board to add to my hard fork of Lua. If so, I would also
> create patches for vanilla Lua as well! :)


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

KHMan
In reply to this post by Paige DePol
On 1/28/2018 11:02 PM, Paige DePol wrote:
> Dibyendu recently started a discussion about wether or not Lua has reached
> perfection. Of course, this will be a subject highly dependant on the need
> and opinions of each user of Lua.
>
> On that same discussion topic the desire for a switch/case like construct
> in Lua came up... so I thought I would start a new discussion thread to
> see what features people would like to see added to vanilla Lua.

Here is an analogy to support the notion of switch/case as a sort
of mental model: A recipe is mostly written as a list of steps,
mostly serial, but there can be decision making and branches too.
A time-table is instead tabulated, steps can be laid out in
various ways in a compact form; a person can see and grasp the
entire time-table easily.

Of course, it's not a perfect analogy, but it's an illustration of
a kind of structure that we apply to information so that we can
better manage it. Everybody is clear about the structure of math.
Here we are dealing with the structure of information that is the
code we are writing.

> So, if you could add any one feature to Lua right now, what would that
> feature be and why would you want to see it added? Please note that this
> discussion is in no way meant to be interpreted as pressuring Team Lua to
> add any features to Lua, I am genuinely curious what features people want
> to see added to Lua and why.
>
> My interest in this subject isn't just academic, however, I may take some
> of these ideas on board to add to my hard fork of Lua. If so, I would also
> create patches for vanilla Lua as well! :)


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia



Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Kenneth Lorber
In reply to this post by Paige DePol
> Date: Sun, 28 Jan 2018 09:02:24 -0600
> From: Paige DePol <[hidden email]>
> Subject: Desired Lua Features
> To: Lua mailing list <[hidden email]>
> Message-ID: <[hidden email]>
>
> So, if you could add any one feature to Lua right now, what would that
> feature be and why would you want to see it added?

I'd like something with the functionality of the C-preprocessor's #line directive.

I added a simple version of that (it accepts but doesn't handle filenames) with the syntax:
        @N F
where the @ must be in column 1, N is a line number, and F is an optional filename.

Why do I want it?  I've been writing code generators for Lua and being able to trace errors
back to the input, an input template, or a bug in the code generator is incredibly useful; if
it's standardized the debuggers would (hopefully) support it which would make it even more
useful.

Also +1 for switch.

Thanks,
Ken Lorber
Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Roland
In reply to this post by Paige DePol
Hi List,

Such an interesting topic, and I am eager to see what kind of
features/suggestions would pop up.
I would like to make a suggestion however. In order to keep track of all the
suggestions and have anyone expand on every single idea (with possible
implementations, discuss the features themselves, etc), why not turn this
thread into a github project ? As such, every feature proposal become an
issue ticket. People would discuss with comments and suggest how the feature
could be implemented.

Well of course, not everyone has a github account, but it seems to me most
of the people here has one. What do you guys think of it ?

Roland.




--
Sent from: http://lua.2524044.n2.nabble.com/Lua-l-f2524044.html

Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Paige DePol
Roland <[hidden email]> wrote:

> Such an interesting topic, and I am eager to see what kind of
> features/suggestions would pop up.
> I would like to make a suggestion however. In order to keep track of all the
> suggestions and have anyone expand on every single idea (with possible
> implementations, discuss the features themselves, etc), why not turn this
> thread into a github project ? As such, every feature proposal become an
> issue ticket. People would discuss with comments and suggest how the feature
> could be implemented.

I suppose if the discussion becomes really in-depth that could work. I don't
know if we're going to go that deep in discussing implementation details and
the like though? I was just aiming for a casual discussion about the features
people have wanted to see in Lua over the years that have not manifested.

As the list itself isn't terribly busy I thought a discussion about the
desired features in Lua could keep us all talking for a bit... but if the
subject drifts too off-topic, or too much into implementation details then
your idea is something that would be helpful.

Also, discussing on the list means everything is archived on the various
archives for the mailing list, whereas discussions on GitHub would not be.

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Dirk Laurie-2
Well, although Lua is _almost_ perfect, the mere existence
of the Lua repository proves that it is not stagnant.

My favourite feature suggestions are:

1. Extend syntax "-l module" command line option to
"-l name=module". I actually run a patched lua5.3
that does it.

2. In a for statement, allow extra conditons before the 'do'.
2a.

for _,item in ipairs(list) if type(item)=='table' do
...
end

equivalent to

for _,item in ipairs(list) do if type(item)=='table' then
...
end end

2b.

for _,item in ipairs(list) while type(item)=='table' do
...
end

equivalent to

for _,item in ipairs(list) do if type(item)~='table' then break end
...
end

2c.

for _,item in ipairs(list) until type(item)=='table' do
...
end

equivalent to

for _,item in ipairs(list) do
...
if type(item)=='table' then break end
end

3. Bring back __ipairs.


2018-01-28 21:49 GMT+02:00 Paige DePol <[hidden email]>:

> Roland <[hidden email]> wrote:
>
>> Such an interesting topic, and I am eager to see what kind of
>> features/suggestions would pop up.
>> I would like to make a suggestion however. In order to keep track of all the
>> suggestions and have anyone expand on every single idea (with possible
>> implementations, discuss the features themselves, etc), why not turn this
>> thread into a github project ? As such, every feature proposal become an
>> issue ticket. People would discuss with comments and suggest how the feature
>> could be implemented.
>
> I suppose if the discussion becomes really in-depth that could work. I don't
> know if we're going to go that deep in discussing implementation details and
> the like though? I was just aiming for a casual discussion about the features
> people have wanted to see in Lua over the years that have not manifested.
>
> As the list itself isn't terribly busy I thought a discussion about the
> desired features in Lua could keep us all talking for a bit... but if the
> subject drifts too off-topic, or too much into implementation details then
> your idea is something that would be helpful.
>
> Also, discussing on the list means everything is archived on the various
> archives for the mailing list, whereas discussions on GitHub would not be.
>
> ~Paige
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Sean Conner
In reply to this post by Paige DePol
It was thus said that the Great Paige DePol once stated:
>
> So, if you could add any one feature to Lua right now, what would that
> feature be and why would you want to see it added? Please note that this
> discussion is in no way meant to be interpreted as pressuring Team Lua to
> add any features to Lua, I am genuinely curious what features people want
> to see added to Lua and why.

  Right now---breakpoints.  Every CPU I've programmed has had such a
feature.  The x86 has INT3, the MC68000 has TRAPn, MIPS the BREAK, the 6502
BRK, the 6809 SWI, etc.  I would like to see a Lua VM opcode that does the
same thing, which could be used to avoid the overhead of hooks (the Lua
program can run full speed until the breakpoint is hit).  

  Some API in the debug module would probably have to be made to support
this, but it's something I feel would be nice.  Even something as simple as
tripping on a function call:

        debug.setbreakpoint(target_function,code_to_run)

where code_to_run() can then do the full hooks method if further detail was
needed.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Paige DePol
In reply to this post by Dirk Laurie-2
Dirk Laurie <[hidden email]> wrote:

> Well, although Lua is _almost_ perfect, the mere existence
> of the Lua repository proves that it is not stagnant.
>
> My favourite feature suggestions are:
>
> 2. In a for statement, allow extra conditons before the 'do'.
>
> for _,item in ipairs(list) if type(item)=='table' do
> for _,item in ipairs(list) while type(item)=='table' do
> for _,item in ipairs(list) until type(item)=='table' do

Those look quite interesting, thanks for sharing the idea!

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Paige DePol
In reply to this post by Sean Conner
Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Paige DePol once stated:
>> So, if you could add any one feature to Lua right now, what would that
>> feature be and why would you want to see it added? Please note that this
>> discussion is in no way meant to be interpreted as pressuring Team Lua to
>> add any features to Lua, I am genuinely curious what features people want
>> to see added to Lua and why.
>
>  Right now---breakpoints.  Every CPU I've programmed has had such a
> feature.  The x86 has INT3, the MC68000 has TRAPn, MIPS the BREAK, the 6502
> BRK, the 6809 SWI, etc.  I would like to see a Lua VM opcode that does the
> same thing, which could be used to avoid the overhead of hooks (the Lua
> program can run full speed until the breakpoint is hit).  
>
>  Some API in the debug module would probably have to be made to support
> this, but it's something I feel would be nice.  Even something as simple as
> tripping on a function call:
>
> debug.setbreakpoint(target_function,code_to_run)
>
> where code_to_run() can then do the full hooks method if further detail was
> needed.

I was developing a macOS program a while back, even posted a screenshot, and
it had the ability to set breakpoints. However, it was via a patch to allow
me direct access to all the internals of Lua without using hooks. The idea
being that I wanted to let Lua run as it should, calling hooks when needed,
but allowing me to peek into the internals as needed as well.

A nice benefit of that was gaining the ability of having the parser tell me
what elements it had found so I could do very nice code syntax coloring!

I also had the ability to set breakpoints either on specific lines of code
or via direct instructions in the bytecode, so I can see how having the
ability to set breakpoints would be useful.

I would think that being able to compile a special "debugger" version of Lua
may be helpful. It could then potentially use some standardised protocol to
reveal the internals of Lua directly, leaving hooks for the actual code that
uses them to do so. Then once debugging was finished the standard release
version of Lua could be used to mitigate any performance loss or memory usage
overhead from using the debugging specific version.

I do plan to use the guts of the program I created in a new cross-platform
project that will have the same goal, watching the internals of Lua.

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Sean Conner
In reply to this post by KHMan
It was thus said that the Great KHMan once stated:
>
> I think certain thinking processes when coding translates well to
> a switch/case kind of construct, but it doesn't happen often
> (well, depends). When it happens, the coder stops and asks, why
> can't I use switch/case here?

  I'm going through my C code, looking at the various switch statments, and
a few things jump out to me.  One, most of them are to handle a sequence of
values (usually an enum) that in most cases, a jump table can easily handle.
Two, state machines, whehter in parsing text or handling network protocols.
And occasionally to avoid the ugliness of an if/elseif chain.

  The first case is handled well with a Lua table (I've rarely missed this
variant in Lua), and the second one I usually replace with functions using
TCO (each function handles a state) or LPeg (for the parsing tasks).  That
leaves the last case, which again, can be done in Lua with a table.
Granted, there is a bit of clumsiness when it comes to using tables for
this, so I can see the desire for some syntax.

  As far as fallthrough though,, that is *so* rare in my code as it's not a
consideration for me.  I *have* used fallthrough, but generally it's only
when parsing the command line:

        switch(argc)
        {
          case 3: /* we have a baz!, process and fall thorugh */
          case 2: /* we have a bar!, process and fall through */
          case 1: /* we have a foo!, process */
               break;
          default: /* we got nothing! Defaults or error, depending */
        }

I'm trying to think when else I did that, and while I'm sure I *have*,
nothing comes to mind immediately.

  That said, I was reminded of this article:

        http://prog21.dadgum.com/166.html [1]

  -spc

[1] Check the archives for there is a lot of good material here.  Lots
        of food for thought.

Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Sean Conner
In reply to this post by KHMan
It was thus said that the Great KHMan once stated:
>
> I think certain thinking processes when coding translates well to
> a switch/case kind of construct, but it doesn't happen often
> (well, depends). When it happens, the coder stops and asks, why
> can't I use switch/case here?

  Talking about switches.  One thing I often wish I could do is the
following [1]:

        switch(c)
        {
          case < 0 : /* handle case */
               break;
          case == 0 : /* handle this case */
               break;
          case > 0 : /* and this case */
               break;
        }

I do recall reading about a proposed language back in the mid-80s that
unified if-then with switch (with the added bonus of removing the keywords!)
which is where I got the above.  The actual proposal was:

        (?var
          = value1 : statements ;
          = value2 : statements ;
          = @      : statements ; /* default value */
        ?)

A simple 'if' statement would be:

        (?var = x : statement ?)
        ?var = x : statement ;

And this variation:

        (?
          M  = 'C'; 'S' ; 'Q';
         ^n := 1;    2;    3;
        ?)

which assigns n depending upon what is in M.  There's also Erlang's switch,
whch uses patterns [2] to decide what to do:

        case Position of
                { X , Y , Dir }         -> do_that();
                { X , Y , Dir , _ , _ } -> do_thing();
                { X , Y , _ , _ , _ }   -> do_other();
                { X , Y }               -> do_this();
        end

where '_' is a "don't care what the value is."  A better example would be
this (note:  the code was written for a wide window):

scorestrike( [ {First,Second}                | _ ]) when First < 10, Second < 10 -> First + Second;
scorestrike( [ {10   , _    } , {Third , _ } | _ ]) when Third < 10              -> 10 + Third;
scorestrike( [ {10   , _    } , {10    , _ } | _ ])                              -> 20.

  The Erlang compiler will figure out how best to represent that (internally
treated like a series of if/else or a switch or whatever).

  -spc (There are a lot of ways to go with this)

[1] Related to that:

                0 <= x < 15

        but I don't know of any language that supports that type of check.

[2] Not Lua patterns.

Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Jonathan Goble
On Sun, Jan 28, 2018, 5:23 PM Sean Conner <[hidden email]> wrote:
[1]     Related to that:

                0 <= x < 15

        but I don't know of any language that supports that type of check.

Python has supported that syntax for a long time.
Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Paige DePol
Jonathan Goble <[hidden email]> wrote:

> On Sun, Jan 28, 2018, 5:23 PM Sean Conner <[hidden email]> wrote:
> [1]     Related to that:
>
>                 0 <= x < 15
>
>         but I don't know of any language that supports that type of check.
>
> Python has supported that syntax for a long time.

And yet Python doesn't support switch case? Amusing! :)

I was thinking of adding this to Lua++ as well, given it is a pretty common
construct and has the bonus that any variables in the expression will only
be evaluated once.

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Paige DePol
In reply to this post by Sean Conner
Sean Conner <[hidden email]> wrote:

> Talking about switches.  One thing I often wish I could do is the
> following [1]:
>
> switch(c)
> {
>  case < 0 : /* handle case */
>       break;
>  case == 0 : /* handle this case */
>       break;
>  case > 0 : /* and this case */
>       break;
> }

Well the == case could just leave off the == bit, but the < and > versions
are interesting to contemplate.

In an earlier discussion with Soni we were discussing non-constant case
values, for which it would probably be simpler to devolve the switch/case
construct to an if/else system, but with special OP_JMP opcodes emitted
in the case that fallthrough was required.

These type of comparison case values could be added to such a system, so
I will definitely keep this idea in mind!


> I do recall reading about a proposed language back in the mid-80s that
> unified if-then with switch (with the added bonus of removing the keywords!)
> which is where I got the above.  The actual proposal was:
>
> (?var
>  = value1 : statements ;
>  = value2 : statements ;
>  = @      : statements ; /* default value */
> ?)

This looks like some strange merging of if/else, switch/case and the
ternary operator... which is something else I want to implement.


> where '_' is a "don't care what the value is."  A better example would be
> this (note:  the code was written for a wide window):

In my current mega-patch I have added the ability to use 'nil' to
indicate return values that should be discarded. It works quite well!


>  I'm going through my C code, looking at the various switch statments, and
> a few things jump out to me.  One, most of them are to handle a sequence of
> values (usually an enum) that in most cases, a jump table can easily handle.
> Two, state machines, whehter in parsing text or handling network protocols.
> And occasionally to avoid the ugliness of an if/elseif chain.


Yes, enums are a great use of switch/case, and accordingly I have created
the ability to add consts and enumerations as well... which makes the code
look so much nicer vs magic numbers, or having to use global variables to
hold what are essentially constant values.

I also realise now that I could make a slightly more efficient switch/case
construct in the case where the case values are all enums of the same type!


>  As far as fallthrough though,, that is *so* rare in my code as it's not a
> consideration for me.  I *have* used fallthrough, but generally it's only
> when parsing the command line:


I noticed in my research that not all languages even support fallthrough in
their switch constructs, however, it wasn't hard to implement so I figured
why not offer it as an option?

The source code of Lua itself does use fallthrough in a number of places
as well to good use. It may not necessarily be common but I think providing
the facility for fallthrough is worth having.


>  That said, I was reminded of this article:
> http://prog21.dadgum.com/166.html [1]
> [1] Check the archives for there is a lot of good material here.  Lots
> of food for thought.

Thank you for that link, I have bookmarked it for later reading! :)

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

KHMan
In reply to this post by Sean Conner
On 1/29/2018 5:59 AM, Sean Conner wrote:
> It was thus said that the Great KHMan once stated:
>>[snip snip snip]
>[snip snip snip]
> I'm trying to think when else I did that, and while I'm sure I *have*,
> nothing comes to mind immediately.
>
>    That said, I was reminded of this article:
>
> http://prog21.dadgum.com/166.html [1]

In the blog post, the author was also searching for words to
describe this switch/case thing, as I was when trying to put this
phenomenon to words. He used 'intent', that we are handing over
code generation to the compiler to optimize the thing, so that we
can clearly focus on our intent in the switch code.

In a scripting language however, performance is less of a
priority, because we have existing arguments that switch/case
constructs can easily be coded by things like if-then-elseif
strings, it's not needed, blah blah. We already have a lot of
technical arguments, so what is the underlying non-technical issue
that prompts the desire for switch/case?

IMHO, in the case of a scripting language, we have consciously or
unconciously desired to structure information (code) in a certain
way that humans often found useful and efficient (the time-table
analogy). We wanted it presented in a certain way, so that the
structured information can be most useful to the coder.

It's a bit like syntactic sugar. It's not like we decry syntactic
sugar as bad or unnecessary because syntactic sugar can help
present a thing more clearly, because it more closely matches
things everybody knows, e.g. math norms.

Sorry if anyone on the list thinks that this seems like more like
hand-waving psychology mumbo-jumbo. But past discussions have got
nowhere with technical arguments. We often forget the wetware
inside our skulls -- it's an important part of the coding process
too. Should the brain comply obediently to language
specifications, or should we help the brain to clearly express our
intent. That is why we structure information, we lay out code in
certain ways, etc. (Also, read Jakob Nielsen.)


>    -spc
>
> [1] Check the archives for there is a lot of good material here.  Lots
> of food for thought.
>


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Paige DePol
KHMan <[hidden email]> wrote:

> Sorry if anyone on the list thinks that this seems like more like
> hand-waving psychology mumbo-jumbo. But past discussions have got nowhere
> with technical arguments. We often forget the wetware inside our skulls --
> it's an important part of the coding process too. Should the brain comply
> obediently to language specifications, or should we help the brain to
> clearly express our intent. That is why we structure information, we lay
> out code in certain ways, etc. (Also, read Jakob Nielsen.)

I fully understand what you mean here... when I think of code I often
already have a structure in mind for how it should function. Having to
change that structure around when typing in the code can break that flow
and can even introduce bugs. If I see my code in a switch/case construct,
or even ternaries, then it can be a pain having to convert it to if/else!

The various structures we use for coding go along with how we think about
the code we are writing. In the book 1984 the language, Newspeak, was
created by removing words from the English language. In this way the manner
in which the people could think could be controlled. If eventually they
didn't have the words to conceive the thought, then they couldn't rebel.

I can see parallels here with programming languages, when you come from a
language with a robust syntax, think Perl, to one not as verbose, such as
Lua, it can be difficult to adjust... I know it took me a while to stop
trying to append my if statements on single expressions! However, once you
get used to the limited syntax and use it for a long time it may be harder
to think in terms of the constructs you haven't used for a long time.

One thing I always enjoy is discovering the uncommon syntax used by other
programming languages. It is always interesting to learn new ways I could
potentially think in terms of coding!

This desire to express my code with different structures is also what helps
drive my patching of Lua. That and a desire to hack and learn what makes
things work the way they do! :)

~Paige



Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Sean Conner
It was thus said that the Great Paige DePol once stated:
>
> I can see parallels here with programming languages, when you come from a
> language with a robust syntax, think Perl, to one not as verbose, such as
> Lua, it can be difficult to adjust... I know it took me a while to stop
> trying to append my if statements on single expressions! However, once you
> get used to the limited syntax and use it for a long time it may be harder
> to think in terms of the constructs you haven't used for a long time.

  The problem I have with Perl is that there are so many variations on
syntax [1] ("More than one way to do it!") that it becomes difficult to read
other people's code.  And I know that I find it odd to think of an
expression negated by a conditional *afterwards!* The whole

        do_this() if that;

just seems ... odd to me.  [2]  But I can see where you are coming from.
There were plenty of things I couldn't express in C that I could in
assembly.  Things like anonymous variables:

                push 100 ; we're doing something 100 times

        again:
                ; lots of code using all registers

                dec [esp] ; are we there yet?
                jne again

No need to name the variable.  Then there was the ability to return multiple
values (still something I sorely miss in C).  And it cuts both ways---after
programming in C for the past twenty years, there are things I now miss when
programming in Assembly [3], like not having to think about register
allocation, or mismanaging the stack [4].

> One thing I always enjoy is discovering the uncommon syntax used by other
> programming languages. It is always interesting to learn new ways I could
> potentially think in terms of coding!

  One of the books that changed how I code [5] is _Thinking Forth_ by Leo
Brodie.  Yes, it's geared for Forth, but it really got me thinking about
code in general and how I approach it.

> This desire to express my code with different structures is also what helps
> drive my patching of Lua. That and a desire to hack and learn what makes
> things work the way they do! :)

  For a real mindblowing language, look up INRAC.  It's a non-deterministic
language with the oddest flow control mechanism I've ever seen.  And I know
of three commercial products written with INRAC [6].

  -spc

[1] Understandable when one realizes that Perl was designed and written
        by a linguist, who likes to use implicit pronouns.

[2] Then again, I never liked Perl to start with.

[3] For fun these days.  

[4] Mismatched push/pop instructions, not stack overwriting.

[5] The other one is _Writing Solid Code_.  Yes, it's published by
        Microsoft and I get the irony.  It's still a great book.

[6] Only two of which are programs!

Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Coda Highland
In reply to this post by Sean Conner
On Sun, Jan 28, 2018 at 3:39 PM, Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Paige DePol once stated:
>>
>> So, if you could add any one feature to Lua right now, what would that
>> feature be and why would you want to see it added? Please note that this
>> discussion is in no way meant to be interpreted as pressuring Team Lua to
>> add any features to Lua, I am genuinely curious what features people want
>> to see added to Lua and why.
>
>   Right now---breakpoints.  Every CPU I've programmed has had such a
> feature.  The x86 has INT3, the MC68000 has TRAPn, MIPS the BREAK, the 6502
> BRK, the 6809 SWI, etc.  I would like to see a Lua VM opcode that does the
> same thing, which could be used to avoid the overhead of hooks (the Lua
> program can run full speed until the breakpoint is hit).
>
>   Some API in the debug module would probably have to be made to support
> this, but it's something I feel would be nice.  Even something as simple as
> tripping on a function call:
>
>         debug.setbreakpoint(target_function,code_to_run)
>
> where code_to_run() can then do the full hooks method if further detail was
> needed.
>
>   -spc

I mean, Javascript has the debugger; statement.

If you want to imitate this behavior, all you need to do is write a
trivial C API function and call it. It checks for a suitable debugger
hook, calls it if present, and returns. This doesn't require any
changes to the VM.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Desired Lua Features

Russell Haley
In reply to this post by Paige DePol
On Sun, Jan 28, 2018 at 7:02 AM, Paige DePol <[hidden email]> wrote:

> Dibyendu recently started a discussion about wether or not Lua has reached
> perfection. Of course, this will be a subject highly dependant on the need
> and opinions of each user of Lua.
>
> On that same discussion topic the desire for a switch/case like construct
> in Lua came up... so I thought I would start a new discussion thread to
> see what features people would like to see added to vanilla Lua.
>
> So, if you could add any one feature to Lua right now, what would that
> feature be and why would you want to see it added? Please note that this
> discussion is in no way meant to be interpreted as pressuring Team Lua to
> add any features to Lua, I am genuinely curious what features people want
> to see added to Lua and why.
>
> My interest in this subject isn't just academic, however, I may take some
> of these ideas on board to add to my hard fork of Lua. If so, I would also
> create patches for vanilla Lua as well! :)
>
> ~Paige
>
>

I'd like to see a safe table navigation syntax and a syntax for
constants that throw a compile time exception if you try to assign to
them after their declaration (The only allowable data types would be
boolean, number and string). Both can be mimicked with tables, but I
would argue that the implementations of safety should be a language
feature, not a manipulation performed using a data structure (tables).

In terms of switch/case statements, I like them because I can read
them quickly and I know that only a single item is being compared.
"ifelse" requires more thought (perhaps not a bad thing. tee hee). I
just think case statements provides a nice simplified condition
statement. Dare I say it would "clean the syntax up" for readability.
ifelse means I'm performing logic, switch means I'm checking options.

Sometimes I think a Ternary condition statement would be good. Then I
read C and decide against that. :(

Other things I think would be nice: the search path for modules
defaulting to the main scripts path if a full path is specified, and a
built in strict mode. Both features are available in penlight and many
other add ons.

Coming from the C# world, I can say it's wonderful that this
discussion can even be had. I think it vindicates the decision to keep
all these nice to haves out of the language itself. "Want more
features? There's the sources..." ;)

Russ

12