Thought experiment: what would you remove from Lua

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

Thought experiment: what would you remove from Lua

Dibyendu Majumdar
Are there features in Lua that could be removed to create a simpler language?

Of course 'simpler' needs to be defined.

Simpler for users?
Simpler for implementors?

Often these are conflicting goals.

I, for instance, never use co-routines ... and I know they add a bunch
of complexity both from implementation and user point of view.

Another feature I never use is inheritance - at most I use simple class objects.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
On Tue, Jul 31, 2018 at 5:16 PM, Dibyendu Majumdar
<[hidden email]> wrote:

> Are there features in Lua that could be removed to create a simpler language?
>
> Of course 'simpler' needs to be defined.
>
> Simpler for users?
> Simpler for implementors?
>
> Often these are conflicting goals.
>
> I, for instance, never use co-routines ... and I know they add a bunch
> of complexity both from implementation and user point of view.
>
> Another feature I never use is inheritance - at most I use simple class objects.
>
> Regards
> Dibyendu

Coroutines are one of those things that are hard to understand and you
can go for years without ever having a use case for them, but then one
day you find a need for them and they make all the difference in the
world.

Certainly they're not STRICTLY necessary, as it's always possible to
use closures and state machines to implement the same functionality,
but when they're the right tool for the job then having them supported
at the language level makes them much easier to work with and reason
about than the alternative.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

dyngeccetor8
In reply to this post by Dibyendu Majumdar
On 08/01/2018 01:16 AM, Dibyendu Majumdar wrote:
> Are there features in Lua that could be removed to create a simpler language?

For me it is not well-placed question. Answer depends
on what you need. For example garbage collector may be
dropped for certain class of scripts.

>From syntactical point of view Lua is simple language.
It's ABNF syntax may be written on three A4 pages.
But some syntax sugar may be technically dropped:
 * three types of quotes,
 * two-plus character quoting possibilities,
 * ":",
 * "," or ";" in table constructors,
 * "t.a" (may be changed to "t['a']")

There are also features and functions which I use rarely:

* coroutines (never used yet but planning in next ten years),
* metatables (not wish to use (except when have to)),
* integers and C-like bit operands (kool, but not crucial),
* string.reverse() (anyone used it?)

-- Martin


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
It was thus said that the Great dyngeccetor8 once stated:
> On 08/01/2018 01:16 AM, Dibyendu Majumdar wrote:
> > Are there features in Lua that could be removed to create a simpler language?
>
> There are also features and functions which I use rarely:
>
> * coroutines (never used yet but planning in next ten years),

  I use them all the time.  They make network programming *much* nicer when
you don't have to deal with callback hell.

> * metatables (not wish to use (except when have to)),

  They are indispensable when using userdata from C.

> * integers and C-like bit operands (kool, but not crucial),

  64-bit ints, I like.  The C-like bit operators are nice, but string.pack()
and string.unpack() were godsends and removed the need for a lot of C code.

> * string.reverse() (anyone used it?)

  I can see a use for it, but it's a very special case, and if it was gone,
I probably wouldn't miss it.

  Something I don't use much are Lua patterns---I much prefer LPeg for that
type of thing.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Vaughan McAlley-2
In reply to this post by dyngeccetor8
On 1 August 2018 at 09:55, dyngeccetor8 <[hidden email]> wrote:

> * string.reverse() (anyone used it?)

I was using it when "deleting" a string—going through the string
backwards and simulating appropriate keystrokes to delete that
character. Then I changed to going backwards through the string by
UTF-8 codepoint, so had to think of something else.

Vaughan

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
In reply to this post by Dibyendu Majumdar
2018-08-01 0:16 GMT+02:00 Dibyendu Majumdar <[hidden email]>:

> Are there features in Lua that could be removed to create a simpler language?

Of course there are. It has been done, too. Many times.

One such language is Lua 1.0 — I have it on my machine.

Features that it does not have:

1. An interactive interpreter.

$ lua1.0
usage: lua filename [functionnames]

2. Documentation

"There is no documentation, except the test programs. The manual for Lua 1.1
probably works for this version as well."

There is an 11-page research paper [1] called "The design and implementation
of a language for extending applications". It is worth reading even now.

[1] https://www.lua.org/semish94.html

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
In reply to this post by dyngeccetor8
2018-08-01 1:55 GMT+02:00 dyngeccetor8 <[hidden email]>:

> * string.reverse() (anyone used it?)

The project I am currently working on (reverse-engineering a PDF file
via XML to Markdown) uses it.

It has a routine that converts text formatted this way:

<text font=font7>The quick brown fox jumps over the lazy dog</text>

to this:

**_`The quick brown fox jumps over the lazy dog`_**

I assemble the starting markdown sequence from the font information
and then the ending is done by string.reverse.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Axel Kittenberger
In reply to this post by Dibyendu Majumdar
dibyendu> Are there features in Lua that could be removed to create a simpler language?

- the .. operator and with it implicit string/number coercions.
- goto, the only sensible applications IMO can be replaced with better: continue and a more sophisticated try/except/throw scheme than pcall.

As a rule of thumb I'd say, if it's a feature that's not found in most other programming languages in similar areas and it's controversial, it was probably not that good of an idea. However, if it's a feature that distinguishes Lua from other programming languages and there is a wider consensus about it, it probably was one of the better ideas (for example the : operator vs. JS 'this' shenanigans, or metatables in general etc.).

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Eike Decker
In reply to this post by Dibyendu Majumdar


Dibyendu Majumdar <[hidden email]> schrieb am Mi., 1. Aug. 2018, 00:16:
Are there features in Lua that could be removed to create a simpler language?

Of course 'simpler' needs to be defined.

Simpler for users?
Simpler for implementors?

Often these are conflicting goals.

I'd like to see a version with a reference counting GC instead of a mark and sweep algorithm.
There'd be wasted memory with cyclic references, but the __gc call would be deterministic and would allow guard objects,e.g. like a mutex lock object that would unlock upon cleanup.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
In reply to this post by Axel Kittenberger
2018-08-01 9:03 GMT+02:00 Axel Kittenberger <[hidden email]>:
> dibyendu> Are there features in Lua that could be removed to create a
> simpler language?
>
> - the .. operator

Hang on, that's in Lua 1.0. One can't go lower than Lua 1.0.

> implicit string/number coercions.

That's already out in Lua 5.4. Compatibility with 5.3 comes in a metatable.

> - goto,

I use this only when implementing pseudocode from Knuth's books. My
attempts to do without it always seem to introduce subtle logic bugs.

> the only sensible applications IMO can be replaced with better:
> continue and a more sophisticated try/except/throw scheme than pcall.

Anyway, the OP did not ask what you would add, only what you would remove.

> it probably was one of the better ideas (for example the
> : operator vs. JS 'this' shenanigans, or metatables in general etc.).

'self' is so much nicer than 'this', yes? :-)

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Axel Kittenberger
> Hang on, that's in Lua 1.0. One can't go lower than Lua 1.0.

And? It's not like the question was version specific. It already could have been cut from Lua 1.0

'self' is so much nicer than 'this', yes? :-)

On the caller part yes, since it's explicit what 'this/self' is going to be while JS makes some akward auto-logic into it (once you get used to it, it's okay to live with, but elegant it's not) 

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Albert Chan
In reply to this post by Dirk Laurie-2

> * string.reverse() (anyone used it?)

My script calc.lua used it to search for last ";"

Calc a=3; b=7; c=10; b*b - 4*a*c

=> lua calc.lua "a=3; b=7; c=10; b*b - 4*a*c"
=> -71

 t= s:reverse():find(';', 2, 'plain')    -- locate last ;

if t then    -- multi-statements detected
  s = "function()" .. s:sub(1, -t) ..
         " return " .. s:sub(-t+1) ..
         " end)()"
end
print( loadstring("return " .. s)() )    -- evaluate


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

szbnwer@gmail.com
In reply to this post by Axel Kittenberger
hi all! :)

2018-08-01 7:03 GMT+00:00 Axel Kittenberger <[hidden email]>:
> and a more sophisticated try/except/throw scheme than pcall.

i hate those, however i can understand you... :D
i prefer simplicity, and oop (that i believe made the need for these)
gives simple interfaces, right, however there is nothing that cant be
solved without these with simple interfaces as well, but oop mostly
gives codes that are much harder to follow when one need to dig
deeper... i think even the machine is thankful for not using oop magic
like a protocol but implement its goodies (its simple) only in case of
real need... habits/rules over the real life need is rarely a good
thing imo. but this is just my opinion...

bests! :)

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Ahmed Charles
In reply to this post by Dirk Laurie-2

> On Aug 1, 2018, at 2:01 AM, Dirk Laurie <[hidden email]> wrote:
> That's already out in Lua 5.4. Compatibility with 5.3 comes in a metatable.

No entirely true. Only arithmetic operators no longer do string to number conversion. I too assumed this meant no more string to number conversions, but I checked the code. Turns out that the following is still valid (ignoring the silly quotes from my email client):

for i = “1”, “10”, “2” do print(i) end
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

John Hind
In reply to this post by Dibyendu Majumdar
Definitely 'ipairs' and the metamethod on 'pairs'. The former is usually
better done using numeric 'for' and can be trivially implemented in Lua
if wanted. The latter can be done by replacing 'pairs' or by writing
another iterator with a name reflecting what it does.

Generally I'd remove everything from the standard libraries that does
not justify implementation in 'C' either because it cannot be done in
Lua or because serious performance gains can be had. Then I'd have
standard Lua implementations for the rest.



Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
It was thus said that the Great John Hind once stated:
> Definitely 'ipairs' and the metamethod on 'pairs'. The former is usually
> better done using numeric 'for' and can be trivially implemented in Lua
> if wanted. The latter can be done by replacing 'pairs' or by writing
> another iterator with a name reflecting what it does.

  And there goes iterating over userdata ...

> Generally I'd remove everything from the standard libraries that does
> not justify implementation in 'C' either because it cannot be done in
> Lua or because serious performance gains can be had. Then I'd have
> standard Lua implementations for the rest.

  Okay, do you have any suggestions then?  Because I can't think of much in
the standard libraries that can be removed ...

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

dyngeccetor8
In reply to this post by Vaughan McAlley-2
> On 1 August 2018 at 09:55, dyngeccetor8 <[hidden email]> wrote:
>
>> * string.reverse() (anyone used it?)

On 08/01/2018 08:25 AM, Vaughan McAlley wrote:

> I was using it when "deleting" a string—going through the string
> backwards and simulating appropriate keystrokes to delete that
> character. Then I changed to going backwards through the string by
> UTF-8 codepoint, so had to think of something else.
>
> Vaughan


On 08/01/2018 09:00 AM, Dirk Laurie wrote:

> **_`The quick brown fox jumps over the lazy dog`_**
>
> I assemble the starting markdown sequence from the font information
> and then the ending is done by string.reverse.


On 08/01/2018 02:12 PM, Albert Chan wrote:

> My script calc.lua used it to search for last ";"
>
> Calc a=3; b=7; c=10; b*b - 4*a*c
>
> => lua calc.lua "a=3; b=7; c=10; b*b - 4*a*c"
> => -71
>
>  t= s:reverse():find(';', 2, 'plain')    -- locate last ;
>
> if t then    -- multi-statements detected
>   s = "function()" .. s:sub(1, -t) ..
>          " return " .. s:sub(-t+1) ..
>          " end)()"
> end
> print( loadstring("return " .. s)() )    -- evaluate

Wow! String reversing function is surprisingly practical!

And I like this code snippet from Albert Chan: short, simple
and useful. Clever usage of negative offsets.

My vision on string manipulations improved. Thank you guys!

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Phil Leblanc
In reply to this post by Dibyendu Majumdar
On Tue, Jul 31, 2018 at 6:16 PM, Dibyendu Majumdar
<[hidden email]> wrote:
> Are there features in Lua that could be removed to create a simpler language?

Thought experiment level 1:

-- Remove all special metamethods keys ("__add" and friends, including
__len),  excluding __index, __newindex and __gc

Thought experiment level 2:

-- Remove metatables

i.e. less "object-oriented" things. Going more with plain functions,
tables of functions and closures.

Remember, this is NOT my wish list for a future Lua! :-)  and I don't
know how much simpler it would make the language implementation

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dibyendu Majumdar
In reply to this post by Coda Highland
On 1 August 2018 at 00:10, Coda Highland <[hidden email]> wrote:

> On Tue, Jul 31, 2018 at 5:16 PM, Dibyendu Majumdar
> <[hidden email]> wrote:
>> Are there features in Lua that could be removed to create a simpler language?
>>
>> Of course 'simpler' needs to be defined.
>>
>> Simpler for users?
>> Simpler for implementors?
>>
>> Often these are conflicting goals.
>>
>> I, for instance, never use co-routines ... and I know they add a bunch
>> of complexity both from implementation and user point of view.
>>

> Coroutines are one of those things that are hard to understand and you
> can go for years without ever having a use case for them, but then one
> day you find a need for them and they make all the difference in the
> world.
>

Maybe ...

What triggered this thought experiment was a recent talk on Ruby:

https://youtu.be/4vxIncIm2D4

We also have Roberto's talk on the cost of adding features to Lua:

https://youtu.be/EUvgoxBm7uc

As someone trying to optimize Lua, I am very much aware of the
implementation cost of some features.

For instance:

1) upvalues in Lua are like pointers to stack locations.
2) Debug api can manipulate values on the stack
3) C api can mess with the stack

All of these features are nice I am sure but, you have to pay a heavy
price in terms of the ability to optimize code.

I am surprised no one mentioned dropping boolean type by the way ...

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
On Wed, Aug 1, 2018 at 1:12 PM, Dibyendu Majumdar
<[hidden email]> wrote:

> On 1 August 2018 at 00:10, Coda Highland <[hidden email]> wrote:
>> On Tue, Jul 31, 2018 at 5:16 PM, Dibyendu Majumdar
>> <[hidden email]> wrote:
>>> Are there features in Lua that could be removed to create a simpler language?
>>>
>>> Of course 'simpler' needs to be defined.
>>>
>>> Simpler for users?
>>> Simpler for implementors?
>>>
>>> Often these are conflicting goals.
>>>
>>> I, for instance, never use co-routines ... and I know they add a bunch
>>> of complexity both from implementation and user point of view.
>>>
>
>> Coroutines are one of those things that are hard to understand and you
>> can go for years without ever having a use case for them, but then one
>> day you find a need for them and they make all the difference in the
>> world.
>>
>
> Maybe ...
>
> What triggered this thought experiment was a recent talk on Ruby:
>
> https://youtu.be/4vxIncIm2D4
>
> We also have Roberto's talk on the cost of adding features to Lua:
>
> https://youtu.be/EUvgoxBm7uc
>
> As someone trying to optimize Lua, I am very much aware of the
> implementation cost of some features.
>
> For instance:
>
> 1) upvalues in Lua are like pointers to stack locations.
> 2) Debug api can manipulate values on the stack
> 3) C api can mess with the stack
>
> All of these features are nice I am sure but, you have to pay a heavy
> price in terms of the ability to optimize code.
>
> I am surprised no one mentioned dropping boolean type by the way ...
>
> Regards
> Dibyendu
>

Well, given that coroutines CAN be implemented in terms of other
language features, you could implement them at a higher level -- some
sort of automated source transformation at parse time so that the
VM/JIT/whatever doesn't have to worry about it. The Javascript
community has done this for quite a while now in order to work around
lack of browser-side support, and while the generated code is really
hard to read it's definitely just mechanical.

/s/ Adam

12345