[Template-haskell] GADTs

[Einar Karttunen]

On 14.08 14:07, Bulat Ziganshin wrote:
> this means that TH competes with such tools as Lisp macros and C preprocessor.
> and imho, TH should evolve in the way that will eventually allow to
> include it in the Haskell standard. this means, in particular, that
> we should divide it into Haskell-compatible features and GHC
> extensions

Having a generic Dec that supports GADT in the most general form
possible would be good for standardization. Each implementation
would only generate the subset of legal definitions in that
implementation and complain if the user tried to use more
generic ones.

All standard data declarations can be easily expressed as a GADT.

This would make code work easier in different compilers with
different extensions.


> third, as you said, TH should simplify two different tasks - analyzing
> of existing Haskell code and generating new one. For that, we can
> allow to use full Haskell/GHC power in code constructed by user
> functions but at the same time pass to these functions already
> desugared code; i.e. make input data as simple as possible while allow
> to use in output data as much features as one want

Simple datatypes + intelligent constructors.


> another solution will be implementing desugaring functions that
> accepts full-fledged Exp/Dec/... and returns desugared one. this
> solution don't need any changes in existing code and can be
> implemented without any changes to core TH implementation, it's just
> additional user-level functions

This means that pattern matching will be always incomplete - which
is not nice.

> this will break almost all existing TH programs, made Dec
> ghc-specific and require incompatible changes that we should wait
> until ghc 6.8

Dec is already GHC-specific. I agree that 6.6 is too soon.

> on the other side, adding new variant to existing Dec type is
> obvious. one can then write desugarer that turns any type definition
> into GADT one

The more variants we add the harder using TH comes. Just version
the package and keep an old version installed alongside the new
one. Thus old libraries will be fine.

> so i propose to keep TH declarations a mirror of official H98 syntax,
> add new variants for GHC-specific extensions, and implement desugaring
> functions to simplify TH usage. at the last end, we can got official
> H2098 report where Haskell syntax defined in terms of Haskell data
> structures and desugarer as Haskell program :)

TH has never been H98. I think we should have the actual datatypes
as simple as possible to make pattern matching easy. Providing
intelligent constructor functions to support language constructs
should be the way.


- Einar Karttunen