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

[Dibyendu Majumdar <mobile@...>]

On 14 March 2018 at 14:55, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
>> My reaction was: What would you call this new language?
>
> I think "Lua" would be a great name :-)
>
> Every year or so the list has its recurrent discussion about the length
> operator and holes in sequences. Quite often, this discussion leads some
> people to propose that Lua needs an array type, different from tables.
>
> My current view is quite the opposite. The implementation of arrays on
> top of tables is not the source of the problem with holes. The tendency
> to view them as a different type is what blinds us to the real problem,
> which is that tables cannot have nils. Tables also have problems with
> holes, but they are less annoying, and so we think about it as a problem
> with arrays.
>
> Many years ago, we added booleans to the language exactly because we
> could not store nil in tables. 'false' is just a 'nil' that we can store
> in tables. ('true' is useless in Lua.) If tables could store nils, the
> language would not need 'false'.
>
> We will not make this change now, because of compatibility. But, the
> next time the list gets its annual discussion about length, it would
> be good to recall this proposal.
>

My opinion is that if introducing booleans was a kludge then this
proposal appears to be another kludge on top of an existing kludge. It
will make an already bad situation even worse for users of the
language.

I think the whole confusion is that an implementation detail (array
part) has leaked into the language / library as I guess originally Lua
just had associative arrays or maps.

It is actually relatively easy to add a table subtype that has a
defined 'length'. Not computed length but defined length. I already do
this in Ravi. Lua could adopt this approach - allow via syntax or API
call to mark a table as having a defined length. Such tables should
not allow metamethod on #, and should only allow the table to grow by
1 when entry is added to [#+1]. This is all prior art in the sense
that Ravi already does this. The only thing that I haven't been able
to figure out yet if there is a nice syntax for 'constructors' that
can enforce this - e.g. could one use []{ .... } or [ ... ]. The
latter may have some ambiguities.

I haven't had the time but at some point I will extend the current
Ravi array subtype to allow generic array subtypes - not just
number/integer ones.

In my opinion, Lua should either say there are no array semantics, it
is all a map; or provide an array subtype, rather than doing this type
of clever hack which is nonetheless a hack. For the sake of the poor
user.

Regards
Dibyendu