- Libraries - Haskell.org

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

Re: Proposal: Add Applicative (and Monoid) instances in GHC.Generics (Libraries Digest, Vol 174, Issue 27)
by Ryan Scott 23 Feb '18

23 Feb '18

Those Monoid instances (and Semigroup instance for V1) you propose sound reasonable. I'd also be fine with adding Monoid instances for Par1, Rec1, and (:.:), since we already define other instances like Eq, Ord, Read, and Show for them. Besides, if we don't add them this time around, someone else will just ask for them later :) Ryan S.

1 0

Re: Proposal: Add Applicative (and Monoid) instances in GHC.Generics
by Ryan Scott 22 Feb '18

22 Feb '18

In response to each of your proposals: > 1. Add an instance (Monoid c => Applicative (K1 i c)) This seems like a no-brainer to me. +1 > 2. Add helpers > > gmempty :: (Generic a, Applicative (Rep a)) => a > gmempty = to (pure ()) > > gmappend :: (Generic a, Applicative (Rep a)) => a -> a -> a > gmappend a b = to (from a <*> from b) > > -- also gpure, gap for generic Applicative I'm weakly -1 on this. I don't think GHC.Generics should be a place where we collect combinators for generically implementing various type class methods. I'd prefer that these be left to downstream libraries, especially since they're usually extremely straightforward to implement and wouldn't cross the Fairbairn threshold for me. > 3. Add Monoid instances I think I support this idea. But just to be sure we're on the same page: can you say which instances in particular you're adding, and how you'd implement them? Ryan S.

4 3

Spam on Hackage
by Marco Zocca 22 Feb '18

22 Feb '18

Hi all, I've just noticed two clearly fraudulent/spammy library entries: https://hackage.haskell.org/package/my-test-docs https://hackage.haskell.org/package/Facebook-Password-Hacker-Online-Latest-… I think it would be appropriate to delete them and ban the user (which seems to be a sock puppet account anyway). Kind regards, Marco

2 1