November 2018 - Haskell-prime

Re: Helium II
by Anthony Clayden 04 Dec '18

04 Dec '18

On *Thu Nov 29 15:00:19 UTC 2018, Doug McIlroy wrote:* > >* Frankly after you've filtered out all that, I'd be astonished if you** have anything left. It seems to be usual practice on Hackage to switch** on a swag of LANGUAGE pragmas even if this module isn't using them.* >>* (MPTCs, FlexibleInstances/Contexts in particular.)* > A depressing remark, which comes close to saying > there is no true Haskell. ? There wasn't a true Haskell in 1998. Already Hugs (in HugsMode) and GHC (with glasgow-extns) had MPTCs, FlexibleInstances/Contexts, FunDeps, UndecidableInstances. Overlapping instances was optional extra. > It's one reason I hang mostly with Hugs. Interesting. Does that mean Hugs98? How on earth do you manage without at least some of the above? > GHC pretty well repudiates Haskell 2010. So does Hugs (in HugsMode): a large proportion of the extra features in H2010 were suggested by the Hugs teams; and Hugs 2006 was already far advanced beyond it. > May Haskell 2020 receive more respect! I think you'll need to adjust your expectations: I doubt H2020 will happen. There was a glimmer of activity last month, but this list has resumed its moribund state. So I think we can put last month down to dead cat bounce. If H2020 does happen, HugsMode will still be well ahead of whatever gets added. AntC

3 2

Re: Helium II
by Doug McIlroy 29 Nov '18

29 Nov '18

> Frankly after you've filtered out all that, I'd be astonished if you > have anything left. It seems to be usual practice on Hackage to switch > on a swag of LANGUAGE pragmas even if this module isn't using them. > (MPTCs, FlexibleInstances/Contexts in particular.) A depressing remark, which comes close to saying there is no true Haskell. It's one reason I hang mostly with Hugs. GHC pretty well repudiates Haskell 2010. May Haskell 2020 receive more respect! Doug

1 0

Re: Helium II
by Anthony Clayden 29 Nov '18

29 Nov '18

*On 2018-11-28 14:03:30 UTC, **Mario Blažević wrote:* >> On 2018-11-28 2:17 a.m., Jurriaan Hage wrote: > >>* do we actually have something like an extensive set of tests* >>* to throw at any Haskell 2010 compliant compiler that would help find mistakes on our parr?* > If you want to be really thorough: > > 1. start with all of Hackage, > > 2. filter out all packages with the extensions: field in the cabal file, > > 3. filter out all modules with the {-# LANGUAGE ... #-} pragma, > > 4. recursively filter out all modules that import any filtered-out module, > > 5. you're left with a large set of pure Haskell 2010 modules. At 3.b. also filter out anything with inline pragmas like {-# OVERLAPS/PING/ABLE, INCOHERENT #-}. Note that GHC allows "the possibility" of instances to overlap even without any flags/pragmas set. It's only if you try to use them that it starts insisting on pragmas. Whereas the H2010 standard is clear that overlaps are not allowed. What about anything that relies on the FTP changes to Prelude? Has Juriaan's team upgraded their Prelude? Frankly after you've filtered out all that, I'd be astonished if you have anything left. It seems to be usual practice on Hackage to switch on a swag of LANGUAGE pragmas even if this module isn't using them. (MPTCs, FlexibleInstances/Contexts in particular.) AntC

1 0

Helium II
by Jurriaan Hage 28 Nov '18

28 Nov '18

Dear all, We’ve been active since September making the Helium compiler more Haskell 2010 compliant. In particular, we have a branch with support for Haskell 2010 type classes, a branch that supports import/export following the standard, and a branch that compiles to LLVM instead of the `old’ Helium-specific LVM that has become harder and harder to maintain. These still need to be integrated. When I find time for that is hard to say. Another project will be taking place in the period Feb-Apr and I expect we can tie up a lot of loose ends then. Current loose ends include newtype, record syntax, integration of previous projects, Cabal support, Quickcheck, strict data fields, improving the LLVM back-end. One thing I have wondered about: do we actually have something like an extensive set of tests to throw at any Haskell 2010 compliant compiler that would help find mistakes on our parr? My students have come up with a range of examples to test their implementations, but there is nothing like a set of programs you’ve never seen or heard about. We shall also be adding support for GADTs as part of a reseach project this course year. Again, a large range of examples would be welcome indeed. best, Jur

2 1

The first proposal has been merged
by Mario Blažević 27 Nov '18

27 Nov '18

Break out the champagne, because the first Haskell 2020 proposal has been fully merged [1]. By fully merged, I mean that the text of the report has been updated, so we have accomplished something material. Should the Haskell 2020 commitee agree so, we now have the option to declare the Haskell 2018 standard finished, merge the report text back into the official Haskell Report, and hand it over to future generations. Admittedly the RFC in question, -XRelaxedPolyRec, was probably the most trivial possible. My preference would be for the members of the committee to follow the lead of this proposal and apply the same process to more significant issues. The process to follow is: 1. Take any RFC you're interested in from the In Discussion column of the repo project (https://github.com/haskell/rfcs/projects/1) Alternatively, write up a new proposal, put it up for discussion, and wait a decent time. 2. If there is no serious objection to the proposal after a while, make sure all technical objections are addressed and move the RFC to the Last Call column. Declare on the mailing list that you've done so. 3. Modify the text of the report on the same branch where the RFC is written up. If there is no objection to the proposal in the Last Call status in the following two weeks (and there is some approval), move the proposal into the Ready for Report column and declare so on the mailing list. 4. Leave at least another two weeks to refine the details of the Report text, then merge the RFC. [1] https://github.com/haskell/rfcs/pull/17

2 1

LAST CALL to comment on the RelaxedPolyRec proposal
by Mario Blažević 19 Nov '18

19 Nov '18

I hereby officially announce that the RFC for the relaxed dependency analysis (https://github.com/haskell/rfcs/pull/17) has attained the rarefied status of Last Call. Please take some time within the following two weeks to vote for or against the proposal, or just leave a comment to indicate you're still alive but didn't form an opinion on it.

1 1

Report merged, steps to follow
by Mario Blažević 06 Nov '18

06 Nov '18

Four weeks having passed since the previous discussion with no objections, I have now merged the content of the Haskell Report from https://github.com/haskell/haskell-report into https://github.com/haskell/rfcs To remind everybody again, the point of this move was to enable adding an actionable change to the report to every RFC. From this point on, any proposal that passes the full process to becoming accepted can update the report by the simple act of getting merged. In order to test this process, over a year ago I've picked and submitted the least controversial RFC I could find, namely https://github.com/haskell/rfcs/pull/17. There has been no objection to the proposal. In fact there has been no comment whatsoever, but I suppose that's beside the point. So today I have moved the RFC to the "Last Call" column (https://github.com/haskell/rfcs/projects/1) as the first and only proposal to gain that awesome status. It's not at all clear what should happen to the RFC between this point and it getting merged, but I'm determined to test drive the process with it. This is my plan: 1. I'm going to add update the report with a patch to the report content, then 2. wait another two weeks for any objection before 3. moving the proposal from the Last Call to the Ready for Report status, then 4. announce that the proposal is Ready for Report and 5. wait another two weeks for the full approval, then finally 6. merge the RFC. The only flaw in my cunning plan above is defining what constitutes "the full approval". The committee being rather ... disengaged and scattered, there is little hope of getting 50% of votes from all its members. The criteria of no raised objection, which I've used so far, seems much too lax for a full approval. I think the only reasonable fair criteria of success would be a public and unanimous approval by at least N committee members. I have no idea what N should be, but I know that if this test proposal can't garner N approvals, no proposal will ever pass the hurdle. To make it plain, I suggest we take the number of committee members that comment on the test proposal as the maximum bound of N. I do hope max(N) > 1.

3 2