Yitzchak Gale | 16 Nov 10:13 2010

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

I propose that the haskell-src package be renamed
haskell20nn-src for each revision Haskell 20nn of
the standard, and be made an official machine-readable
component of the standard.

This has the following advantages:

1. It would require almost no extra work, because
haskell-src already exists, and syntax changes, if
any, will be very minimal for each revision.

2. For the portion of the standard that it covers,
any ambiguity that might creep into the human-readable
standard document would be resolved.

3. It would serve as a basic machine-verification tool
which is easily extensible.

4. As a side-effect, the haskell-src package would be
continually maintained. The package is useful in its
own right as a much lighter-weight version of haskell-src-exts.
It is much easier to use when an application does
not require full support of all of Haskell's syntax.

This proposal is a natural extension of a proposal
raised on the libraries mailing list in the context of
the Haskell Platform: Ian Lynagh proposed that the
current haskell-src-exts be renamed haskell-src
(and included in the Haskell Platform, as suggested
by Sterling Clover), and that the current haskell-src
(Continue reading)

Ben Millwood | 16 Nov 15:35 2010

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

On Tue, Nov 16, 2010 at 9:13 AM, Yitzchak Gale <gale@...> wrote:
> I propose that the haskell-src package be renamed
> haskell20nn-src for each revision Haskell 20nn of
> the standard, and be made an official machine-readable
> component of the standard.
>

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.

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.

(Examples of controversies possible in haskell-src: we have the Hs
prefix on constructors everywhere, we can't provide fixity information
(and the haskell-src-exts implementation of this is unsatisfactory in
several important ways), a lot of type class instances are absent
(even Ord!), the distribution of SrcLocs is a little awkward when
manipulating source abstractly, and some constructors allow impossible
values, e.g. HsLambda can contain zero patterns)
(Continue reading)

Yitzchak Gale | 16 Nov 16:40 2010

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

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.

(Continue reading)

Ben Millwood | 16 Nov 18:44 2010
Picon

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

On Tue, Nov 16, 2010 at 3:40 PM, Yitzchak Gale <gale@...> 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
(Continue reading)

Lennart Augustsson | 16 Nov 20:51 2010
Picon

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

Please explain.  Fixity information cannot be provided unless you find
all the imported modules and process those, so I'm not sure how
haskell-src-exts could do any better than it currently does.

>
> (Examples of controversies possible in haskell-src: we have the Hs
> prefix on constructors everywhere, we can't provide fixity information
> (and the haskell-src-exts implementation of this is unsatisfactory in
> several important ways), a lot of type class instances are absent
> (even Ord!), the distribution of SrcLocs is a little awkward when
> manipulating source abstractly, and some constructors allow impossible
> values, e.g. HsLambda can contain zero patterns)
Ben Millwood | 17 Nov 00:22 2010
Picon

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

On Tue, Nov 16, 2010 at 7:51 PM, Lennart Augustsson
<lennart@...> wrote:
> Please explain.  Fixity information cannot be provided unless you find
> all the imported modules and process those, so I'm not sure how
> haskell-src-exts could do any better than it currently does.
>

The tickets I had in mind were:

http://trac.haskell.org/haskell-src-exts/ticket/197
http://trac.haskell.org/haskell-src-exts/ticket/191

and this one I've just submitted:

http://trac.haskell.org/haskell-src-exts/ticket/207
Simon Peyton-Jones | 17 Nov 08:55 2010
Picon

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

See http://hackage.haskell.org/trac/ghc/ticket/4430 for what we are proposing for Template Haskell.

S

| -----Original Message-----
| From: haskell-prime-bounces@...
[mailto:haskell-prime-bounces <at> haskell.org] On
| Behalf Of Lennart Augustsson
| Sent: 16 November 2010 19:52
| To: Ben Millwood
| Cc: haskell-prime@...
| Subject: Re: Add haskell-src as an official machine-readable component of the Haskell
| standard
| 
| Please explain.  Fixity information cannot be provided unless you find
| all the imported modules and process those, so I'm not sure how
| haskell-src-exts could do any better than it currently does.
| 
| >
| > (Examples of controversies possible in haskell-src: we have the Hs
| > prefix on constructors everywhere, we can't provide fixity information
| > (and the haskell-src-exts implementation of this is unsatisfactory in
| > several important ways), a lot of type class instances are absent
| > (even Ord!), the distribution of SrcLocs is a little awkward when
| > manipulating source abstractly, and some constructors allow impossible
| > values, e.g. HsLambda can contain zero patterns)
| _______________________________________________
| Haskell-prime mailing list
| Haskell-prime@...
| http://www.haskell.org/mailman/listinfo/haskell-prime
(Continue reading)

Niklas Broberg | 17 Nov 08:58 2010
Picon

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

Thanks, I'll look into all of that when I get a chance, hopefully soonish.

Cheers,

/Niklas

On Wed, Nov 17, 2010 at 12:22 AM, Ben Millwood <haskell@...> wrote:
> On Tue, Nov 16, 2010 at 7:51 PM, Lennart Augustsson
> <lennart@...> wrote:
>> Please explain.  Fixity information cannot be provided unless you find
>> all the imported modules and process those, so I'm not sure how
>> haskell-src-exts could do any better than it currently does.
>>
>
> The tickets I had in mind were:
>
> http://trac.haskell.org/haskell-src-exts/ticket/197
> http://trac.haskell.org/haskell-src-exts/ticket/191
>
> and this one I've just submitted:
>
> http://trac.haskell.org/haskell-src-exts/ticket/207
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime@...
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
Yitzchak Gale | 17 Nov 09:52 2010

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

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.

If we can get a parser based on haskell-src-exts instead,
that would be great. But it's more work. haskell-exts is
basically ready today.

> ...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.
(Continue reading)

S. Doaitse Swierstra | 17 Nov 14:46 2010
Picon

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


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

On 17 nov 2010, at 08:55, Simon Peyton-Jones wrote:

> See http://hackage.haskell.org/trac/ghc/ticket/4430 for what we are proposing for Template Haskell.
> 
> S
> 
> 
> | -----Original Message-----
> | From: haskell-prime-bounces@...
[mailto:haskell-prime-bounces@...] On
> | Behalf Of Lennart Augustsson
> | Sent: 16 November 2010 19:52
> | To: Ben Millwood
> | Cc: haskell-prime@...
> | Subject: Re: Add haskell-src as an official machine-readable component of the Haskell
(Continue reading)


Gmane