Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interesting things about the Lua interpreter (2020)

thesephist.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Interesting things about the Lua interpreter (2020)

#31

Post by xvilka »

VWWHFSfQ wrote: post #20
sireat wrote: post #18

I suppose that's the price for the small core but I do wish Lua had string interpolation. Instead there are like 5 hacky ways to do it: http://lua-users.org/wiki/StringInterpolation

As with nearly everything in Lua, if you want bells-and-whistles then you need to find a library. I've been writing a lot of extensions in Rust using mlua [1] which has been fantastic. I've written so much FFI code for Lua it's ridiculous. Rust mlua has been a total game-changer for me. [1] https://github.com/khvzak/mlua

I wish there was a Lua implementation in pure Rust (I understand about likely performance degradation compared to LuaJIT). There's incomplete Luster[1], but it's still unusable.

[1] https://github.com/kyren/luster

Re: Interesting things about the Lua interpreter (2020)

#32

Post by ColonelPhantom »

VWWHFSfQ wrote: post #22
Lyngbakr wrote: post #21

Earlier quoted context omitted.

mlua looks amazing. Is that the go-to library for Lua bindings in Rust or are there still several options jostling for position?

mlua is pretty much the standard for Rust at this point. There are a few others but they're not nearly as comprehensive and they all suffer from various safety issues that require unsafe{}. mlua doesn't require any unsafe usage in its API.

I thought rlua was safer than mlua? Am I mistaken there and has the situation perhaps changed, or are you claiming rlua requires you to use unsafe{} in various places?

Re: Interesting things about the Lua interpreter (2020)

#33

Post by cjohnson318 »

xenadu02 wrote: post #25
ithkuil wrote: post #13

Earlier quoted context omitted.

This. Some CPU architecture even blur the line between hardware registers and stack slots: register windows! Indeed what matters is whether each instruction addresses operands explicitly (registers) or implicitly (top of the stack)

The funny part is all modern CPUs use register renaming (with a 100s deep register file) so they're effectively SSA machines if you squint.

What's an SSA machine? Is it this, from Wikipedia? https://en.wikipedia.org/wiki/Static_single-assignment_form

Re: Interesting things about the Lua interpreter (2020)

#34

Post by ithkuil »

astrange wrote: post #29
xenadu02 wrote: post #25

Earlier quoted context omitted.

The funny part is all modern CPUs use register renaming (with a 100s deep register file) so they're effectively SSA machines if you squint.

Having so many registers but only a few register names helps because you don’t have to save/restore them all in context switches.

The main advantage is that you can keep the size of each instruction small. The more "architectural" registers, the more bits you need to encode each operand in all instructions. The larger the code, the more time is spent fetching the code from RAM and more i-cache is required.

So how does having a larger "microarchitectural" register file help?

Regiater renaming is used to eliminate false data dependencies arising from the reuse of registers by successive instructions that do not have any real data dependencies between them.

This allows independent instructions to be executed in parallel even if seems that you'd have to wait until a regiater is freed up.

Re: Interesting things about the Lua interpreter (2020)

#35

Post by edflsafoiewq »

deathanatos wrote: post #15

I'd love to see upvalues diagrammed as they are represented in memory. It sounds like the stack is perhaps a Stack , where each Frame contains the locals for that stack frame; then a coroutine just needs to keep a pointer to the stack frame it is closing over. (And then, Frame does too, recursively, incase there is more than one scope being closed over.) This would be extremely similar to … most any other language ……

> multiple-return is pretty much unique to Lua (vs. returning a tuple)

Multiple returns are from Common Lisp (I don't know if the history goes back further though), and they aren't tuples. They're the return-position analogue of what are default arguments in argument-position; like default args allow callers to ignore arguments they don't care about, multiple returns allow callers to ignore the return values they don't care about. You can add a secondary return value to a function without breaking existing callers, just like you can add a new default arg.

Re: Interesting things about the Lua interpreter (2020)

#36

Post by kazinator »

I made some seemingly similar design choices in TXR Lisp (not knowing anything about Lua or its internals).

- register based VM with 32 bit instruction words holding 6 bit opcodes.

- closures that start on the stack and are moved to the heap.

- single pass compiler with no SSA, Lisp straight to code - but with additional optimization, informed by control and data flow analysis, done on the VM assembly code.

Re: Interesting things about the Lua interpreter (2020)

#37

Post by vvanders »

ivoras wrote: post #14

Lua's simplicity is sometimes it's real selling point. I was just today searching for a small scripting language to implement in a mobile app in .net, where app size is a premium, and it turns out that the smallest useful JavaScript interpreter is at least 3x the size of a Lua interpreter. I do believe that an un-bloated JavaScript language from when it was just invented would be simpler than Lua (as both were design…

Tables + metatables are awesome, I've seen full OOP, composition based design various forms of dynamic dispatch all built on those simple mechanisms.

One fun thing we did with co-routines was build literate-style scripting for our designers to define AI routines. They could write them in a linear/semi linear way with yield() that allowed them to script all sorts of interesting behaviors without extensive programming knowledge.

We also ran the whole thing inside a 400kb pre-allocated block, it's an incredible powerful, embeddable language.

Re: Interesting things about the Lua interpreter (2020)

#38

Post by mftb »

munificent wrote: post #6
mftb wrote: post #3

The Lua interpreters, "upvalues" sound suspiciously like the results of Tcl's, "upvar", can anybody comment on how similar they actually are?

I don't think there's any deep connection. "upvar" in Tcl is a language feature. Upvalues in Lua are purely an implementation detail of the interpreter. If you want all the gritty details, a chapter of Crafting Interpreters walks through a complete implementation of Lua's approach to closures: http://craftinginterpreters.com/closures.html

Cool, Crafting Interpreters is on my list anyway, so I'll check it out, ty.

Re: Interesting things about the Lua interpreter (2020)

#39

Post by mftb »

ufo wrote: post #9
mftb wrote: post #3

The Lua interpreters, "upvalues" sound suspiciously like the results of Tcl's, "upvar", can anybody comment on how similar they actually are?

Nowadays the upvalues in Lua are bona-fide lexical scoping a-la Scheme or Javascript. However, the name comes from Lua 4.0 where the upvalues worked in a more unusual way. Not in the same way as Tcl though, but just as surprising for the uninitiated. https://www.lua.org/manual/4.0/manual.html#4.6

Interesting ty, will review.

Re: Interesting things about the Lua interpreter (2020)

#40

Post by xanathar »

ivoras wrote: post #14

Lua's simplicity is sometimes it's real selling point. I was just today searching for a small scripting language to implement in a mobile app in .net, where app size is a premium, and it turns out that the smallest useful JavaScript interpreter is at least 3x the size of a Lua interpreter. I do believe that an un-bloated JavaScript language from when it was just invented would be simpler than Lua (as both were design…

The concatenation operand makes sense though... String concatenation is hardly addition and for weakly typed languages it's easy for the + operator to end up doing the wrong thing instead of failing.

Out of curiosity: what Lua interpreter did you pick for your .net project?

Post reply on HN