- Libraries - Haskell.org

Fwd: Give alternate default definition for (<=)
by Dannyu NDos 27 May '20

27 May '20

---------- Forwarded message --------- 보낸사람: Dannyu NDos <ndospark320(a)gmail.com> Date: 2020년 5월 8일 (금) 16:35 Subject: Re: Give alternate default definition for (<=) To: Sven Panne <svenpanne(a)gmail.com> 2020년 5월 8일 (금) 15:33, Sven Panne <svenpanne(a)gmail.com>님이 작성: > Eq is a superclass of Ord, so how do you define that for Computable? > instance Eq Computable where x == y = x <= y && y <= x >

2 3

Stop the deprecation of Data.Monoid.{First,Last}
by Simon Jakobi 26 May '20

26 May '20

Hi! For two years there has been a plan ([1], [12]) to deprecate and eventually remove Data.Monoid.{First,Last} ([13]), in order to resolve the name conflict with Data.Semigroup.{First,Last} ([14]). While implementing ([2]) this plan in GHC and the core libraries, and testing the migration in a few packages, I encountered some difficulties which made me question whether the benefits of the deprecation would outweigh its costs: * Code that previously used Data.Monoid.{First,Last} becomes noisier. See e.g. a patch to migrate the summoner package ([3]). * Higher Kinded Data applications of D.M.{First,Last} such as in higgledy ([4]) are difficult to migrate, partly due to missing instances for D.S.{First,Last} ([5]). * Additionally, there's an important difference in the strictness of the Semigroup instances for D.M.{First.Last} and the suggested replacement of (Maybe D.S.{First,Last}): [6], [9]. In sum, the existing migration story is painful in multiple ways. Moreover, D.S.{First,Last} don't actually seem to be useful in practice. I couldn't find any code using them except to define the usual newtype instances. In consequence, I think the deprecation should be scrapped, and the documentation of base updated accordingly. Regarding alternative ways to resolve the name clash, I see the following options: A) Deprecate and remove D.S.{First,Last}. B) Rename D.S.{First,Last}. C) Do nothing. Haskellers are already used to handling the name clash, usually via qualified imports. I would also like to mention that the process surrounding the deprecation has IMHO been somewhat less than ideal: 1. The deprecation was apparently decided without much research on how D.M.{First,Last} are being used in the ecosystem, and without properly testing the suggested migration. 2. Apart from the brief discussion on the libraries mailing list and changes to the haddocks ([7], [8]) for D.M.{First,Last}, there appears not to have been any announcement of the planned deprecation. 3. When, shortly after the haddocks changes, the strictness differences between D.M.First and (Maybe D.S.First) were pointed out on the libraries mailing list ([9]), the deprecation was apparently not reconsidered, nor the documentation updated. I myself wasn't aware of this aspect while I worked on the deprecation! 4. I should have sent this email 9 months ago, when I stopped working on the deprecation. The incorrect information in the haddocks has since caused some confusion ([10], [11]). What do you think? Cheers, Simon [1] https://mail.haskell.org/pipermail/libraries/2018-April/028712.html [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/842 [3] https://github.com/kowainik/summoner/pull/319 [4] https://github.com/i-am-tom/higgledy/issues/4 [5] https://gitlab.haskell.org/ghc/ghc/issues/16636 [6] https://gitlab.haskell.org/ghc/ghc/issues/17967 [7] https://gitlab.haskell.org/ghc/ghc/-/commit/e34e30e492a7bc40e3da5a05b8e297a… [8] https://gitlab.haskell.org/ghc/ghc/-/commit/cf35ab9ac7e0f33e39af6af16ecf850… [9] https://mail.haskell.org/pipermail/libraries/2018-May/028818.html [10] https://github.com/conal/checkers/issues/44 [11] https://gitlab.haskell.org/ghc/ghc/issues/18041 [12] https://gitlab.haskell.org/ghc/ghc/issues/15028 [13] http://downloads.haskell.org/~ghc/8.10.1/docs/html/libraries/base-4.14.0.0/… [14] http://downloads.haskell.org/~ghc/8.10.1/docs/html/libraries/base-4.14.0.0/…

6 13

What do you assume when you see fromListN in a library?
by Carter Schonwald 23 May '20

23 May '20

Hey everyone: When you see fromListN as a function in a library, do you assume / presume it’s expecting an exactly N element list ? Or do you expect/tolerate other behavior ? Should it reject shorter lists? Should it truncate or reject longer lists? A corner case of this came up in some bug discussion I was having regarding vector, and I shall claim and or presume that most folks assume exact size with prompt rejection of too long or too short. Thoughts please ? -Carter

13 32

Adding new contructors to IOMode to support "don't overwrite if already exists" behavior
by Grey Mitchell 22 May '20

22 May '20

The current behavior for System.IO.openFile will either truncate an existing file (with WriteMode) or append new content to the end (with AppendMode). However, there's another behavior that's available from the underlying API: signal an error when the file already exists. I poked around at the code and i think that with a couple extra variants of IOMode, this behavior could be added with a relatively small patch. I have a branch pushed where i added this behavior: https://gitlab.haskell.org/QuietMisdreavus/ghc/-/commit/1ff18d4d3fc63f42c37… I'm a relative newcomer to contributing to GHC or the base library, so if i'm missing something in my patch please let me know. Specifically, i would like to know is there's a place i can add a test for this behavior. I'm also open to changing the names of the new IOModes - this was just something i wrote in to get something working. Looking forward to working with maintainers to get this added! Thanks, Grey Mitchell (@QuietMisdreavus)

5 8

What replaces prime.haskell.org?
by Gershom B 20 May '20

20 May '20

With prime.haskell.org gone (perhaps permanently?) what becomes of its archives, in particular of libraries committee related material? In particular, I was looking up the three release policy, and the canonical link for it seems to be http://web.archive.org/web/20190422080453/https://prime.haskell.org/wiki/Li… Is this available elsewhere, or will it be migrated elsewhere? Thanks, Gershom

3 2

Potential space leak in transpose
by David Feuer 15 May '20

15 May '20

In Data.List, we define transpose :: [[a]] -> [[a]] transpose [] = [] transpose ([] : xss) = transpose xss transpose ((x : xs) : xss) = (x : [h | (h : _) <- xss]) : transpose (xs : [t | (_ : t) <- xss]) The potential difficulty is that we essentially mapMaybe over the xss list twice in the third case. So we hang on to the heads where we need the tails and the tails where we need the heads. We could fix that with something like this: transpose ((x : xs) : xss) = (x : fronts) : transpose (xs : rears) where (fronts, rears) = unzip [(h,t) | (h : t) <- xss] I don't know how much that'll cost in practice.

5 15

Better API for BaudRate
by Travis Whitaker 14 May '20

14 May '20

Hello fellow Haskellers, In my line of work I have the (mis)fortune of making extensive use of the POSIX TTY API. The System.Posix.Terminal module from the unix package is mostly fine for this, except for handling baud rates. The trouble is that POSIX stipulates the presence of a small set of baud rate options as CPP macros in the range 0 - 38400, but this is far too slow for any modern device. Linux, macOS, and likely other Unixes conditionally define many additional CPP macros for baud rates: Linux's termbits.h goes all the way up to 4000000. So, we know from CPP at compile time which baud rate values should work with the TTY syscalls. Given this, I'd propose a set of definitions for baud rates similar to what Ed Kmett uses in his "gl" package: represent baud rates as their C type, and use CPP to define bidirectional pattern synonyms for the present baud rate constants. This eliminates a key problem with the current API: baud rate code can fail at compile time (BaudRate constructors are conditionally present based on CPP) _or_ runtime (there are CPP-conditional partial functions on BaudRate in the API). With the pattern synonyms approach, all failures due to missing baud rate CPP definitions will occur at compile time, and total functions on baud rate must be defined in terms of a conversion to the underlying numeric type. There is a sketch of this technique here: https://github.com/haskell/unix/pull/145 I'm eager to hear others' thoughts on how the baud rate API might be improved. Travis Whitaker

3 2

Questions regarding Bounded
by Simon Jakobi 09 May '20

09 May '20

Hi! I was surprised not to find any documentation regarding interactions of Ord and Bounded. Are there any instances where minBound <= x == True and maxBound >= x == True don't hold for every x? Possibly relatedly, I was looking for Bounded instances for Maybe and Either. To me the following instances seem sensible: instance Bounded a => Bounded (Maybe a) where minBound = Nothing maxBound = Just maxBound instance (Bounded a, Bounded b) => Bounded (Either a b) where minBound = Left minBound maxBound = Right maxBound Are these instances omitted for a reason? Interestingly, both types do have corresponding Ord instances. Lastly, I noticed that Natural has a lower bound (0) but not an upper one, and therefore cannot have a Bounded instance. Is anyone aware of some prior art regarding a LowerBounded class or similar? Cheers, Simon

6 13

Ord methods are surprisingly strict
by Simon Jakobi 08 May '20

08 May '20

Hi! Generally, when using libraries, I expect functions to be as lazy as possible, unless they are documented to have different strictness properties. My impression was that this rule of thumb is fairly widely accepted. If this is not a good rule to work with, please do correct me! In any case, I noticed that many instances of Ord in base are an exception to that rule: (>=), max, etc. tend to evaluate both arguments, although a result could often be produced based on the value of only one argument. For example (True >= x) could return True without evaluating x, but it doesn't. The most blatant and trivial example would be () where the ordering can be determined without looking at any argument. However: $ ghci GHCi, version 8.10.1: https://www.haskell.org/ghc/ :? for help > () >= undefined *** Exception: Prelude.undefined CallStack (from HasCallStack): error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err undefined, called at <interactive>:13:7 in interactive:Ghci1 > undefined >= () *** Exception: Prelude.undefined CallStack (from HasCallStack): error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err undefined, called at <interactive>:14:1 in interactive:Ghci1 The code where I first noticed the issue looked a bit like this: data Const = Type | Kind | Sort deriving (Eq, Ord, Show) f :: NonEmpty Const -> Const f = maximum Ideally f would stop traversing the list once it encounters the first Sort. Yet it doesn't: > f (Sort :| [undefined]) *** Exception: Prelude.undefined Redefining the Ord instance is trickier than expected too: instance Ord Const where Type <= _ = True Kind <= Kind = True Kind <= Sort = True Sort <= Sort = True _ <= _ = False This is insufficient to fix max, since its default implementation is biased towards the second argument: max x y = if x <= y then y else x > max Sort undefined *** Exception: Prelude.undefined So I customize max: max Type x = x max Kind Sort = Kind max Kind _ = Kind max Sort _ = Sort (f (Sort :| [undefined])) still fails! This turns out be due to NonEmpty's Foldable instance relying on the default definition for maximum: maximum :: forall a . Ord a => t a -> a maximum = fromMaybe (errorWithoutStackTrace "maximum: empty structure") . getMax . foldMap (Max #. (Just :: a -> Maybe a)) The problem here is that Maybe's Semigroup instance is strict in both arguments! So I have to define f = foldr1 max …to finally get > f (Sort :| [undefined]) Sort So my questions are: Why are derived Ord instances and most Ord instances in base so surprisingly strict? How come the entire tooling around Ord seems so biased towards strict Ord implementations? Cheers, Simon

7 15

Give alternate default definition for (<=)
by Dannyu NDos 08 May '20

08 May '20

I have following datatype for representing arbitrary computable numbers: newtype Computable = Inexact (Word -> Integer) "Inexact" encapsulates Cauchy sequences. min and max will halt: instance Ord Computable where min (Inexact f) (Inexact g) = Inexact (\n -> min (f n) (g n)) max (Inexact f) (Inexact g) = Inexact (\n -> max (f n) (g n)) But comparison functions won't halt for same numbers: compare (Inexact f) (Inexact g) = go 0 where go n = compare (f n) (g n) <> go (n+1) So in this case, it would be inappropriate to defaultly define min and max. It would be nice if there was a function for alternately defining comparison functions: defaultLessThan :: Ord a => a -> a -> Bool defaultLessThan x y = x == y || x == min x y Then we can let (<=) = defaultLessThan. Also I have to mention that the "realAbs" function I suggested in January must be the following definition in this regard: realAbs x = max x (negate x)

2 2