Re: 1-based indexing in Lua

[Coda Highland <chighland@...>]

On Thu, Mar 29, 2018 at 10:30 AM, Dong Feng <middle.fengdong@gmail.com> wrote:
>
>
> On Thu, 29 Mar 2018 at 01:52 Axel Kittenberger <axkibe@gmail.com> wrote:
>>
>> > Moreover, it is not strictly correct to say that Lua has 1-based
>> > indexing.
>>
>> Mixed 1-based and 0-based indexing is the worst possible state of affairs
>> regarding this for a programming system.
>>
>
> It's not if there is proper justification. 0-based indexing should be an
> "offset". It's justified in C because C array indexing is always an
> "offset". You can write:
>
> int a[3];
> 1[a] = 5;
> *(a+2) = 6;
>
> Not the case for all languages' arrays.

The argument isn't that it's absolutely bad for a language to have
1-based indexing.

The argument is that it's bad to MIX 1-based and 0-based indexing in
the same system, and unfortunately for Lua's design as an embeddable
and extendable language, that's exactly the case here. The vast
majority of applications that will embed Lua will use 0-based indexing
internally, and a similar majority of libraries that one might wish to
bind to Lua will also use 0-based indexing.

While it is of course possible to translate between the two at the API
level so that each language involved can operate using their own
preferred style, programmers that are working in both the host's code
and Lua code, or who are using the same library both directly and
bound to Lua, will have to mentally switch between the two indexing
styles, which increases the likelihood of human error.

Obviously, it's stuff that's usually going to shake out during testing
and debugging. But it's still a level of overhead that wouldn't be
there if host language and embedded language were in agreement.

On the other hand, it would be a BIGGER source of errors to CHANGE the
status quo after the ecosystem has been established. This is the
reason that I have never argued that Lua should change -- it's a speed
bump, but only a minor one, and one that any competent developer will
be able to manage with experience; the alternative is far worse.

/s/ Adam