Re: Add haskell-src as an official machine-readable component of the Haskell standard
On Tue, Nov 16, 2010 at 9:13 AM, Yitzchak Gale g...@sefer.org wrote: I propose that the haskell-src package be renamed haskell20nn-src for each revision Haskell 20nn of the standard, and be made an official machine-readable component of the standard. As much as I like the idea of standardising a representation of Haskell syntax, it's a highly nontrivial library and so coming to consensus on the various design decisions involved in producing the AST and so forth would be thorny if we started demanding that every implementation upheld them. I think that in general, libraries in the Report should be minimal, and generally only provide obvious or primitive constructs which would likely be the same in every implementation, and on which can be built more interesting libraries separately. It would become necessary to include this sort of thing, I think, if we ever wanted something like Template Haskell or any other metaprogramming facilities to be included in the language. But I don't think anyone believes that TH or anything like it is ready for inclusion in haskell' yet. (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
Re: Add haskell-src as an official machine-readable component of the Haskell standard
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). However, I don't think we should make it official or part of the standard. 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. I also don't want the Haskell Prime Committee to take on the jobs of library maintainership or implementation, those are best kept elsewhere. Thanks, Neil On Tue, Nov 16, 2010 at 9:13 AM, Yitzchak Gale g...@sefer.org wrote: I propose that the haskell-src package be renamed haskell20nn-src for each revision Haskell 20nn of the standard, and be made an official machine-readable component of the standard. This has the following advantages: 1. It would require almost no extra work, because haskell-src already exists, and syntax changes, if any, will be very minimal for each revision. 2. For the portion of the standard that it covers, any ambiguity that might creep into the human-readable standard document would be resolved. 3. It would serve as a basic machine-verification tool which is easily extensible. 4. As a side-effect, the haskell-src package would be continually maintained. The package is useful in its own right as a much lighter-weight version of haskell-src-exts. It is much easier to use when an application does not require full support of all of Haskell's syntax. This proposal is a natural extension of a proposal raised on the libraries mailing list in the context of the Haskell Platform: Ian Lynagh proposed that the current haskell-src-exts be renamed haskell-src (and included in the Haskell Platform, as suggested by Sterling Clover), and that the current haskell-src be renamed to haskell98-src (and removed from the Platform). The libraries subthread is here: http://www.haskell.org/pipermail/libraries/2010-November/015018.html Thanks, Yitz ___ 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
Ben Millwood wrote: 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... So why are you proposing that it be different from a Hackage package in /any/ respect? ...Why doesn't an independent parser do that? ...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... In an enterprise software development environment, getting the software to work in a practical way is not good enough. You need to be able to produce officially recognized documented evidence that it works. The existence of well-specified standards is a prerequisite for the adoption of a language in the mainstream. Haskell is particularly well-suited to the needs of verification, validation, and certification. Galois is doing a lot of great work in this area. I am proposing a simple step, requiring almost no effort on our part. It would immediately raise the quality of the standard considerably, by enriching the expressiveness available to the writers of the standard. It would also immediately raise the perceived value of the standard considerably, by providing the beginnings of an automated validation and certification framework. And it would provide a basis for future work in many directions, both within the standard and based upon it. Thanks, 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
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 ___ 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
Add haskell-src as an official machine-readable component of the Haskell standard
I propose that the haskell-src package be renamed haskell20nn-src for each revision Haskell 20nn of the standard, and be made an official machine-readable component of the standard. This has the following advantages: 1. It would require almost no extra work, because haskell-src already exists, and syntax changes, if any, will be very minimal for each revision. 2. For the portion of the standard that it covers, any ambiguity that might creep into the human-readable standard document would be resolved. 3. It would serve as a basic machine-verification tool which is easily extensible. 4. As a side-effect, the haskell-src package would be continually maintained. The package is useful in its own right as a much lighter-weight version of haskell-src-exts. It is much easier to use when an application does not require full support of all of Haskell's syntax. This proposal is a natural extension of a proposal raised on the libraries mailing list in the context of the Haskell Platform: Ian Lynagh proposed that the current haskell-src-exts be renamed haskell-src (and included in the Haskell Platform, as suggested by Sterling Clover), and that the current haskell-src be renamed to haskell98-src (and removed from the Platform). The libraries subthread is here: http://www.haskell.org/pipermail/libraries/2010-November/015018.html Thanks, 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 Tue, Nov 16, 2010 at 7:51 PM, Lennart Augustsson lenn...@augustsson.net 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 ___ 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
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
