Remove eq and show from num class

Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Remove eq and show from num class

Bardur Arantsson-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Remove eq and show from num class

John Wiegley-2
In reply to this post by Carter Schonwald
>>>>> "CS" == Carter Schonwald <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Remove eq and show from num class

Sven Panne-2
In reply to this post by Herbert Valerio Riedel-3
2017-09-08 10:43 GMT+02:00 Herbert Valerio Riedel <[hidden email]>:
[...] 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Shall the Haskell Report remain in LaTeX?

Herbert Valerio Riedel-3
In reply to this post by Mario Blažević
Hello *,

On 2017-09-08 at 00:46:52 +0200, Mario Blazevic wrote:

[...]

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

No, it's not that bad, it's just that there likely won't be a service
that'll work out of the box with GitHub integration like readthedocs...

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

...but I wouldn't go as far as to suggest this is reason enough to
translate the report into .rst

I guess I was rather trying to fish for some commitment that we want in
fact to stay with LaTeX; I was planning to pick up where I left things
in 2015 and clean up/refactor the TeX text and also investigate what our
current options are to generate state-of-the-art .pdf, .html and .epub
output. And I'd like to avoid this resulting a waste of effort in case
we decide to move away from LaTeX in the foreseeable future...

Long story short, is everyone ok to stay with (La)TeX, or is there some
compelling reason that would justify migrating to a different
documentation system?

-- hvr
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Shall the Haskell Report remain in LaTeX?

Carter Schonwald
I personally kinda enjoy latex.  Granted that's assuming it's well written :)

On Sat, Sep 9, 2017 at 2:41 PM Herbert Valerio Riedel <[hidden email]> wrote:
Hello *,

On 2017-09-08 at 00:46:52 +0200, Mario Blazevic wrote:

[...]

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

No, it's not that bad, it's just that there likely won't be a service
that'll work out of the box with GitHub integration like readthedocs...

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

...but I wouldn't go as far as to suggest this is reason enough to
translate the report into .rst

I guess I was rather trying to fish for some commitment that we want in
fact to stay with LaTeX; I was planning to pick up where I left things
in 2015 and clean up/refactor the TeX text and also investigate what our
current options are to generate state-of-the-art .pdf, .html and .epub
output. And I'd like to avoid this resulting a waste of effort in case
we decide to move away from LaTeX in the foreseeable future...

Long story short, is everyone ok to stay with (La)TeX, or is there some
compelling reason that would justify migrating to a different
documentation system?

-- hvr
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Remove eq and show from num class

AntC
In reply to this post by Carter Schonwald
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Remove eq and show from num class

Edward Kmett-2
On Sun, Sep 10, 2017 at 4:48 AM, Anthony Clayden <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
On Sun, Sep 10, 2017 at 4:48 AM, Anthony Clayden <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Shall the Haskell Report remain in LaTeX?

Mario Blažević-3
In reply to this post by Herbert Valerio Riedel-3
On 2017-09-09 09:40 AM, Herbert Valerio Riedel wrote:
> Long story short, is everyone ok to stay with (La)TeX, or is there some
> compelling reason that would justify migrating to a different
> documentation system?


Since nobody said no in the 7 weeks since, I think it's safe to assume
yes. Can we proceed with this now?

Once the report is a part of the RFCs repository, I assume it will
become the proper home that pull requests
https://github.com/haskell/haskell-report/pull/3 (if also accompanied by
an RFC).


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Shall the Haskell Report remain in LaTeX?

Nicolas Wu
It’s a yes from me for us to be using LaTeX, but I think it might be useful to use lhs2TeX to generate the LaTeX.

lhs2TeX makes it possible for us to write literate Haskell files as the source to the Report, which in turn allows us to type-check much of the code we write, which is nice.

Best wishes,

Nick



> On 30 Oct 2017, at 15:39, Mario Blažević <[hidden email]> wrote:
>
> On 2017-09-09 09:40 AM, Herbert Valerio Riedel wrote:
>> Long story short, is everyone ok to stay with (La)TeX, or is there some
>> compelling reason that would justify migrating to a different
>> documentation system?
>
>
> Since nobody said no in the 7 weeks since, I think it's safe to assume yes. Can we proceed with this now?
>
> Once the report is a part of the RFCs repository, I assume it will become the proper home that pull requests https://github.com/haskell/haskell-report/pull/3 (if also accompanied by an RFC).
>
>
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Shall the Haskell Report remain in LaTeX?

Mario Blažević
On 2017-10-31 05:28 AM, Nicolas Wu wrote:
> It’s a yes from me for us to be using LaTeX, but I think it might be useful to use lhs2TeX to generate the LaTeX.
>
> lhs2TeX makes it possible for us to write literate Haskell files as the source to the Report, which in turn allows us to type-check much of the code we write, which is nice.
>

        If we agree to use lhs2TeX, we can migrate the Haskell code fragments
incrementally, after we check in the existing report. I suppose that
would be just another RFC pull request, so feel free to submit it.


> Best wishes,
>
> Nick
>
>
>
>> On 30 Oct 2017, at 15:39, Mario Blažević <[hidden email]> wrote:
>>
>> On 2017-09-09 09:40 AM, Herbert Valerio Riedel wrote:
>>> Long story short, is everyone ok to stay with (La)TeX, or is there some
>>> compelling reason that would justify migrating to a different
>>> documentation system?
>>
>>
>> Since nobody said no in the 7 weeks since, I think it's safe to assume yes. Can we proceed with this now?
>>
>> Once the report is a part of the RFCs repository, I assume it will become the proper home that pull requests https://github.com/haskell/haskell-report/pull/3 (if also accompanied by an RFC).
>>
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Shall the Haskell Report remain in LaTeX?

S. Doaitse Swierstra
In reply to this post by Herbert Valerio Riedel-3
The good thing about laTeX is that out of all the candidates it is the most likely one to still work 40 years from now,

    Doaitse



> Op 9 sep. 2017, om 15:40  heeft Herbert Valerio Riedel <[hidden email]> het volgende geschreven:
>
> Hello *,
>
> On 2017-09-08 at 00:46:52 +0200, Mario Blazevic wrote:
>
> [...]
>
>>> 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?
>
> No, it's not that bad, it's just that there likely won't be a service
> that'll work out of the box with GitHub integration like readthedocs...
>
>> 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.
>
> ...but I wouldn't go as far as to suggest this is reason enough to
> translate the report into .rst
>
> I guess I was rather trying to fish for some commitment that we want in
> fact to stay with LaTeX; I was planning to pick up where I left things
> in 2015 and clean up/refactor the TeX text and also investigate what our
> current options are to generate state-of-the-art .pdf, .html and .epub
> output. And I'd like to avoid this resulting a waste of effort in case
> we decide to move away from LaTeX in the foreseeable future...
>
> Long story short, is everyone ok to stay with (La)TeX, or is there some
> compelling reason that would justify migrating to a different
> documentation system?
>
> -- hvr
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Shall the Haskell Report remain in LaTeX?

John Wiegley-2
>>>>> "DS" == Doaitse Swierstra <[hidden email]> writes:

SD> The good thing about laTeX is that out of all the candidates it is the
SD> most likely one to still work 40 years from now,

+1 from me for LaTeX as well.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Shall the Haskell Report remain in LaTeX?

Carter Schonwald
agreed

On Tue, Oct 31, 2017 at 10:37 AM, John Wiegley <[hidden email]> wrote:
>>>>> "DS" == Doaitse Swierstra <[hidden email]> writes:

SD> The good thing about laTeX is that out of all the candidates it is the
SD> most likely one to still work 40 years from now,

+1 from me for LaTeX as well.

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


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Shall the Haskell Report remain in LaTeX?

Henrik Nilsson-2
Yes, I see no benefits moving from LaTeX. So remain LaTeX.

/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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Shall the Haskell Report remain in LaTeX?

Doug McIlroy
In reply to this post by Herbert Valerio Riedel-3
> The good thing about laTeX is that out of all the candidates it is the
> most likely one to still work 40 years from now,

If past results are any measure of future performance, the only
candidate with demonstrated 40-year longevity is troff/groff :)

Doug McIlroy
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
12