Re: Remove eq and show from num class

[Cale Gibbard]

I fully agree with Edward here. This change to Num has been a positive one.
It also seemed fairly uncontroversial as far as Prelude changes go - many
people wanted to see that change for years. While it caused a handful of
hiccups when it happened, it was generally easy enough to fix code to
support it. If anyone would care to argue against the change, I would
recommend pointing your time machines at the end of 2011.

Regardless of how you may feel about GHC and its derivatives (GHCJS mainly)
being the main implementation, it at least ought to make it easier to
determine what is true of modern Haskell. If we want the Report to continue
to document the Prelude, I would start by looking at what it actually
exports now, and trying to follow that as closely as reasonable. It would
be much more valuable in my opinion if the Report were to document a
language that really exists.
On Sun, Sep 10, 2017, 11:00 Edward Kmett  wrote:

> On Sun, Sep 10, 2017 at 4:48 AM, Anthony Clayden <
> anthony_clay...@clear.net.nz> wrote:
>
>> > 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.
>>
>
> Smileys and process aside, all that is being proposed is ratifying the
> actual behavior that GHC has had since 2011. Num would lose Eq and Show
> superclasses in the report. This allows users to create instances like Num
> a => Num (x -> a), overloaded integers for working with non-printable
> expression types, infinite precision real number types that literally
> cannot be safely compared for equality, etc. All of which are fairly common
> things to talk about in haskell today.
>
> Yes, a small section of the report would have to be rewritten slightly to
> codify the change in report behavior, and that numeric literals in pattern
> position need to incur an Eq constraint, which is what they do today in GHC.
>
> Nobody is proposing removing any instances for types that have them,
> merely capturing the existing behavior that having Num a does not imply Eq
> a and Show a. There is simply no good reason other than historical accident
> for it to do so and many good reasons for it to not.
>
> -Edward
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Edward Kmett]

On Sun, Sep 10, 2017 at 4:48 AM, Anthony Clayden <
anthony_clay...@clear.net.nz> wrote:

> > 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.
>

Smileys and process aside, all that is being proposed is ratifying the
actual behavior that GHC has had since 2011. Num would lose Eq and Show
superclasses in the report. This allows users to create instances like Num
a => Num (x -> a), overloaded integers for working with non-printable
expression types, infinite precision real number types that literally
cannot be safely compared for equality, etc. All of which are fairly common
things to talk about in haskell today.

Yes, a small section of the report would have to be rewritten slightly to
codify the change in report behavior, and that numeric literals in pattern
position need to incur an Eq constraint, which is what they do today in GHC.

Nobody is proposing removing any instances for types that have them, merely
capturing the existing behavior that having Num a does not imply Eq a and
Show a. There is simply no good reason other than historical accident for
it to do so and many good reasons for it to not.

-Edward
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Anthony Clayden]

> 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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Sven Panne]

2017-09-08 10:43 GMT+02:00 Herbert Valerio Riedel :

> [...] Moreover, the CLC together with the Hackage Trustees also maintains
> the
> https://github.com/haskell/pvp specification which is integral to the
> way Hackage and the Cabal solver interact. [...]
>

Although I'm actively following quite a few Haskell-related mailing lists
and maintain various Haskell packages, this is the first time in my life
that I've heard of https://pvp.haskell.org/. It would be good to improve
communication about such central pieces of information... :-/ Don't get me
wrong: The page itself is great, as are other pages/repos/mailing lists,
but the overall organization of information leaves a lot to be desired IMHO.

Cheers,
   S.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[John Wiegley]

> "CS" == Carter Schonwald  writes:

CS> I mostly wanted to confirm that we in fact will actually say yes before
CS> doing the formal writtingup :)

Ah, I actually misread the English sentence!  I though it said "all yays from
committee members", and that it was then asking people to simply affirm the
vote. I should have read, "everyone who agrees, say yay". :)

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Bardur Arantsson]

On 2017-09-08 13:55, Anthony Clayden wrote:

>> 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.

AFAIUI these are far from trivial to spec without reference to
implementation details such as the type inference algorithm, etc.

> 
> 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.
> 

It's a strong hint that the spec should be changed. There aren't really
any widely used Haskell compilers other than GHC and speccing for things
that aren't actually used in practice is a waste of time (at best) and
actively harmful (at worst). There's a reason that Design by Committee
is generally seen as a bad thing if you don't actually have an
implementation to guide the spec.

Regards,

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Carter Schonwald]

I mostly wanted to confirm that we in fact will actually say yes before
doing the formal writtingup :)

On Fri, Sep 8, 2017 at 2:06 PM, John Wiegley  wrote:

> > "AC" == Anthony Clayden  writes:
>
> AC> All yays from committee members please reply with yes to this email :)
>
> Just to note: I don't recall their being an actual "vote" on this during
> our
> informal meeting of just a few of the committee members here at ICFP, so I
> took Carter's note to be a sign of enthusiasm, and not actual procedural
> decision making.
>
> --
> John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[John Wiegley]

> "AC" == Anthony Clayden  writes:

AC> All yays from committee members please reply with yes to this email :)

Just to note: I don't recall their being an actual "vote" on this during our
informal meeting of just a few of the committee members here at ICFP, so I
took Carter's note to be a sign of enthusiasm, and not actual procedural
decision making.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Anthony Clayden]

> 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:
>> ... 
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Anthony Clayden]

> 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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

RE: Remove eq and show from num class

[Simon Peyton Jones via Haskell-prime]

Good summary Herbert.  It'd be great to have it as a page on haskell.org, 
rather than just in soon-lost email.

Simon

| -Original Message-
| From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On Behalf
| Of Herbert Valerio Riedel
| Sent: 08 September 2017 09:43
| To: Anthony Clayden 
| Cc: haskell-prime@haskell.org
| Subject: Re: Remove eq and show from num class
| 
| On 2017-09-08 at 09:19:54 +0200, Anthony Clayden wrote:
| 
| [...]
| 
| > 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?
| 
| I can see how the proliferation of committees & github repos may seem
| confusing to casual observers, so let me provide a quick overview which
| hopefully doesn't worsen the confusion... :-)
| 
| ## Haskell Core Library Committee
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.has
| kell.org%2FCore_Libraries_Committee&data=02%7C01%7Csimonpj%40microsoft.co
| m%7Ca13a8633ae3c436a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7
| C1%7C0%7C636404570444220789&sdata=wQ%2B6bfpKtDPUmnxa54FWVDiq%2F3H7eVfnkGF
| kW4s82Ns%3D&reserved=0
| 
| Basically, the core library committee oversees decisions of what happens
| with core libraries such as `base` which includes the API defined by the
| Haskell library report. However, the Eq/Show=>Num superclass removal
| proposal (<https://mail.haskell.org/pipermail/libraries/2011-
| September/016712.html>),
| however predates the core libraries committee's existence (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).
| 
| Moreover, the CLC together with the Hackage Trustees also maintains the
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fhaskell%2Fpvp&data=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633ae3c4
| 36a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63640457
| 0444220789&sdata=uI0uVdaGjBLmNrlUqdrPeO7g6%2B4isWj8w1Qi3CDHIIU%3D&reserve
| d=0 specification which is integral to the way Hackage and the Cabal
| solver interact.
| 
| ## Haskell Language Committee (aka Haskell Prime Committee)
| 
|  - https://mail.haskell.org/pipermail/haskell-prime/2016-
| April/004050.html
| 
| So this committee's incarnation has just been formed last year; it's a
| bit too early to declare it dead.
| 
| ## GHC Steering Committee
| 
|  - https://ghc.haskell.org/trac/ghc/wiki/SteeringCommittee
| 
| This is mostly about user-facing changes to GHC and was created shortly
| after the prime committee's formation was announced. It surely wasn't
| intended to replace the prime committee, but was rather formed as a
| reaction to complaints about GHC's governance, you can read up about its
| intent at
| 
|  - https://ghc.haskell.org/trac/ghc/blog/rethinking-proposals
| 
| Not all changes are even relevant to the Haskell Report (like e.g.
| warning flags); but Report-relevant changes may start their life-cycle as
| GHC extensions to get some empirical field-testing, and if desirable to
| later be promoted to Haskell Prime proposals subject to the Prime
| process.
| 
| ## Other Committees
| 
| For completeness, here's a few other Haskell-related committees and/or
| working-group like processes OTTOMH:
| 
| ### Haskell.org committee
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.has
| kell.org%2FHaskell.org_committee&data=02%7C01%7Csimonpj%40microsoft.com%7
| Ca13a8633ae3c436a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%
| 7C0%7C636404570444220789&sdata=7yZv2psUaTehR%2FsiCtNY0n1AXzrGcHXrUKoDxeeV
| HyY%3D&reserved=0
| 
| ### The Haskell.org Website Working Group (HWWG)
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fndmitchell%2Fhwwg&data=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633a
| e3c436a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
| 04570444220789&sdata=cKoBAcJdILupv2mlkwvHuSCx1lwdwIimCi3%2BTujuSHo%3D&res
| erved=0
| 
| ### Haskell Ecosystem Proposals
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fhaskell%2Fecosystem-
| proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633ae3c436a9deb08
| d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63640457044422078
| 9&sdata=XW3ojdp3kjN8wB%2FhOzeWSi6T2UKYaH2M9u8YaSWzeGQ%3D&reserved=0
| 
| ### Industrial Haskell Group
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Findustry.
| haskell.org&data=02%7C01%7Csimon

Re: Remove eq and show from num class

[Herbert Valerio Riedel]

On 2017-09-08 at 09:19:54 +0200, Anthony Clayden wrote:

[...]

> 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?

I can see how the proliferation of committees & github repos may
seem confusing to casual observers, so let me provide a quick overview
which hopefully doesn't worsen the confusion... :-)

## Haskell Core Library Committee

 - https://wiki.haskell.org/Core_Libraries_Committee

Basically, the core library committee oversees decisions of what happens
with core libraries such as `base` which includes the API defined by the
Haskell library report. However, the Eq/Show=>Num superclass removal proposal
(),
however predates the core libraries committee's existence (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).

Moreover, the CLC together with the Hackage Trustees also maintains the
https://github.com/haskell/pvp specification which is integral to the
way Hackage and the Cabal solver interact.

## Haskell Language Committee (aka Haskell Prime Committee)

 - https://mail.haskell.org/pipermail/haskell-prime/2016-April/004050.html

So this committee's incarnation has just been formed last year; it's a
bit too early to declare it dead.

## GHC Steering Committee

 - https://ghc.haskell.org/trac/ghc/wiki/SteeringCommittee

This is mostly about user-facing changes to GHC and was created shortly
after the prime committee's formation was announced. It surely wasn't
intended to replace the prime committee, but was rather formed as a
reaction to complaints about GHC's governance, you can read up about its
intent at

 - https://ghc.haskell.org/trac/ghc/blog/rethinking-proposals

Not all changes are even relevant to the Haskell Report (like
e.g. warning flags); but Report-relevant changes may start their
life-cycle as GHC extensions to get some empirical field-testing, and if
desirable to later be promoted to Haskell Prime proposals subject to the
Prime process.

## Other Committees

For completeness, here's a few other Haskell-related committees and/or
working-group like processes OTTOMH:

### Haskell.org committee

 - https://wiki.haskell.org/Haskell.org_committee

### The Haskell.org Website Working Group (HWWG)

 - https://github.com/ndmitchell/hwwg

### Haskell Ecosystem Proposals

 - https://github.com/haskell/ecosystem-proposals

### Industrial Haskell Group

 - http://industry.haskell.org

### Commercial Haskell Group

 - https://github.com/commercialhaskell/commercialhaskell


HTH,
  HVR
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Nathan van Doorn]

Anthony, this proposal is to remove the Eq and Show constraints from the
Num class. Specific instances of Num, like Int and Float, will still have
those instances. 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.

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).

I'm not sure why this is being discussed on the mailing list rather than
the Github proposals thing, but I do know that that has grown somewhat
inactive and this is as good as anything for getting the Haskell' committee
to make a final judgement.

Nathan

On 8 Sep 2017 8:35 am, "Anthony Clayden" 
wrote:

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

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Mario Blazevic]

On Fri, Sep 8, 2017 at 3:19 AM, Anthony Clayden <
anthony_clay...@clear.net.nz> wrote:

> 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?
>

It's complementary to the GitHub repo. It seemed easier to discuss general
things via e-mail.


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.)
>

All the standard instances of Num do have instances for Eq, Ord, and other
usual classes. If you mean that you're comparing a parametric Num a => a,
you'll be disappointed when you upgrade to GHC 7.4.1:

https://downloads.haskell.org/~ghc/7.4.1/docs/html/users_guide/release-7-4-1.html
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Anthony Clayden]

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

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Henrik Nilsson]

On 09/08/2017 12:45 AM, Carter Schonwald wrote:

please say yes or no. its quite easy with email . i'm not going to write
that little proposal if folks wont accept it :)


I'd love to see those constraints go. But it is important that the full
ramifications are clearly articulated.

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.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Carter Schonwald]

well sure, i'm happy to write the 3 line diff, but because of the sheer
unambiguity of this i'd rather get the votes on email before botthering to
write the diff, at which point the main question is whether i wrote the
diff correctly


please say yes or no. its quite easy with email . i'm not going to write
that little proposal if folks wont accept it :)

On Thu, Sep 7, 2017 at 11:44 PM, Mario Blazevic  wrote:

> On Thu, Sep 7, 2017 at 6:20 PM, Richard Eisenberg 
> wrote:
>
>> I don't mean to be a killjoy, but I think even something as simple as
>> this should have a proposal. We still have to draft the changes to the
>> Report associated with this change, and at least one is non-obvious: now
>> numeric literals induce an Eq constraint (which should be mentioned). I'm
>> certainly not against this change, but I don't think it's as easy as this.
>>
>
> I agree. I just I thought it was implicit that every change to the report
> goes throught a pull request, which is the same as a proposal. Were you
> volunteering for something else, Carter?
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Mario Blazevic]

Sending to the mailing list instead of to Herbert alone...

On Thu, Sep 7, 2017 at 2:20 PM, Herbert Valerio Riedel 
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
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Mario Blazevic]

On Thu, Sep 7, 2017 at 6:20 PM, Richard Eisenberg 
wrote:

> I don't mean to be a killjoy, but I think even something as simple as this
> should have a proposal. We still have to draft the changes to the Report
> associated with this change, and at least one is non-obvious: now numeric
> literals induce an Eq constraint (which should be mentioned). I'm certainly
> not against this change, but I don't think it's as easy as this.
>

I agree. I just I thought it was implicit that every change to the report
goes throught a pull request, which is the same as a proposal. Were you
volunteering for something else, Carter?
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Richard Eisenberg]

I don't mean to be a killjoy, but I think even something as simple as this 
should have a proposal. We still have to draft the changes to the Report 
associated with this change, and at least one is non-obvious: now numeric 
literals induce an Eq constraint (which should be mentioned). I'm certainly not 
against this change, but I don't think it's as easy as this.

Richard

> On Sep 7, 2017, at 4:43 PM, Carter Schonwald  
> wrote:
> 
> All yays from committee members please reply with yes to this email :) 
> 
> -Carter 
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Herbert Valerio Riedel]

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... :-)

> 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#successful-proposals

?

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.

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.

> 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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Mario Blazevic]

On Thu, Sep 7, 2017 at 11:47 AM, Herbert Valerio Riedel 
wrote:

> "yes" :-)
>
> 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. We agreed today to move the report
itself to the https://github.com/haskell/rfcs/ repository. 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. I wish GitHub made it possible
to symlink files in two repositories like this.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Mario Blazevic]

On Thu, Sep 7, 2017 at 11:43 AM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

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

Yes please.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Herbert Valerio Riedel]

"yes" :-)

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

On Thu, Sep 7, 2017 at 5:43 PM, Carter Schonwald
 wrote:
> All yays from committee members please reply with yes to this email :)
>
> -Carter
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Remove eq and show from num class

[Cale Gibbard]

If you don't do it, the Report will just be inaccurate.

On Thu, 7 Sep 2017 at 11:43 Carter Schonwald 
wrote:

> All yays from committee members please reply with yes to this email :)
>
> -Carter
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Remove eq and show from num class

[Carter Schonwald]

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

-Carter
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime