lua-users home
lua-l archive

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

On Mon, Jan 30, 2012 at 11:30 AM, Enrico Tassi <> wrote:
> IMO, prototypes really benefit from static typing. You don't know how to
> solve a problem, so you change every basic design decision a lot of
> times and the compiler drives you to all the code spots affected by your
> change.

The conventional wisdom goes the other way; that dynamic languages are
like sculpting in clay, and it's easier to put a prototype together
without a static type system getting in the way.  For larger
applications type annotations give some guarantees about code changes
and make refactoring a lot easier.  Obvious enough for Lua and Java,
but my little experience with Go suggests that a static inferred-type
language can be almost as nimble (Go interfaces are like compile-time
duck typing).

Constructing an appropriate type system for Lua would be an
entertaining exercise for the student but I don't know how far
explicit type annotations for function arguments etc would take us
towards IDE Nirvana. Fabien and his team at Sierra is wrestling with
this approach, and he's contributed an implementation of argument
modifiers to ldoc. Currently, instead of "@param name first name of
person" you can write "@tparam string name first name of person" where
the type of the argument can be captured and made available for
further analysis.  The idea is that if the signatures of each function
in an API can be more specified, then more intelligent features like
auto-completion can be provided.  The trade-off is that such APIs need
richer documentation, but it would not be much more work than existing
*Doc comments.

It would be useful if these type annotations had a regular parseable
structure so that they at least could be checked for correctness.
Currently I would represent 'a map with string keys and integer
values' as {[string]=int,...}.  But that's a 'serving suggestion' as
they say on food packaging; just one way of specifying Lua types.

steve d.