lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

It was thus said that the Great Dibyendu Majumdar once stated:
> On 1 August 2018 at 00:10, Coda Highland <> wrote:
> > On Tue, Jul 31, 2018 at 5:16 PM, Dibyendu Majumdar
> > <> 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
sequences, right?

  -spc (If I want to program in a language that lacks closures, upvalues,
	and no booleans, then I'd stick with C ... )