Re: Add haskell-src as an official machine-readable component of the Haskell standard
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. If we can get a parser based on haskell-src-exts instead, that would be great. But it's more work. haskell-exts is basically ready today. > ...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. > ...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. Yes, it should be in scope if possible. If the fixity handling of haskell-src-exts is deemed sufficient and we move to that now or in the future, we'll have it. > ...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. haskell-src does provide that. It works and it is usable. Again, if we can be based on haskell-src-exts now or in the future, all the better. Regards, Yitz ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Add haskell-src as an official machine-readable component of the Haskell standard
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 On 17 nov 2010, at 08:55, Simon Peyton-Jones wrote: > See http://hackage.haskell.org/trac/ghc/ticket/4430 for what we are proposing > for Template Haskell. > > S > > > | -Original Message- > | From: haskell-prime-boun...@haskell.org > [mailto:haskell-prime-boun...@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 > > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Add haskell-src as an official machine-readable component of the Haskell standard
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. ___ Haskell-prime mailing list Haskell-prime@haskel
Re: Add haskell-src as an official machine-readable component of the Haskell standard
On 17 nov 2010, at 16:21, Ben Millwood wrote: On Wed, Nov 17, 2010 at 8:52 AM, Yitzchak Gale 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. That is why I refined the proposal in my last sentence to only allowing them after the import's. It is also the only way I see programming environments ever becoming "priority aware". Doaitse ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Add haskell-src as an official machine-readable component of the Haskell standard
Ben Millwood wrote: > 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. No we don't. With regard to its inclusion as part of the standard, we make only one guarantee - that it serves to verify whether code is compliant to the standard. For your convenience, the package maintainer will try to make it useful for other things too, but in that respect it is no different than any other package on Hackage. > What purpose does it serve that a Haskell > parser independent of the report does not? Machine verification of Haskell 20nn standards compliance. > We can't guarantee it's bug-free We can't guarantee that the human-readable part of the standard is bug-free, either. It always has had bugs and it always will, like any standard. We do the best we can. Actually, there is the possibility of developing an automated system to generate unit tests from the standards document to verify the consistency of the parser with the document. Those same unit tests could then also be used by compiler writers to certify the compliance of their Haskell 20nn mode and do regression testing. There are many intriguing possibilities. > 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 Yes that is one of the advantages of this approach. > 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. For you it may not be a priority. But for enterprise project architects who are required to consider and document every possible risk before agreeing to adopt Haskell, it is a priority. Regards, Yitz ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Add haskell-src as an official machine-readable component of the Haskell standard
On Wed, Nov 17, 2010 at 10:20 PM, Yitzchak Gale wrote: > Ben Millwood wrote: >> 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. > > No we don't. With regard to its inclusion as part of the > standard, we make only one guarantee - that it serves > to verify whether code is compliant to the standard. So we don't actually specify the content or API of the library itself, merely state its existence? If we specify the API we make those decisions, if we don't I don't see what exactly you are asking for. > For your convenience, the package maintainer will try > to make it useful for other things too, but in that respect > it is no different than any other package on Hackage. So why are you proposing that it be different from a Hackage package in /any/ respect? >> What purpose does it serve that a Haskell >> parser independent of the report does not? > > Machine verification of Haskell 20nn standards compliance. Why doesn't an independent parser do that? >> We can't guarantee it's bug-free > > We can't guarantee that the human-readable part of > the standard is bug-free, either. It always has had > bugs and it always will, like any standard. We do > the best we can. Everyone does the best they can, this is not particular to the standards committee. My point here is that a standardised parser can't provide any more guarantees than anyone else writing a parser, so I don't see any benefit in putting an "official" stamp on a particular one. It doesn't give it a practical edge over any other, apart from perhaps ensuring it is well-maintained - but if all we want is a well-maintained parser library, I'm sure a "strike force" or something could be arranged. Furthermore, I think the effort required to maintain of the standard is proportional to the size of the standard, so the best way to keep it high-quality is to keep it minimalist - obviously no bugs rather than no obvious bugs, etc. In fact, I think I would be more inclined to argue for a smaller library specification in the report than a larger one. Adding an entire parser in sounds like a poor reward:effort ratio to me. > Actually, there is the possibility of developing an > automated system to generate unit tests from the > standards document to verify the consistency of > the parser with the document. Those same unit tests > could then also be used by compiler writers to certify > the compliance of their Haskell 20nn mode and > do regression testing. Generating unit tests for compilers sounds like a useful idea, but I'm not sure how they could be made both useful and compiler-agnostic, so I'm not sure you're doing anything here that compilers aren't doing already for themselves. Also, this is the sort of development that could (and, by the minimalist argument, probably should) go on outside of the language definition itself. > There are many intriguing possibilities. > >> 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 > > Yes that is one of the advantages of this approach. > >> 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. > > For you it may not be a priority. But for enterprise project > architects who are required to consider and document > every possible risk before agreeing to adopt Haskell, > it is a priority. > I don't follow. Where's the risk? Why should it be a priority to enforce a property that so far has never been violated? Nothing gets into the Haskell standard without having already been implemented, practically speaking, so in a sense a reference implementation always already exists. Even if this was not the case, I don't see how that would be a concern for project architects, since they will be using the existing and functional implementations anyway. As it is, I don't think this has ever been a concern, and there is no reason to believe that will change. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
