[erlang-questions] Luerl - Lua in Erlang

Robert Virding <>
Mon Feb 20 14:41:15 CET 2012


Hi Henning, 

----- Original Message -----

> On 2/20/12 3:38 AM, Robert Virding wrote:
> > I have given some more comments in
> > http://news.ycombinator.com/item?id=3610332 .
> 

> > Suggestions are welcome.
> 
> >> Re ycombinator:
> >> "Lua is a nice, small, relatively clean language."

> I experience Lua as very magic, in the non-least surprising sense.

> It can be so overloaded that it can be hard to guess what a simple
> bit of Lua code really does. Which is maybe not ideal for an DSL

> Since __metatable is on the TODO list, maybe Luerl hasn't yet run
> into those waters.

I do implement metatables. What I meant was that in getmetatable and setmetatable I don't check for the __metatable key in the metatable, I just happily get/set the metatable. A bit of laziness from my side. 

> I'd expect challenges there because the magic stems from Lua's
> formidable small- & cleanness -- or maybe Erlang turns out a
> marvelous fit. Certainly a very exciting side of the experiment.

> >> "However, the interface between Erlang and Lua in luerl is
> >> definitely faster so for smaller amounts of work it may be
> >> better."

> This is a very exciting point - and all it needs for an answer to the
> 'practical use' question. I'm anxious to see how you will eventually
> implement the tables.

I now implement tables using orddict, it mightn't be the most efficient for larger tables but for smaller tables it is good. It is also an easy data-structure to explicitly handle, which I need to do in some of the libraries. The global data record, #luerl{}, contains a tabs field which is the table store. Tables are referenced by index in the store, 0,1,2,3,4,... . Initially the store is also an orddict but I have versions where it is an array, the process dictionary and ETS tables. It works through macros. Orddicts are easy to read when testing/developing. #luerl{} also has fields for free indexes and the next index into the table store. There is a simple garbage collector for freeing/reclaiming unused table indexes. 

You could vary the table implementation depending on their size; I have no feeling for how big tables get. 

I also use tables for the block/function environments. It could probably done more efficiently, but most of the environments I have seen are quite small. 

> To go for speed, wouldn't you have to make a choice based on table
> size? Isn't there an absolute threshold where lists and trees just
> become to expensive to 'udate'? I measured structures once and the
> cost of flat vs deep structures' mutations was as expected [1].

> Is it known lore from when on ets are more performant than, say,
> trees?

A bit difficult to say, it depends on the number of elements and their size. Ets is efficient on looking up elements, at least with their key, but copying large elements costs. I will get the different versions doing properly and do some proper timing. 

> The table structure in Lua has been endlessly debated on the Lua
> list. Good thing you are probably striving for a true image rather
> than a 'better' Lua. The temptations would be endless.

> However, if you were to restrict yourself to a version that e.g.
> leaves metatables out, it would not really be Lua, but as a DSL
> still very useful. Maybe -- even more so.

Metatables are IN, they are definitely one of the more powerful features of Lua. I definitely want a "proper" Lua so I am striving to do as lua does. 

Robert 

> Henning

> [1] http://www.eonblast.com/blog/cost-of-mutation/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120220/b805bf67/attachment.html>


More information about the erlang-questions mailing list