On Wed, Nov 17, 2010 at 8:52 AM, Yitzchak Gale
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
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.