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