- Libraries - Haskell.org

Monoid Instance for ReaderT
by Andrew Martin 28 Nov '17

28 Nov '17

There's a thread from earlier this year where someone asked about a Monoid instance for ReaderT: https://mail.haskell.org/pipermail/haskell-cafe/2017-March/126588.html Several other people showed interest in the instance, but in the end, the request was dismissed since there are other valid monoid instances for ReaderT. Conseqently, the PR was closed ( https://hub.darcs.net/ross/transformers/issue/38) This final comment ( https://mail.haskell.org/pipermail/haskell-cafe/2017-March/126605.html) concludes with: > In the absence of a principled reason to prefer one over the others and a general consensus, I think it’s better not to choose. This is the point I'd like to argue. There were three possible monoid instances for ReaderT discussed. They are: instance (Applicative m, Monoid a) => Monoid (ReaderT r m a) instance (Alternative m) => Monoid (ReaderT r m a) instance (Monoid (m a)) => Monoid (ReaderT r m a) I believe there is good reason to prefer the first instance over the other two. The third instance requires FlexibleContexts. This takes it outside the realm of Haskell98 and Haskell2010, which the transformers library stays within. In fact, transformers pioneered the Eq1, Ord1, etc. classes that ended up in base specifically to avoid FlexibleContexts, and deviating from this now seems against the spirit of the library, since transformers intends that it is able to be built with any Haskell compiler, not just GHC. The Alternative-based instance is reasonable, but we already have another instance that for ReaderT that is implemented this way: the Alternative instance! Here it is: instance Alternative m => Alternative (ReaderT r m) Here I'm going to loosely adapt an argument that Gabriel Gonzalez makes when defending his Monoid instance for ListT ( https://www.reddit.com/r/haskell/comments/4r5bcj/listtransformer_a_beginner… ): > Also, with the Alternative class the only thing you can do is concatenate collections (there's no way to write the cartesian product because the whole class is higher-kinded) so it's meaning is always unambiguous. However, with the Monoid class there are two possible behaviors (append or cartesian product). Given that the Alternative class has to be append, I prefer to give the Monoid class the other behavior. From the end user's perspective, if you use Alternative you always know exactly what you are getting so there is no disadvantage to using Alternative. > The other reason that it's nice to give the Monoid class the other behavior is that it works really nicely when chaining monoid instances as described in this post. The Alternative instance for ReaderT has to be Alternative-based. There is no way around this. Given that we have two possibilities for the Monoid instance, I would prefer to see the one that gives us something different from an instance we already have. Why is it beneficial to have the different behavior instead of the existing behavior? In part, it's because we now have a greater number of behaviors from the typeclasses that most people are familiar with. Additionally, we actually end up in a better situation when the Monoid instance isn't what we need. Let's consider two scenarios to measure the inconvenience that a user faces when the Monoid instance isn't the one that they want: 1) The Monoid instance for ReaderT, WriterT, StateT, etc. is Monoid-based but we wish are in a scenario where we want the Alternative-based one. 2) The Monoid instance for ReaderT, WriterT, StateT, etc. is Alternative-based but we wish are in a scenario where we want the Monoid-based one. In scenario (1), the workaround is trivial. In Data.Monoid, we have Alt, which recovers a Monoid instance from an Alternative instance: newtype Alt f a = Alt {getAlt :: f a} instance Alternative f => Monoid (Alt f a) where mempty = Alt empty mappend = coerce ((<|>) :: f a -> f a -> f a) The same Alt data type is reusable with ReaderT, WriterT, and StateT to recover the Alternative-based instance we wanted: myActions :: [ReaderT IO ()] runUntilSuccess :: ReaderT IO () runUntilSuccess = coerce (fold (coerce myActions :: [Alt (ReaderT IO) ()])) But what about scenario (2)? Let's say that we now instead want the Monoid-based instance that requires all of the actions to succeed. myActions :: [ReaderT IO ()] runAll :: ReaderT IO () runAll = ... What do we put in place of the ellipsis? We can just write it out by hand, but it would be nicer if this Monoid instance was reusable in some way. Let's say that we introduce a newtype wrapper for the Monoid-based Monoid instance: newtype MonoidReaderT m a = MonoidReaderT ... instance (Applicative m, Monoid a) => Monoid (MonoidReaderT m a) But now if we want something like this for StateT or WriterT, they're going to need their own newtype wrappers as well. That's unfortunate. In scenario (1), we needed a single newtype wrapper (that already exists in base!) to recover everything that we lost. In scenario (2), we need a newtype wrapper per type. So, by providing an instance that gives us more behaviors from haskell's blessed set of typeclasses, we end up in a better situation when we need to recover what we don't have. Finally, and this is the weakest part of my argument since it's pure speculation, I think that the Monoid-based instance is more useful in practice. For some loosely analogous historical precedent, I would point to the Monoid instance for IO. In July 2014, Edward Kmett pointed out that one issue with admitting a Monoid instance for IO was that two possible instances existed ( https://mail.haskell.org/pipermail/glasgow-haskell-users/2014-July/025124.h…) One of them monoidally concatenated the results, and the one was identical to IO's Alternative instance. Sounds familiar. Ultimately though, in November 2014, when Gabriel Gonzalez proposed the instance that monoidally concatenated results, nobody objected ( https://mail.haskell.org/pipermail/libraries/2014-November/024310.html) Every person who responded on the mailing list wanted the Monoid-based instance, not the one that was a copy of Alternative. (And it's always recoverable via Alt in the event that someone does want it). So, and again I want to stress that I consider this a weaker part of the argument since it's more rooted in human preferences rather than logic, I think the Monoid-based instance is just generally more useful in practice. In my own experience, I often have wanted the Monoid-based instances, but I have never wanted the Alternative-based instances With all that said, I would like to ask that the Monoid-based Monoid instances for ReaderT, WriterT, StateT, AccumT, etc. be considered. I would also appreciate any feedback or further discussion of this issue. -- -Andrew Thaddeus Martin

3 5

Storing lifted and unlifted pointer types in the same Array#
by Reiner Pope 21 Nov '17

21 Nov '17

Hi libraries@, In GHC.Prim, it is documented that Array# and ArrayArray# have the same runtime representation. I'd like to exploit this to put unlifted and lifted pointers into the same array (for example, unlifted pointers at even indices and lifted pointers at odd indices). The reason I want to do this is to save some array header words, and also to improve the cache locality of my data, so that a read of a (lifted, unlifted) pointer pair only needs to touch a single cache line rather than two. I believe it is safe to do this (put unlifted and lifted pointers in the same array), as long as I always read at the same liftedness and type that I ran the write at for that index. Can you confirm? Specifically, I'm expecting to use a code pattern like the following, to read an unlifted value from an Array#, by coercing the Array# to ArrayArray#, then doing the unlifted read there: coerceToArrayArray :: Array# a -> ArrayArray# coerceToArrayArray = unsafeCoerce# coerceToUnlifted :: forall (b :: TYPE 'UnliftedRep). ArrayArray# -> b coerceToUnlifted = unsafeCoerce# indexUnliftedFromArray :: forall a (b :: TYPE 'UnliftedRep). Array# a -> Int# -> b indexUnliftedFromArray arr i = coerceToUnlifted (indexArrayArrayArray# (coerceToArrayArray arr) i) Similarly, I'm expecting to do writes by coercing the array to a MutableArrayArray# and doing the writes to that. Reiner

3 2

Proposal: add ordNub somewhere in containers
by Gershom B 13 Nov '17

13 Nov '17

There have been many discussions over the years about adding an efficient order preserving nub somewhere to our core libraries. It always comes down to the same issue: an efficient nub wants to be backed by an efficient `Set`, but the API of the `nub` itself doesn't make reference to any other data structures besides lists. So it feels a bit conceptually strange to put an efficient nub anywhere besides `Data.List` even though it can't go there without inverting our dependency tree in a weird way or inlining an efficient set implementation into the middle of it. Nonetheless, the convenience of having a good `nub` lying around in a core library is undeniable, and after writing the "usual" one in my code for the zillionth time, I decided to raise an issue about it: https://github.com/haskell/containers/issues/439 I was promptly directed here to make a proper proposal. So, here: 1) I propose two new functions, `ordNub` and `intNub` with the standard implementation (from https://github.com/nh2/haskell-ordnub) import qualified Data.Set as Set ordNub :: (Ord a) => [a] -> [a] ordNub l = go Set.empty l where go _ [] = [] go s (x:xs) = if x `Set.member` s then go s xs else x : go (Set.insert x s) xs and the same implementation, but specialized to `Int` and using `IntSet`s. The rationale for the names is that the former has a long history of use in folklore, and the latter is the obvious specialization of it. 2) I propose these functions be added to a new module in the `containers` library: `Data.Containers.ListUtils`. This can also potentially in the future add efficient list intersection, etc. as documented on the above reference link. The rationale for the new module is that it can provide a meaningful home for such functions which operate on lists, but require other data structures to be implemented efficiently... Discussion period: 2 weeks. --Gershom

13 25

Inaccurate docs for atomically
by Andrew Martin 13 Nov '17

13 Nov '17

In the stm package, the docs for atomically read: > You cannot use 'atomically' inside an 'unsafePerformIO' or 'unsafeInterleaveIO'. Any attempt to do so will result in a runtime error. (Reason: allowing this would effectively allow a transaction inside a transaction, depending on exactly when the thunk is evaluated.) This doesn't seem to be true. The following program runs fine: import Control.Monad.STM import Control.Concurrent.STM.TVar import System.IO.Unsafe main :: IO () main = do v <- atomically $ newTVar (7 :: Int) print $ unsafePerformIO $ atomically $ do readTVar v I suspect that the runtime only gives you an error if you actually create a nested transaction. Is my understanding correct? -Andrew Thaddeus Martin

4 6

Pattern synonym that provides `Typeable` constraint
by Baldur Blöndal 11 Nov '17

11 Nov '17

https://github.com/ghc/ghc/blob/4bb54a4522d44a81b2c47233f482 52bd73c38279/testsuite/tests/polykinds/T14270.hs https://github.com/sweirich/dth/blob/2bb0c9aa9adb514b787ea56 295419fae55dc3734/examples/dynamic/DataDynamic.hs This is a pattern synonym to construct but more importantly to deconstruct an explicit `TypeRep a` into a `Typeable a` constraint > asTypeable :: TypeRep a -> Dict (Typeable a) > asTypeable rep = > withTypeable rep > Dict > > pattern Typeable :: () => Typeable a => TypeRep a > pattern Typeable <- (asTypeable -> Dict) > where Typeable = typeRep Similar discussion for SingI [1], same benefits: + (Nice) direct alternative to CPS `withTypeable` + Reusable in other pattern synonyms [1] https://github.com/goldfirere/singletons/issues/273

1 0

ThreadId to Int
by Andrew Martin 02 Nov '17

02 Nov '17

ThreadId has a Show instance that makes uses the FFI to turn a ThreadId to a CInt: instance Show ThreadId where showsPrec d t = showString "ThreadId " . showsPrec d (getThreadId (id2TSO t)) foreign import ccall unsafe "rts_getThreadId" getThreadId :: ThreadId# -> CInt Can getThreadId be exported? This would make it possible to write a Hashable instance for ThreadId, and it would make it possible to use a ThreadId to index into an array (with modulus of course). -Andrew Thaddeus Martin

4 4

Proposal: Add "Alternative" instance for ZipList, as well as Semigroup and Monoid
by Zemyla 21 Oct '17

21 Oct '17

This paper on monoids and near-semirings gives an Alternative instance for ZipList consistent with its Applicative instance: https://lirias.kuleuven.be/bitstream/123456789/499951/1/main.pdf The original definition of (<|>) leaves a lot to be desired, because it iterates through the first list twice, preventing inlining of xs: ZipList xs <|> ZipList ys = ZipList $ xs ++ drop (length xs) ys Edited for efficiency, it winds up being: instance Alternative ZipList where empty = ZipList [] ZipList xs <|> ZipList ys = ZipList $ go xs ys where go [] ys = ys go xs [] = xs go (x:xs) (_:ys) = x:go xs ys A different formulation, using foldr/build, goes like this: ZipList xs <|> ZipList ys = ZipList $ build $ \c z -> let goX x xr !n = c x $ xr $ n + 1 goY y yr n | n <= 0 = c y $ yr 0 | otherwise = yr $ n - 1 in foldr goX (foldr goY (const z) ys) ys (0 :: Int) It is an idempotent monoid, and sconcat/mconcat can be written as follows: zlconcat :: Foldable t => t (ZipList a) -> ZipList a zlconcat xss = ZipList $ build $ \c z -> let goO (ZipList xs) xr !n = foldr goI endI xs 0 where goI x xk i | i < n = xk $ i + 1 | otherwise = c x $ xk $ i + 1 endI i = if i < n then xr n else xr i in foldr goO (const z) xss (0 :: Int) So in the end, the Semigroup/Monoid instances look like: instance Semigroup (ZipList a) where (<>) = (<|>) sconcat = zlconcat stimes = stimesIdempotentMonoid instance Monoid (ZipList a) where mempty = empty mappend = (<|>) mconcat = zlconcat Sadly, the paper doesn't prove that it's a valid left catch Alternative, and sort of mentions it offhand, but tests suggest it is associative, [] is obviously the identity for <|> and the zero for <*>, and pure a <|> x = pure a. Any ideas on which implementation to prefer, or different ideas for implementing sconcat/mconcat?

1 0

documentation bug in base
by Ben Franksen 15 Oct '17

15 Oct '17

Data.List claims: unlines is an inverse operation to lines. which I understand to mean prop> unlines (lines s) = s which is false in general. It should say prop> unlines (lines s) = if last s == '\n' then s else s ++ "\n" Cheers Ben

1 0

Proposal: Taking over/up network maintainership
by Merijn Verstraaten 12 Oct '17

12 Oct '17

Hi hackage admins & libraries@ readers, So, to the best of my knowledge 'network' is currently maintained by libraries@/the community, which is code for "not maintained". I've previously entertained the thought of taking up maintainership, but so far was held back by the fact that I don't do windows dev experience. I've discussed this in #ghc before and the consensus was that *nix only maintenance is probably still better than no maintenance. I was inspired to finally write this email and try to take up maintenance after spending all day yesterday tomorrow debugging an issue in my code, only to realise that Network.ByteString.Lazy.getContents will literally *always* crash/throw an exception when used. My plans are to: Short term: fix obvious errors like getContents, cut through the PR backlog on github to see what can be merged, what needs work, etc. Medium term: Improve exception/error handling (network specific exception type that people can catch), better (async) exceptions safety guarantees/documentation of safety Long term: I would like ditch the current (deprecated) high-level interface and replace it with modern high level API. Now, the biggest problem is that I don't have experience developing on Windows and neither the time nor the motivation to get started with that, so I will need someone to take up co-maintainership of the windows parts (I'll probably send an email about this to -cafe if people are supportive of me taking up maintenance). Cheers, Merijn

6 7

Re: Deprecating fromIntegral
by Thomas Jakway 25 Sep '17

25 Sep '17

I can see both sides of this and am dismayed. On the one hand, -Wall literally means with all warnings--so it makes sense to pack as many warnings as possible into it. If that's too many warnings for the end user, they can disable individual ones when looking through the output. If we wanted to be really thorough we could provide a suggestion at the end of the output ("90% of your warnings are from ____"). On the other hand, grep -I -R --include="*.hs" "fromIntegral" | wc -l on ghc prints 2598, which is a lot. For what it's worth I'm in favor of adding it to -Wall because I would rather be warned about too many things and have to force myself not to ignore them than spend a long time figuring out the source of a bug. At the very least when I do encounter a bug it'll give me somewhere to start. There's no great solution here, only tradeoffs. I won't lose any faith in Haskell whichever route we take. On 09/22/2017 02:53 PM, Evan Laforge wrote: > On Thu, Sep 21, 2017 at 4:19 PM, Niklas Hambüchen <mail(a)nh2.me> wrote: >> On 21/09/17 19:27, Evan Laforge wrote: >>> If I were to suddenly get 10,000 lines of warnings... >> If the built tool is set up sensibly (perhaps we should make it so if >> that is not already possible, but I think these days warnings of >> dependency packages are omitted anyway, as cabal and stack build them in >> parallel), you should get (and care about and fix) only warnings about >> those occurrences that are in the packages you maintain / build directly. > I mean dependencies within the project, not external packages. If > modify something in the middle of the dependency tree, I'll be usually > recompiling (say) a couple of hundred modules, for my personal > medium-ish project. I assume in a real company with a larger codebase > you could easily be recompiling thousands. Maybe just the mono-repo > ones though. > > Also I'm assuming most code is not in packages, and is not in hackage. > I have no real basis for that, other than experience with other > languages. But, as shown below, my guesses can be pretty wrong: > >> Most packages have < 3 occurrences of fromIntegral, a few have < 20 >> occurrences. Very few have more than 20. >> >> Assuming we go for a naming improvement and add 3 functions ala >> maybeFromInteger / runtimeCheckedFromInteger / fromIntegerWrap, a >> package owner would have to step through their deprecation warnings and >> replace each with one of the new 3 functions to get their package >> warning-free. > I'm surprised about that, I assumed more. Grepping for fromIntegral > in a local project, I get 259 occurrences over 693 modules... I > expected a lot more. > > However, a lot of those I think would be false positives, because > they're converting across newtypes, where the underlying type is the > same. I'm not sure what I would use for those... I guess it would be > fromIntegerWrapped, but it's kind of verbose and awkward and is > implying wrapping when it's not actually present. Maybe they should > be using 'coerce'? Most of them existed before coerce did, but that's > not an excuse any more. I think I'd be more likely to try out > int-cast. > >> I could probably already have fixed 1000 of the 7000 total occurrences >> on Hackage myself within the time it as taken me to debug integer >> conversion related problems in GHC/base in the last week. >> >> (In other words, these changes are cheap and have high payoff.) > Of course that's the bottom line, so if it's the case then it's hard > to argue against. > > I've had similar bugs due to sloppy haskell -> C FFI conversions so > I'm sympathetic to the idea. It's just a blanket deprecation on > fromIntegral seems like a broad brush. > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0