Re: TypedLua

[Andre Murbach Maidl <andremm@...>]

> I'm not sure I agree with Bracha's "errors as warnings" policy either.
> In my experience, the vast majority of type errors correspond to
> legitimate problems. Even in cases where they don't correspond to
> runtime errors, they often do correspond to bad design. Allowing
> programmers to ignore errors may give them some extra flexibility in a
> few corner cases, but far more often it will allow them to ignore errors
> which genuinely need to be fixed.

Same feeling here.

> I was actually talking about "Semantics and Types for Objects with
> First-Class Member Names". The subtyping parable in section 4.3.1
> presents an issue that you would probably have to deal with to enable
> typed, configuration style code. I was thinking about this yesterday,
> and I realized that presence annotations would probably be overkill for
> typed lua, especially considering how elegant its table types are
> shaping up to be.

I haven't reached this paper yet, and it definitely is something that I
should include in my related work. Many thanks for pointing me to it.

> My idea, which wouldn't involve altering the type system, works as
> follows. When checking an table argument's type, I imagine that you
> would be using bidirectional type-checking in check mode. When checking
> a table constructor expression, you know that any unmentioned entries
> are definitely absent. If the expected table type contains keys which
> are not mentioned in the constructor being checked, you would include
> those keys in the computed type, giving them type Nil.

Sounds an elegant solution.