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