[Template-haskell] GADTs

[Bulat Ziganshin]

Hello Einar,

Monday, August 14, 2006, 5:28:08 PM, you wrote:

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

this looks fine except that ghc-specific language facilities will be
exposed to other compilers

> Simple datatypes + intelligent constructors.

good alternative. i agree that this is the better. except perhaps for
situations when one want to know exact syntax what was used in some
Haskell code. but is anyone need this?


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

yes, it's not ideal solution. but adding new features to language and
mirroring them in TH datatypes also makes old code incomplete ;)

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

i propose to drive TH into the direction of making general Haskell
utility that at some moment may become part of the official language
instead of increasing this incompatibility

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

i'm not sure that this will work with TH, which needs compiler
support. Is GHC 6.8 should support generation of ASTs for all TH
versions ever developed? :)

>> 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 propose to drive it into this direction. Of course, it will not
become even part of H' standard, but at least making TH subset that
supports current Haskell standard will be a good step toward TH
standardization and making it available for other compilers

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

yes, that's great


and, i think that adding TH constructs for all new language features
in 6.6 is really important for all TH developers. otherwise, we will
be like one-armed invalid. if SPJ don't want to change TH datatypes
after 6.6 release, it should be done just now


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