​Dead Batteries

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Dibyendu Majumdar
On Wed, 15 Jan 2020 at 21:10, Sean Conner <[hidden email]> wrote:
>
> > Ditto for exposing metatables.
>
>   So what's the issue with exposing metatables?  Python has its own form of
> operator overloading.
>

It is not the concept of meta information but that the mechanism is
exposed. So now Lua is forever tied to supporting the mechanism.

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Sean Conner
It was thus said that the Great Dibyendu Majumdar once stated:

> On Wed, 15 Jan 2020 at 21:10, Sean Conner <[hidden email]> wrote:
> >
> > > Ditto for exposing metatables.
> >
> >   So what's the issue with exposing metatables?  Python has its own form of
> > operator overloading.
> >
>
> It is not the concept of meta information but that the mechanism is
> exposed. So now Lua is forever tied to supporting the mechanism.

  So in an ideal world, how would you have defined/implemented it?  You
*have* to expose *something* for it to be useful.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Dibyendu Majumdar
On Wed, 15 Jan 2020 at 22:09, Sean Conner <[hidden email]> wrote:
> > It is not the concept of meta information but that the mechanism is
> > exposed. So now Lua is forever tied to supporting the mechanism.
>
>   So in an ideal world, how would you have defined/implemented it?  You
> *have* to expose *something* for it to be useful.
>

Of course there is no ideal world and this is my opinion only. In my
experience exposing implementation details is always risky.

This is what probably happened:

1. We need to attach meta data to stuff.
2. We would like to reuse tables to store meta data.
3. Well why not allow users to set a table as meta table, problem solved.

I think it is 3) that is a problem. Because now Lua has no control
over what the user might do to the table.
We only needed an api to set the meta data. That way the
'implementation' would be hidden.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Steve Litt
In reply to this post by Dibyendu Majumdar
On Wed, 15 Jan 2020 20:34:59 +0000
Dibyendu Majumdar <[hidden email]> wrote:

> On Wed, 15 Jan 2020 at 16:59, Steve Litt <[hidden email]>
> wrote:
>
> >
> > But given the fact that Lua, as it has existed for the past five
> > years, is a pretty much perfect language, curating a group of
> > approved add-ons would be the best way to improve Lua.
> >  
>
> http://lua-users.org/lists/lua-l/2018-01/msg00392.html
> http://lua-users.org/lists/lua-l/2018-01/msg00513.html
> http://lua-users.org/lists/lua-l/2018-03/msg00096.html

All three of the preceding links look excellent to me.

SteveT

Steve Litt
January 2020 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Egor Skriptunoff-2
In reply to this post by Dibyendu Majumdar
On Wed, Jan 15, 2020 at 11:44 PM Dibyendu Majumdar wrote:
Mixing arrays and maps in a single data structure was a big mistake in my view!



Merging arrays with dictionaries is a step toward making Lua
both compact and powerful.
It has brought some minor problems to the language;
but IMO the step looks correct.

It seems that there is a possibility to make next step in that direction:
to merge Lua tables and Lua functions in a single data structure.

You may have noticed that there is a similarity between how we
construct an array and how we define a function:
   arr = {11; 22; 33}
   function func() local x=42; x=x*x; return x; end
In both cases, it looks like we store a sequence of elements in a container:
in the first line we store numbers, in the second line - Lua statements.
Assuming we have new basic data type "statement",
a function definition may be treated as an array constructor.
So, "func[2]" would be the statement "x=x*x"

Dictionary seems to be a right structure to store
a set of local variables defined inside a function.
For example, we could use expression "func.x" to access
internal variable x which equals to nil before invocation of the function
and equals to 42^2 after invocation.
Actually, these variables would not be "local" anymore
as they could be accessed from outside of the function.

Nested statements, such as "if a then b=b+1 else print(c) end",
are similar to nested tables.
We should consider "b=b+1" as a nested function inside the outer function.
Assuming "func[5]" is the statement "if a then b=b+1 else print(c) end",
we could obtain "b=b+1" by "func[5][1]".

In other words, a function contains its statements (in form of AST)
in its "array part" (in positive integer indices)
and contains its local variables in its "dictionary part" (in fields).

A bonus:
1) A function could modify its own code on-the-fly
by writing to its own "array part".
2) By indexing an inner block "func[2][3][4]" we could obtain access to
its local variable "func[2][3][4].z" which is usually inaccessible
due to lexical scope rules.

(thanks for reading this crazy idea)
Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Sam Putman


On Sat, Jan 18, 2020 at 2:44 AM Egor Skriptunoff <[hidden email]> wrote:

It seems that there is a possibility to make next step in that direction:
to merge Lua tables and Lua functions in a single data structure.

You may have noticed that there is a similarity between how we
construct an array and how we define a function:
   arr = {11; 22; 33}
   function func() local x=42; x=x*x; return x; end


you could have this data structure right now, in pure Lua!
```
local insert = table.insert
local func = {}

insert(func, function() func.x = 42 end)
insert(func, function() func.x = func.x * func.x end)
insert(func, function() return func.x end)

setmetatable(func,
   { __call = function(tab)
         for i = 1, #tab - 1 do
              tab[i]()
        end
       return tab[#tab]()
end})

func()
```

I'm not sure what you plan to do with it, but, there it is.

cheers,
-Sam.
             
      
   
 
123