lua-users home
lua-l archive

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



On 07/08/16 06:53 AM, Duane Leslie wrote:



On 7 Aug 2016, at 06:36, Sean Conner <sean@conman.org> wrote:

It was thus said that the Great Soni L. once stated:

On 06/08/16 05:30 PM, Sean Conner wrote:
  You just need a Y-combinator:

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

    print(Y(function(rec, x)
            if x < 2 then
                return 1
            else
                return x * rec(x-1)
            end
        end)(5))

  That will allow you to call an anonymous function recurively from within
the anonymous function.  No need for _SELF in this case.

That doesn't solve the dynamic variable indexing issue.

  Oh, I'm sorry I failed to read your mind again.  I thought that was what
_SUPER was for.  I'm so sorry you have to reject MY ATTEMPT to give you
something you could use and grovel that I have to have your proposal
explained to me like I'm five.

  -spc (Why do I even bother?)

I appreciated the explanation.  I like learning ways to 'upgrade' a language with clever syntactic sugar without having to change the underlying language.  It gives the option to use much more powerful paradigms within a simpler language.

I personally think this _SELF/_SUPER thing comes unravelled with the requirement that it support dynamic variable lookups.  That adds an overhead to the runtime which I don't agree with.  If it was only statically declared lookups then it could be easily implemented as a custom parser that would actually generate standard byte-code.


This only needs 4 new opcodes:

IMOVE - R(R(A)) := R(B)
MOVEI - R(A) := R(R(B))
ISETUPVALUE - Upval[R(A)] := R(B)
IGETUPVALUE - R(B) := Upval[R(A)]

The actual functionality is just sugar for these 4 opcodes + tables.
It's free if you don't use it. And even if you do, it only causes overhead where you do use it, not in any of the surrounding code. This is way better than Python or JS. 



I miss that metalua didn't make the jump to 5.2/5.3, I'm often tempted to bring it up to date but for now I still find it easier to just modify the parser directly.  I think if metalua was current a lot of these feature requests could just be resolved with a metalua script.


--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.