- Libraries - Haskell.org

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

13 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 11 Mar '18

11 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

Re: Storable laws
by Henning Thielemann 07 Mar '18

07 Mar '18

On Sun, 17 Dec 2017, Merijn Verstraaten wrote: > Tools like hsc2hs already pad the result of sizeOf to the appropriately > aligned size (at least the ones I've used), so this is a non-issue for > that scenario. But that's tailored to C. If I understand Sven correctly, then this is not valid for Storable.

5 7

What stops Data.Foldable from having foldl1'?
by sonne 06 Mar '18

06 Mar '18

Good evening. I notice Data.Foldable ain't got no `foldl1'`, while `foldl'` and `foldl1` are both there. Is there a reason? What will it take to have it introduced? I refer to this specific version, which is to my understanding the latest to have been released: https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Foldable.html Thank you.

3 2

Re: opt out of accursedUnutterablePerformIO
by David Feuer 05 Mar '18

05 Mar '18

Does bytestring turn off some optimization flags (e.g., -fno-full-laziness) to make this work? On Mar 5, 2018 8:48 AM, "Ben Franksen" <ben.franksen(a)online.de> wrote: Am 04.03.2018 um 22:48 schrieb Ben Gamari: >> Ben Franksen <ben.franksen(a)online.de> writes: >> Anyway. Would you perchance have any idea what could possibly make a >> program work fine with the first version of linesPS and crash with the >> second one? I find this pretty scary and would like to understand it. >> > Indeed that is quite scary. The cause is not at all obvious. Do you have > an isolated reproducer that you could share? Sharing is no problem, this happened with darcs, which notably has its own share of dark and dangerous corners. I have considered trying to cook this down to some small example but my hopes of succeeding with this are almost nil. As I said, I have no evidence whatsoever that the problem has even anything to do with that-what-must-not-be-named, it's been purely a guess. FWIW, I re-checked that the behavior is reproducible. I have uploaded a clone of darcs-screened with my patch applied on top to https://hub.darcs.net/bf/darcs-screened To reproduce the crash, cabal configure with --enable-tests, then do ./dist...whatever...darcs-test --shell=no Unpull the last patch and everything works. Cheers Ben _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

Re: Proposal: Add Eq1 and Ord1 instances in GHC.Generics, and synchronize with Data.Functor.* types
by Ryan Scott 25 Feb '18

25 Feb '18

> - GHC.Generics is missing Eq1, Ord1, Show1, Read1 instances I'd be in favor of this idea. However, see my caveat below. > Data.Functor.* is missing Semigroup and Monoid instances (that my > previous proposal would add to GHC.Generics) This is (or was) by design. See [1] for the full story. We migrated the Data.Functor.* module hierarchy from transformers, which is a library that is very much committed to using a Haskell98 style of code. The style of Semigroup/Monoid instances you're proposing to be added would not be Haskell98, since an instance like this: instance Monoid (f (g p)) => Monoid (Compose f g p) Would not be Haskell98 due to its use of FlexibleContexts. Of course, there are other ways one could conceivably define Monoid instances for these classes that are Haskell98, but as Edward noted in [1], they each had subtle flaws. So, we punted on the idea of adding Semigroup/Monoid instances at the time. Now granted, we didn't adhere to this Haskell98 philosophy everywhere. We did add Data instances for Compose et al., for example, and those require FlexibleContexts due to the way they work. But Data is a GHC-specific class, so this exception is somewhat understandable. However, you're proposing we make an exception for Semigroup/Monoid. Is this OK? Granted, the Haskell Report mentions neither to my knowledge, but at the same time, nothing about them requires FlexibleContexts on the surface. So I'm a bit ambivalent about the idea. Now, back to Eq1, Ord1, Show1, and Read1. The arrival of these classes into base predates GHC.Generics, so when Eq, Ord, Read, and Show instances were added for the data types in GHC.Generics, they were of the form: instance (Eq (f (g p)) => Eq ((f :.: g) p) instance (Ord (f (g p)) => Ord ((f :.: g) p) ... Of course, this is not what is done for the data types in the Data.Functor.* hierarchy. For instance, there we have: instance (Eq1 f, Eq1 g) => Eq (Compose f g p) instance (Ord1 f, Ord1 g) => Ord (Compose f g p) ... So while we could add Eq1, Ord1, Read1, and Show1 instances for the data types in GHC.Generics, it does serve as a reminder that the corresponding Eq, Ord, Read, and Show instances are inconsistent with the ones from the Data.Functor.* space. Personally, I don't think this need be a dealbreaker—after all, Eq1 et al. simply weren't around at the time. It just means that if we ever have a (theoretical) merger of the data types between Data.Functor.* and GHC.Generics, we'd have to pick one style of Eq/Ord/Read/Show instances over the other. But this is a bridge we need not cross now. *tl;dr* I'm +1 in favor of your first idea, and ambivalent about your second idea. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/11135#comment:25

1 0

Proposal: Add Eq1 and Ord1 instances in GHC.Generics, and synchronize with Data.Functor.* types
by Li-yao Xia 25 Feb '18

25 Feb '18

Eq1 and Ord1 are two more useful classes to implement in GHC.Generics, and would be useful to derive Eq1 and Ord1 generically. Note that we can currently use transformers-compat to derive these. Moreover, most of the GHC.Generics types are equivalent to types in the Data.Functor.* modules. Would it be a good idea for them to have the same instances? Concretely, the current differences are: - GHC.Generics is missing Eq1, Ord1, Show1, Read1 instances - Data.Functor.* is missing Semigroup and Monoid instances (that my previous proposal would add to GHC.Generics) Li-yao

1 0