- Libraries - Haskell.org

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

An IsString (NonEmpty Char) instance
by Artyom 13 Sep '17

13 Sep '17

7 12

Bug in the documentation of (<**>)
by Wolfgang Jeltsch 11 Sep '17

11 Sep '17

Hi! The documentation of (<**>) says: “A variant of <*> with the arguments reversed.” In my opinion, this means that (<**>) = flip (<*>). However, this is not true, since (<**>) does not change the order of effects. The actual definition of (<**>) is a <**> f = liftA2 (\ x h -> h x) a f. Could this please be fixed? All the best, Wolfgang

2 1

FunctorFix
by Wolfgang Jeltsch 11 Sep '17

11 Sep '17

Hi! There is the MonadFix class with the mfix method. However, there are situations where you need a fixed point operator of type a -> f a for some f, but f is not necessarily a monad. What about adding a FunctorFix class that is identical to MonadFix, except that it has a Functor, not a Monad, superclass constraint? All the best, Wolfgang

5 18

Proposal: Rework Data.Type.Equality.==
by David Feuer 08 Sep '17

08 Sep '17

The discussion has been going for nearly a month, but I've only really gotten feedback from Richard and Ryan Scott (which was both positive and useful). Based on that feedback, I'd like to make this an official proposal and get some votes. Be it proposed that Data.Type.Equality shall be redefined as follows: type family (a :: k) == (b :: k) :: Bool where f a == g b = f == g && a == b a == a = 'True _ == _ = 'False Unlike the previous definition: 1. (==) is a *closed* type family. 2. It works out of the box for types of all kinds, in a completely uniform manner. 3. It is now safe to conclude in all cases that (a == b) ~ 'True entails a ~ b, although GHC will not give us direct evidence of that. Since all the ad hoc instances and special cases are gone, there will be cases in which the previous definition will reduce and this one will not, and vice versa. But there was no particular rhyme or reason to the way it used to be, and I think that making everything simple and uniform is worth the (likely minor) breakage. David Feuer

2 1

Re: Let's rework Data.Type.Equality.==
by Ryan Scott 05 Sep '17

05 Sep '17

Personally, I'd be more inclined towards latter approach (in https://phabricator.haskell.org/D3837) After all, one of the key properties of (==) (for which the Haddocks even make a special note) is that it does not attempt to provide an instance that works for every possible kind. Indeed, as you've discovered, there are cases when it doesn't make sense to use DefaultEq, such as for (). I'll tentatively give my support for D3837, although I'd be curious to hear what Richard has to say about this (since I'm reasonably confident he gave (==) its current implementation). Ryan S.

5 8

Let's rework Data.Type.Equality.==
by David Feuer 01 Sep '17

01 Sep '17

The (==) type family in Data.Type.Equality was designed largely to calculate structural equality of types. However, limitations of GHC's type system at the type prevented this from being fully realized. Today, with TypeInType, we can actually do it, replacing the boatload of ad hoc instances like so: type (a :: k) == (b :: k) = Equal k a b infix 4 == type family Equal (k :: Type) (a :: k) (b :: k) where Equal k ((f :: j -> k) (a :: j)) ((g :: j -> k) (b :: j)) = Equal (j -> k) f g && Equal j a b Equal k a a = 'True Equal k a b = 'False This == behaves in a much more uniform way than the current one. I see two potential causes for complaint: 1. For types of kind *, the new version will sometimes fail to reduce when the old one succeeded (and vice versa). For example, GHC currently accepts eqeq :: forall (a :: *). proxy a -> (a == a) :~: 'True eqeq _ = Refl while the proposed version does not. 2. Some users may want non-structural equality on their types for some reason. The only example in base is type instance (a :: ()) == (b :: ()) = 'True which consists two types of kind () the same even if they're stuck types. But perhaps someone wants to implement a non-trivial type-level data structure with a special notion of equality. I don't think (1) is really worth worrying too much about. For (2), if users want to have control, we could at least use a mechanism similar to the above to make the obvious instances easier to write.

2 6

Reviving strict-concurrency
by Yitzchak Gale 29 Aug '17

29 Aug '17

The base library does not provide strict variants for the basic concurrency primitives. Instead, the haddocks for Control.Concurrent.MVar recommend using Don Stewarts's strict-concurrency library: https://hackage.haskell.org/package/strict-concurrency But that library has not been buildable for years. The homepage seems no longer accessible, and there is no source repository link. I created a github repo from the tarball for version 0.2.4.1 (the latest, from 2010), and then made the minor tweaks needed to get it build with modern GHC. The library provides no tests, so I have no idea if what I did still provides the advertised guarantees or even actually works. My repo is here: https://github.com/ygale/strict-concurrency Is the library still as critical as it used to be? Perhaps not in this age of async and STM, but to me it still makes sense to offer strict versions of these primitives. If so, then perhaps this small and simple library should be taken under the wing of libraries as maintainer. In any case, could someone please at least apply my patch and upload to hackage, so that it will be buildable again? I became aware of this because I was hoping to use vacuum for a complex debugging task, but vacuum also hasn't been buildable for several years due to its dependence on strict-concurrency. Whether vacuum will actually work after several years of neglect is a separate question. Thanks, Yitz

3 3