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

[Yitzchak Gale]

Ben Millwood wrote:
> 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.

I am not proposing that haskell-src become part of the
standard libraries.

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.

The current use of Alex and Happy does create the uncomfortable
situation that in practice it is hardly possible for a human to read
and understand the full source code of haskell-src without looking
at the Alex and Happy from which it was generated, while the Alex
and Happy sources themselves are not actually part of the standard.
That can be remedied in future versions if someone gets around to
writing a lexer and parser without resorting to those tools. But I don't
see the use of Alex and Happy as an obstacle in principle, as long
as the generated code is Haskell 20nn compliant.

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

I don't see why the presence or absence of TH makes any difference.

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

Why does this matter?

> we can't provide fixity information

Therefore fixity is currently beyond the scope of this proposal.

> a lot of type class instances are absent
> (even Ord!),

Those instances are defined in the libraries, they are
certainly outside the scope of this proposal.

> the distribution of SrcLocs is a little awkward

SrcLoc is irrelevant.

> some constructors allow impossible
> values, e.g. HsLambda can contain zero patterns

If it would accept (\ -> undefined) as valid Haskell,
that is a bug that would need to be fixed. Otherwise it is not
an impediment, though not ideal.

Thanks,
Yitz