wip typeclasses

[stylewarning]

No description provided.

[stylewarning]

mid-progress report:

So far, constrained types are parsed into CTYs, which contain constraints as CXs. The new syntax is

(FOR <constraints> => <type>)

For example, Haskell's == would have type

(FOR (Eq a) => (fn a a -> Boolean))

This expression (when parsed) is a CTY, and the sub-part (Eq a) is a CX.

The entire Coalton system doesn't yet fully really understand CTY. Some functions take TY, others take CTY, others take both. If/when this PR is finished, this should be very seriously resolved (either accept one or the other).

The PR so far doesn't have any mechanism to define new type classes or instances. There's a paltry overloaded slot in the ENTRY struct, which (I intend, if not changed) to be used to indicate a symbol refers to a type class member.

Since constrained types can only originate from globally defined function names, as long as a constrained type is in the global type database, then the node-variable branch of derive-type will take that into account. It will collect these constraints into a list and house them in a final CTY:

COALTON-IMPL> (unparse-type (derive-type (parse-form '(coalton:fn (a) (coalton-user::binary-or
                                                                       (== 1 a)
                                                                       (gt 1 a))))))

(COALTON:FOR (EQ COALTON:INTEGER) (ORD COALTON:INTEGER) COALTON:=>
 (COALTON:FN COALTON:INTEGER
   COALTON:->
   COALTON:BOOLEAN))

The H-M implementation is sloppy though; there is no simplification of constraints. For instance,

COALTON-IMPL> (unparse-type (derive-type (parse-form '(coalton:fn (a) (coalton-user::binary-or
                                                                        (== 1 a)
                                                                        (== 2 a))))))
(COALTON:FOR (EQ COALTON:INTEGER) (EQ COALTON:INTEGER) COALTON:=>
 (COALTON:FN COALTON:INTEGER
   COALTON:->
   COALTON:BOOLEAN))

There's still tons TODO, but I'd say the next thing to do is start compiling nodes and determining how to pass dictionaries around. That in and of itself will generate a ton of work.