November 2010 - Haskell-prime

ExplicitForAll complete
by Ian Lynagh 05 Jan '11

05 Jan '11

Hi all, I've completed the ExplicitForAll proposal, started by Niklas Broberg (but any errors are doubtless mine!): http://hackage.haskell.org/trac/haskell-prime/wiki/ExplicitForall http://hackage.haskell.org/trac/haskell-prime/ticket/133 I imagine this is too late for H2011 (if that will actually be happening?), but there wasn't an H2012 milestone, so I put it in H2011 anyway. Please feel free to remilestone. Thanks Ian

5 8

Small report fixes
by Ian Lynagh 23 Dec '10

23 Dec '10

Hi all, I've made a couple of tickets for small fixes to the report: http://hackage.haskell.org/trac/haskell-prime/ticket/140 http://hackage.haskell.org/trac/haskell-prime/ticket/141 Thanks Ian

2 1

Re: [Haskell] typo in Haskell definition
by Yitzchak Gale 20 Nov '10

20 Nov '10

Moving this to the haskell-prime list, where perhaps someone will notice it. Serge D. Mechveliani wrote: > Looking into the on-line Haskell-2010 definition, > I see in the Library definition > > 20.4.3 ... > iteratef (instead of "iterate f"), > repeatx (instead of "repeat x"). Also, replicaten x (instead of "replicate n x"). Thanks for the report. I don't seem to be able to log in to the trac, so perhaps someone else will submit the ticket. Thanks, Yitz

2 1

Add haskell-src as an official machine-readable component of the Haskell standard
by Yitzchak Gale 18 Nov '10

18 Nov '10

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 be renamed to haskell98-src (and removed from the Platform). The libraries subthread is here: http://www.haskell.org/pipermail/libraries/2010-November/015018.html Thanks, Yitz

6 11

Add haskell-src as an official machine-readable component of the Haskell standard
by Yitzchak Gale 18 Nov '10

18 Nov '10

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. 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. > What purpose does it serve that a Haskell > parser independent of the report does not? Machine verification of Haskell 20nn standards compliance. > 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. 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. 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. Regards, Yitz

2 2

Re: Add haskell-src as an official machine-readable component of the Haskell standard
by S. Doaitse Swierstra 17 Nov '10

17 Nov '10

On 17 nov 2010, at 16:21, Ben Millwood wrote: On Wed, Nov 17, 2010 at 8:52 AM, Yitzchak Gale <gale(a)sefer.org> 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. That is why I refined the proposal in my last sentence to only allowing them after the import's. It is also the only way I see programming environments ever becoming "priority aware". Doaitse _______________________________________________ Haskell-prime mailing list Haskell-prime(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

1 0

Re: Add haskell-src as an official machine-readable component of the Haskell standard
by S. Doaitse Swierstra 17 Nov '10

17 Nov '10

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(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On > | Behalf Of Lennart Augustsson > | Sent: 16 November 2010 19:52 > | To: Ben Millwood > | Cc: haskell-prime(a)haskell.org > | 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(a)haskell.org > | http://www.haskell.org/mailman/listinfo/haskell-prime > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime

1 0