March 2018 - Libraries

What are the laws for Eq1, Eq2, Ord1, and Ord2?
by David Feuer 16 Mar '18

16 Mar '18

I was looking at the Eq2 instances for Data.Map and Data.HashMap, and the Eq1 instances for Set and HashSet, and I realized that they're a bit ... weird. My instinct is to remove these instances immediately, but I figure I should first check with the community (and Oleg, who added them to begin with) to make sure they don't make some sort of sense I don't understand. In particular, these instances compare keys in the order in which they appear in the container. That order may be completely unrelated to the given key comparison function. Data.Map example: suppose I have a Map k () and a Map (Down k) (), where Down is from Data.Ord. If I call liftEq2 (\x (Down y) -> x == y) (==), I will get what looks to me like a totally meaningless result. Data.HashMap example: suppose I have a HashMap Int () and a Hashmap String (). If I call liftEq2 (\x y -> show x == y) (==), that won't return True even if the strings in the second map are actually the results of applying show to the numbers in the first map. Intuitively, I think Eq1 f only makes sense if the shape of f x does not depend on the values of type x, and Eq2 p only makes sense if the shape of p x y does not depend on the values of types x and y. Is there a way to formalize this intuition with class laws? I believe that in the case of a Functor, parametricity will guarantee that liftEq eq (f <$> xs) (g <$> ys) == liftEq (\x y -> eq (f x) (g y)) xs ys Are there *any* legitimate instances of Eq1 or Ord1 that are not Functors? Are there *any* legitimate instances of Eq2 or Ord2 that are not Bifunctors? My intuition says no. We might wish we could write instances for unboxed arrays or vectors, but I believe that is totally impossible anyway. David

3 6

Proposal: offer a way to augment call stacks
by David Feuer 15 Mar '18

15 Mar '18

HasCallStack constraints give us a pretty good view of where we came from when an error occurs, but they don't always tell us enough about what was going on there at the time. I think we should add a small feature to the call stack interface to improve matters. == Motivating example == Suppose we have f :: Int -> Int f x = g (h x) If g throws an error because its argument is bad, we'd like to know how that happened. A HasCallStack constraint on g will reveal that g was called by f. Now we'd like to dig deeper. Was f supplied a bad argument? Did h calculate a bad value from it? If f is only called a few times, it's easy to work this out: just add a trace call to f reporting x. But if f is called thousands of times, that won't work at all. == Proposed change == I'd like to add a function (of whatever name) recordInCallStack :: forall (a :: TYPE rep) HasCallStack => String -> (HasCallStack => a) -> a We could then modify the above program thus: f :: Int -> Int f x = recordInCallStack msg (g (h x)) where msg = "x = " ++ show x Now when g throws an error, we'll see the message f recorded in its proper position in the call stack. == Implementation == I believe the cleanest approach would be to add a new constructor to CallStack (perhaps called Message): Message :: String -> CallStack -> CallStack Then recordInCallStack can look like recordInCallStack :: forall (a :: TYPE rep) HasCallStack => String -> (HasCallStack => a) -> a recordInCallStack s a = let ?callStack = Message s ?callStack in a == Questions == For performance reasons, I believe recordInCallStack should be lazy in its string argument. But this means that we could encounter another error in the process of printing a call stack. How if at all should we attempt to recover in this case? If we don't do anything special, I believe we may start printing a second call stack in the middle of the first. Kind of gross. Another option is to catch all exceptions when evaluating the message. Then we could note that the message couldn't be printed but continue with the rest of the call stack. David

2 2

Re: Proposal: Add inductively-defined Nat to base
by Daniel Cartwright 14 Mar '18

14 Mar '18

I believe that at the value level, Peano Nats can be optimised using pattern synonyms. The primary interest of Peano Nats, however, is in their use at the kind level - so I think two things are possible: 1. With -XDependentHaskell, one can define a pattern synonym allowing the optimisation of Peano Nats, 2. With type families, it _might_ be possible to define a weaker form of (1), provided it is possible to put a type synonym on the LHS of a type family. Question: Can a TypeApplication be used on the LHS of an injective type family? On Wed, Mar 14, 2018 at 9:05 PM, Daniel Cartwright <chessai1996(a)gmail.com> wrote: > The proposed addition is simple, add the following to base: > > data Nat = Zero | Succ Nat, > > i.e. Peano Nats - commonly used along with -XDataKinds. > > I will list the pros/cons I see below: > > Pros: > - This datatype is commonly defined throughout many packages throughout > Hackage. It would be good for it to have a central location > - The inductive definition of 'Nat' is useful for correctness (e.g. > safeHead :: Vec a (Succ n) -> a; safeHead (Cons a as) = a;) > - -XDependentHaskell is likely to bring this into base anyway > - I believe that it might be possible to eliminate a Peano Nat at some > stage during/after typechecking. I'm not well-versed in GHC implementation, > but something along the lines of possibly converting an inductive Nat to a > GMP Integer using some sort of specialisation (Succ -> +1)? Another > interesting, related approach (and this is a very top-level view, and > perhaps not totally sensical) would be something like a function 'f', that > given a data structure and a number system, outputs the representation of > that data structure in that number system (Nat is isomorphic to List (), so > f : List () -> Binary -> BinaryListRep) > > Cons: > - -XDependentHaskell will most likely obviate any benefit brought about by > type families defined in base that directly involve Nat > - Looking at base, I'm not sure where this would go. Having it in its own > module seems a tad strange. > > I am open to criticism concerning the usefulness of the idea, or if anyone > sees a Pro(s)/Con(s) that I am missing. > >

1 0

Proposal: Remove the bogus MonadFail instance for ST
by David Feuer 14 Mar '18

14 Mar '18

I just noted that ST is an instance of MonadFail, with fail throwing an error. This seems utterly contrary to the purpose of MonadFail! Can we please remove this instance? David Feuer

3 2

Re: Proposal: Add more exports to public array modules
by Ryan Scott 13 Mar '18

13 Mar '18

Sounds good to me. Ryan S.

1 0

Proposal: Add more exports to public array modules
by David Feuer 12 Mar '18

12 Mar '18

The array package offers several ".Unsafe" modules exporting unsafe operations. Unfortunately, there are some operations that are very important for high-performance code that are only exported from the Haddock-hidden and officially unsupported (but practically fairly stable) Data.Array.Base. Among them are: IArray methods: unsafeArray unsafeAt unsafeReplace unsafeAccum unsafeAccumArray MArray methods: unsafeRead unsafeWrite unsafeNewArray I propose that we export IArray (..) and MArray (..) from new modules Data.Array.IArray.Unsafe and Data.Array.MArray.Unsafe, respectively. David

1 0

opt out of accursedUnutterablePerformIO
by Ben Franksen 11 Mar '18

11 Mar '18

I had a program I was working on lately (darcs) crash with a segmentation fault after I made a seemingly harmless refactoring. The original code was {-# INLINE linesPS #-} linesPS :: B.ByteString -> [B.ByteString] linesPS ps | B.null ps = [B.empty] | otherwise = BC.split '\n' ps which I wanted to optimize, pasting code from the definition of Data.ByteString.lines, to linesPS ps = case search ps of Nothing -> [ps] Just n -> B.take n ps : linesPS (B.drop (n + 1) ps) where search = BC.elemIndex '\n' So I looked at the bytestring library to see if there was something that could explain the crash. I found that it uses accursedUnutterablePerformIO all over the place. The dire warnings accompanying this "function" (including the citation of a number of problem reports against commonly used libraries) made me think that it may be worthwhile to offer an opt-out for users of libraries like bytestring or text. (Note that I am not claiming my particular crash is due to a bug in bytestring, I merely want to exclude the possibility.) For the libraries in question it would be simple to do this: just add a cabal flag to optionally disable use of accursedUnutterablePerformIO. That still leaves the question of how users can make their project depend on a bytestring that has been built with this flag. I know this can be done with manual installation of a new version of the library, but I would rather use cabal new-build (as I am used to) and let it figure out itself that it has to attach a new hash to the variant with the flag. Cheers Ben

7 17

Clarification on the codes of the errors thrown by listDirectory?
by sonne 10 Mar '18

10 Mar '18

Hello! In `directory` package, there is a function `System.Directory.listDirectory`. It says on the box that it throws error messages that can be branched on. (`isDoesNotExistError`, `InappropriateType` and so on.) I dug into it a little, and it appears to me that, in actuality, on Windows (unlike on a Posix compliant operating system) there is no reliable way to sort the errors in some pre-defined categories like "no such file", "not a directory", et cetera. Therefore I must presume that either the documentation is incomplete and misleading, or it is I who is somehow misled. The information I have is summarized in a Stack Overflow question linked below. I would like to receive a clarification. Perhaps an amendment to the documentation should be considered? The point that initially aroused my suspicion is that `NoSuchThing` is associated with both `eNoEnt` and `eNotDir`. Is there a rationale behind this? From the `man 3 opendir`, I do not see the need for this ambiguity. This is the S.O. question I mentioned: stackoverflow.com/q/49212400 There is also a linked question that elaborates on the motivation behind my inquiry. Thank you!

2 1

Re: [Haskell-cafe] Dropping containers support for old GHC versions
by Tom Ellis 09 Mar '18

09 Mar '18

On Fri, Mar 09, 2018 at 11:12:40AM -0500, Brandon Allbery wrote: > Because not everyone has access to the latest and greatest hardware? (Which > attitude is showing just a bit of privilege.) > [...] I think you may be reading something into my message that I didn't say.

1 0

Is it safe to index a little bit out of bounds
by Andrew Martin 08 Mar '18

08 Mar '18

Let's say I have a gc-managed byte array of length 19. GHC promises that byte arrays are machine-word-aligned on the front end. That is, on a 64-bit machine, this array starts on a memory address that divide 8 evenly. However, the back end will certainly be unaligned. So, these two calls will be fine: - indexWordArray# myArr# 0# - indexWordArray# myArr# 1# But this one is non-deterministic: - indexWordArray# myArr# 2# Some of the bytes in the word will have garbage in them. However, this could always be masked out with a bit mask (you have to know the platform endianness for this to work right). Is this safe? I doubt think this could ever cause a segfault but I wanted to check. -- -Andrew Thaddeus Martin

4 5