Add haskell-src as an official machine-readable component of the Haskell standard

[Ben Millwood]

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