replacing the Prelude (again)

[Malcolm Wallace]

> > The defaulting mechanism *only* applies to types constrained by
> > the original builtin Prelude.Num, not to the transformed class
> > HatPrelude.Num.
> 
> I did wonder how Hat tackled this.
> Out of curiosity what is the solution that Hat uses?

Hat doesn't have a solution.  When the lack of correct defaulting
causes Hat to generate type-incorrect code, the underlying compiler
will complain vociferously.  Our advice to users is to write `default
()' at the top of the module, then resolve the type errors they
get from the normal compilation so that defaulting is completely
eliminated.  The code will then go through Hat smoothly.

It isn't very satisfactory, but in practice, defaulting doesn't
really occur very often, so it isn't too much of a hardship.

Ideally, the solution is a language design issue.  Defaults are
currently very implicit, second-class things.  It would be much better
if we could have a more generalised defaulting mechanism, applicable
to any class.  For instance

    default Num (Integer, Double)
    default Monad (IO)
    default MyClass (MyType)

or something - at the least an association of a set of types with a
named class.  Maybe more is required.

> This adds an extra element of difficulty to the problem. I am trying
> my hardest to avoid needing the to import the original Prelude in 
> a transformed module - this requires quite a bit of desugaring in the
> transformation. 
> 
> For what reasons do you require the original prelude? 

Exactly the same reasons.  We want to do as little desugaring as
necessary in the transformation, so inevitably we need at least a
small part of the Prelude in scope.

Regards,
    Malcolm