Informal discussion about the progression of `base`

Core Libraries Committee
#103

… there have been previous discussions where other folks have said it too

#104

It isn’t only Haskell (or Haskellers) that have had difficulties with floating-point numbers:

Perhaps the next revision of IEEE 754 will be of assistance here…

#105

Oh there’s already cool stuff in 2008 spec that ghc isn’t using. Including a defined total order for floating point! Cf my earlier remark along with a thread we had on the libraries list in 2018 ish about signalling nans for Haskell

1 Like
#106

& should have been |>.

1 Like
#107

Also, Show is limited by the requirements of Read being able to read it. My suggestion would be to remove Read/Show overall and replace it with a better solution. Perhaps something that does some pretty printing already, too.

#108

Pretty-printing was already mentioned earlier.

#109

…if it’s so wonderful, then why on this planet did the designers of Rust opt for the likes of PartialEq and PartialOrd?

#110

FunDeps in GHC are indeed not fit for stressful purposes. There’s a draft proposal and POC implementation for that.

#111

I like python’s distinction between str() and repr(). repr is analogous to Show, ideally supporting round trips using eval() whereas str is for human readable printing.

4 Likes
#112

Perhaps, but if we’d picked |> for &, we probably would never have invented the coherent operator language that we have now. We have (<$>) = fmap acting sort of like the “functorised” version of $, and if you know that (&) = flip ($), then you can guess what (<&>) will do. The mapMaybe operators from package witherable are similarly easy to predict: <$?> and <&?>. Having |> and <| would also cause a mnemonic clash with the “one-winged” operators like (<$), ($>), (<*) and (*>). I also think that reading (&) as “and” is a nice mnemonic.

8 Likes
An alternative frontend for Haskell?
#113

Because that’s the choice they made. Decisions about anthropological constructs need not lie in the land of universal truths.

But also thats simply an equivalent way to encapsulate the check that I referenced earlier, -inf <= x <= inf , is the checking predicate for not nan according to the total order as defined in ieee.

The lack of monads or higher kinded traits makes composing the partial order stuff substantially less ergonomic than it could be though.

1 Like
#114

Yeah, maybe something like <&> would be less guessable if & was taken out, but honestly, I’m willing to make that sacrifice. On one hand, the original namesake is gone, but on the other, people can just guess that other operators are flipped if they already knew <&> existed. For the big benefit of having |>, which i definitely prefer as a name, and I think it would make more sense for about everyone involved.

1 Like
#115

To be clear: current ghc doesn’t have the total order I mentioned.

#116

I can’t believe that this has not been mentioned before:

  • maximum and minimum should have type :: (Foldable f, Ord a) => f a → Maybe a.

I lost track of how many times I’ve had to implement something along those lines. Of course such a change would break a lot of code out there…

The other part of the problem at least has been fixed nowadays (i.e. a total maximum and minimum in Data.Foldable1 with type (Foldable1 f, Ord a) => f a → a :)) (which I would have preferred to be called maximum1 and minimum1 but whatever).

4 Likes
#117

…yeah: I though this was about Haskell, not anthropology. But you have brought good news regarding the need of PartialEq and PartialOrd in Haskell: they aren’t necessary! Thank you.

So just upgrading Haskell’s floating-point “constructs” to IEEE 754-2008 - to then have regular Eq and Ord working (more) as intended for the relevant instances - should be enough. Perhaps there can be two changes Haskell 2024 (or later) introduces:

  • String (a.k.a [Char]) is replaced by Text.

  • Float and Double are updated to use IEEE 754-2008.

#118

I do not understand the benefit, and to me it looks like some kind of one-sided operator related to (<|>). Can you please explain it to me? All I see right now is the downsides: that we’d give up an operator which is pronounceable ((&) = “and”) and damage internal consistency and predictability of base and other libraries.

While on the topic of operators, I wish (<**>) didn’t exit. It seems to be very rarely used and gets in the way if one wants to define “doubled” operators like (<$$>) for something that’s Applicative-like but not a standard Applicative.

And while on the topic of Applicatives, I wish we had better support for the contravariant hierarchy somehow. I think if we’d had that, we’d have less codec typeclasses (which, unless one is really careful, often end with a domain-specific type sharing serialisation code between two very different contexts). But Divisible and Decidable are hard to use, because you have a lot of manual splitting/rearranging of tuples andEithers. I hesitate to suggest a syntax extension, because I’m not sure if adding the Arrow syntax was worth it, but maybe that would help?

Speaking of Arrows, I wish all of that had been discovered after Applicative and built on a less janky typeclass. Arrows which described their operation in terms of Profunctor, Strong, Choice, etc, would play much more nicely with the typeclasses in common use.

2 Likes
#119

So to be clear, the ieee floating point standard has both orderings available. And changing to that ordering has a different issue: all preexisting nan aware code might depend on floating point equality being defined to be irreflexive Aka for x = any nan, x!=x. That said, we could make the change and have a ghc warning to highlight or transform any such floating point expression to isNan…

There’s actually a large pile of floating point changes that would be great to do. I’m happy to do a video call or something to talk about some of the ideas and challenges for progressing ghc in that space. I’ve been a bit busy with life (health, then currently job hunting and a puppy) , so I’ve a large backlog of ideas in this space I’m more than happy to share

#120

Well, it’s defined in various places so you don’t need to reimplement it yourself. However, I agree it should be in base, and as a CLC member I would vote for inclusion. Would you care to make a proposal?

1 Like
#121

That’s the kinda compile time breakage that fixes runtime bugs, it’s not arbitrary breakage. I believe it’s a change we should encourage.

1 Like
#122

I can’t see a world in which the CLC changes the types of maximum and minimum, but I think that a proposal adding maximumMaybe and minimumMaybe is almost certain to be approved.