On Wed, Nov 17, 2010 at 8:52 AM, Yitzchak Gale <g...@sefer.org> 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 <doai...@swierstra.net> 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. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
