On Tue, Nov 16, 2010 at 3:40 PM, Yitzchak Gale <g...@sefer.org> wrote: > > I am not proposing that haskell-src become part of the > standard libraries. >
Right, I misunderstood here. > 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. So essentially, all you are asking for is an official implementation of haskell parsing, so that you input a program and it spits out either "valid" or "not valid", according to the parts of the spec that it audits. This is not such a bad idea, except that I feel like there are a lot of examples of languages /without/ an official standard whose compliance to the spec is therefore determined, as you seem to suggest, by compliance to a reference implementation, and I think it tends to be more painful as a process. If there are bugs in the reference implementation, other implementations then have to decide whether to "implement" them or do what they think is best. If there are disagreements between the reference implementation and language spec, or ambiguities in language spec, the spec should certainly be fixed! I strongly believe that a bureaucratic, democratic, and conceptual approach to the design of the Haskell language is one of its major strengths - its design decisions are made by committee and after lengthy discussion, rather than by implementors according to whatever works at the time. So I'm not convinced that converting part of the language description into a machine-readable form is necessarily for the best. >> (Examples of controversies possible in haskell-src: we have the Hs >> prefix on constructors everywhere, > > Why does this matter? It's just annoying and makes code more verbose for no obvious reason. It's not a big deal but it's one of the things we'd have to talk about if we wanted your library to expose its parsing API - it's something that, for example, haskell-src and haskell-src-exts have diverged on. >> we can't provide fixity information > > Therefore fixity is currently beyond the scope of this proposal. Hmm. But fixity resolution is one of the trickiest parts of Haskell parsing, imo. It seems like an awful cop-out to put the really difficult cases - like parsing \x -> x == x == 0 - out of the scope of your verification tool. Everything else I said assumed people wanted to use the official parsing library to manipulate the AST it generated, in which case the random SrcLocs and too-liberal constructors are real annoyances, but I suppose that's not really what you're after. But it seems a bit odd to have a complete parsing library that nevertheless doesn't provide AST inspection and manipulation, which is what I guess most people use a haskell parser in Haskell for. (Other things that I would find really nice in developing applications for manipulating source are resumability, like attoparsec, or error-correcting, like uu-parsinglib. More control over how I feed the input into the parser could also be useful for running parses of files without resorting to unsafe interleaving. But that's all way out of the scope of this proposal and for discussion somewhere else entirely). _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
