Re: [ANN] Lua 5.2.0 (work1) now available

[Ben Kelly <ranavin@...>]

Luiz Henrique de Figueiredo wrote:
> Lua 5.2.0 (work1) is now available at
> 	http://www.lua.org/work/lua-5.2.0-work1.tar.gz
> 
> All feedback welcome. Thanks.
> --lhf

Based on a quick look through the documentation...

	Stuff that isn't in here that I wanted:

I'm sad that there's still no builtin macro, token filter, or other
compile-time metaprogramming support in the language. I have a lot of
other things I'd like to see (try/catch instead of (x)pcall hacks, for
example), but all of those are just subsets of "I want to be able to
modify the language without stepping outside the language".

I'm also sad that varargs is still not first-class, so code like:
    function f(...)
        return function() print(...) end
    end
remains illegal.

For the Name lexeme, what's a "locale-dependent character"? Anything
outside ASCII? Why not just allow any character that isn't otherwise
used or unambiguous? This is both a suggestion and a question; I would
like to hear your reasoning.


	table.*
This module is still called 'table' and not 'list'?


	table.pack
the utility of this is questionable; it's a one-liner in lua, and isn't
that usually an argument *not* to include something in the standard
library in these parts?


	bit.*
I like having a bitwise operators library, but it's only occasionally
useful to me; I tend to reach straight for the heavier stuff (like
vstruct). On the plus side, this will make the next version of vstruct
faster and easier on the eyes.


	lexical environments
I like these but I won't be using them much, because most of the time
I'm using...


	setfenv/getfenv
WHY ARE YOU TAKING THIS OUT? lexical environments and loadin are not a
replacement; I tend to rely a lot on creating a function once, and then
altering its environment to change its semantics, rather than creating
it many times with minor source alterations. I would very much like to
know the underlying reasoning behind the deprecation of getfenv/setfenv.

That said, something that lets you, given a function, create a new
function with the same code and a different environment (without needing
to dump->load it and thus destroy its upvalues) would also suit my
purposes. As it is, though, it looks like setfenv is being removed
without replacing it with anything.


	__len
Yay! Fixing this obsoletes pretty much all of my uses of newproxy.


That's all so far; I'll provide more feedback as I play with it more and
think of more things.

	Ben