RE: splicing types

Robert

| disincluded from GHC 6.10 -- http://hackage.haskell.org/trac/ghc/ticket/1=
476).
| So I was wondering if 1)
| splicing types is inseparable from the  (harder?) problem of splicing pat=
terns
| and 2) if splicing types is something that will is likely at some point
| to be implemented (is it that a good solution isn't yet
| apparent, or that it's just not important enough for the goals of TH?)
| and 3) has this idea, or
| something similar, been explored (regardless of the fact that it won't
| work with TH as-implemented) before?

Interesting.  I hope that others will, like Claus, suggest other ways of lo=
oking at your problem.   For example, Max Bolingbroke in his SoC project is=
 thinking about programmer "annotations" or "attributes" that might propaga=
te robustly down the compiler pipeline.
        http://hackage.haskell.org/trac/ghc/wiki/Plugins/Annotations
Your example might serve as an interesting use-case for him.

You mention a special code generator -- who writes that?

>         val2 :: Ann Int (Omitted $(encT [|1000|]))

Could you instead write a declaration splice?
        $(sigEncode "val2" 100)
where sigEncode generates a suitable declaration?


But meanwhile to answer your questions

1) I think that splicing types is very much easier than splicing patterns; =
unlike the latter, splicing types raises few problems of principle.  The on=
ly one I remember is this. If you see this
        f :: Int -> a -> (a,b) -> a
then what you mean (adding the implicit forall) is this
        f :: forall a b. Int -> a -> (a,b) -> a
But if you see
        f :: Int -> a -> $(foo 3)
then what do you mean?  What implicit foralls are added?

2)  I don't think this is insoluble at all, but someone needs to work it al=
l out and implement it.  I have postponed doing this until sufficient user =
pressure arises!  It's just a bandwidth problem -- I am totally snowed unde=
r at the moment.  Would anyone care to help?

3) Claus's pointer to Oleg's stuff is relevant here I think.

Simon