- Haskell-prime - Haskell.org

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

type (++) = (<>)
by Vassil Ognyanov Keremidchiev 04 Jul '17

04 Jul '17

Hello! What do you think of making (++) the same as (<>) so we could use ++ as concatenation of any monoid, not just lists in Haskell 2020? This will be more intuitive for beginners, too. Best regards, Vassil Keremidchiev

5 8

“If typeclass a, then a is also an instance of b by this definition.”
by Saurabh Nanda 09 Jun '17

09 Jun '17

Hi, At the outset I would like to mention that I do not completely understand how type-class instance resolution works, and why it works that way. I have tried reading up, but I don't completely understand WHY it works that way. So, please feel free to ask me to RTFM if what I'm about to say doesn't make any sense, although TFM doesn't make sense to me! >From a pragmatic standpoint is there any way to express the following idea in Haskell (or a future version of Haskell), **with minimal amount of boilerplate** If a type has an instance of type-class `a`, then here's how you can get an instance of type-class `b` Without the ability to express this idea, you end up with a **lot** of type-class boilerplate, (even if you use GHC Generics) eg: data State = data State = Inactive | Incomplete | Deleted | Trial | Unpaid | Paid deriving (Eq, Show, Generic) instance AppEnum State where toString = gEnumToString fromString = gEnumFromString -- You are still forced to do the following for **every single type** even though, conceptually, this can be driven by a rule instance ToJSON State where toJSON s = toJSON $ toString x instance FromJSON State where parseJSON (Aeson.String s) = fromString s parseJSON _ = fail "unexpected type" instance FromFIeld State where fromField _ mBS = case mBS of Nothing -> fail "not expecting a NULL/Nothing" (Just bs) -> pure $ fromString bs instance ToField State where toField s = toField $ toString s I tried talking to people on IRC and also trawling StackOverflow [1] and my take-away is essentially, that Haskell cannot express this idea. However, my submission is, that it is a very useful idea to express and probably the next version of the language should do something to make the lives of programmers a little easier. [1] https://stackoverflow.com/questions/3213490/how-do-i-write-if-typeclass-a-t… -- Saurabh.

3 2

Re: Haskell-prime Digest, Vol 104, Issue 2
by Soham Chowdhury 27 May '17

27 May '17

Apologies if this question's already been discussed here, but have there been any discussions about switching the meanings of the : and :: operators? The rationale here is, of course, that :: is (probably, beware of anecdata) used a lot more than : is. Obviously this would have the effect of breaking essentially every module ever written if it were done "automatically", but could there not be something akin to what -XDataKinds did for the * kind? I don't genuinely expect this to ever happen, and I can't exactly defend the headache this would pose for comparatively little gain (including having to check the file header if not all your code sticks to one convention), but it would still, well, be really nice. I've been doing some type-level stuff for a while using Type instead of *, and it's caused less friction than I expected there to be. As a logical extension of this, it seems like a :/:: replacement might improve ergonomics more than a little as we move towards full Dependent Haskell. Soham On Wed, May 17, 2017, 17:57 <haskell-prime-request(a)haskell.org> wrote: > Send Haskell-prime mailing list submissions to > haskell-prime(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > or, via email, send a message with subject or body 'help' to > haskell-prime-request(a)haskell.org > > You can reach the person managing the list at > haskell-prime-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-prime digest..." > > > Today's Topics: > > 1. Re: Default module header `module Main where` (Matthias Fischmann) > 2. Re: Default module header `module Main where` (Iavor Diatchki) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 16 May 2017 21:40:49 +0200 > From: Matthias Fischmann <mf(a)zerobuzz.net> > To: Adam Bergmark <adam(a)bergmark.nl> > Cc: haskell-prime(a)haskell.org > Subject: Re: Default module header `module Main where` > Message-ID: <20170516194049.GX1508(a)localhost.localdomain> > Content-Type: text/plain; charset=utf-8 > > > you're inside the module, so you have access to all top-level > bindings, not just to the export list. > > the issue with the implicit `module Main(main) where` is that it > errors if main is not defined, even though that's a perfectly harmless > situation. > > (i hope i got the question right?) > > > On Tue, May 16, 2017 at 05:53:17PM +0000, Adam Bergmark wrote: > > Date: Tue, 16 May 2017 17:53:17 +0000 > > From: Adam Bergmark <adam(a)bergmark.nl> > > To: José Manuel Calderón Trilla <jmct(a)jmct.cc>, > haskell-prime(a)haskell.org > > Subject: Re: Default module header `module Main where` > > > > GHCIs current behavior seems inconsistent with this, why is foo > accessible > > and why don't I get an unused warning like i do if i have an explicit > > `module Main (main) where`? > > > > ``` > > $ cat Main.hs > > main :: IO () > > main = pure () > > > > foo :: Int > > foo = 1 > > > > $ ghci Main.hs -Wall > > GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help > > Loaded GHCi configuration from /Users/adam.bergmark/.ghci > > [1 of 1] Compiling Main ( Main.hs, interpreted ) > > Ok, modules loaded: Main. > > > > λ foo > > 1 > > ``` > > > > On Tue, 16 May 2017 at 19:00 José Manuel Calderón Trilla <jmct(a)jmct.cc> > > wrote: > > > > > Agreed, this sounds sensible. > > > > > > Can anyone think of any unintended consequences? > > > > > > -Jose > > > > > > On Tue, May 16, 2017, at 09:50 AM, Iavor Diatchki wrote: > > > > > > That seems fairly reasonable to me. > > > > > > -Iavor > > > > > > On Tue, May 16, 2017 at 7:18 AM, Joachim Breitner < > > > mail(a)joachim-breitner.de> wrote: > > > > > > Hi, > > > > > > a very small proposal to be considered for Haskell': > > > > > > Currently, the report states > > > > > > An abbreviated form of module, consisting only of the module body, > > > is permitted. If this is used, the header is assumed to be ‘module > > > Main(main) where’. > > > > > > I propose to change that to > > > > > > An abbreviated form of module, consisting only of the module body, > > > is permitted. If this is used, the header is assumed to be ‘module > > > Main where’. > > > > > > The rationale is that a main-less main module is still useful, e.g. > > > when you are working a lot in GHCi, and offload a few extensions to a > > > separate file. Currently, tools like hdevtools will complain about a > > > missing main function when editing such a file. > > > > > > It would also work better with GHC’s -main-is flag, and avoid problems > > > like the one described in > https://ghc.haskell.org/trac/ghc/ticket/13704 > > > > > > > > > I don’t see any downsides. When compiling to a binary, implementations > > > are still able to detect that a Main module is not imported by any > > > other module and only the main function is used, and optimize as if > > > only main were exported. > > > > > > Greetings, > > > Joachim > > > > > > > > > > > > -- > > > Joachim “nomeata” Breitner > > > mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ > > > XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > > > Debian Developer: nomeata(a)debian.org > > > _______________________________________________ > > > Haskell-prime mailing list > > > Haskell-prime(a)haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > > > *_______________________________________________* > > > Haskell-prime mailing list > > > Haskell-prime(a)haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > > > > > > _______________________________________________ > > > Haskell-prime mailing list > > > Haskell-prime(a)haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > > > _______________________________________________ > > Haskell-prime mailing list > > Haskell-prime(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > -- > https://zerobuzz.net/ > mf(a)zerobuzz.net > +49 179 7733 223 > > > ------------------------------ > > Message: 2 > Date: Tue, 16 May 2017 13:25:16 -0700 > From: Iavor Diatchki <iavor.diatchki(a)gmail.com> > To: Joachim Breitner <mail(a)joachim-breitner.de> > Cc: "haskell-prime(a)haskell.org Prime" <haskell-prime(a)haskell.org> > Subject: Re: Default module header `module Main where` > Message-ID: > <CAGK9nupOZ4a84V+= > sjWnSafi_peu9nzpvxE5dpeAekDdwsxRfA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > One potential difference between the two is that the current behavior > allows the `Main` module to import `main` from another module, while the > new behavior would fail in that case. > > For example, a file that has only a single line: > > import SomeOtherModule(main) > > This still seems like a fairly unusual corner case (with an obvious work > around), so I don't think it matters much, but I thought I'd mention it so > that we are aware of it. > > > > > > > On Tue, May 16, 2017 at 7:18 AM, Joachim Breitner < > mail(a)joachim-breitner.de> > wrote: > > > Hi, > > > > a very small proposal to be considered for Haskell': > > > > Currently, the report states > > > > An abbreviated form of module, consisting only of the module body, > > is permitted. If this is used, the header is assumed to be ‘module > > Main(main) where’. > > > > I propose to change that to > > > > An abbreviated form of module, consisting only of the module body, > > is permitted. If this is used, the header is assumed to be ‘module > > Main where’. > > > > The rationale is that a main-less main module is still useful, e.g. > > when you are working a lot in GHCi, and offload a few extensions to a > > separate file. Currently, tools like hdevtools will complain about a > > missing main function when editing such a file. > > > > It would also work better with GHC’s -main-is flag, and avoid problems > > like the one described in https://ghc.haskell.org/trac/ghc/ticket/13704 > > > > > > I don’t see any downsides. When compiling to a binary, implementations > > are still able to detect that a Main module is not imported by any > > other module and only the main function is used, and optimize as if > > only main were exported. > > > > Greetings, > > Joachim > > > > > > > > -- > > Joachim “nomeata” Breitner > > mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ > > XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > > Debian Developer: nomeata(a)debian.org > > _______________________________________________ > > Haskell-prime mailing list > > Haskell-prime(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > >

3 2