Re: Soft Types System Proposal

[Asger Ottar Alstrup <aalstrup@...>]

I agree that an optional type system in Lua would really make a huge 
difference for us.

We are using Lua today, and are pretty happy with it - except that we 
mostly work with statically typed programming languages. That means we 
tend to make a lot of simple keytyping mistakes which are not caught by 
the Lua interpreter until runtime. We waste a lot of time chasing up 
such simple typing mistakes, which are normally caught by our compilers 
in the other programming languages.

We know of lualint and luaparse, and they help to some extent, but a 
built-in optional type system in Lua itself is to prefer.

In your proposal, it seems that the typename is simply any identifier. 
This is a nice idea. However, I would suggest that some basic types like 
"number" and "string" corresponding to the built-in types are 
recognised, and checked harder by the compiler.

As a principle, the type system of Lua should be pretty simple, like the 
rest of the language is, but still expressive enough to allow enforcing 
error-checking on elaborate datastructures. To allow that, I suggest 
that the type system is strict in the sense that there is no automatic 
type conversions. So, if two locals are declared as type1 and type2, 
those types are incompatible even if they both hold a number. In order 
to express type conversion, I suggest to include a special type "any" 
which is also the same as the default type for all items in the 
language. The type conversion can then be declared with an identity 
function that takes an "any" parameter and returns the type you want to 
convert to.

The syntax could be close to your proposal (although I think the 
typename should be optional always to preserve backwards compatibility), 
or a Haskell-type of syntax where the type information can be declared 
in separate lines.

Also, it seems you omit possibility to declare the return type of 
functions, which I think should be there.

I do not think it is necessary to extend the runtime or API with type 
information to be useful. Of course that would be nice, but a pyre 
compile time mechanism which did not affect the bytecode (except for 
optimisations) or the API would be very useful in it self.

But the most important thing is to get some kind of type check into the 
compiler at compile time. That will help catch a lot of common problems. 
As long as the typing is optional, other users will not pay for it.

Typing information give you these advantages:

1) More static checks by the compiler at compile time
2) Potential performance, since some type checks can be optimised away
3) Self-documenting code if you use intelligent type names

I think that's an offer most programmers will take.

Regards,
Asger Ottar Alstrup