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⑈ _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime