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

[Alexander Gladysh <agladysh@...>]

On Sat, Jan 9, 2010 at 08:11, Ben Kelly <ranavin@gmail.com> wrote:
> 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.

> 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".

Looking at the change list, I get a feeling 5.2 is more about fixing
small language design defects and promoting some established practice
to the standard level. The limited scope of this update is a good
thing — changes are small and controllable.

The token filters (or other meta-stuff) you ask for are alone worth to
be a single feature in the next update, and that update should
probably be called 6.0.

If you take token filters specifically, I, personally, do not see wide
adoption of them (perhaps its just me though). There was a lot of hype
back then token filters were released, but now everything is quiet.

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

That is one of my pet feature requests as well. It is sad that it is
not in 5.2. Perhaps there is still a chance?

> 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.

There were a discussion on this list where this decision was
announced, you may search for it.

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

I think that because main Lua data type is still called table.

>        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?

Actually, table.pack is really useful when you need to pass vararg as
an upvalue to a new closure... I guess that is here to compensate for
not having first class varargs in a language.

>        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.

I've seen too many copies of Lua 5.1 code patched to support bitwise
operators. I hope this addition would stop that horrible practice.

However, I share Mike Pall's concerns on not reusing established
implementation of the library.

>        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.

This is being discussed in a parallel thread.

Alexander.