[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua Observations/Questions
- From: Roberto Ierusalimschy <roberto@...>
- Date: Fri, 09 Jul 1999 10:59:48 -0300
> Using tagmethods for gc and setglobal would seem to be the answer, but
> things could easily get out of sync when local varibles are used.
I guess you only need the gc method. It tells you exactly what you want
to know: When a reference is released.
> That brings up a question i've been wondering about for a while --
> why are there no setlocal/getlocal tags?
Performance (mainly).
> Also, is there any documentation at all for the lauxlib functions?
> They look quite useful, but I can't find any documentation and there
> aren't comments in lauxlib.c describing what they do.
Those functions are not part of the official API. On the other hand, it is
quite safe to use them, because they use only the official API, and
therefore you can always copy them directly into your code if they become
unavailable in later versions.
The absence of external documentation tries to reflect this idea. You
should only use those functions if you know where they are and how to
get them if you need.
The absence of internal comments has no excuse except our slothfulness ;-)
But I hope it is not difficult to figure out what they do looking at
their code (most of them are very simple). You can also ask if you need
more help.
> Speaking of which, add me to the list of people who think that Lua
> really needs a boolean type. The whole "nil" issue for expressions
> makes me really uncomfortable with what is otherwise a really clean
> language.
Maybe (maybe!) that was not a good design. Anyway, I don't see how we could
change that now, without creating a major incompatibility. We could create
a new boolean type, and make the conditionals in the language to accept
both "false" and "nil" as false, but many people write code like
if a() == nil then ...
and other idioms that assume that nil is false and false is nil. (Scheme is
still today trying to get rid of Lisp's assumption that nil is false...)
-- Roberto