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:
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.
mid-progress report:
So far, constrained types are parsed into
CTY
s, which contain constraints asCX
s. The new syntax isFor example, Haskell's
==
would have typeThis expression (when parsed) is a
CTY
, and the sub-part(Eq a)
is aCX
.The entire Coalton system doesn't yet fully really understand
CTY
. Some functions takeTY
, others takeCTY
, 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 theENTRY
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 ofderive-type
will take that into account. It will collect these constraints into a list and house them in a finalCTY
:The H-M implementation is sloppy though; there is no simplification of constraints. For instance,
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.