On Wed, Nov 17, 2010 at 10:20 PM, Yitzchak Gale <g...@sefer.org> 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
