Re: Simulating Lua states in Lua with only 250 lines of code

["Soni L." <fakedme@...>]

On 26/06/15 07:27 PM, Sean Conner wrote:
> It was thus said that the Great Soni L. once stated:
> > Lua States (from C) work well for sandboxing. I don't see why we
> > SHOULDN'T have them available as coroutines. I believe the debug API
> > should make Lua side just as powerful as C side (at least when it comes
> > to VM interaction).
>    Then wrap Lua up into a module:
>
> 	lua = require "lua"
>
> 	L = lua.Lnewstate()
> 	L:gc('stop')
> 	L:Lopenlibs()
> 	L:gc('start')
But that looks nothing like Lua!

lua = require "lua"

L = lua.newstate() -- Luaism: optionally pass extra arguments for 
allocator/etc
L:gc('stop')
L:Lopenlibs() -- whatever
L:gc('start')
local r1, r2, r3 = L:pcall(L._G.f, ...) -- Luaism: varargs. and multiret.
> 	...
>
>    -spc (Or instead of the entirety of Lua, just enough to sandbox like you
> 	can in C ... )
Lua is a programming language. You should be able to use it to its 
fullest extent from itself. You don't need to use assembly to be able to 
use all of C's features: you can use all of C's features from C itself. 
Same goes for Java (altho Scala is more powerful), and many other 
languages. Why should it be different with Lua?

My change also doesn't break any existing code. It also requires you to 
use the debug library. (Java's reflection = Lua's debug... Well actually 
Java's reflection > Lua's debug, beause Java's reflection lets you do 
much more than Lua's debug.)

--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.