Thought experiment: what would you remove from Lua

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

Re: Thought experiment: what would you remove from Lua

Francisco Olarte
On Sat, Sep 8, 2018 at 7:25 AM, Axel Kittenberger <[hidden email]> 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 )

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Albert Chan

> On Sat, Sep 8, 2018 at 7:25 AM, Axel Kittenberger <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sam Pagenkopf
In reply to this post by Francisco Olarte
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 <[hidden email]> wrote:
Hi:

On Sat, Sep 8, 2018 at 6:24 AM, Sam Pagenkopf <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
It was thus said that the Great 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


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

pocomane
In reply to this post by Albert Chan
On Sat, Sep 8, 2018 at 7:26 AM Axel Kittenberger <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>
> F.O.S.
> ( Note/disclaimer: I  like function a(x) better )
>

Same for me!

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Francisco Olarte
In reply to this post by Albert Chan
Albert:

On Sun, Sep 9, 2018 at 3:43 PM, Albert Chan <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Francisco Olarte
In reply to this post by pocomane
On Mon, Sep 10, 2018 at 10:11 AM, pocomane <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
Op Ma., 10 Sep. 2018 om 13:23 het Francisco Olarte
<[hidden email]> geskryf:

>
> On Mon, Sep 10, 2018 at 10:11 AM, pocomane <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

pocomane
On Mon, Sep 10, 2018 at 1:34 PM Dirk Laurie <[hidden email]> 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...

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Gé Weijers
In reply to this post by Sean Conner

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 <[hidden email]> 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




--
--

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

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

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Gavin Wraith
In message <[hidden email]>
          Roberto Ierusalimschy <[hidden email]> 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 ([hidden email])
Home page: http://www.wra1th.plus.com/

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Aapo Talvensaari
In reply to this post by Dibyendu Majumdar
On Wed, Aug 1, 2018 at 1:16 AM Dibyendu Majumdar <[hidden email]> 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 :-).



Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
Op Wo., 12 Sep. 2018 om 00:44 het Aapo Talvensaari
<[hidden email]> geskryf:
>
> On Wed, Aug 1, 2018 at 1:16 AM Dibyendu Majumdar <[hidden email]> 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".

Reply | Threaded
Open this post in threaded view
|

Practical experiment: what could you avoid using from Lua?

Dirk Laurie-2
In reply to this post by Dibyendu Majumdar
Op Wo., 1 Aug. 2018 om 00:16 het Dibyendu Majumdar
<[hidden email]> 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 :-)

Reply | Threaded
Open this post in threaded view
|

Re: Practical experiment: what could you avoid using from Lua?

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

Reply | Threaded
Open this post in threaded view
|

Re: Practical experiment: what could you avoid using from Lua?

Dibyendu Majumdar
In reply to this post by Dirk Laurie-2
On Wed, 12 Sep 2018 at 08:29, Dirk Laurie <[hidden email]> wrote:
>
> Op Wo., 1 Aug. 2018 om 00:16 het Dibyendu Majumdar
> <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Practical experiment: what could you avoid using from Lua?

Tom Sutcliffe
In reply to this post by Dirk Laurie-2
On 12 Sep 2018, at 8:28 am, Dirk Laurie <[hidden email]> wrote:

>
> Op Wo., 1 Aug. 2018 om 00:16 het Dibyendu Majumdar
> <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Practical experiment: what could you avoid using from Lua?

Dirk Laurie-2
Op Ma., 17 Sep. 2018 om 13:46 het Tom Sutcliffe <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Petri Häkkinen
In reply to this post by Sean Conner

> On 7 Sep 2018, at 23.41, Sean Conner <[hidden email]> 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
12345