[Template-haskell] GADTs

Bulat Ziganshin bulat.ziganshin at gmail.com
Mon Aug 14 06:07:01 EDT 2006


Hello Simon,

Monday, August 14, 2006, 12:51:08 PM, you wrote:

> 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 propose to place this question into more global frame - what is a TH
unique place among other Haskell extensions? imho, TH is (at least) an
attempt to develop macro-preprocessing feature that is able to
accomplish tasks in ways not accessible to the bare language

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

second, it will be interesting to implement TH as true preprocessing
tool generating Haskell code that can be compiled by any *hc

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

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


> 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.

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

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

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 :)


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com



More information about the template-haskell mailing list