Haskell' - class aliases

John Meacham john at repetae.net
Fri May 2 07:33:54 EDT 2008


On Fri, May 02, 2008 at 11:54:13AM +0100, Simon Peyton-Jones wrote:
> Even more crumbs!  Is this fixpoint iteration (being careful to avoid
> infinite expansion) *really* essential to your proposal?  That would
> be a significant and unwelcome thing IMHO.
> 
> To be concrete, consider f :: (Foo a) => ...
> 
> In GHC, f really takes an extra dictionary argument for the class Foo.
> If aliases mean aliases in the sense of type synonyms (which I think
> you intend) you must expand Foo to find out whether f takes zero, one,
> or many dictionary arguments.  Furthermore, everyone must expand in
> precisely the same way, so that we agree on the order of these
> arguments.  That's reasonably simple if "expand" simply means
> "normalise"; but it's more complicated if there's a fixpoint algorithm
> involved.

Yeah, I do mean normalize I think. There is no run time representation
of class aliases at all so this issue doesn't arise. f will just take a
'Bar' dictionary argument. I am envisioning class alias expansion taking
place very early in the desugaring, certainly before any transformation
to ghc core and turning contexts into dictionary arguments. 

> So is this really crucial?

Probably not, minimal fixpoint calculations are just what I find the simplest
way to formally define/think about things. In this case, I am sure a
simpler straight up normalization algorithm can be used to get
equivalent results... but minimal fixpoints are so easy to implement in
haskell and formally well defined that I am not sure of the value of
specifying the extension in terms of it. It of course doesn't mean
compilers have to perform the fixpoint iteration, it is just a
declarative statement of what class aliases are equivalent to.

        John
 

-- 
John Meacham - ⑆repetae.net⑆john⑈


More information about the Haskell-prime mailing list