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@gmail.com