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

[Ben Millwood]

On Wed, Nov 17, 2010 at 8:52 AM, Yitzchak Gale <gale at sefer.org> wrote:
> Ben Millwood wrote:
>> 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.
>
> Yes, that is the most essential requirement.
>
> It is a desirable feature for it to work as a parser, too.
> It can then be used as the basis for further verification
> tools, and for parsing with guarantees about standards
> compliance. And haskell-exts does work as a parser,
> though it perhaps not as polished as some other parsers.

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. All of this relatively special-interest
stuff now becomes the business of the language design committee, which
sounds like an unnecessary burden to me.

Also, don't get me wrong - haskell-src-exts is a leader in its field,
it's more mature than any other standalone Haskell parser I know of.
But it's still a complex library with difficult issues to be tackled,
and I don't think the place to tackle those issues is in the language
specification.

>> ...compliance to a reference implementation...
>> 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! ...So I'm not convinced that converting part
>> of the language description into a machine-readable form is
>> necessarily for the best.
>
> I am not suggesting converting part of the spec into code
> and dispensing with that part of the document.
>
> I am suggesting that both the human-readable document and
> the reference parser should be officially part of the spec.
> If there is inconsistency between them, that is a bug in the spec
> which needs to be fixed like any other.

Well, sure, but then I wonder what your automated verification program
is actually useful for. What purpose does it serve that a Haskell
parser independent of the report does not? We can't guarantee it's
bug-free, so we can't make any more assurances than a third party
could about the correctness of its parsing behaviour. We still have to
(and should!) maintain the abstract language description, which may
well involve duplicating information: indeed, if the reference parser
is /not/ redundant, that's a bug :P

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

On Wed, Nov 17, 2010 at 12:18 PM, S. Doaitse Swierstra
<doaitse at swierstra.net> wrote:
> Reading this proposal I think it clearly states my point made earlier: allowing infix specifications everywhere provides unneeded  flexibility and unnecessary complexity.
>
> Ideally I would like to see them even before the module keyword: they state how to read the text that follows, and thus fall in the category of:
>
>  - LANGUAGE pragma's which add sometimes extra syntax
>  - import's, which extend the name space
>
> Restricting them to occur only directly after the imports is something I cannot see anyone to object to, and would enable the immediate correct parsing of all expressions to follow.
>
>  Doaitse
>

This is an interesting idea! It would certainly solve a fair few
issues with fixity parsing, but I worry that we'd lose a lot of
consistency, and/or gain a lot of redundancy - we want operators to
associate the same way in every file, but people will have different
ideas about which way to associate what (I like associating $ to the
left, but I generally don't for the sake of my readers' sanity).
Plus, like explicit import lists, I suspect that a list of all
operators used in the program, potentially some distance away from
their usage site, is going to invite subtle errors when people forget
to add one, redundancy when people forget to remove one, and noise in
patch files when people do the right thing. So as much as I want to
see Haskell's infix syntax simplified, I'm not sure this is a
practical way to do so. I once had the idea of having fixity
determined in some sense by the name of the operator - long operators
binding more tightly/loosely than short ones, or an angle bracket in
the right place changing the associativity - but I don't think there's
any satisfactory way of doing that either.