Re: Remove eq and show from num class

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

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,
participants (2)
-
Anthony Clayden
-
Bardur Arantsson