Re: Lua Observations/Questions

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

>From lua-l@tecgraf.puc-rio.br Wed Jun 23 18:23:59 1999
>From: Ken Rawlings <krawling@shooter.bluemarble.net>
>
>   Is there a general timeframe for the 3.2 release?

Real soon now, and I meant it! (hopefully this week.)

>   Speaking of strings being byte arrays, are there any plans to add
>   more operators to work with raw binary data?

"operators", no -- we intend to keep the syntax frozen as it is, except that
the preprocessor will be made more general (but not for 3.2).
What kind of functions for handling raw binary data would yoou like to see?

>> >  * Lua does not appear to be properly tail-recursive, which makes
>> You mean, it will be slow?
>
>   No, speed isn't a huge concern, since it's so easy to call a C
>   function. The problem is that the following function will blow up
>   the stack with a large n:
>
>   function tailR(n, curr)
>      if n == 0 then
>        return 1 * curr
>      else
>        return tailR(n-1, n*curr)
>   end

I think that the existence of tag methods for getglobal makes it impossible
for Lua to be tail recursive, because the tag method may return anything in
the place of tailR in your example.
However, 3.2 includes a TAILCALL opcode that is used for statements such as
	return f(a,b,c,d)
even if f is not the function being run at the moment.
I think the main use of the opcode is to make the calling function return
exactly the same results as f does.

>   My experience so far has shown it to be surprisingly fast for an
>   interpreter -- on the order of 3 times faster than TCL and Perl, and
>   about 50% faster than Python.

Like someone said, "Lua is the speed demon of scripting languages" :-)

--lhf