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