Ben Millwood wrote: > As much as I like the idea of standardising a representation of > Haskell syntax, it's a highly nontrivial library and so coming to > consensus on the various design decisions involved in producing the > AST and so forth would be thorny if we started demanding that every > implementation upheld them. I think that in general, libraries in the > Report should be minimal, and generally only provide "obvious" or > primitive constructs which would likely be the same in every > implementation, and on which can be built more interesting libraries > separately.
I am not proposing that haskell-src become part of the standard libraries. Neither its design, nor its suitability for use in any application, are relevant to this proposal, except for one application: machine verification of the compliance of certain aspects of the syntax of a Haskell program with the standard. The library itself (after being generated by Alex and Happy, and apart from the Data and Typeable instances and the pretty printer, which are all outside the scope of this proposal) is Haskell 20nn. It is simply Haskell 20nn compliant code which, when compiled by any compliant compiler and fed a program, will determine by definition whether the program is compliant with the Haskell 20nn standard or not with respect to those aspects of Haskell 20nn that are within its scope. The current use of Alex and Happy does create the uncomfortable situation that in practice it is hardly possible for a human to read and understand the full source code of haskell-src without looking at the Alex and Happy from which it was generated, while the Alex and Happy sources themselves are not actually part of the standard. That can be remedied in future versions if someone gets around to writing a lexer and parser without resorting to those tools. But I don't see the use of Alex and Happy as an obstacle in principle, as long as the generated code is Haskell 20nn compliant. > It would become necessary to include this sort of thing, I think, if > we ever wanted something like Template Haskell or any other > metaprogramming facilities to be included in the language. But I don't > think anyone believes that TH or anything like it is ready for > inclusion in haskell' yet. I don't see why the presence or absence of TH makes any difference. > (Examples of controversies possible in haskell-src: we have the Hs > prefix on constructors everywhere, Why does this matter? > we can't provide fixity information Therefore fixity is currently beyond the scope of this proposal. > a lot of type class instances are absent > (even Ord!), Those instances are defined in the libraries, they are certainly outside the scope of this proposal. > the distribution of SrcLocs is a little awkward SrcLoc is irrelevant. > some constructors allow impossible > values, e.g. HsLambda can contain zero patterns If it would accept (\ -> undefined) as valid Haskell, that is a bug that would need to be fixed. Otherwise it is not an impediment, though not ideal. Thanks, Yitz _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime