Re: Extending array types in Ravi

[Dirk Laurie <dirk.laurie@...>]

2015-11-03 0:22 GMT+02:00 Dibyendu Majumdar <mobile@majumdar.org.uk>:

> The problem with numeric indices is readability and error-proneness.

I'll go further, and say that the moment you code an explicit numerical
constant index, it is bad programming style.

> It is more readable to say:
>
> print(Employee.name)
>
> than say:
>
> print(Employee[1])
>
> But if there was a way to assign symbolic names to numeric values then
> maybe one could write:
>
> constant name = 1

LHF had this to say on named constants:

| Bottom line: there isn't a problem that needs to be solved by adding a syntax
| for constants. The parser might be smart and use the constant's index instead
| of the local's index, but they are both just an array access in the VM.

Of course, the Ravi philosophy is different :-) Names may in effect
be reserved and introducing a "constant" qualifier seems justified
when static typing is available. Go for it.

Of course, next thing is that people will start demanding that function
parameters could be declared constant, and before you rub out your
eyes you've got C++ with Ravi syntax, but that's all part of the fun, isn't it?

>
> print(Employee->name)

> The compiler would know that name is a constant and replace
> Employee->name with Employee[1]. The use of the '->' syntax is to
> distinguish between this transformation versus the standard Lua syntax
> of accessing elements by key.

The payoff is small if not nonexistent (no keystrokes saved). The compiler
could equally well recognize `name` in `Employee[name]` and translate
it to `Employee[1]`.

> local Employee : [] = { 'dibyendu', 'majumdar' }
>
> Above could be how an array of dynamic types is declared.

What performance benefits do you see in static-typing an array but
not its entries?