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

[Coda Highland]

On Tue, Jul 31, 2018 at 5:16 PM, Dibyendu Majumdar
<***@majumdar.org.uk> 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

[Dibyendu Majumdar]

On 1 August 2018 at 00:10, Coda Highland <***@gmail.com> wrote:
> On Tue, Jul 31, 2018 at 5:16 PM, Dibyendu Majumdar
> <***@majumdar.org.uk> 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

[Coda Highland]

On Wed, Aug 1, 2018 at 1:12 PM, Dibyendu Majumdar
<***@majumdar.org.uk> wrote:
> On 1 August 2018 at 00:10, Coda Highland <***@gmail.com> wrote:
>> On Tue, Jul 31, 2018 at 5:16 PM, Dibyendu Majumdar
>> <***@majumdar.org.uk> 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

[Sean Conner]

It was thus said that the Great Coda Highland once stated:
>
> 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.

You would still need to inform the compiler what the blocking points are
and ... no. Just no.

-spc (You can pry coroutines from my cold dead hands ... )

[Coda Highland]

On Wed, Aug 1, 2018 at 3:02 PM, Sean Conner <***@conman.org> wrote:
> It was thus said that the Great Coda Highland once stated:
>>
>> 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.
>
> You would still need to inform the compiler what the blocking points are
> and ... no. Just no.
>
> -spc (You can pry coroutines from my cold dead hands ... )
>

You misunderstand: The recommendation is to PRESERVE the coroutine
syntax and do a preprocessing pass to translate that into something
more amenable to efficient VM implementation. As mentioned, this is
what the Javascript community has been doing for a couple years. The
yield statement gets transformed behind the scenes into returning some
sort of state object that can be used to resume execution.

Under no circumstances would I want to remove coroutines from the
actual language syntax, because they are far too useful.

/s/ Adam

[Andrew Starks]

On Wed, Aug 1, 2018 at 1:25 PM, Coda Highland <***@gmail.com> wrote:

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
>
>
I think that meta-programming is a useful boarder. Whenever you're adding
language features into the language that you're programming, you're
meta-programming. JavaScripts lack of a concurrency framework requires
immense amounts of meta-programming and complexity.

Lua has this too, but mostly for extending existing mechanisms in
particular directions: cqueues, object libraries and ad hoc type systems.

I think that wherever there is meta programming, it's good to ask why and
evaluate whether it's not needed or should be part of the language.

--
Andrew Starks

[Coda Highland]

On Wed, Aug 1, 2018 at 4:01 PM, Andrew Starks <***@starksfam.org> wrote:
>
>
> On Wed, Aug 1, 2018 at 1:25 PM, Coda Highland <***@gmail.com> wrote:
>
>> 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
>>
>
> I think that meta-programming is a useful boarder. Whenever you're adding
> language features into the language that you're programming, you're
> meta-programming. JavaScripts lack of a concurrency framework requires
> immense amounts of meta-programming and complexity.
>
> Lua has this too, but mostly for extending existing mechanisms in particular
> directions: cqueues, object libraries and ad hoc type systems.
>
> I think that wherever there is meta programming, it's good to ask why and
> evaluate whether it's not needed or should be part of the language.
>
> --
> Andrew Starks

By that definition, working on the interpreter itself is
metaprogramming. And while that's technically true -- and other things
like building a source-to-source transpilation tool are also
metaprogramming -- that makes the distinction much less useful for
figuring out what should or shouldn't be part of a language. Because
at some point, SOMEONE has to do some metaprogramming, or else you're
never going to be able to use the language in the first place.

Likewise, it's really not fair to judge a feature by which compiler
pass it's implemented in. That's just an implementation detail and the
design of the language shouldn't have to be concerned about it.

Conversely, a different perspective: If it requires metaprogramming
hackery to be able to do something, isn't that a sign that it's
something that SHOULD be considered for addition to the language, so
that you don't have to do the hacky thing?

/s/ Adam

[Andrew Starks]

On Wed, Aug 1, 2018 at 4:50 PM, Coda Highland <***@gmail.com> wrote:

> On Wed, Aug 1, 2018 at 4:01 PM, Andrew Starks <***@starksfam.org>
> wrote:
> >
> >
> > On Wed, Aug 1, 2018 at 1:25 PM, Coda Highland <***@gmail.com>
> wrote:
> >
> >> 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
> >>
> >
> > I think that meta-programming is a useful boarder. Whenever you're adding
> > language features into the language that you're programming, you're
> > meta-programming. JavaScripts lack of a concurrency framework requires
> > immense amounts of meta-programming and complexity.
> >
> > Lua has this too, but mostly for extending existing mechanisms in
> particular
> > directions: cqueues, object libraries and ad hoc type systems.
> >
> > I think that wherever there is meta programming, it's good to ask why and
> > evaluate whether it's not needed or should be part of the language.
> >
> > --
> > Andrew Starks
>
> By that definition, working on the interpreter itself is
> metaprogramming. And while that's technically true -- and other things
> like building a source-to-source transpilation tool are also
> metaprogramming -- that makes the distinction much less useful for
> figuring out what should or shouldn't be part of a language. Because
> at some point, SOMEONE has to do some metaprogramming, or else you're
> never going to be able to use the language in the first place.
>
> Likewise, it's really not fair to judge a feature by which compiler
> pass it's implemented in. That's just an implementation detail and the
> design of the language shouldn't have to be concerned about it.
>
> Conversely, a different perspective: If it requires metaprogramming
> hackery to be able to do something, isn't that a sign that it's
> something that SHOULD be considered for addition to the language, so
> that you don't have to do the hacky thing?
>
> /s/ Adam
>
>
I can't help but think we're saying exactly the same thing. Meta
programming isn't bad. It does happen and it just is. Another way to look
at it is attempted growth or mutations to the language. The ones that stick
and have wide use are either sufficient as libraries or big red flags that
demark potential areas for change that might result in more simplicity.

Type is a great example. Lua has a little type but not a lot. It's tempting
to want to extend type in the core language, but then you realize that
testing takes care of a lot of the reasons why you want to check for object
type. And so a type library does not come to be a required library to
download in order to "really use Lua". Often you might find yourself
looking in a `._class` field or something. But people do this and while
there may be benifits to providing such features or enforcing limitations
in the language, those decisions cut off possibilities. And that's pretty
much what designing a language must come down to.
--
Andrew Starks
612 840 2939
***@starksfam.org

[Coda Highland]

On Wed, Aug 1, 2018 at 5:07 PM, Andrew Starks <***@starksfam.org> wrote:
>
>
> On Wed, Aug 1, 2018 at 4:50 PM, Coda Highland <***@gmail.com> wrote:
>>
>> On Wed, Aug 1, 2018 at 4:01 PM, Andrew Starks <***@starksfam.org>
>> wrote:
>> >
>> >
>> > On Wed, Aug 1, 2018 at 1:25 PM, Coda Highland <***@gmail.com>
>> > wrote:
>> >
>> >> 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
>> >>
>> >
>> > I think that meta-programming is a useful boarder. Whenever you're
>> > adding
>> > language features into the language that you're programming, you're
>> > meta-programming. JavaScripts lack of a concurrency framework requires
>> > immense amounts of meta-programming and complexity.
>> >
>> > Lua has this too, but mostly for extending existing mechanisms in
>> > particular
>> > directions: cqueues, object libraries and ad hoc type systems.
>> >
>> > I think that wherever there is meta programming, it's good to ask why
>> > and
>> > evaluate whether it's not needed or should be part of the language.
>> >
>> > --
>> > Andrew Starks
>>
>> By that definition, working on the interpreter itself is
>> metaprogramming. And while that's technically true -- and other things
>> like building a source-to-source transpilation tool are also
>> metaprogramming -- that makes the distinction much less useful for
>> figuring out what should or shouldn't be part of a language. Because
>> at some point, SOMEONE has to do some metaprogramming, or else you're
>> never going to be able to use the language in the first place.
>>
>> Likewise, it's really not fair to judge a feature by which compiler
>> pass it's implemented in. That's just an implementation detail and the
>> design of the language shouldn't have to be concerned about it.
>>
>> Conversely, a different perspective: If it requires metaprogramming
>> hackery to be able to do something, isn't that a sign that it's
>> something that SHOULD be considered for addition to the language, so
>> that you don't have to do the hacky thing?
>>
>> /s/ Adam
>>
>
> I can't help but think we're saying exactly the same thing. Meta programming
> isn't bad. It does happen and it just is. Another way to look at it is
> attempted growth or mutations to the language. The ones that stick and have
> wide use are either sufficient as libraries or big red flags that demark
> potential areas for change that might result in more simplicity.
>
> Type is a great example. Lua has a little type but not a lot. It's tempting
> to want to extend type in the core language, but then you realize that
> testing takes care of a lot of the reasons why you want to check for object
> type. And so a type library does not come to be a required library to
> download in order to "really use Lua". Often you might find yourself looking
> in a `._class` field or something. But people do this and while there may be
> benifits to providing such features or enforcing limitations in the
> language, those decisions cut off possibilities. And that's pretty much what
> designing a language must come down to.
> --
> Andrew Starks
> 612 840 2939
> ***@starksfam.org

Oh, I see. I had interpreted your proposed border as being a rubric
for acceptance instead of a sign of where further consideration is
needed. Especially since I'm a C++ programmer, I get a lot of
"metaprogramming bad!" responses from people when the subject comes
up.

I can certainly agree that tasks that require metaprogramming should
be looked at as informative use cases for language design. The need
should be addressed one way or the other, whether by "there's already
a simpler way to do that" on the one hand or "that's useful enough to
be incorporated" on the other.

/s/ Adam

[Sean Conner]

It was thus said that the Great Dibyendu Majumdar once stated:
> On 1 August 2018 at 00:10, Coda Highland <***@gmail.com> wrote:
> > On Tue, Jul 31, 2018 at 5:16 PM, Dibyendu Majumdar
> > <***@majumdar.org.uk> 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.

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

[dyngeccetor8]

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

[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

[Vaughan McAlley]

On 1 August 2018 at 09:55, dyngeccetor8 <***@disroot.org> 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

[dyngeccetor8]

> On 1 August 2018 at 09:55, dyngeccetor8 <***@disroot.org> 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

[Dirk Laurie]

2018-08-01 1:55 GMT+02:00 dyngeccetor8 <***@disroot.org>:

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

[Albert Chan]

> * 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

[Dirk Laurie]

2018-08-01 0:16 GMT+02:00 Dibyendu Majumdar <***@majumdar.org.uk>:

> 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

[Axel Kittenberger]

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

[Dirk Laurie]

2018-08-01 9:03 GMT+02:00 Axel Kittenberger <***@gmail.com>:
> 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? :-)

[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)

[Ahmed Charles]

[s***@gmail.com]

hi all! :)

2018-08-01 7:03 GMT+00:00 Axel Kittenberger <***@gmail.com>:
> 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! :)

[Tom Sutcliffe]

> On 31 Jul 2018, at 11:16 pm, Dibyendu Majumdar <***@majumdar.org.uk> wrote:
>
> Are there features in Lua that could be removed to create a simpler language?

Interesting question.

> On 1 Aug 2018, at 8:03 am, Axel Kittenberger <***@gmail.com> wrote:
>
> 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.).

I think that's a good summary.

I haven't personally found a use for gotos in Lua, but I'm sure they are useful when translating code from another language which has them (or in machine-generated code), so I don't really object to them as they never get in my way. I just don't use them.

The only thing that I'd really get rid of is the implicit string/number conversions. Those you *do* unavoidably hit just by using numbers and strings and occasionally not realising there's a wrong type somewhere. I'd much prefer less magic and more "you've done something wrong here" errors. Javascript's handling of type coercions is insane, C++ is pretty close, basically implicit type conversions are almost always a slippery slope of unpleasantness. lua_tolstring being able to mutate the underlying value and mess up lua_next (amongst other things) is one of those gotchas that just shouldn't exist, and is (imo) one of the few genuine missteps in the Lua C API. KISS is the only way to go here which keeps your sanity intact.

I think I've pretty much used every other aspect of Lua in a significant way, by which I mean there's a real-world project relying on it. coroutines, debug, utf8, userdata, most metamethods, bitwise operators, ability to build for severely resource-constrained platforms with a compiler that doesn't even support floating point, I've used them all. Maybe weak tables? I don't think I've yet relied on them although I've come close a few times, so I don't think I'd be happy if they weren't an option. string.reverse I admit I've never ever used, although the 'cost' to the language of having it is so minimal I don't really care, and it's interesting to see that some people have found a use for it. Lua's string pattern matching you can prise from my cold, dead hands given how much simpler and smaller it is to regex (while being still pretty powerful) and how it's actually built in (yes std C++, I'm looking at you).

Lua is pretty much the definition of everything I really need in a language, and nothing that I don't. Which is one of the reasons I like it :-)

Cheers,

Tom

[Dirk Laurie]

Op Do., 6 Sep. 2018 om 19:34 het Tom Sutcliffe <***@me.com> geskryf:

> The only thing that I'd really get rid of is the implicit string/number conversions.

Well, it's already in Lua 5.3 as simple compiling with NOCVTS2N, and
in Lua 5.4 you don't need to recompile, just assign nil to the
offending string metamethods.

> Lua is pretty much the definition of everything I really need in a language, and nothing that I don't. Which is one of the reasons I like it :-)

Amen, brother.

[Tom Sutcliffe]

On 6 Sep 2018, at 9:18 pm, Dirk Laurie <***@gmail.com> wrote:
>
> Op Do., 6 Sep. 2018 om 19:34 het Tom Sutcliffe <***@me.com> geskryf:
>
>> The only thing that I'd really get rid of is the implicit string/number conversions.
>
> Well, it's already in Lua 5.3 as simple compiling with NOCVTS2N, and
> in Lua 5.4 you don't need to recompile, just assign nil to the
> offending string metamethods.

I didn't realise that LUA_NOCVTN2S disabled the lua_tolstring automatic conversions (I thought it controlled just the Lua-side ones like "a"..1). Now that I look, it does indeed. I've learnt something today!

Now I'm really kicking myself for not enabling those in my last project, maybe I can quietly sneak them in with enough testing of all the existing code... (I was trying to be as close to stock Lua as possible, at the time, but it has progressed to the point where I probably could safely change this).

Cheers,

Tom

[Axel Kittenberger]

>
> Maybe weak tables?


Oh I use them in Lua! Usecase, opaque handlers given to a user script,
which the weak table links to the full implementation in the "core". Once
the user script drops them, the core can cleanup the linked objects too.

And I'm looking forward to the day Javascript finally gets something
similar (WeakMap/WeakSet is only half of it). I'd really want to intern
immutable objects by hash values which is not yet possible.

[Sam Pagenkopf]

It would break everything, but I'd remove the top-level function keyword
entirely, with the side effects. 2 more keystrokes for `=` in free
functions, plus 4 for `self` in methods.

It's really not so bad. It's more visible. You need to write ``x = function
(self, ...)`` in some places no matter what. It would become more clear
that function declarations in lua are just assignments. It's also less to
parse, and one less thing for new users to trip on. I did attempt the
nonsensical ``x:y = function (...)`` when I was first learning! When I
write lua now, I prefer to write ``x.y = function (self, ...)`` for
everything that uses a self, because I want to be very clear whether its a
free function or a method (prefer free functions!). I don't know if it
would warrant removing the `x:y(args)` call syntax, I'm okay with a
shorthand if the behavior is consistent, and the ``self`` is just repeated
text which was passed anonymously to begin with. Speaking of, the
``x:y{key: value, ...}`` call is a delicious and useful shorthand for named
method args.

I'm also reasonably sure that you could convert any valid lua program using
the top-level function keyword into a valid one with the other syntax.
Correct me if I'm wrong on that, edge cases are always fun.

On Thu, Sep 6, 2018 at 12:35 PM Tom Sutcliffe <***@me.com> wrote:

> > On 31 Jul 2018, at 11:16 pm, Dibyendu Majumdar <***@majumdar.org.uk>
> wrote:
> >
> > Are there features in Lua that could be removed to create a simpler
> language?
>
> Interesting question.
>
> > On 1 Aug 2018, at 8:03 am, Axel Kittenberger <***@gmail.com> wrote:
> >
> > 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.).
>
> I think that's a good summary.
>
> I haven't personally found a use for gotos in Lua, but I'm sure they are
> useful when translating code from another language which has them (or in
> machine-generated code), so I don't really object to them as they never get
> in my way. I just don't use them.
>
> The only thing that I'd really get rid of is the implicit string/number
> conversions. Those you *do* unavoidably hit just by using numbers and
> strings and occasionally not realising there's a wrong type somewhere. I'd
> much prefer less magic and more "you've done something wrong here" errors.
> Javascript's handling of type coercions is insane, C++ is pretty close,
> basically implicit type conversions are almost always a slippery slope of
> unpleasantness. lua_tolstring being able to mutate the underlying value and
> mess up lua_next (amongst other things) is one of those gotchas that just
> shouldn't exist, and is (imo) one of the few genuine missteps in the Lua C
> API. KISS is the only way to go here which keeps your sanity intact.
>
> I think I've pretty much used every other aspect of Lua in a significant
> way, by which I mean there's a real-world project relying on it.
> coroutines, debug, utf8, userdata, most metamethods, bitwise operators,
> ability to build for severely resource-constrained platforms with a
> compiler that doesn't even support floating point, I've used them all.
> Maybe weak tables? I don't think I've yet relied on them although I've come
> close a few times, so I don't think I'd be happy if they weren't an option.
> string.reverse I admit I've never ever used, although the 'cost' to the
> language of having it is so minimal I don't really care, and it's
> interesting to see that some people have found a use for it. Lua's string
> pattern matching you can prise from my cold, dead hands given how much
> simpler and smaller it is to regex (while being still pretty powerful) and
> how it's actually built in (yes std C++, I'm looking at you).
>
> Lua is pretty much the definition of everything I really need in a
> language, and nothing that I don't. Which is one of the reasons I like it
> :-)
>
> Cheers,
>
> Tom
>
>
>

[Axel Kittenberger]

>
> It would break everything, but I'd remove the top-level function keyword
> entirely, with the side effects. 2 more keystrokes for `=` in free
> functions, plus 4 for `self` in methods.
>

The issue is with recursive functions. You can't do that simply with the
"name = function()" syntax.

[Dirk Laurie]

Op Sa., 8 Sep. 2018 om 07:26 het Axel Kittenberger <***@gmail.com> geskryf:

>> It would break everything, but I'd remove the top-level function keyword entirely, with the side effects. 2 more keystrokes for `=` in free functions, plus 4 for `self` in methods.
>
> The issue is with recursive functions. You can't do that simply with the "name = function()" syntax.

Oh, you can. "local function func(...)" is syntactic sugar for

local func
func = function(...)

I'm sure this is in the manual, but don't have it open in my browser right now.

[Italo Maia]

I would probably remove/change global by default; all the rest is quite
handy.

Em sáb, 8 de set de 2018 08:32, Dirk Laurie <***@gmail.com>
escreveu:

> Op Sa., 8 Sep. 2018 om 07:26 het Axel Kittenberger <***@gmail.com>
> geskryf:
>
> >> It would break everything, but I'd remove the top-level function
> keyword entirely, with the side effects. 2 more keystrokes for `=` in free
> functions, plus 4 for `self` in methods.
> >
> > The issue is with recursive functions. You can't do that simply with the
> "name = function()" syntax.
>
> Oh, you can. "local function func(...)" is syntactic sugar for
>
> local func
> func = function(...)
>
> I'm sure this is in the manual, but don't have it open in my browser right
> now.
>
>

[Francisco Olarte]

On Sat, Sep 8, 2018 at 7:25 AM, Axel Kittenberger <***@gmail.com> wrote:
>> It would break everything, but I'd remove the top-level function keyword
>> entirely, with the side effects. 2 more keystrokes for `=` in free
>> functions, plus 4 for `self` in methods.
> The issue is with recursive functions. You can't do that simply with the
> "name = function()" syntax.

Is this true? The manual says translation for "local function" is made
in a certain way to allow self references, and in my machine:
Lua 5.3.3 Copyright (C) 1994-2016 Lua.org, PUC-Rio
> a=function(x) print(x); if x>0 then a(x-1); end end
> a(3)
3
2
1
0

F.O.S.
( Note/disclaimer: I like function a(x) better )

[Albert Chan]

> On Sat, Sep 8, 2018 at 7:25 AM, Axel Kittenberger <***@gmail.com> wrote:
>>> It would break everything, but I'd remove the top-level function keyword
>>> entirely, with the side effects. 2 more keystrokes for `=` in free
>>> functions, plus 4 for `self` in methods.
>> The issue is with recursive functions. You can't do that simply with the
>> "name = function()" syntax.
>
> Is this true? The manual says translation for "local function" is made
> in a certain way to allow self references, and in my machine:
> Lua 5.3.3 Copyright (C) 1994-2016 Lua.org, PUC-Rio
>> a=function(x) print(x); if x>0 then a(x-1); end end
>> a(3)
> 3
> 2
> 1
> 0
>
> F.O.S.
> ( Note/disclaimer: I like function a(x) better )

it work because a is a global function, not local.

[pocomane]

On Sat, Sep 8, 2018 at 7:26 AM Axel Kittenberger <***@gmail.com> wrote:
> The issue is with recursive functions. You can't do that simply with the "name = function()" syntax.

I think it is possible, continue reading.

On Sun, Sep 9, 2018 at 3:43 PM Albert Chan <***@yahoo.com> wrote:
> it work because a is a global function, not local.

True, but the following is not, and it still works

```
Lua 5.3.4 Copyright (C) 1994-2017 Lua.org, PUC-Rio
> local a; a=function(x) print(x); if x>0 then a(x-1); end end; a(3)
3
2
1
0
> print(a)
nil
```

On Sun, Sep 9, 2018 at 11:53 AM Francisco Olarte <***@peoplecall.com> wrote:
>
> F.O.S.
> ( Note/disclaimer: I like function a(x) better )
>

Same for me!

[Francisco Olarte]

On Mon, Sep 10, 2018 at 10:11 AM, pocomane <***@pocomane.com> wrote:
>> local a; a=function(x) print(x); if x>0 then a(x-1); end end; a(3)

Slapping myself. I should have known the trick to local use is to just
stash everything in a line so it's processed by a single
load_whatever. Trying to commit it to long term storage :( .


>> ( Note/disclaimer: I like function a(x) better )
> Same for me!

Nearly everyone loves sugar in moderate amounts, and in particular
places. I've been putting it in black coffee for 40 years despite many
people diskliking it. ;->

Francisco Olarte Sanz.

[Dirk Laurie]

Op Ma., 10 Sep. 2018 om 13:23 het Francisco Olarte
<***@peoplecall.com> geskryf:
>
> On Mon, Sep 10, 2018 at 10:11 AM, pocomane <***@pocomane.com> wrote:
> >> local a; a=function(x) print(x); if x>0 then a(x-1); end end; a(3)
>
> Slapping myself. I should have known the trick to local use is to just
> stash everything in a line so it's processed by a single
> load_whatever. Trying to commit it to long term storage :( .
>
>
> >> ( Note/disclaimer: I like function a(x) better )
> > Same for me!
>
> Nearly everyone loves sugar in moderate amounts, and in particular
> places. I've been putting it in black coffee for 40 years despite many
> people diskliking it. ;->

"Sugar is something that makes coffee bitter when you forget to put it
in." — Anonymous 5-year old.

[pocomane]

On Mon, Sep 10, 2018 at 1:34 PM Dirk Laurie <***@gmail.com> wrote:
>
> "Sugar is something that makes coffee bitter when you forget to put it
> in." — Anonymous 5-year old.
>

5-year kids should not drink coffee. But at 6 they can start to drink
wine. My dad just did this way with me :)

I am not sure what this means for the metaphor...

[Francisco Olarte]

Albert:

On Sun, Sep 9, 2018 at 3:43 PM, Albert Chan <***@yahoo.com> wrote:
>> Is this true? The manual says translation for "local function" is made
>> in a certain way to allow self references, and in my machine:
>> Lua 5.3.3 Copyright (C) 1994-2016 Lua.org, PUC-Rio
>>> a=function(x) print(x); if x>0 then a(x-1); end end
>>> a(3)
>> 3
>> 2
>> 1
>> 0
...
> it work because a is a global function, not local.

I should have explained myself better:

I DID NOT made an example for local because:
1.- it would need a nested function in the unmodified command line
environbment I use ( local does not work right in the repl ).
2.- Manual explicitly says it shuld work, so if it doesn't it is just
a bug to be reported.

I did make an example for global because:
0.- I was unable to find a paragraph stating it should as directly as
3.4.11, my knowledge of how globals are just entries in a magic hash (
a => _ENV.a or _G.a ) pointed it should do ( you can even do mutual
recursion to a to be defined function in globals, and even do a calls
b ( not defined ), b calls c ( not defined ), set c=a, it know works,
but I felt the example was better ).

And in the discussion I was trying to rply to they where talking about
all uses of function, not just locals or globals.

Francisco Olarte.

[Dirk Laurie]

Op Sa., 8 Sep. 2018 om 06:24 het Sam Pagenkopf <***@gmail.com> geskryf:

> It would break everything, but I'd remove the top-level function keyword entirely, with the side effects. 2 more keystrokes for `=` in free functions, plus 4 for `self` in methods.

I never use 'self', but I am not a party OOPer. [1]

In its defence, though:

'self' is not a keyword.

It is in the same category as 'arg': a pre-assigned non-global
variable with a conventional meaning,

> It would become more clear that function declarations in lua are just assignments.

This is "dieting", i.e. deliberately cutting out sugar. Cutting out
"pairs" and "ipairs" is similar.

Nothing more annoying than having to adjust one's eating habits just
because someone else is dieting, unless you happen to be Saint Paul. I
prefer not to use 'self' and 'pairs', but I would not dream of
removing them from Lua.

On the other hand, unlike Dibyendu and Paige, writing and supporting
dialects of Lua is not my hobby. (Btw Dibyendu, if you need a name for
this stripped-down Lua of yours, how about Deimos? For over 100 years,
it was the smallest known moon in the universe.)

> When I write lua now, I prefer to write ``x.y = function (self, ...)`` for everything that uses a self, because I want to be very clear whether its a free function or a method (prefer free functions!).

This is what I do, except I don't use the word self, I use a name that
tells me what class I expect. If the metatable is called "Deque", the
first parameter in its methods is "deque".

> I don't know if it would warrant removing the `x:y(args)` call syntax,

It won't. That syntax does not need 'self'.

The question I ask is: is the logic of the program easier to follow?
And the one feature of object-oriented programming that I do still
embrace (admittedly only in a platonic way) is that there is at most
one value passed to a method that you are allowed to change. Moving
that value out of the argument list makes a lot of sense.

This syntax comes into its own when 'x' is an expression. Youl'll find
some people saying you should anyway assign that expression to a local
variable, but I do find e.g.

for k,v in next,template do
tbl[k]:action(v)
end

a useful idiom.

-- Dirk

[1] My love affair with "object-oriented" languages like Delphi and
C++ (note that these are about as old as Lua) was never more than a
passing crush; I did not even get past Paragraph 1 of tutorials for
Ada and Java, and I don't know more about Smalltalk than its name.

[Dibyendu Majumdar]

On Sat, 8 Sep 2018 at 06:27, Dirk Laurie <***@gmail.com> wrote:
> On the other hand, unlike Dibyendu and Paige, writing and supporting
> dialects of Lua is not my hobby. (Btw Dibyendu, if you need a name for
> this stripped-down Lua of yours, how about Deimos? For over 100 years,
> it was the smallest known moon in the universe.)
>

Nice name. I think there is a smaller language / implementation
lurking inside Lua that might be more efficient and optimizable. The
problem as always is of compatibility - and the fact that it is very
very hard to establish a new language. It requires full time attention
and many years of effort. The amount of time I am able to give to Ravi
for example, is insufficient to do this. And the difficulty then of
popularizing it makes it hard to be motivated.

Regards
Dibyendu

[Dirk Laurie]

Op Sa., 8 Sep. 2018 om 14:33 het Dibyendu Majumdar
<***@majumdar.org.uk> geskryf:
>
> On Sat, 8 Sep 2018 at 06:27, Dirk Laurie <***@gmail.com> wrote:
> > On the other hand, unlike Dibyendu and Paige, writing and supporting
> > dialects of Lua is not my hobby. (Btw Dibyendu, if you need a name for
> > this stripped-down Lua of yours, how about Deimos? For over 100 years,
> > it was the smallest known moon in the universe.)
> >
>
> Nice name. I think there is a smaller language / implementation
> lurking inside Lua that might be more efficient and optimizable. The
> problem as always is of compatibility - and the fact that it is very
> very hard to establish a new language. It requires full time attention
> and many years of effort. The amount of time I am able to give to Ravi
> for example, is insufficient to do this. And the difficulty then of
> popularizing it makes it hard to be motivated.

Actually Lua is so minimalistic, the question is always what one could
add rather than what could one remove, and the answer in both cases
can usually be implemented by loading a package.

[Dibyendu Majumdar]

On Sat, 8 Sep 2018 at 17:08, Dirk Laurie <***@gmail.com> wrote:
>
> Op Sa., 8 Sep. 2018 om 14:33 het Dibyendu Majumdar
> <***@majumdar.org.uk> geskryf:
> >
> > On Sat, 8 Sep 2018 at 06:27, Dirk Laurie <***@gmail.com> wrote:
> > > On the other hand, unlike Dibyendu and Paige, writing and supporting
> > > dialects of Lua is not my hobby. (Btw Dibyendu, if you need a name for
> > > this stripped-down Lua of yours, how about Deimos? For over 100 years,
> > > it was the smallest known moon in the universe.)
> > >
> >
> > Nice name. I think there is a smaller language / implementation
> > lurking inside Lua that might be more efficient and optimizable. The
> > problem as always is of compatibility - and the fact that it is very
> > very hard to establish a new language. It requires full time attention
> > and many years of effort. The amount of time I am able to give to Ravi
> > for example, is insufficient to do this. And the difficulty then of
> > popularizing it makes it hard to be motivated.
>
> Actually Lua is so minimalistic, the question is always what one could
> add rather than what could one remove, and the answer in both cases
> can usually be implemented by loading a package.
>

Sure, if you aren't interested in performance.

As someone trying to build an efficient JIT for Lua, I do wish I could
do away with some things that broadly speaking:

* Lead to lots of runtime type checking - such as metamethods, Integer subtype
* Unpredictable stack manipulation - via C api, or debug api
* Coroutines
* Need to support inheritance via metatables

I haven't kept of list of issues that I would like to address - these
are off the top of my head.

I think a language that had none of these features (but was otherwise
Lua) would still be very powerful. Difficulty is getting anyone to
adopt a new language.

[Francisco Olarte]

Hi:

On Sat, Sep 8, 2018 at 6:24 AM, Sam Pagenkopf <***@gmail.com> wrote:
> It would break everything, but I'd remove the top-level function keyword
> entirely, with the side effects. 2 more keystrokes for `=` in free
> functions, plus 4 for `self` in methods.
....
> I'm also reasonably sure that you could convert any valid lua program using
> the top-level function keyword into a valid one with the other syntax.
> Correct me if I'm wrong on that, edge cases are always fun.

Well, if I read correctly (5.3 ref manual, 3.4.11 function definitions
) all "top level" function keyword usages are syntactic sugar with a
translation defined there, so it's easy to be sure. You could remove
it, but normally it is called syntactic sugar instead of
syntactic-PITA for a reason.

F.O.S.

[Sam Pagenkopf]

The recursive definitions are something I didn't consider. If you were to
enable recursion in local function assignments. it would be strange because
it violates scoping rules. I think the most complete and useful answer
would be a shorthand for `local x x = `, whatever that may be. No longer a
removal, but a replacement.

On Sun, Sep 9, 2018 at 4:47 AM Francisco Olarte <***@peoplecall.com>
wrote:

> Hi:
>
> On Sat, Sep 8, 2018 at 6:24 AM, Sam Pagenkopf <***@gmail.com> wrote:
> > It would break everything, but I'd remove the top-level function keyword
> > entirely, with the side effects. 2 more keystrokes for `=` in free
> > functions, plus 4 for `self` in methods.
> ....
> > I'm also reasonably sure that you could convert any valid lua program
> using
> > the top-level function keyword into a valid one with the other syntax.
> > Correct me if I'm wrong on that, edge cases are always fun.
>
> Well, if I read correctly (5.3 ref manual, 3.4.11 function definitions
> ) all "top level" function keyword usages are syntactic sugar with a
> translation defined there, so it's easy to be sure. You could remove
> it, but normally it is called syntactic sugar instead of
> syntactic-PITA for a reason.
>
> F.O.S.
>
>

[Sean Conner]

It was thus said that the Great Sam Pagenkopf once stated:
> The recursive definitions are something I didn't consider. If you were to
> enable recursion in local function assignments. it would be strange because
> it violates scoping rules.

Nope, not with the Y-combinator:

local fact = Y(function(self,n)
if n == 0 then
return 1
else
return n * self(n - 1)
end
end)

print(fact(5))

Now the trick is to define Y().

-spc

[Gé Weijers]

local function Y(f)
local function g(...) return f(g, ...) end
return g
end

print(Y(function(fac, n) if n <= 1 then return 1 else return n*fac(n-1) end
end)(10))


There's a more complicated version of Y that does not require an assignment
(local function g(...) is really local g; g = function(...))

On Sun, Sep 9, 2018 at 6:24 PM Sean Conner <***@conman.org> wrote:

> It was thus said that the Great Sam Pagenkopf once stated:
> > The recursive definitions are something I didn't consider. If you were to
> > enable recursion in local function assignments. it would be strange
> because
> > it violates scoping rules.
>
> Nope, not with the Y-combinator:
>
> local fact = Y(function(self,n)
> if n == 0 then
> return 1
> else
> return n * self(n - 1)
> end
> end)
>
> print(fact(5))
>
> Now the trick is to define Y().
>
> -spc
>
>
>

--
--
Gé

[Roberto Ierusalimschy]

> local function Y(f)
> local function g(...) return f(g, ...) end
> return g
> end
>
> print(Y(function(fac, n) if n <= 1 then return 1 else return n*fac(n-1) end
> end)(10))
>
>
> There's a more complicated version of Y that does not require an assignment
> (local function g(...) is really local g; g = function(...))

The problem here is not the assignment per se, but the fact that 'g'
is recursive, so it only moves the recursion from one place to another.
The following version does not use recursion (although this particular
one is usually called Z, not Y):

local Y = function (le)
local a = function (f)
return le(function (...) return f(f)(...) end)
end
return a(a)
end


-- Roberto

[Gavin Wraith]

In message <***@arraial.inf.puc-rio.br>
Roberto Ierusalimschy <***@inf.puc-rio.br> wrote:

>The problem here is not the assignment per se, but the fact that 'g'
>is recursive, so it only moves the recursion from one place to another.
>The following version does not use recursion (although this particular
>one is usually called Z, not Y):
>
>local Y = function (le)
> local a = function (f)
> return le(function (...) return f(f)(...) end)
> end
> return a(a)
> end

What a mind-twisting beautiful combinator! I remember an amusingly
illustrated article called "The Care and Feeding of Combinators",
produced in the early 80s as light entertainment for a conference on
functional programming. Alas, it is no longer on my shelf. Lua is
not generally advertised as a functional programming language, but
of course it is - among other things.

--
Gavin Wraith (***@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

[Lorenzo Donati]

On 11/09/2018 22:14, Roberto Ierusalimschy wrote:
[...]

> local Y = function (le)
> local a = function (f)
> return le(function (...) return f(f)(...) end)
> end
> return a(a)
> end
>

OUCH! My brain hurts!

I can "feel" its beauty, but it's way over my functional head to understand!

(It almost reminds me of the difficulties of understanding Duff's device :-)


>
> -- Roberto
>
>

[Coda Highland]

On Sat, Sep 22, 2018 at 2:51 AM, Lorenzo Donati
<***@tiscali.it> wrote:
> On 11/09/2018 22:14, Roberto Ierusalimschy wrote:
> [...]
>
>> local Y = function (le)
>> local a = function (f)
>> return le(function (...) return f(f)(...) end)
>> end
>> return a(a)
>> end
>>
>
> OUCH! My brain hurts!
>
> I can "feel" its beauty, but it's way over my functional head to understand!
>
> (It almost reminds me of the difficulties of understanding Duff's device :-)
>

I dunno, Duff's device is pretty simple by comparison.

/s/ Adam

[Lorenzo Donati]

On 23/09/2018 01:18, Coda Highland wrote:
> On Sat, Sep 22, 2018 at 2:51 AM, Lorenzo Donati
> <***@tiscali.it> wrote:
>> On 11/09/2018 22:14, Roberto Ierusalimschy wrote:
>> [...]
>>
>>> local Y = function (le)
>>> local a = function (f)
>>> return le(function (...) return f(f)(...) end)
>>> end
>>> return a(a)
>>> end
>>>
>>
>> OUCH! My brain hurts!
>>
>> I can "feel" its beauty, but it's way over my functional head to understand!
>>
>> (It almost reminds me of the difficulties of understanding Duff's device :-)
>>
>
> I dunno, Duff's device is pretty simple by comparison.

I didn't mean to compare the two things directly. I just compared how I
felt when coming in contact with those. The bedazzling feeling is the
same! :-)

I saw Duff's device for the first time probably 25+ years ago and I was
waaaay less experienced as a programmer back then. Moreover (IIRC) it
was in K&R book and I didn't have to understand it for my uni courses,
so it was just a curiosity. I did understand it some years later (and it
took me quite an effort).

I totally agree that Roberto's example is far more mind-boggling.



>
> /s/ Adam
>
>

[Eike Decker]

Dibyendu Majumdar <***@majumdar.org.uk> 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.

[John Hind]

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.

[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

[Phil Leblanc]

On Tue, Jul 31, 2018 at 6:16 PM, Dibyendu Majumdar
<***@majumdar.org.uk> 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

[Dirk Laurie]

2018-08-01 19:57 GMT+02:00 Phil Leblanc <***@gmail.com>:
> On Tue, Jul 31, 2018 at 6:16 PM, Dibyendu Majumdar
> <***@majumdar.org.uk> 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

In fact, it is a nostalgia list for a previous Lua: 4.0 had no
metatables (but it did have tag methods).

[Phil Leblanc]

On Wed, Aug 1, 2018 at 2:46 PM, Dirk Laurie <***@gmail.com> wrote:
[...]
>> 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.
>>
[...]
>
> In fact, it is a nostalgia list for a previous Lua: 4.0 had no
> metatables (but it did have tag methods).
>

Well, not nostalgia since I discovered Lua around the 5.0/5.1
transition. And I really like many recent Lua features (mostly the
64-bit integer subtype, the bit operators and the built-in string
pack/unpack functions).

[Dibyendu Majumdar]

On 1 August 2018 at 19:46, Dirk Laurie <***@gmail.com> wrote:
> 2018-08-01 19:57 GMT+02:00 Phil Leblanc <***@gmail.com>:
>> Thought experiment level 2:
>>
>> -- Remove metatables
>>
>> i.e. less "object-oriented" things. Going more with plain functions,
>> tables of functions and closures.
>>
> In fact, it is a nostalgia list for a previous Lua: 4.0 had no
> metatables (but it did have tag methods).
>

Meta tables are indeed another problematic feature from optimization
point of view. Of course it seems grand that the table type is reused
to hold meta information too - wonderful unifying design! Except that
now an implementation detail has become user visible, and the
implementor has no way of knowing what the user might do.

The more you allow users to mess with 'meta' information, including
stacks, in uncontrolled ways, the harder it becomes to implement
efficient implementations (unless you are a genius called Mark Pall).

I guess every feature enacts a price. A beautiful coherent design from
one view may be a poor design from another point of view!

Regards
Dibyendu

[Dirk Laurie]

2018-08-01 21:19 GMT+02:00 Dibyendu Majumdar <***@majumdar.org.uk>:

> The more you allow users to mess with 'meta' information, including
> stacks, in uncontrolled ways, the harder it becomes to implement
> efficient implementations (unless you are a genius called Mark Pall).

You don't by any chance mean Mike Pall?

[Dibyendu Majumdar]

On 1 August 2018 at 20:44, Dirk Laurie <***@gmail.com> wrote:
> 2018-08-01 21:19 GMT+02:00 Dibyendu Majumdar <***@majumdar.org.uk>:
>
>> The more you allow users to mess with 'meta' information, including
>> stacks, in uncontrolled ways, the harder it becomes to implement
>> efficient implementations (unless you are a genius called Mark Pall).
>
> You don't by any chance mean Mike Pall?
>

Indeed I meant Mike Pall (a certain Mark was on my mind as I had been
watching a talk on Java Stewards) - thank you for the correction!

Regards
Dibyendu

[Sean Conner]

It was thus said that the Great Dibyendu Majumdar once stated:
> On 1 August 2018 at 19:46, Dirk Laurie <***@gmail.com> wrote:
> > 2018-08-01 19:57 GMT+02:00 Phil Leblanc <***@gmail.com>:
> >> Thought experiment level 2:
> >>
> >> -- Remove metatables
> >>
> >> i.e. less "object-oriented" things. Going more with plain functions,
> >> tables of functions and closures.
> >>
> > In fact, it is a nostalgia list for a previous Lua: 4.0 had no
> > metatables (but it did have tag methods).
> >
>
> Meta tables are indeed another problematic feature from optimization
> point of view.

You *really* don't use C-based modules at all, do you? Because without
metatables, userdata becomes rather useless.

> Of course it seems grand that the table type is reused
> to hold meta information too - wonderful unifying design! Except that
> now an implementation detail has become user visible, and the
> implementor has no way of knowing what the user might do.

Can't trust those programmers, can you?

-spc

[Dibyendu Majumdar]

Hi Sean,

On 1 August 2018 at 21:04, Sean Conner <***@conman.org> wrote:
> It was thus said that the Great Dibyendu Majumdar once stated:
>> On 1 August 2018 at 19:46, Dirk Laurie <***@gmail.com> wrote:
>> > 2018-08-01 19:57 GMT+02:00 Phil Leblanc <***@gmail.com>:
>> >> Thought experiment level 2:
>> >>
>> >> -- Remove metatables
>> >>
>> >> i.e. less "object-oriented" things. Going more with plain functions,
>> >> tables of functions and closures.
>> >>
>> > In fact, it is a nostalgia list for a previous Lua: 4.0 had no
>> > metatables (but it did have tag methods).
>> >
>>
>> Meta tables are indeed another problematic feature from optimization
>> point of view.
>
> You *really* don't use C-based modules at all, do you? Because without
> metatables, userdata becomes rather useless.
>

Apologies I don't mean to argue. But maybe you are thinking of meta methods?

Regards
Dibyendu

[Sean Conner]

It was thus said that the Great Dibyendu Majumdar once stated:
> Hi Sean,
>
> On 1 August 2018 at 21:04, Sean Conner <***@conman.org> wrote:
> > It was thus said that the Great Dibyendu Majumdar once stated:
> >> On 1 August 2018 at 19:46, Dirk Laurie <***@gmail.com> wrote:
> >> > 2018-08-01 19:57 GMT+02:00 Phil Leblanc <***@gmail.com>:
> >> >> Thought experiment level 2:
> >> >>
> >> >> -- Remove metatables
> >> >>
> >> >> i.e. less "object-oriented" things. Going more with plain functions,
> >> >> tables of functions and closures.
> >> >>
> >> > In fact, it is a nostalgia list for a previous Lua: 4.0 had no
> >> > metatables (but it did have tag methods).
> >> >
> >>
> >> Meta tables are indeed another problematic feature from optimization
> >> point of view.
> >
> > You *really* don't use C-based modules at all, do you? Because without
> > metatables, userdata becomes rather useless.
>
> Apologies I don't mean to argue. But maybe you are thinking of meta methods?

Yes, which require metatables to store. You can also set the __index meta
method to said metatable to index methods other than the meta methods
without having to write a custom __index function (ore __newindex function
for that matter). So you can do things like:

data = file:read()

Yes, that is syntactic sugar for

data = file.read(file)

but without the metatable on file containing __index pointing to itself, you
then have to do

data = io.read(file)

and you lose the ability to pass in something that isn't the result of
io.open() to code but does have the ability to return data like io.read()
does, say, from, a socket or a mocked file.

-spc

[Dibyendu Majumdar]

On 1 August 2018 at 21:18, Sean Conner <***@conman.org> wrote:
>> >> Meta tables are indeed another problematic feature from optimization
>> >> point of view.
>> >
>> > You *really* don't use C-based modules at all, do you? Because without
>> > metatables, userdata becomes rather useless.
>>
>> Apologies I don't mean to argue. But maybe you are thinking of meta methods?
>
> Yes, which require metatables to store.

Sorry you didn't get my point at all. I was specifically talking about
using standard Lua tables as an implementation approach - its nothing
to do with the functional goal .

Regards

[Sean Conner]

It was thus said that the Great Dibyendu Majumdar once stated:
> On 1 August 2018 at 21:18, Sean Conner <***@conman.org> wrote:
> >> >> Meta tables are indeed another problematic feature from optimization
> >> >> point of view.
> >> >
> >> > You *really* don't use C-based modules at all, do you? Because without
> >> > metatables, userdata becomes rather useless.
> >>
> >> Apologies I don't mean to argue. But maybe you are thinking of meta methods?
> >
> > Yes, which require metatables to store.
>
> Sorry you didn't get my point at all. I was specifically talking about
> using standard Lua tables as an implementation approach - its nothing
> to do with the functional goal .

That was not clear at all.

It also seems you have problems with the C API and the debug module and
would like to see those go away as well (or downplayed as much as possible
because they complicate the design of a JIT for Lua).

-spc

[Dibyendu Majumdar]

On 1 August 2018 at 21:27, Sean Conner <***@conman.org> wrote:
>> Sorry you didn't get my point at all. I was specifically talking about
>> using standard Lua tables as an implementation approach - its nothing
>> to do with the functional goal .
>
> That was not clear at all.

Okay my bad then. I thought it was clear in the context of Dirk's
comment about how Lua 4.0 did it differently.

>
> It also seems you have problems with the C API and the debug module and
> would like to see those go away as well (or downplayed as much as possible
> because they complicate the design of a JIT for Lua).
>

Just making my position clear if it hasn't been given my past posts
here. I am strongly against breaking backward compatibility. So I will
never argue for breaking changes in Lua.

This is an academic discussion - a thought experiment. It is not a
plea to change Lua.

Regards
Dibyendu

[Phil Leblanc]

On Wed, Aug 1, 2018 at 4:04 PM, Sean Conner <***@conman.org> wrote:
> It was thus said that the Great Dibyendu Majumdar once stated:
>> On 1 August 2018 at 19:46, Dirk Laurie <***@gmail.com> wrote:
>> > 2018-08-01 19:57 GMT+02:00 Phil Leblanc <***@gmail.com>:
>> >> Thought experiment level 2:
>> >>
>> >> -- Remove metatables
>> >>
>> >> i.e. less "object-oriented" things. Going more with plain functions,
>> >> tables of functions and closures.
>> >>
[...]
>>
Meta tables are indeed another problematic feature from optimization
>> point of view.
>
> You *really* don't use C-based modules at all, do you? Because without
> metatables, userdata becomes rather useless.

I wouldn't say "useless". Maybe more risky, or more inconvenient?

I think that Dibyendu's thought experiment objective is not to find
features that you can remove and get an as good and convenient
language as Lua is today.

My understanding is that the objective is to find a subset, or a
simplified dialect of Lua that could be more efficiently compiled (or
interpreted?). Such a dialect would be simpler, lower-level at some
places, maybe rougher for the developer. These would be trade-offs for
a higher execution speed (or a smaller implementation).

I find the exercise interesting :-)

[Sean Conner]

It was thus said that the Great Dibyendu Majumdar once stated:
> On 1 August 2018 at 19:46, Dirk Laurie <***@gmail.com> wrote:
> > 2018-08-01 19:57 GMT+02:00 Phil Leblanc <***@gmail.com>:
> >> Thought experiment level 2:
> >>
> >> -- Remove metatables
> >>
> >> i.e. less "object-oriented" things. Going more with plain functions,
> >> tables of functions and closures.
> >>
> > In fact, it is a nostalgia list for a previous Lua: 4.0 had no
> > metatables (but it did have tag methods).
> >
>
> Meta tables are indeed another problematic feature from optimization
> point of view. Of course it seems grand that the table type is reused
> to hold meta information too - wonderful unifying design! Except that
> now an implementation detail has become user visible, and the
> implementor has no way of knowing what the user might do.
>
> The more you allow users to mess with 'meta' information, including
> stacks, in uncontrolled ways, the harder it becomes to implement
> efficient implementations (unless you are a genius called Mark Pall).

So, how would you implement meta information then? What, specifically, is
difficult with the current design?

-spc

[Marc Balmer]

> Am 01.08.2018 um 00:16 schrieb Dibyendu Majumdar <***@majumdar.org.uk>:
>
> Are there features in Lua that could be removed to create a simpler language?

Obviously, syntactic sugars could be removed, as they do not add to the power of the language.

>
> Of course 'simpler' needs to be defined.
>
> Simpler for users?
> Simpler for implementors?

Exactly. Removing aforementioned syntactic sugars would make the code a bit harder to read, and less maintainable, imo.
>
> 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.

Lua has no inheritance.

In general, I would probably not remove anything and not add much. But then, nobody asks me and I am not in charge ;)

>
> Regards
> Dibyendu
>

[Peter Hickman]

The only things I would want to add to Lua is "trailing conditionals" (I
think they are called)

if process_the_data == true then
slice_and_dice(data)
end

would become

slice_and_dice(data) if process_the_data == true

It really reads smoother for me like this (and having 'unless' would make
things readable too)

I don't use Lua as much as Ruby or Python but when I do I find the the Lua
code can be quite verbose for trivial parts. I keep having to stop and ask
"what is this bunch of syntax doing" The phrase 'intent revealing' comes to
mind, Lua can be quite nuts and bolts and syntax can obscure semantics.
When reading code what it is doing is more important that how it is doing
it, at least on the first pass

However I use Lua for what it is. Never thought "if only ..."

[Axel Kittenberger]

== true ...

I'll always cringe to that since beginners think an if _must_ have a
comparison operator in it.

It is already boolean, no need to thest it again.

if process_the_data then
slice_and_dice(data)
end

PS: Exception is when it explicitly checks it to be a boolean value at the
same time, so 1 ought to be false..

Oh and this discussion is about removing not adding.

On Thu, Aug 2, 2018 at 2:53 PM, Peter Hickman <
***@googlemail.com> wrote:

> The only things I would want to add to Lua is "trailing conditionals" (I
> think they are called)
>
> if process_the_data == true then
> slice_and_dice(data)
> end
>
> would become
>
> slice_and_dice(data) if process_the_data == true
>
> It really reads smoother for me like this (and having 'unless' would make
> things readable too)
>
> I don't use Lua as much as Ruby or Python but when I do I find the the Lua
> code can be quite verbose for trivial parts. I keep having to stop and ask
> "what is this bunch of syntax doing" The phrase 'intent revealing' comes to
> mind, Lua can be quite nuts and bolts and syntax can obscure semantics.
> When reading code what it is doing is more important that how it is doing
> it, at least on the first pass
>
> However I use Lua for what it is. Never thought "if only ..."
>
>

[Oliver Kroth]

What about

return process_the_data and slice_and_dice( data )

?


Am 02.08.2018 um 15:00 schrieb Axel Kittenberger:
> slice_and_dice(data) if process_the_data == true

[Peter Hickman]

On 2 August 2018 at 15:23, Oliver Kroth <***@nec-i.de> wrote:

> What about
>
> return process_the_data and slice_and_dice( data )
>
> ?
>

Thanks, will try and remember that

[Peter Hickman]

On 2 August 2018 at 14:00, Axel Kittenberger <***@gmail.com> wrote:

> == true ...
>
> I'll always cringe to that since beginners think an if _must_ have a
> comparison operator in it.
>
> It is already boolean, no need to thest it again.
>
> if process_the_data then
> slice_and_dice(data)
> end
>
>
Better safe than sorry. process_the_data might return anything, anything
other than false or nil will resolve as true. I prefer to avoid 'sort of
true' in conditionals


> Oh and this discussion is about removing not adding.
>

Oops my bad. Got sidetracked when Mark Balmer mentioned readability.

[Petri Häkkinen]

> On 1 Aug 2018, at 1.16, Dibyendu Majumdar <***@majumdar.org.uk> wrote:
>
> Are there features in Lua that could be removed to create a simpler language?

I would remove ’:’ and ’self’. I never use them in my code and they support bad habits.

Petri

[Sean Conner]

It was thus said that the Great Petri Häkkinen once stated:
>
> > On 1 Aug 2018, at 1.16, Dibyendu Majumdar <***@majumdar.org.uk> wrote:
> >
> > Are there features in Lua that could be removed to create a simpler language?
>
> I would remove ’:’ and ’self’. I never use them in my code and they support bad habits.

What bad habbits? The excessive use of OOP?

-spc

[Petri Häkkinen]

> On 7 Sep 2018, at 23.41, Sean Conner <***@conman.org> wrote:
>
> It was thus said that the Great Petri Häkkinen once stated:
>>
>> I would remove ’:’ and ’self’. I never use them in my code and they support bad habits.
>
> What bad habbits? The excessive use of OOP?
>
> -spc

I’m sorry, I somehow forgot to check back on this.

I’m talking about OOP in general. Every OO codebase I’ve worked with has been an overdesigned, hard to maintain mess. In my opinion, the invention of OOP was a misstep, leading to analysis paralysis (so many ways to model the program as classes) and poor performance (caused by too much emphasis on abstractions and code reuse rather than efficient data flow — see Data Oriented Design).

Luckily more and more programmers are beginning to realize this (including pretty much all experienced programmers I personally know).

For me it took almost two decades in C++ land to realize it. After that I wrote a pretty substantial OO codebase in Lua, still OO because classes was all I could see back then. Now I’ve been working on a Lua codebase with only free functions for 2+ years and it feels much cleaner and easier to work with than any of the OO stuff I’ve done before.

Especially with a powerful dynamic language such as Lua I see no need for rigid classes & inheritance.

Petri

[Sean Conner]

It was thus said that the Great Petri Häkkinen once stated:
>
> > On 7 Sep 2018, at 23.41, Sean Conner <***@conman.org> wrote:
> >
> > It was thus said that the Great Petri Häkkinen once stated:
> >>
> >> I would remove ’:’ and ’self’. I never use them in my code and they
> >> support bad habits.
> >
> > What bad habbits? The excessive use of OOP?
>
> I’m talking about OOP in general. Every OO codebase I’ve worked with has
> been an overdesigned, hard to maintain mess. In my opinion, the invention
> of OOP was a misstep, leading to analysis paralysis (so many ways to model
> the program as classes) and poor performance (caused by too much emphasis
> on abstractions and code reuse rather than efficient data flow — see Data
> Oriented Design).
>
> Luckily more and more programmers are beginning to realize this (including
> pretty much all experienced programmers I personally know).

While I agree with that (yes, I'm not a fan of OOP myself) I do find the
':' notation worthwile as a form of scope for functions (mostly with
userdata). I find:

config = tls.config()
config:protocols("all")
config:verify_client(true)
config:ca_file("trust_these")
config:cert_file("my_cert")

server = tls.server()
server:configure(config)

connection = server:accept_socket(s)

nicer than:

config = tls.config()
tls.config_protocols(config,"all")
tls.config_verify_client(config,true)
tls.config_ca_file(config,"trust_these")
tls.config_cert_file(config,"my_cert")

server = tls.server()
tls.configure(server,config)

connection = tls.accept_socket(server)

As it stands, my top level tls module [1] only has five functions instead
of some 80 functions---the configuration functions are only available to the
config "object" (for lack of a better term); the context functions are only
available to the "context" (or in this case, "server") object. It's a form
of organization.

-spc

[1] https://github.com/spc476/lua-conmanorg/blob/master/src/tls.c

Rockspec coming soon ...

[Petri Häkkinen]

> On 17 Sep 2018, at 23.57, Sean Conner <***@conman.org> wrote:
> While I agree with that (yes, I'm not a fan of OOP myself) I do find the
> ':' notation worthwile as a form of scope for functions (mostly with
> userdata). I find:
>
> config = tls.config()
> config:protocols("all")
> config:verify_client(true)
> config:ca_file("trust_these")
> config:cert_file("my_cert")
>
> server = tls.server()
> server:configure(config)
>
> connection = server:accept_socket(s)
>

I agree, ’:’ can be useful for data description.

[ I forgot I use it in my custom shader DSL for describing struct fields:

struct ”vertex”
: float3 ”position”
: float4 ”color”

]

So, I take back that ’:’ should be removed. But my (strong) opinion on OOP still stands :)

Petri

[Coda Highland]

On Mon, Sep 17, 2018 at 12:24 PM, Petri Häkkinen <***@gmail.com> wrote:
>
>> On 7 Sep 2018, at 23.41, Sean Conner <***@conman.org> wrote:
>>
>> It was thus said that the Great Petri Häkkinen once stated:
>>>
>>> I would remove ’:’ and ’self’. I never use them in my code and they support bad habits.
>>
>> What bad habbits? The excessive use of OOP?
>>
>> -spc
>
> I’m sorry, I somehow forgot to check back on this.
>
> I’m talking about OOP in general. Every OO codebase I’ve worked with has been an overdesigned, hard to maintain mess. In my opinion, the invention of OOP was a misstep, leading to analysis paralysis (so many ways to model the program as classes) and poor performance (caused by too much emphasis on abstractions and code reuse rather than efficient data flow — see Data Oriented Design).
>
> Luckily more and more programmers are beginning to realize this (including pretty much all experienced programmers I personally know).
>
> For me it took almost two decades in C++ land to realize it. After that I wrote a pretty substantial OO codebase in Lua, still OO because classes was all I could see back then. Now I’ve been working on a Lua codebase with only free functions for 2+ years and it feels much cleaner and easier to work with than any of the OO stuff I’ve done before.
>
> Especially with a powerful dynamic language such as Lua I see no need for rigid classes & inheritance.
>
> Petri

There's nothing wrong with OOP in general. There is a tendency for
some engineers to overengineer, this is true, and some tools end up
demanding overengineering (Java, I'm looking at you), but nothing
about the paradigm in and of itself is necessarily bad.

As with everything, it's always a question of having the right tool
for the job. There are some domains where an object-oriented modeling
is the obvious fit. There are some domains where trying to crystallize
up an object model ends up making more of a mess than it solves. And
the most egregious source of trouble is when you're forced to use
SOMEONE ELSE'S object model because the underlying framework demands
it even when it doesn't make sense for your needs. And on the flip
side, having a bunch of free functions means that you expect all of
your things to behave the same way all the time -- which is a
perfectly reasonable design for some applications, and a dangerously
bad design for others.

That said, I agree with the conclusion that Lua doesn't need rigid
classes and inheritance built-in. Dynamic languages have their roles
just like static languages do. If your problem is one that would be
better served by a static language, then you should use something
besides Lua instead of trying to force Lua to conform to what you're
looking for.

Lua's implementation of OO is a very good balance for a dynamic
language. It allows grouping related data together in a container, it
allows that data to carry around the functions that it expects you to
use on it, and it gives objects the ability to share a set of
predefined behaviors. None of these are required if they don't fit
your purposes, but they're sufficiently lightweight and unopinionated
that they can deal with most use cases.

/s/ Adam

[Petri Häkkinen]

> On 18 Sep 2018, at 0.25, Coda Highland <***@gmail.com> wrote:
>
> There's nothing wrong with OOP in general. There is a tendency for
> some engineers to overengineer, this is true, and some tools end up
> demanding overengineering (Java, I'm looking at you), but nothing
> about the paradigm in and of itself is necessarily bad.

Well, that’s the theory but practice is altogether different matter. :) OO systems start nice and well behaved but when time goes on and new features are implemented over existing ones they all fall to mess. Nobody has time to remodel the classes when requirements change. So in my opinion just letting it go is the most sane & time saving solution.

> a bunch of free functions means that you expect all of
> your things to behave the same way all the time

Polymorphism can still be achieved for example with lambdas / callbacks in your data. Actually this is much more powerful than classes, because you can mix those callbacks any way you like (unlimited combinations vs. fixed number of classes), override them per instance rather than needing to create a new class (specialization for those weird cases), add them dynamically (do this after that) etc.

Petri

[Coda Highland]

On Tue, Sep 18, 2018 at 1:17 AM, Petri Häkkinen <***@gmail.com> wrote:
>
>> On 18 Sep 2018, at 0.25, Coda Highland <***@gmail.com> wrote:
>>
>> There's nothing wrong with OOP in general. There is a tendency for
>> some engineers to overengineer, this is true, and some tools end up
>> demanding overengineering (Java, I'm looking at you), but nothing
>> about the paradigm in and of itself is necessarily bad.
>
> Well, that’s the theory but practice is altogether different matter. :) OO systems start nice and well behaved but when time goes on and new features are implemented over existing ones they all fall to mess. Nobody has time to remodel the classes when requirements change. So in my opinion just letting it go is the most sane & time saving solution.
>
>> a bunch of free functions means that you expect all of
>> your things to behave the same way all the time
>
> Polymorphism can still be achieved for example with lambdas / callbacks in your data. Actually this is much more powerful than classes, because you can mix those callbacks any way you like (unlimited combinations vs. fixed number of classes), override them per instance rather than needing to create a new class (specialization for those weird cases), add them dynamically (do this after that) etc.
>
> Petri

Not all OOP looks like C++ or Java. Carrying callbacks in your data is
still OOP.

Having an object with optional event handlers is a form of OOP that's
actually OLDER than C++.

It's even still OOP if you're just dealing with stuff by using
consistent interface contracts even if there's no direct coupling or
dependency.

Don't throw the baby out with the bathwater.

/s/ Adam

[Petri Häkkinen]

> On 18 Sep 2018, at 22.32, Coda Highland <***@gmail.com> wrote:
>
> Not all OOP looks like C++ or Java. Carrying callbacks in your data is
> still OOP.
>
> Having an object with optional event handlers is a form of OOP that's
> actually OLDER than C++.

I disagree. Using function pointers does not automatically mean that it’s OO. Especially since with the callbacks there’s no direct correlation between functions and data (the callbacks may not even get the pointer to the data, for example with continuations). I’m pretty sure jump tables & function ptrs predate OOP by at least a decade, so saying that any code that uses function pointers is automatically OO sounds weird.

Petri

[Coda Highland]

On Wed, Sep 19, 2018 at 1:27 AM, Petri Häkkinen <***@gmail.com> wrote:
>
>> On 18 Sep 2018, at 22.32, Coda Highland <***@gmail.com> wrote:
>>
>> Not all OOP looks like C++ or Java. Carrying callbacks in your data is
>> still OOP.
>>
>> Having an object with optional event handlers is a form of OOP that's
>> actually OLDER than C++.
>
> I disagree. Using function pointers does not automatically mean that it’s OO. Especially since with the callbacks there’s no direct correlation between functions and data (the callbacks may not even get the pointer to the data, for example with continuations). I’m pretty sure jump tables & function ptrs predate OOP by at least a decade, so saying that any code that uses function pointers is automatically OO sounds weird.
>
> Petri
>

I didn't say "using function pointers." I said "carrying callbacks in
your data." And on the assumption that your data is structured and the
callback always has a consistent semantic meaning concerning the data
carrying it, then that is at least rudimentarily object-oriented code.
Obviously the rest of the program might not be structured in such a
way that the object-oriented nature of that structure is relevant at
all, so I wouldn't go so far as to say the code is automatically OO,
but the kernel is there and it can certainly be beneficial to make use
of that nature when it's the right tool for the job.

(In particular I was actually talking about Smalltalk, which uses
message passing, not function pointers.)

Because central to the idea of object-oriented programming is the
concept of polymorphism: the notion that objects that obey a certain
contract can be treated interchangeably even though their
implementation details differ. Languages like C++ and Java define
these contracts statically, requiring that the programmer teach the
compiler how to enforce this. Languages like Lua allow the contract to
be defined informally. But as long as that contract has the object
itself providing the implementation details of some operation, you can
meaningfully call it object-oriented.

This is obviously not the right choice for many kinds of applications.
If your data is always the same structure anyway, then flat functions
have some clear advantages -- namely, it's a lot easier to describe
some properties about the functions, such as whether or not they're
pure.

The biggest problem with OO is, as I mentioned previously, opinionated
frameworks. "When all you have is a hammer," as the saying goes: Java
engineers in particular have a tendency to try to build frameworks
that are generic enough to tackle anything without thinking about
whether or not it's actually the best idea. (C++ engineers do the same
thing but instead of making a zillion interfaces that require you to
define dozens of tiny classes, they make a zillion templates.)

This isn't the fault of the object-oriented paradigm, though, because
you'll see the same failures in the functional programming community:
a rigidly narrow focus on defining everything in terms of pure
functions, higher-order functions, and function composition, inventing
schemas and frameworks and patterns that they swear will make your
code better if only you follow the rules. And if your application fits
the kind of ideas where that structure makes sense, it does. And if
your application doesn't quite fit that mold, you end up having to
hack around it, making a mess where you might have been able to
express the same thing in a few obvious lines of code.

In short: Use the right tool for the job. Sometimes OOP is the right
tool. Sometimes FP is the right tool. Sometimes good old-fashioned
structural/procedural code is the right tool. Sometimes it works best
to use a hybrid of the techniques. (There's a functional-OO hybrid
that I'm particularly fond of that I've seen a few different sources
discuss but there's no consensus on what to call it because there's
not yet a large body of formal theory around it.) No programming
paradigm is inherently bad, and you shouldn't dismiss them just
because you've had bad experiences -- odds are, your bad experiences
were the result of it not being the right tool for the task you were
doing at the time.

/s/ Adam

[Dirk Laurie]

Op Do., 20 Sep. 2018 om 04:08 het Coda Highland <***@gmail.com> geskryf:
>

> The biggest problem with OO is, as I mentioned previously, opinionated
> frameworks. "When all you have is a hammer," as the saying goes: Java
> engineers in particular have a tendency to try to build frameworks
> that are generic enough to tackle anything without thinking about
> whether or not it's actually the best idea. (C++ engineers do the same
> thing but instead of making a zillion interfaces that require you to
> define dozens of tiny classes, they make a zillion templates.)
>
> This isn't the fault of the object-oriented paradigm, though, because
> you'll see the same failures in the functional programming community:
> a rigidly narrow focus on defining everything in terms of pure
> functions, higher-order functions, and function composition, inventing
> schemas and frameworks and patterns that they swear will make your
> code better if only you follow the rules. And if your application fits
> the kind of ideas where that structure makes sense, it does. And if
> your application doesn't quite fit that mold, you end up having to
> hack around it, making a mess where you might have been able to
> express the same thing in a few obvious lines of code.

Two days ago, I bought a second-hand copy of Reiser and Wirth's 1992
book "Programming in Oberon" at a library sale for half the price of a
can of beer, even though the PDF is free and I have it somewhere on my
computer too. It repaid the investment within minutes.

"Object-orientation as a programming technique, together with object-
oriented programming languages, is a fashionable topic. Oberon is true
to its spirit: a minimal language extension — namely extension of record
types — suffices. This is in contrast to other approaches that introduce a
wealth of new concepts many simply renaming established notions."

"The ultimate innovation was data type extensibility, which unfortunately
remained obscured behind the much less expressive term ‘object-oriented.’"

The book is exactly as old as Lua, which also has does it by only a
minimal language extension. Dare I guess that Lua's authors, too, were
and are not over-fond of OO buzzwords and hype?

[Albert Chan]

Earlier in this thread, Y combinator were introduced (a week ago ?)

I was confused.
Why would we complicate a recursive function like that ?

Then, I found this: http://dreamsongs.com/Files/WhyOfY.pdf

From the same site, this might apply to Lua, the language
There is no need to create the perfect language ...

http://dreamsongs.com/WorseIsBetter.html

[Petri Häkkinen]

> On 20 Sep 2018, at 5.07, Coda Highland <***@gmail.com> wrote:

> In short: Use the right tool for the job. Sometimes OOP is the right
> tool.

Well, if it works for you, go for it. Personally I have no use for OO anymore, unless forced to deal with an existing codebase.

There were times when I thought OOP was well suited to certain areas, e.g. GUIs. But the cheer pleasure of working with immediate mode guis have shown that to be a fallacy.

Petri

[Aapo Talvensaari]

> On 20 Sep 2018, at 5.07, Coda Highland <***@gmail.com> wrote:

>
> > In short: Use the right tool for the job.


I don't believe this anymore. It just leads to overtooling. Instead you
should just pick a few tools and try to do most with them. And only
occasionally use some very specialized tools.

>

[Coda Highland]

On Thu, Sep 20, 2018 at 9:45 AM, Petri Häkkinen <***@gmail.com> wrote:
>
>> On 20 Sep 2018, at 5.07, Coda Highland <***@gmail.com> wrote:
>
>> In short: Use the right tool for the job. Sometimes OOP is the right
>> tool.
>
> Well, if it works for you, go for it. Personally I have no use for OO anymore, unless forced to deal with an existing codebase.
>
> There were times when I thought OOP was well suited to certain areas, e.g. GUIs. But the cheer pleasure of working with immediate mode guis have shown that to be a fallacy.
>
> Petri

TMTOWTDI. Nothing says there is one and only one right tool for the
job. Immediate mode GUIs can certainly be the right tool for the job,
especially for simpler layouts. I wouldn't want to use an immediate
mode framework for something more complex, like web layout.

It should also be noted that the underlying code for the immediate
mode GUI is almost certainly object-oriented even if you don't have to
use OOP code to interface with it. There are just too many advantages
to being able to treat GUI components polymorphically when you're
working at that level.


On Thu, Sep 20, 2018 at 12:14 PM, Aapo Talvensaari
<***@gmail.com> wrote:
>> On 20 Sep 2018, at 5.07, Coda Highland <***@gmail.com> wrote:
>>
>>
>> > In short: Use the right tool for the job.
>
>
> I don't believe this anymore. It just leads to overtooling. Instead you
> should just pick a few tools and try to do most with them. And only
> occasionally use some very specialized tools.

It sounds like you do still believe in it; you just have new
requirements for defining the "right tool" -- namely, if you have a
tool that you're already using in a project, and it's close enough,
then that IS the right tool for the job, because the cost of bringing
in another tool is greater than the benefit it would give you.
Likewise, if you have a tool you're proficient with that's close
enough, while you're unfamiliar with the tool that would on the
surface appear to be superior, then that other tool is NOT the right
tool for the job. And your cited exception is the cases where the
tools you're already using AREN'T close enough and the benefit of
bringing a new one in outweighs the drawbacks.

This is EXACTLY the right mindset to use in practical software engineering.

/s/ Adam

[Dirk Laurie]

Op Do., 20 Sep. 2018 om 20:44 het Coda Highland <***@gmail.com> geskryf:

> Likewise, if you have a tool you're proficient with that's close
> enough, while you're unfamiliar with the tool that would on the
> surface appear to be superior, then that other tool is NOT the right
> tool for the job.

Well, by that definition, most of the time Lua is the right tool for
the job. I did Python for about four years and never felt
"proficient"; I considered myself proficient (albeit optimistically)
after about 18 months of Lua and have not looked back.

If I may for a moment regress to the OP's subject, my answer after 89
messages, is: nothing.

[Coda Highland]

On Thu, Sep 20, 2018 at 2:06 PM, Dirk Laurie <***@gmail.com> wrote:
> Op Do., 20 Sep. 2018 om 20:44 het Coda Highland <***@gmail.com> geskryf:
>
>> Likewise, if you have a tool you're proficient with that's close
>> enough, while you're unfamiliar with the tool that would on the
>> surface appear to be superior, then that other tool is NOT the right
>> tool for the job.
>
> Well, by that definition, most of the time Lua is the right tool for
> the job. I did Python for about four years and never felt
> "proficient"; I considered myself proficient (albeit optimistically)
> after about 18 months of Lua and have not looked back.
>
> If I may for a moment regress to the OP's subject, my answer after 89
> messages, is: nothing.

Lua has the beautiful advantage of being unopinionated. It has exactly
the feature set necessary to implement a broad variety of meaningful
programming paradigms without overprivileging any one of them. It can
do OOP (prototypes), it can do FP (tail call optimization and
lambdas), it can do declarative (original design motivation!), or of
course it's happy to do good ol' procedural/imperative. It can do
synchronous or asynchronous. With a bit of elbow grease it can
integrate with just about anything.

It's not the perfect tool for every job -- no tool is -- but as long
as you don't need C levels of performance, you've got the deployment
side of things solved, and you've got bindings for any libraries you
want to use, Lua is a great general-purpose workhorse. And if you need
to embed a scripting language in a host application, Lua jumps from
"great" to "best in class".

So yes, I too hold the opinion that the Lua core can't afford to lose
anything it has built into it right now. It's as lean as it can get
without sacrificing its versatility.

/s/ Adam

[m***@clawdesign.com]

> -----Ursprüngliche Nachricht-----
> Von: lua-l-***@lists.lua.org <lua-l-***@lists.lua.org> Im Auftrag
> von Petri Häkkinen
> Gesendet: Montag, 17. September 2018 19:24
> An: Lua mailing list <lua-***@lists.lua.org>
> Betreff: Re: Thought experiment: what would you remove from Lua


> Especially with a powerful dynamic language such as Lua I see no need for
> rigid classes & inheritance.

This, very much. F.i. I have all kinds of functions working with "rectangles", like
intersections, collisions checks, grow/shrink/point inclusion etc. etc. but there's
no need to limit the usage to any predefined type. In my case it's just tables and
as long as they contain x/y/width/height key/value pairs, they're valid data.

It's much much more reusable than any OOP/interface construct, no dependency
or coupling of any kind.

[Tim Hill]

> On Sep 17, 2018, at 10:24 AM, Petri Häkkinen <***@gmail.com> wrote:
>
>
> I’m sorry, I somehow forgot to check back on this.
>
> I’m talking about OOP in general. Every OO codebase I’ve worked with has been an overdesigned, hard to maintain mess. In my opinion, the invention of OOP was a misstep, leading to analysis paralysis (so many ways to model the program as classes) and poor performance (caused by too much emphasis on abstractions and code reuse rather than efficient data flow — see Data Oriented Design).
>
> Luckily more and more programmers are beginning to realize this (including pretty much all experienced programmers I personally know).
>
> For me it took almost two decades in C++ land to realize it. After that I wrote a pretty substantial OO codebase in Lua, still OO because classes was all I could see back then. Now I’ve been working on a Lua codebase with only free functions for 2+ years and it feels much cleaner and easier to work with than any of the OO stuff I’ve done before.
>
> Especially with a powerful dynamic language such as Lua I see no need for rigid classes & inheritance.
>
> Petri

+1 on all your points.

—Tim

[Aapo Talvensaari]

On Wed, Aug 1, 2018 at 1:16 AM Dibyendu Majumdar <***@majumdar.org.uk>
wrote:

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

I think I would be just fine without:
- goto (and labels)
- repeat ... until
- varargs
- do ... end (maybe even this could go)

Also:
- load, loadfile, dofile, loadstring -> just load
- consolidate setmetatable and debug.setmetatable etc. (?)
- string.len

Well, maybe even:
- Weak tables could go

On (built-in) libs there is a lot to remove. But well a lot to add too :-).

[Dirk Laurie]

Op Wo., 12 Sep. 2018 om 00:44 het Aapo Talvensaari
<***@gmail.com> geskryf:
>
> On Wed, Aug 1, 2018 at 1:16 AM Dibyendu Majumdar <***@majumdar.org.uk> wrote:
>>
>> Are there features in Lua that could be removed to create a simpler language?

> I think I would be just fine without:

> - goto (and labels)

People will immediately start clamouring for "continue" again.

> - repeat ... until

Well yes, we don't need it if we have 'while'. But it pays Lua's debt
to Pascal. And it is more powerful than 'while', because the
termination test can refer to variable local to the loop.

> - varargs

Without that and its 'select', you cannot distinguish between
fct(x,y,nil) and fct(x,y).

> - do ... end (maybe even this could go)

Impossible. You lose 'for' and 'while'. Multi-line inputs in the
interactive interpreter. Local variables with less than file-global
scope.

But having read this far, it strikes me that you could remove 'do ..
end', both kinds of 'for', and 'while', as long as you keep "repeat
... until".

[Dirk Laurie]

Op Wo., 1 Aug. 2018 om 00:16 het Dibyendu Majumdar
<***@majumdar.org.uk> geskryf:
>
> Are there features in Lua that could be removed to create a simpler language?

We've had a lot of fun playing that game, let's get serious. Let's do it.

It's as easy as just not using the features that we would remove. Try
coding that way for say a week. You will find that some things are not
really missed, others you simply can't keep yourself from using no
matter how hard you try to avoid them.

I'm looking forward to trying to use "repeat ... until" as my only
looping and local blocking construct :-)

[Sergey Zakharchenko]

Hi Dirk,

> I'm looking forward to trying to use "repeat ... until" as my only
> looping and local blocking construct :-)

Why stop at that, use repeat ... break ... until true as your only error
handling construct as well (only half joking).

Best regards,

--
DoubleF

[Dibyendu Majumdar]

On Wed, 12 Sep 2018 at 08:29, Dirk Laurie <***@gmail.com> wrote:
>
> Op Wo., 1 Aug. 2018 om 00:16 het Dibyendu Majumdar
> <***@majumdar.org.uk> geskryf:
> >
> > Are there features in Lua that could be removed to create a simpler language?
>
> We've had a lot of fun playing that game, let's get serious. Let's do it.
>

It's easy actually because isn't Lua 5.1 still the most widely used
version? So for a start one could remove all features added since 5.1.

I personally don't use some features, such as coroutines, '...',
repeat until, etc. I also don't use inheritance.

But my real interest is in getting rid of details that cause issues
when generating efficient code.

[Tom Sutcliffe]

On 12 Sep 2018, at 8:28 am, Dirk Laurie <***@gmail.com> wrote:
>
> Op Wo., 1 Aug. 2018 om 00:16 het Dibyendu Majumdar
> <***@majumdar.org.uk> geskryf:
>>
>> Are there features in Lua that could be removed to create a simpler language?
>
> We've had a lot of fun playing that game, let's get serious. Let's do it.
>
> It's as easy as just not using the features that we would remove. Try
> coding that way for say a week. You will find that some things are not
> really missed, others you simply can't keep yourself from using no
> matter how hard you try to avoid them.
>
> I'm looking forward to trying to use "repeat ... until" as my only
> looping and local blocking construct :-)
>

It struct me today that "dofile" must be the only function in the standard library that is entirely implementable using other stuff in the standard library, and as such is something of an oddity given there is very little redundancy and "more than one way to do it" anywhere else.

(I suppose "assert" is in that category too, but it's too useful as the inverse to pcall to want to remove).

Unfortunately most of my Lua work at the moment is in an established largeish codebase, and writing clear legible code that adheres to the coding standards of the project is much more important than attempting any experimentation :-) I like the idea though!

Cheers,

Tom

[Dirk Laurie]

Op Ma., 17 Sep. 2018 om 13:46 het Tom Sutcliffe <***@me.com> geskryf:

> It struct me today that "dofile" must be the only function in the standard library that is entirely implementable using other stuff in the standard library, and as such is something of an oddity given there is very little redundancy and "more than one way to do it" anywhere else.

Several others:

'pairs' is equivalent to:

function(tbl)
local meta = getmetatable(tbl)
local _pairs = meta and rawget(meta,"__pairs)
if _pairs then return _pairs(tbl)
else return next,tbl
end
end

In particular, if you know that you never set __ipairs, you can code
just "for k,v in next,tbl" rather than "for l,v in pairs(tbl)" and
save yourself three keypresses.

Also ipairs (obviously so; the manual practically spells out the
code), loadfile and print if you grant me the io library, tonumber and
tostring if you have not killed string metamethods, pcall if we still
have xpcall.

I suspect somebody will be able to fiddle some more if
debug.getregistry is intact.