Re: [ANN] Lua 5.3.4 (rc1) now available

[Russell Haley <russ.haley@...>]

Is the makefile in the lua Github mirror different from the Makefiles
in the tarball on purpose or did I miss something?

Thanks,
Russ

On Sat, Jan 7, 2017 at 12:27 PM, Hisham <h@hisham.hm> wrote:
> On 5 January 2017 at 20:50, Lorenzo Donati <lorenzodonatibz@tiscali.it> wrote:
>> On 02/01/2017 18:39, Dirk Laurie wrote:
>>>
>>> 2017-01-02 17:05 GMT+02:00 Luiz Henrique de Figueiredo
>>> <lhf@tecgraf.puc-rio.br>:
>>>>
>>>> Lua 5.3.4 (rc1) is now available for testing at
>>>>         http://www.lua.org/work/
>>>
>>> ...
>>>>
>>>> Lua 5.3.4 also contains several internal improvements and
>>>> includes a revised reference manual:
>>>>         http://www.lua.org/work/doc/
>>>
>>>
>>> The most visible difference is the documentation of
>>> the length operator, which is now based on the notion
>>> of a border. This should go a long way towards getting
>>> rid of the perpetual posts about the non-intuitive default
>>> behaviour of the length operator. +1.
>
> I liked very much the improved description. I'd even change the second
> example to something like {nil, 20, 30, nil, nil, 60, nil} with
> borders (0, 3 and 6), so that, even though there are four nils spelled
> out, it would still have three borders (just to avoid a possibly
> incorrect lazy reading that "each nil makes a border").
>
>> I bet we'll shortly find someone arguing on how intuitive/useful the notion
>> of "border" is!
>
> A thought: one thing that could help squash the discussions about the
> length operator would be if the Lua reference manual (being the
> working definition of the language) spelled out some big-O guarantees
> to table operations (like the definition of the C++ STL does with
> regard to its data structures).
>
> This approach, while not tying the specification of the language to
> its implementation, would make it more explicit that:
>
> (a) the other behaviors for length that are typically proposed would
> incur some kind of trade-off (usually degrading either length or
> insert/delete to become linear in the worst case), and
> (b) the current unintuitive behavior for #t does bring pratical
> algorithmic benefits.
>
> -- Hisham
>