Re[2]: Soft Types System Proposal

[Gunnar Zötl <gz@...>]

AOA> Gunnar Zötl wrote:
>> type restrictions for variables to be a compile-time thing only

AOA> Yes.

>> the compiler would somehow have to guess the type of a variable

AOA> Yes.

I think I got it now ;-)

AOA> It is a fairly simple pass: You propagate the types up from the leaves of
AOA> the syntax tree to higher levels. When you arrive at the top, you know all
AOA> your type by the type annotation and the structure of the tree.

It is fairly simple as long as you leave tables out of it. If you
also want to consider tables, esp. with metatables, for example use
them as objects, things become, say, more interesting. And I really
think that those things should not be left out in order for this to be
useful.

Remember that you can redefine a lot of operators to work on tables,
but the behaviour might be a bit different depending on the operator
you overload. Consider this:

do
  local mt = {
    __add = function ... end,
    __lt = function ... end,
    __le = function ... end,
    ...
  }
  function buildit()
    return setmetatable({}, mt);
  end
end

a = buildit()
b = buildit()

with appropriately defined functions for the metatable members, you
could do

c = a + b
c = a + 1
c = b + "a"

and

if a < b then ... end

but it is invalid to do

if 3 < b then ... end
if a < "x" then ... end

and, what's more, it is even invalid to do

if a < {} ...
if b < setmetatable({}, {}) ...

i.e. when e is a table with a different metatable than a or none at all.
(please excuse the weird inline object creation...)

This offers a lot of interesting problems such a typechecker should be
able to find, such as creating objects with a function but
accidentially give a new metatable to each instance, which makes them
uncomparable. Of course this would only really be a problem if you 
actually compare the instances, otherwise it would just be a waste of
memory, or even intended. This also means that you may not be able to
spot certain anomalies until you have finished checking the entire
skript.

Another area of interest are function libraries, where you never get
to know the actual types of the function arguments. The best you can
say for a function lib is that there are no type errors under certain
circumstances, which in turn are defined by the actual parameters
passed to the functions. A simple example for this:

function bla(a, b) return(a+b) end

Any type errors here?

With the addition of userdata you reach areas where you can't even
make reasonable guesses about a lot of issues at compile time.

I think an 'official' type checking program should be reasonably
complete at least for the builtin types. But this makes for quite a
complex beast, which will inflate the compiler by quite a few bytes.

So IMO the best way to tackle this would be to make it an external
program, written in lua, and independent of the compiler pass. This
way, you may even create objects in order to see what they can do.
Plus, while developing, you may not need a type checking pass on every
iteration, so there's also some time to be saved here :-)

closing notes:
- an object as mentioned above is not necessarily meant
to be an object in the OO sense, but any kind of data you might want
to model using  table
- my brain is halfway filled with slime at the moment, so this may
all be utter bullsh*t :-)

have a nice day,

Gunnar