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

[Hisham <h@...>]

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