[Template-haskell] Reification

John O'Donnell jtod at dcs.gla.ac.uk
Thu Nov 6 10:31:09 EST 2003


Hi Simon,

>I'm on the TH warpath,
>
Great!  And thanks for all the support.

>Question 1 ...
>  
>
I would prefer to get the whole reification all at once, with something 
like your Info, rather than having separate reifyFixity etc.

>Question 2
>
>The type checker may not know the full type of the thing. ...  So should we give up and refuse to give you f's type?  Or what?
>
What would be most flexible for the user is to return the best 
information that is available.  In the example:

>NB This can apply to top-level decls too:
>	f = 1+2
>	$( ... reify 'f... )
>	g = f + (4::Int)
>
>Because of the monomorphism restriction, the type of f is fixed by f's
>caller, which may be "after" the reification.
>
it might still be useful to find out that an approximation to the type 
is f :: Num a => a, even though that isn't the final type.  That would 
suggest something like

data TypeQuery a = ExactType a  | ApproximationType a

But it isn't clear to me whether ghc could even know whether it has a 
final, exact type!  Still, it would be helpful for ghc to gives the best 
information it has to hand; after all, if the type changes later on it 
will be a refinement of the type that was reported in the reification. 
 Is this feasible?

I'm coming across situations that are analogous to this in Hydra.  For 
example, a defintion might have a top level type like Clocked a => (a,a) 
-> a,
but the a will be refined to something specific, like Stream CMOS, later 
on.  The program transformation really needs to know the (a,a) -> a (and 
it needs to know that a is in the Clocked class), but it is irrelevant 
to know the specific type a.  So, I would like to get the best type ghc 
knows.

>I'm really not sure what to do here. 
>  
>
Me too - my ideas about the best thing to do often change after I've 
implemented something and experimented with it.  For exactly that 
reason, it's best for you to go ahead and release the new TH stuff; as 
long as core functionality isn't removed, I don't mind making changes to 
working code.  Eventually a stable TH will be important, but it's 
obviously too soon for that now!

Best wishes,
John




More information about the template-haskell mailing list