lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

Asger Ottar Alstrup