[Template-haskell] GADTs

Robert Dockins robdockins at fastmail.fm
Mon Aug 14 11:34:19 EDT 2006


On Aug 14, 2006, at 4:51 AM, Simon Peyton-Jones wrote:

> | Also, TH tries to present the completely sugared language to the  
> user;
> | otherwise it would probably work on something more like core.
>
> This really is a tension, and one I don't really know how to resolve.
>
> GHC does represent fully-sugared syntax, including even the  
> placement of
> parens.
>
> I don't think TH need go to these lengths.  TH generates code that we
> might read, but which is mainly intended to be compiled.  It's *also*
> intended to be processed by other TH code, so the smaller the TH data
> type, the better.
>
> I conclude that TH should avoid gratuitous syntactic sugar.  Anything
> that can be converted to a simpler equivalent form, should be.   
> Hence I
> rather think that infix operators in TH are a mistake.  What do they
> really buy us?  Similarly an if-expression, and arithmetic  
> sequence, and
> list expressions.   On the other hand, a list comprehension is much  
> more
> complicated to desugar, so probably deserves to be there.
>
> It'd be good to discuss this and perhaps agree some changes.
>
> Concerning data types, I think it'd be fine to present data types in a
> single, canonical representation as a data type, probably something  
> like
> the GADT style.  That'd be a breaking change, mind you.


I'd just like to voice my agreement with this general idea.  I might  
even suggest going one step further; divorce the world of TH from the  
Haskell front end altogether.  Specify that TH operates in a  
convenient core language which is general enough to cover all the  
interesting haskell extensions (say, Fc http://research.microsoft.com/ 
%7Esimonpj/papers/ext%2Df/).  Then, various implementations of TH can  
simply differ in the TH programs they accept (eg, a pure H98 impl  
might only accept the Fc fragment with sort TY).  But I think the  
important thing is to specify TH in a way that is at least somewhat  
independent of other haskell extensions.

Of course, the devil's in the details...


> Because there are design choices here, I'm dubious about getting  
> any of
> this into 6.6.  Time is very short, and we don't want to make a change
> that we re-change later.
>
> Simon




Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG





More information about the template-haskell mailing list