- Libraries - Haskell.org

Proposal: Change Alternative law for some and many
by David Feuer 14 Dec '18

14 Dec '18

Currently, we document this law: > If defined, some and many should be the least solutions of the equations: > > some v = (:) <$> v <*> many v > many v = some v <|> pure [] This seems a bit too strong. I believe we should weaken "should be the least solutions of" to "should obey". This allows non-bottoming implementations for more types. I would be surprised if the change would meaningfully weaken the value of the law for reasoning about real programs. For example, we currently require some Nothing = Nothing some (Just x) = _|_ many Nothing = Just [] many (Just x) = _|_ But if we weaken the law, we could instead use some Nothing = Nothing some (Just x) = Just (repeat x) many Nothing = Just [] many (Just x) = Just (repeat x) This seems strictly, albeit slightly, more interesting. More significantly, I think, the instance for functor products can also get much better-defined: some (x :*: y) = some x :*: some y many (x :*: y) = many x :*: many y That strikes me as an improvement that may actually be of some practical value.

3 9

TestEquality for references
by Edward Kmett 13 Dec '18

13 Dec '18

I'd like to propose adding a bunch of instances for TestEquality and TestCoercion to base and primitive types such as: IORef, STRef s, MVar as well as MutVar and any appropriately uncoercible array types we have in primitive. With these you can learn about the equality of the types of elements of an STRef when you go to testEquality :: STRef s a -> STRef s b -> Maybe (a :~: b) I've been using an ad hoc versions of this on my own for some time, across a wide array of packages, based on Atze van der Ploeg's paper: https://dl.acm.org/citation.cfm?id=2976008 and currently I get by by unsafeCoercing reallyUnsafePointerEquality# and unsafeCoercing the witness that I get back in turn. =/ With this the notion of a "Key" introduced there can be safely modeled with an STRef s (Proxy a). This would make it {-# LANGUAGE Safe #-} for users to construct heterogeneous container types that don't need Typeable information about the values. Implementation wise, these can either use the value equality of those underlying primitive types and then produce a witness either by unsafeCoerce, or by adding new stronger primitives in ghc-prim to produce the witness in a type-safe manner, giving us well typed core all the way down. -Edward

5 11

Safe FFI and Blocking IO
by Andrew Martin 04 Dec '18

04 Dec '18

According to the FFI chapter [1] in the GHC manual, the safe FFI is useful when you need to call a C function that can call back into haskell code. I had always assumed that the scheduler could somehow interrupt safe FFI calls, but the manual does not indicate this, and in some recent testing I did in the posix library [2], I found that scheduling interrupts definitely do not happen. With the non-threaded runtime, the following test always hangs: testSocketsD :: IO () testSocketsD = do (a,b) <- demand =<< S.socketPair P.unix P.datagram P.defaultProtocol _ <- forkIO $ do bytesSent <- demand =<< S.sendByteArray b sample 0 5 mempty when (bytesSent /= 5) (fail "testSocketsD: bytesSent was wrong") actual <- demand =<< S.receiveByteArray a 5 mempty actual @=? sample sample :: ByteArray sample = E.fromList [1,2,3,4,5] demand :: Either Errno a -> IO a demand = either (\e -> ioError (errnoToIOError "test" e Nothing Nothing)) pure In the above example, sendByteArray and receiveByteArray are safe FFI wrappers around send and recv. It is necessary to use threadWaitRead and threadWaitWrite before these calls to predictably get the correct behavior. This brings to my question. In issue #34 on the github library for the unix package [3], there is a discussion about whether to use the safe or unsafe FFI for various POSIX system calls. On the issue there is strong consensus that the safe FFI calls lead to better performance. Simon Marlow writes [4] that "Unsafe foreign imports which can block for unpredictable amounts of time cause performance problems that only emerge when scaling to multiple cores, because they delay the GC sync. This is a really annoying problem if it happens to you, because it's almost impossible to diagnose, and if it happens due to an unsafe call in a library then it's also really hard to fix." And Gregory Collins adds that "If the call would ever block (and that includes most filesystem functions) that means you want 'safe'." There's something I'm definitely missing. My experience is that safe FFI calls do not help with blocking IO (again, I've been using the non-threaded runtime, but I doubt this makes a difference), that they only help with C functions that call back into haskell. However, a lot of other people seem to have a difference experience. [1] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi-chap.ht… [2] https://github.com/andrewthad/posix [3] https://github.com/haskell/unix/issues/34 [4] https://github.com/haskell/unix/issues/34#issuecomment-68683424 -- -Andrew Thaddeus Martin

3 5

Proposal: Add Semigroup/Monoid instance to Data.Functor.Compose
by Daniel Cartwright 30 Nov '18

30 Nov '18

Data.Functor.Compose: newtype Compose f g a = Compose { getCompose :: f (g a) } there's clear-cut, more traditional instances if `f` and `g` are Applicative: instance (Applicative f, Applicative g, Semigroup a) => Semigroup (Compose f g a) where (<>) = liftA2 (<>) instance (Applicative f, Applicative g, Monoid a) => Monoid (Compose f g a) where mempty = pure mempty There's an alternative with `QuantifiedConstraints`, but it's arguable that this is desirable: instance (forall x. Semigroup x => Semigroup (f x), forall x. Semigroup x => Semigroup (g x), Semigroup a) => Semigroup (Compose f g a) where Compose x <> Compose y = Compose (x <> y) Both to seem to fit the commonplace spirit of lifting monoids up through applicative contexts.

2 5

Whither split base?
by Carter Schonwald 22 Nov '18

22 Nov '18

I just remembered that it was one of the ongoing things the CLC was involved with, for a while. Has there been recent action there ?

13 36

Bootstrap cabal-install in sandbox
by Harley Leyton 22 Nov '18

22 Nov '18

Building cabal-install with bootstrap.sh --sandbox seems to run into https://github.com/haskell/cabal/issues/5391. Any workarounds?

1 1

Re: Proposal: Num instance for (a -> b)
by Anthony Clayden 17 Nov '18

17 Nov '18

> relevant reddit comment thread: ... Are you people completely nuts? Haven't you wreaked enough havoc with the Foldable Traversable Piffle? Why ref pointy-headed discussion on reddit when you could also ref far more frequent complaints: https://blog.plover.com/prog/haskell/type-errors.html "I think there must be something really wrong with the language design here. I don't know exactly what it is, but I think someone must have made the wrong tradeoff at some point." https://blog.plover.com/prog/haskell/evaluation-functor-2.html https://blog.plover.com/prog/haskell/evaluation-functor.html (It's by no means only that author complaining; it's just that was easiest to grab.) No, EKmett, including `length` in `Foldable` with a `((,) a)` instance is a lot more serious than "somewhat unfortunate". > At what point is it better to put "weird" stuff into its own libraries (or newtypes) and keep base clean? Always the standard Prelude should be clean of "weird" stuff. So that beginners don't have to go round the houses to exclude the standard and get a sensible Prelude. A beginner has more than enough to cope with without piling the import mechanism on them. Whereas it's no burden on the pointy-heads to import WeirdPrelude. If the CLC process were to do anything useful, I'd expect yous to be organising that. And then I could leave yew lot to turn your Haskell into Perl, where any composition of symbols can acquire some meaning. As it is, the only reason I monitor the Libraries list is to complain about proposals for nuttiness. AntC

2 1

Generalizing some type signatures involving Int
by Vanessa McHale 15 Nov '18

15 Nov '18

Would it be possible to generalize replicate and length to have type signatures replicate :: Integral a => a -> b -> [b] and length :: (Integral a, Foldable t) => t b -> a ? There have been a few instances where such a thing would have been useful to me. Cheers

8 18

Proposal: Num instance for (a -> b)
by Daniel Cartwright 12 Nov '18

12 Nov '18

relevant reddit comment thread: https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_… instance Num b => Num (a -> b) where f + g = \x -> f x + g x f * g = \x -> f x * g x f - g = \x -> f x - g x negate f = \x -> negate (f x) abs f = \x -> abs (f x) signum f = \x -> signum (f x) fromInteger i = \x -> fromInteger (f x)

8 16

Proposal to add mapAccumL function to vector package
by John Ky 08 Nov '18

08 Nov '18

Hello, I'd like to add the mapAccumL function to the vector package. Specifically the Data.Vector.Storable module, but it would also be useful other vector modules. This is my attempt at an implementation: {-# LANGUAGE ScopedTypeVariables #-} mapAccumL :: forall a b c. (Storable b, Storable c) => (a -> b -> (a, c)) -> a -> DVS.Vector b -> (a, DVS.Vector c) mapAccumL f a vb = DVS.createT $ do vc <- DVSM.unsafeNew (DVS.length vb) a' <- go 0 a vc return (a', vc) where go :: Int -> a -> DVS.MVector s c -> ST s a go i a0 vc = if i < DVS.length vb then do let (a1, c1) = f a0 (DVS.unsafeIndex vb i) DVSM.unsafeWrite vc i c1 go (i + 1) a1 vc else return a0 {-# INLINE mapAccumL #-} The implementation should obey the following law: import qualified Data.List as L import qualified Data.Vector.Storable as DVS (DVS.toList <$> DVS.mapAccumL f a (DVS.fromList bs)) === L.mapAccumL f a bs Cheers, -John

2 5