Re: Lua Observations/Questions

[Luiz Henrique de Figueiredo <lhf@...>]

>From lua-l@tecgraf.puc-rio.br Tue Jun 22 18:32:11 1999
>From: Ken Rawlings <krawling@shooter.bluemarble.net>
>
>  Congratulations to the Lua developers for creating an amazing piece
>  of technology. I recently discovered Lua and am constantly amazed at
>  how elegant, small, and usable it is.

Thanks, these are exactly our goals!

>  I've been trying to port the basic Lua library to Windows CE and have
>  run into several problems(most related to the amazing fact that 
>  the Windows CE C compiler doesn't have stdio.h).

This has been discussed in the list. See the archive.
The simple answer is of course that this Windows CE C compiler is not ANSI.
Lua is 100% pure ANSI C.
But see below.

>  * The basic library does file i/o in order to execute lua scripts
>    from disk. It seems like iolib would be a more natural place for
>    for this code, for portability issues.

Yes, but not in any essential way.
The parser depends only on the "zio" interface.
We have only implemented zio for stdio FILEs and byte arrays, but it should be
simple to add suppport for other sources, such as pipes, sockets, etc;
in particular, for whatever Windows CE uses.

>  * The basic library uses "printf", which has no meaning on systems
>    without a console.

In 3.2, there's only *one* "printf", in errorFB, and this is supposed to
be overridden by whatever is appropriate for systems that do not have consoles.
It should be trivial to replace this with a call to a Windows function to
put up a dialog box with the error message.

>    Would it be possible instead to perhaps have 
>    the host register a callback function that gets called for textual
>    output?

Like I said, this has been done in 3.2. The HISTORY says:

  + redirected all output in Lua's core to _ERRORMESSAGE and _ALERT

>  * Lua doesn't appear to have any knowledge of Unicode strings, since
>    all strings are manipulated as "char *". Are there plans to make Lua
>    Unicode-aware?

Yes, but this is not a simple issue, so don't hold your breath.

>  * Is it safe to have a Lua function(called from lua_dostring()) call a C
>    function, which then calls lua_dostring() itself?

Yes.

>  * Can multiple instances of the Lua interpreter be used inside one
>    process?

Yes. But see below.

>    The presence of one lua_state("L") shared globally is
>    worrisome -- can it be shared by multiple interpreters?

Yes. You can have multiple, simultaneous states, but only one is active
at any one time. There's no sharing between different states.
We have plans to move this state variable into the argument list, so that
Lua will be completely thread-safe, with no global variables.
Maybe in version 4.0.

>  * Is it possible to do binary I/O in Lua? The iolib seems to be
>    text-file specific.

Strings in Lua are actually simply byte arrays.
So, something like write"\027XYZ\000\0001EOF" works.

>  * Lua does not appear to be properly tail-recursive, which makes
>    me hesitate to write any algorithms recursively. Is this something
>    that is important to anyone else?

You mean, it will be slow?
I doubt that this will make any difference in your programs, but let us know.
The overhead of interpreting bytecodes is actually very high -- and even then,
Lua is one of the fastests languages around.

>  * I've been working with Java for a few years, so i've become
>    wary of the "stutter" normally associated with Garbage Collection.
>    Does Lua's GC have this problem when applications become large?

I haven't seen people complaining about this yet.
--lhf