On Tue, Nov 16, 2010 at 3:40 PM, Yitzchak Gale 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).

On Wed, Nov 17, 2010 at 8:52 AM, Yitzchak Gale wrote:

Ben Millwood wrote:

...

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.

Yes, that is the most essential requirement.

It is a desirable feature for it to work as a parser, too. It can then be used as the basis for further verification tools, and for parsing with guarantees about standards compliance. And haskell-exts does work as a parser, though it perhaps not as polished as some other parsers.

But if we make the official parser usable for AST manipulation, we have to rule on the design issues I raised above: whether to make efforts to stop invalid lambdas being constructed, how to name the types and constructors, etc. All of this relatively special-interest stuff now becomes the business of the language design committee, which sounds like an unnecessary burden to me. Also, don't get me wrong - haskell-src-exts is a leader in its field, it's more mature than any other standalone Haskell parser I know of. But it's still a complex library with difficult issues to be tackled, and I don't think the place to tackle those issues is in the language specification.

...

...compliance to a reference implementation... 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! ...So I'm not convinced that converting part of the language description into a machine-readable form is necessarily for the best.

I am not suggesting converting part of the spec into code and dispensing with that part of the document.

I am suggesting that both the human-readable document and the reference parser should be officially part of the spec. If there is inconsistency between them, that is a bug in the spec which needs to be fixed like any other.

Well, sure, but then I wonder what your automated verification program is actually useful for. What purpose does it serve that a Haskell parser independent of the report does not? We can't guarantee it's bug-free, so we can't make any more assurances than a third party could about the correctness of its parsing behaviour. We still have to (and should!) maintain the abstract language description, which may well involve duplicating information: indeed, if the reference parser is /not/ redundant, that's a bug :P I suppose providing a reference parser at least ensures that any modification to Haskell syntax is implementable, and the issues in its implementation will have been considered, but in practice every alteration to the Haskell language from now on is going to be standardising extensions that already exist, so I don't really think this is a priority. On Wed, Nov 17, 2010 at 12:18 PM, S. Doaitse Swierstra wrote:

Reading this proposal I think it clearly states my point made earlier: allowing infix specifications everywhere provides unneeded flexibility and unnecessary complexity.

Ideally I would like to see them even before the module keyword: they state how to read the text that follows, and thus fall in the category of:

- LANGUAGE pragma's which add sometimes extra syntax - import's, which extend the name space

Restricting them to occur only directly after the imports is something I cannot see anyone to object to, and would enable the immediate correct parsing of all expressions to follow.

Doaitse

This is an interesting idea! It would certainly solve a fair few issues with fixity parsing, but I worry that we'd lose a lot of consistency, and/or gain a lot of redundancy - we want operators to associate the same way in every file, but people will have different ideas about which way to associate what (I like associating $ to the left, but I generally don't for the sake of my readers' sanity). Plus, like explicit import lists, I suspect that a list of all operators used in the program, potentially some distance away from their usage site, is going to invite subtle errors when people forget to add one, redundancy when people forget to remove one, and noise in patch files when people do the right thing. So as much as I want to see Haskell's infix syntax simplified, I'm not sure this is a practical way to do so. I once had the idea of having fixity determined in some sense by the name of the operator - long operators binding more tightly/loosely than short ones, or an angle bracket in the right place changing the associativity - but I don't think there's any satisfactory way of doing that either.

On Tue, Nov 16, 2010 at 7:51 PM, Lennart Augustsson wrote:

Please explain.  Fixity information cannot be provided unless you find all the imported modules and process those, so I'm not sure how haskell-src-exts could do any better than it currently does.

The tickets I had in mind were: http://trac.haskell.org/haskell-src-exts/ticket/197 http://trac.haskell.org/haskell-src-exts/ticket/191 and this one I've just submitted: http://trac.haskell.org/haskell-src-exts/ticket/207

See http://hackage.haskell.org/trac/ghc/ticket/4430 for what we are proposing for Template Haskell. S | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On | Behalf Of Lennart Augustsson | Sent: 16 November 2010 19:52 | To: Ben Millwood | Cc: haskell-prime@haskell.org | Subject: Re: Add haskell-src as an official machine-readable component of the Haskell | standard | | Please explain. Fixity information cannot be provided unless you find | all the imported modules and process those, so I'm not sure how | haskell-src-exts could do any better than it currently does. | | > | > (Examples of controversies possible in haskell-src: we have the Hs | > prefix on constructors everywhere, we can't provide fixity information | > (and the haskell-src-exts implementation of this is unsatisfactory in | > several important ways), a lot of type class instances are absent | > (even Ord!), the distribution of SrcLocs is a little awkward when | > manipulating source abstractly, and some constructors allow impossible | > values, e.g. HsLambda can contain zero patterns) | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime

Hi Neil, Neil Mitchell wrote:

There is nothing to stop an library author doing exactly this, and it might even be useful for some people (personally I'm going to stick to haskell-src-exts, because it's a brilliant library).

Yes, it is. I am not proposing changing in any way how we develop and use Haskell parsers as tools. I am proposing taking an existing parser and using it in a different way.

I've found plenty of HSE/GHC parsing differences in my work, and my suspicion is that several of them are probably also present in haskell-src.

Indeed. Easily finding and documenting such discrepancies is one of the major benefits of having a machine-readable component in the standard.

I also don't want the Haskell Prime Committee to take on the jobs of library maintainership or implementation, those are best kept elsewhere.

Agreed. I am not proposing that. The machine-readable portion of the standard will be based on a parser library that exists quite apart from the standard. Thanks, Yitz