September 2017 - Haskell-prime

Re: Remove eq and show from num class
by Mario Blazevic 07 Nov '17

07 Nov '17

Sending to the mailing list instead of to Herbert alone... On Thu, Sep 7, 2017 at 2:20 PM, Herbert Valerio Riedel <hvriedel(a)gmail.com> wrote: Hello! > > On 2017-09-07 at 18:16:39 +0200, Mario Blazevic wrote: > >> Btw, here's an old commit which updates the class diagram to this > >> effect for the report: > >> > >> https://github.com/hvr/haskell-report/commit/ > >> 339ea257ee8b0451fbba388480566efac6ecbbd3 > >> > > Ha, I wasn't aware of that repository. > > I set up the hvr/haskell-report fork[1] shortly after I migrated and set > up the haskell/haskell-report repo back in 2015 to serve as an "updated" > inofficial Haskell201x report... > > While looking through the report it became apparent to me that more > updates may be needed, and that a new Haskell Prime committee was needed > because such an inofficial Haskell report wouldn't provide the desired > authority of a properly produced language standard, and you know the > rest... :-) > That looks farsighted for sure. > > We agreed today to move the report itself to the > > https://github.com/haskell/rfcs/ repository. > > Ok, so how does this change the procedure described at > > https://github.com/haskell/rfcs/blob/master/README.rst#succe > ssful-proposals > > ? > I think the only necessary change is to the strangely worded clause - No one is appointed responsible for actually implementing the change, in particular neither the shepherd nor the author of the proposal. I'd go with some alternative wording like - The successful proposal should include a complete delta to the text of The Haskell Report that can be automatically merged. > > And what is the intended relationship between the haskell/rfcs and the > haskell/haskell-report repos? > > > Should we move the build system around it as well? I'd say probably > > not, leave the haskell/haskell-report repository the canonical one and > > update it from haskell/rfcs/ once we're ready to publish. > > Well, depends... the build-system is a bit incomplete as it only tests > that TeX still builds, the intention was to provide a CI system which > publishes its draft aftifacts somewhere for convenient previewing. And > if I understand this correctly, you intend to have RFCs be accompanied > by deltas to the report in the same repository; and if that's the case I > think the build-system makes a lot of sense to duplicate in the > haskell/rfcs repo. > I'm not familiar with the build system, so I'll trust your judgement on this. The only reason for my earlier choice is that haskell/haskell-report sounds like a proper cannonical place for the official Haskell Report, much more so than haskell/rfcs. > If the report was written in reStructuredText we could simply use > something like the readthedocs.org service. But since it's LaTeX, we > have to do a little bit more work to publishes ("deploys" in newspeak) > .pdf drafts somewhere else, but it's doable. > I can take care to set it up, if it's clear what kind of CI/CD we want. > Is the current publishing system really that difficult? To my grizzled ears, this sounds like you're fishing for a volunteer to translate LaTeX to ReST. I'd actually be willing to do that, as I have plenty of experience with text transformations, but I'd need a buy-in from everybody. > > I wish GitHub made it possible to symlink files in two repositories > > like this. > > I wouldn't worry too much about that... we can cross that bridge when > we're close to a report worth publishing :-) > > Cheers, > HVR >

9 9

New Haskell Prime Chair
by Henrik Nilsson 12 Sep '17

12 Sep '17

Dear Haskell Primers, At the Haskell Prime Meeting at ICFP last week, it was agreed that I will take over as Chair of the Haskell Prime committee from Herbert Valerio Riedel for initially one year with the aim of facilitating and co-ordinating the language revision process. This will allow Herbert to focus on supporting the editorial aspects of the report by improving the LaTeX code of the existing report and automating publication of report drafts and changes to improve overall transparency and facilitate feedback from the wider community. All the best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Re: Remove eq and show from num class
by Anthony Clayden 10 Sep '17

10 Sep '17

> On Fri Sep 8 15:58:10 UTC 2017, Carter Schonwald wrote: > > I mostly wanted to confirm that we in fact will actually say yes > before doing the formal writtingup :) Seriously -- and please stop using smileys: you're right to be cautious. You need to rewrite the whole of Section 6.4 (nearly 5 pages), starting with changing the title. And I think it'll be a struggle to clarify what applies to genuine numbers vs what applies to 'other stuff'. As Bardur says: > far from trivial to spec without reference to implementation details I think there's another way: leave Sec 6.4 largely unchanged. Add a short note that implementations might extend class `Num` to include non-numbers. GHC 'morally complies' to section 6.4 for Numbers. (i.e. all number types are members of `Num, Eq, Show`.) GHC has (or allows) other types in `Num` which are not numbers, so section 6.4 doesn't apply. I'm puzzled by Bardur's other comments: > On Fri Sep 8 16:16:54 UTC 2017, Bardur Arantsson wrote: > > There aren't really any widely used Haskell compilers > other than GHC ... That's true and sad and a weakness for Haskell in general. On this particular topic there are other compilers: GHC prior v7.4, Hugs. > and speccing for things that aren't actually used in practice ... But there's already a spec! namely the existing report. And `Eq`, `Show` for numbers are used heavily. I think this proposal is not to remove `Eq, Show` from number types that already have them(?) But Carter's subject line does seem to be saying that, which is what alarmed me at first reading. AntC

3 2

Re: Remove eq and show from num class
by Anthony Clayden 09 Sep '17

09 Sep '17

I'm baffled. Is this some sort of 'in' joke at ICFP? Then remember the rest of the world can see this list. > All yays from committee members please reply with yes to this email :) If this is to the committee, shouldn't it be on the committee list? (I mean ghc-steering-committee.) Or is there some other committee? I thought the Haskell-prime forum and process was dead/replaced by the github proposals process? If there is a serious proposal, please explain what it is and what is the motivation. At risk of me sounding like a complete dork: I find it rather useful that I can compare numbers for equality and show them. (That is, without having to write my own instances.) AntC

8 8

Re: Remove eq and show from num class
by Anthony Clayden 08 Sep '17

08 Sep '17

> On 8 Sep 2017 at 07:54 Nathan van Doorm wrote: Thank you Nathan and Mario for your explanations. > The motivation is that there are many types with sensible > definitions for addition and multiplication etc that can't > be instances of Eq or Show, for example functions to > numbers (allowing us to write "sin + cos" instead of "\x > -> sin x + cos X") or arbitrary real numbers (where > comparison isn't necessarily computable). The Haskell 2010 report section 6.4 Numbers starts: "Haskell provides several kinds of numbers; ...". Then goes on to class `Num`. Functions `sin`, `cos` are not numbers, so it's not sensible to put them in `Num`. By the same token, I wouldn't expect Haskell to figure out tan == sin / cos so it's not sensible to put those in `Eq`. If you want to write higher-order algebraic expressions with the Num operators, override the Prelude. (Perhaps this is part of a wider issue to do with reorganising `Num` so it has nicer 'mathematical' structure: additive, multiplicative, etc. That might also cover that `Eq` is dodgy for floating-point or `Rational`s representations. But that reorg has seemed prohibitively hard.) > > I'm not sure why this is being discussed on the mailing > list rather than the Github proposals thing, ... Quite. I've found the github proposals process for GHC very valuable. > but I do know that that has grown somewhat inactive The Haskell-prime list has been fairly inactive too. It was originally formed to identify stable features, that were to go into a revised language standard that was to be an evolution from H98. "Haskell' will be a conservative refinement of Haskell 98." it still says on the listinfo. (Note the future tense.) That process ended with the H2010 report. I must admit I thought (wrongly, it seems) that Haskell-prime rather died after that. Somebody could start by loading up the outstanding proposals from the Haskell-prime list. (Herbert says this one is from 2011.) > and this is as good as anything for getting the > Haskell' committee to make a final judgement. > Do we need any judgment at all? The skies do not seem to be falling. > This has been how it is in GHC for a long time now, > so it really is a matter for the Haskell' committee > rather than one of the GHC committees. MPTCs, GADTs (for example) have been in GHC far longer. OK it's bit naughty GHC doesn't have a flag for something that's not compliant to the report. But that's a GHC issue, not a grounds for changing the language spec. AntC > >> On 8 Sep 2017 8:35 am, "Anthony Clayden" wrote: >> ...

2 1

Re: Remove eq and show from num class
by Anthony Clayden 08 Sep '17

08 Sep '17

> On 2017-09-08 at 08:43 AM, Herbert RIedel wrote: Thank you Herbert for the explanation. >> On 2017-09-08 at 09:19:54 +0200, Anthony Clayden wrote: > > [...] > > I can see how the proliferation of committees & github > repos may seem confusing to casual observers, ... Not that so much. I saw: A message from Carter about lunch queues. A new topic from Carter with a 5-word Subject line, not saying it was a proposal; saying something about some committee approving something; with a smiley; several more messages with smileys (a couple from you). That doesn't seem to follow the process in the link you sent. Nothing saying this is a proposal. Nothing explaining or motivating. Now you're referring me back to a 2011 version of some proposal. It's hardly providing context. To repeat: think about all the Haskellers reading this list. So for anybody not at ICFP (I'm not) what's going on? Are you just a bunch of clowns joking around? It doesn't seem to be April 1st. This from you is relevant: > ## Haskell Core Library Committee > > ... (the CLC was originally formed sometime around 2013 > to design and manage big changes such as the implementation of > the Functor/Applicative/Monad proposal -- > for which there was big community support but lack of leadership was > preventing its implementation). Whether or not everything under the FTP were sensible changes (I think not), the actual communication of what was to change was lousy, and the consultation/decision process was rushed at the end. There are still people grumbling about it. You seem at risk of repeating that. AntC

1 0

Remove eq and show from num class
by Carter Schonwald 08 Sep '17

08 Sep '17

All yays from committee members please reply with yes to this email :) -Carter

6 9

Whose gonna be at icfp?
by Carter Schonwald 07 Sep '17

07 Sep '17

I'll be this time! :) We should coord a committee catch-up at icfp. Also I would like to propose we shift back to email based discussion. There's still the valid and important need of then taking the discussion and revisions into a new standard. But let's at least make the first half lighter weight perhaps? the pattern that's working for ghc proposals doesn't seem to matchup with what works for h2020

8 19