- Libraries - Haskell.org

Inaccurate docs for atomically
by Andrew Martin 12 Nov '17

12 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 01 Nov '17

01 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

Re: Deprecating fromIntegral
by dominic＠steinitz.org 22 Sep '17

22 Sep '17

> On 22 Sep 2017, at 13:43, Dominic <dominic.steinitz(a)blueyonder.co.uk> wrote: > > Coincidentally, I was playing with this a few days ago. I didn’t seem to have to do anything to get a warning. > >> GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >> Prelude Data.Word> :m Data.Int >> Prelude Data.Int> 0x80000000 :: Int32 >> >> <interactive>:27:1: warning: [-Woverflowed-literals] >> Literal 2147483648 is out of the Int32 range -2147483648..2147483647 >> If you are trying to write a large negative literal, use NegativeLiterals >> -2147483648 >> Prelude Data.Int> :set -XNegativeLiterals >> Prelude Data.Int> 0x80000000 :: Int32 >> >> <interactive>:29:1: warning: [-Woverflowed-literals] >> Literal 2147483648 is out of the Int32 range -2147483648..2147483647 >> -2147483648 > > I am not clear why it wanted me to use NegativeLiterals but still give the same warning. Does anyone understand the intent here? > >> Message: 1 >> Date: Fri, 22 Sep 2017 14:14:12 +0200 >> From: Herbert Valerio Riedel <hvriedel(a)gmail.com> >> To: Niklas Hambüchen <mail(a)nh2.me> >> Cc: Haskell Libraries <libraries(a)haskell.org> >> Subject: Re: Deprecating fromIntegral >> Message-ID: >> <CAOFsArv1rDT1=KsM_z1vDOf_CW-jamOT8nzGzHk3VnxuEvjMug(a)mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> ...there's one minor detail I'd like to point out as it doesn't seem >> to have been mentioned so far: >> >> On Thu, Sep 21, 2017 at 5:34 PM, Niklas Hambüchen <mail(a)nh2.me> wrote: >> >>> (Though, in practice the current `fromInteger is not partial, e.g. >>> `(fromInteger 256 :: Word8) == 0` without error >> >> That's true. However, here's something you can do already now with >> recent GHCs which gives turns literal-overflows GHC is able to detect into >> hard compile errors: >> >> >> $ ghci -Wall -Werror=overflowed-literals >> GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help >> Prelude> (256 :: Data.Word.Word8) == 0 >> >> <interactive>:1:2: warning: [-Woverflowed-literals] >> Literal 256 is out of the GHC.Word.Word8 range 0..255 >> >> <no location info>: error: >> Failing due to -Werror. >> Prelude> >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> ------------------------------ >> >> End of Libraries Digest, Vol 169, Issue 30 >> ****************************************** > Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

Proposal: Bring the Contravariant class to base
by Daniel Díaz Casanueva 19 Sep '17

19 Sep '17

Dear haskellers, I admit I might not have the strongest arguments here, but I thought that I would share my opinion anyway, and maybe get other people's perspectives. I would like to propose bringing the Contravariant class [1] to base. I know, base keeps growing, and maybe there is no need for it to grow further without a strong argument, but I do feel like Contravariant is a simple, very basic class, that would receive better and greater use if included in base. Contravariant is very similar to Functor (some people call it CoFunctor), but in `contramap` (Contravariant's `fmap`) the "arrow" of the applied function goes in the opposite direction. I think that `contramap` can be useful for many types, just like `fmap` is for many others, but we don't use it because it's not yet so popular, or maybe because it requires the contravariant package to be included as dependency (although personally I don't think that is a real problem). The contravariant package itself provides a plentiful of instances, many of them for types in base. In a real world scenario I had, it was very useful to add a Contravariant instance to `Data.Aeson.ToJSONKeyFunction`, that perhaps is not included in aeson because either it was not desired to add the contravariant package as dependency, or simply because Contravariant is not so well-known. Note that, however, `FromJSONKeyFunction` _is_ instance of Functor. Even though both instances are equally natural and useful in this context, only one of them was implemented. This probably would not have happened if Contravariant was in base. So, in my opinion, for the sake of completeness, I think we should add Contravariant to base, just as we have Functor. Note that my proposal does not necessarily include the rest of types and functions defined in the contravariant package. Best regards, Daniel Casanueva # References [1] http://hackage.haskell.org/package/contravariant-1.4/docs/Data-Functor-Cont…

13 16

Re: [Haskell-cafe] Maintenance of streaming and streaming-bytestring
by Andrew Martin 14 Sep '17

14 Sep '17

If I can do that with a hackage revision, i'll go ahead and do that tonight. If not, there will probably be a new release for both of them in the next week anyway, so I would just wait until then to do it. Sent from my iPhone > On Sep 14, 2017, at 6:08 PM, Bardur Arantsson <spam(a)scientician.net> wrote: > >> On 2017-09-13 19:31, Andrew Martin wrote: >> The streaming and streaming-bytestring libraries are now being >> maintained here: https://github.com/haskell-streaming >> > > You might want to upload a new package to Hackage with a change of URL > :). The Hackage package currently points to the old GitHub. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0