Thoughts on system enhancements

[Bill Cox]

Andrew has more to add here, but here' some ideas I'd like to share.

Today type constraint expressions are compared to datatypes as a post-process.  I'd like to support more operators on types that return types, so that type expressions have datatypes at every node.  A type constraint can then be checked by seeing if an argument's datatype is a subtype of the constraint, without traversing expression trees.

I haven't thought about sub-typing as in traditional class inheritance.  I think we should keep Rune compatible with such an upgrade, but it is not needed for the initial bootstrap.  If someone wants to dive in and build it, however, they are free to.

I'd also like to add an "isType" bit to the Paramspec class, which helps describe a function signature's parameters.  There is hackish scheme in the C Rune compiler where variables are checked to see if they are used in any expressions as values, and if they are, the variable is marked as "instantiated".  Non-instantiated parameters are not passed to the function, which is why we can pass types to functions without generating illegal LLVM IR code.  Whether a parameter is a type vs a value should be part of the function signature.  We should add type expression syntax to show that we expect a type, not a value.  Maybe something like:

func newHashTable(keyType: Type, valueType: Type) -> HashTable<keyType, valueType> {

    ...

}

Maybe we could also convert a type constraint into a constraint that requires types rather than values, something like:

func printType(ty: matchtypes(Int | Uint | Float | string | bool)) {

  typeswitch ty {

    Int => ...

    Uint => ...

    Float => ...

    string => ...

    bool => ...

  }

}

If we did something like this, then a "MatchesTypes" bit or something like that should be added to the Datatype class to indicate that the datatype matches only types, not values.  This is in keeping with the idea above of using type operators to make new types rather than comparing datatypes to type constraint expressions as a post-process.  This scheme would allow us to propagate type constraints just like propagating types.

Bill