[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: High-level language continuum
- From: Paul Hsieh <qed@...>
- Date: Sat, 05 May 2001 22:40:31 -0700
> 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