[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Thought experiment: what would you remove from Lua
- From: Sean Conner <sean@...>
- Date: Wed, 1 Aug 2018 16:01:40 -0400
It was thus said that the Great Dibyendu Majumdar once stated:
> On 1 August 2018 at 00:10, Coda Highland <email@example.com> wrote:
> > On Tue, Jul 31, 2018 at 5:16 PM, Dibyendu Majumdar
> > <firstname.lastname@example.org> 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:
> We also have Roberto's talk on the cost of adding features to Lua:
> 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.
Upvalues are required if you want to support closures. Drop closures, and
Lua becomes less useful as a language.
> 2) Debug api can manipulate values on the stack
Yeah ... it's for debugging.
> 3) C api can mess with the stack
Yes, needed if you want to interface with C.
> 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.
You don't do much with C based modules, do you?
> I am surprised no one mentioned dropping boolean type by the way ...
You are aware that booleans were added to support a nil-like value in
-spc (If I want to program in a language that lacks closures, upvalues,
and no booleans, then I'd stick with C ... )