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

11–20 of 44 posts

Re: Interesting things about the Lua interpreter (2020)

#11

Post by ufo »

giraffe_lady wrote: post #8
munificent wrote: post #6

Earlier quoted context omitted.

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

I'm not sure about that though I haven't used tcl in a while and was never an expert. I think tcl upvar allows you to explicitly do what lua's closure implementation automatically does. They aren't the same thing but they are closely related concepts and similar solutions to the same potential problem.

A big difference is that Tcl's upvar is dynamically scoped. A more appropriate Lua analog would be Lua's debug API (e.g. debug.setlocal)

Re: Interesting things about the Lua interpreter (2020)

#13

Post by ithkuil »

ufo wrote: post #4

> The 5.0 VM is a register machine, which operates on a set of virtual registers that can store and act on the local variables of a function, in addition to the traditional runtime stack. This is a common source of confusion, because the name "register machine" makes people think about CPU registers. However, the registers in a register VM are merely slots in the traditional runtime stack. The difference between a st…

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)

Re: Interesting things about the Lua interpreter (2020)

#14

Post by ivoras »

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 designed as "scripting" languages, not as main ones), but history didn't go that route :)

But... Lua is WEIRD! Weird nomenclature, weird string concatenation operand, 1-based arrays, too clever "tables" and "metatables" stuff.

Re: Interesting things about the Lua interpreter (2020)

#15

Post by deathanatos »

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 … and makes me wonder why Lua gives them such a unique name. It has been hard to really comprehend the Lua spec, when I've tried to understand that facet of it.

(I'd also argue that Lua isn't as simple as it is made out to be: primitives behave wildly different from objects, there's the 1-based indexing, multiple-return is pretty much unique to Lua (vs. returning a tuple, which other languages such as Python, Rust, and sort-of JS, go for; I think that's conceptually simpler).)

¹and note "pointer" here might really be "GC ref", to permit these to be GC'd as necessary, as closures can keep stuff alive far longer than normal.

Re: Interesting things about the Lua interpreter (2020)

#16

Post by hcs »

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 ……

It's not a Lua VM but the bytecode interpreter in Crafting Interpreters uses upvalues similarly and has some diagrams: https://craftinginterpreters.com/closures.html#upvalues

Edit: And yeah I don't think it's anything unique to Lua, it's an implementation detail of closures and lexical scope generally. It's a non-stack wrapper for closed-over variables, the end of the introduction to chapter 25 explains:

> For locals that aren’t used in closures, we’ll keep them just as they are on the stack. When a local is captured by a closure, we’ll adopt another solution that lifts them onto the heap where they can live as long as needed.

Re: Interesting things about the Lua interpreter (2020)

#17

Post by deathanatos »

hcs wrote: post #16
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 ……

It's not a Lua VM but the bytecode interpreter in Crafting Interpreters uses upvalues similarly and has some diagrams: https://craftinginterpreters.com/closures.html#upvalues Edit: And yeah I don't think it's anything unique to Lua, it's an implementation detail of closures and lexical scope generally. It's a non-stack wrapper for closed-over variables, the end of the introduction to chapter 25 explains: > For locals…

> For locals that aren’t used in closures, we’ll keep them just as they are on the stack. When a local is captured by a closure, we’ll adopt another solution that lifts them onto the heap where they can live as long as needed.

I sort of thought about mentioning something like that; that's in what I categorize as an optimization. (A good one, since the common case is that there probably isn't a closure at all in the scope, and the entire scope can thus be moved to the stack, kept out of heap, and not GC'd, reducing GC pressure.)

Re: Interesting things about the Lua interpreter (2020)

#19

Post by Lyngbakr »

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…

Weird? :) Surely all languages have their idiosyncrasies otherwise there'd be so very few to choose from? I mean, 1-based arrays can be found in several popular languages like R, Julia, & MATLAB. Taking the opposite perspective: there's so much in Lua that is familiar. I'd argue that coders who have never used it before could easily make sense of a Lua program. (I'll give you metatables, though — they're a bit unusual!)

Re: Interesting things about the Lua interpreter (2020)

#20

Post by VWWHFSfQ »

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

Post reply on HN