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

[Ben Millwood]

On Tue, Nov 16, 2010 at 3:40 PM, Yitzchak Gale <gale at sefer.org> wrote:
>
> I am not proposing that haskell-src become part of the
> standard libraries.
>

Right, I misunderstood here.

> Neither its design, nor its suitability for use in any application,
> are relevant to this proposal, except for one application:
> machine verification of the compliance of certain aspects
> of the syntax of a Haskell program with the standard.
>
> The library itself (after being generated by Alex and Happy,
> and apart from the Data and Typeable instances and the
> pretty printer, which are all outside the scope of this proposal)
> is Haskell 20nn.
>
> It is simply Haskell 20nn compliant code which, when compiled
> by any compliant compiler and fed a program, will determine by
> definition whether the program is compliant with the Haskell 20nn
> standard or not with respect to those aspects of Haskell 20nn
> that are within its scope.

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.

This is not such a bad idea, except that I feel like there are a lot
of examples of languages /without/ an official standard whose
compliance to the spec is therefore determined, as you seem to
suggest, by compliance to a reference implementation, and I think it
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! I strongly believe that a bureaucratic, democratic, and
conceptual approach to the design of the Haskell language is one of
its major strengths - its design decisions are made by committee and
after lengthy discussion, rather than by implementors according to
whatever works at the time. So I'm not convinced that converting part
of the language description into a machine-readable form is
necessarily for the best.

>> (Examples of controversies possible in haskell-src: we have the Hs
>> prefix on constructors everywhere,
>
> Why does this matter?

It's just annoying and makes code more verbose for no obvious reason.
It's not a big deal but it's one of the things we'd have to talk about
if we wanted your library to expose its parsing API - it's something
that, for example, haskell-src and haskell-src-exts have diverged on.

>> we can't provide fixity information
>
> Therefore fixity is currently beyond the scope of this proposal.

Hmm. But 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.

Everything else I said assumed people wanted to use the official
parsing library to manipulate the AST it generated, in which case the
random SrcLocs and too-liberal constructors are real annoyances, but I
suppose that's not really what you're after. But 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.

(Other things that I would find really nice in developing applications
for manipulating source are resumability, like attoparsec, or
error-correcting, like uu-parsinglib. More control over how I feed the
input into the parser could also be useful for running parses of files
without resorting to unsafe interleaving. But that's all way out of
the scope of this proposal and for discussion somewhere else
entirely).