lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> On Sat, May 05, 2001 at 02:43:25AM -0700, Paul Hsieh wrote:
> > Actually, now that I've thought about both a little more carefully,
> > I realize, that the LISP version is actually somewhat faster, since
> > it does not need to *REPARSE* the "macros" from scratch; they have
> > already been at least tokenized before execution time.  So its the
> > same power, but somewhat slower in Lua.
> 
> I'm still not convinced that dostring has the same power as LISP
> macros. (Disclaimer: I am not a LISP expert.) For starters, dostring
> does not honor scope. Consider, for example:
> 
> lua>>> function a() \
> lua... local b = 123 \
> lua... dostring("print(b + 2)")\
> lua... end
> lua>>> a()

Well the stuff inside of dostring() is going to be in a new scope (the way it is 
implemented makes this obvious).  But the obvious next attempt:

> function a() \
local b = 123 \
dostring("print(%b + 2)")\
end
a()

didn't fair any better.  It produced the following error messages for me:

error: cannot access upvalue in main;
  last token read: `b' at line 1 in string "print (%b+2)"
stack traceback:
   1:  function `dostring' [C]
   2:  function `a' at line 3 [string "function a() ..."]
   3:  main of string "a()" at line 1

> This won't work, while to the best of my knowledge, LISP macros handle
> this situation just fine.

Right.  In fact there doesn't seem to be a clean way to pass local variables at all.
Using globals for everything isn't going to work if the code is re-entrant.

> [...] Another problem is that if you define
> functions in the dostring() call, these end up in the global scope,
> which often is very undesirable. I see no way to force them to use
> local scope, instead.

Well, I wouldn't call "using global scope" necessarily a bad thing.  However, a way 
to share a local scope interface seems to be missing.  It seems to be that something 
like:

    dostring2 ("...", var1, var2, var3, ...)

which would just give var*, upvalue status would probably be good enough (return 
values would be communicated through a table which would have to be specified as one 
of the upvalue parameters.)

Incidentally, if you create a local table, is it properly cleaned up open closure of 
the scope?  I'm going to assume the answer is yes, but I have not read this 
explicitely in the documentation.  Is the clean up process just a natural 
consequence of garbage collection (once a table has no refs to it, does it 
immediately becomes a gc candidate)?

--
Paul Hsieh
qed@pobox.com