- Libraries - Haskell.org

Proposal: Formalise rules for how names are chosen for approved proposals
by Daniel Cartwright 27 Mar '18

27 Mar '18

I have noticed, and I say this with all due respect, that the members of this Library Mailing List (LML) have on multiple occasions derailed otherwise useful conversations over the choice of a name, which is a wasteful use of our time and effort. Below is a rough sketch of how I believe this issue could be addressed. Phase 1: LML member proposes change to widely used library, such as base Phase 2. Proposal is declined by the LML as being sufficiently useful - do nothing Phase 3. Proposal is approved by the LML - members of LML, for a period of 3 weeks, each get up to 3 picks for a name. At the end of the 3 week period, the occurrence of each name is tallied. The name with the most tallies, becomes the name.

3 5

Add a createT analogue for arrays
by David Feuer 23 Mar '18

23 Mar '18

The vector package offers createT :: Traversable t => (forall s. ST s (t (MVector s a))) -> t (Vector a) This is a generalization of create, which is very similar to runSTArray in the array package. I suggest we add functions runSTArrays :: Traversable t => (forall s. ST s (t (STArray s i e))) -> t (Array i e) runSTUArrays :: Traversable t => (forall s. ST s (t (STUArray s i e))) -> t (UArray i e) Why do I think it's worth the trouble? While it's occasionally useful to create multiple arrays of the same type in one go, I think the Maybe and (a,) Traversable instances, and their compositions, are likely more important. I can use (a,) to record some extra information while building an array. I can use Maybe to give up and not produce an array. And the compositions let me do both in different ways.

2 3

Dropping containers support for old GHC versions
by David Feuer 22 Mar '18

22 Mar '18

It's that time again. I'd very much like to drop containers support for GHC version 7.0 (so I can increase the lower bound on array to 0.4 for Safe Haskell-related reasons). I'd also prefer to drop support for GHC versions 7.2 and 7.4, but I'm somewhat open to being convinced not to. What do you all think? David

7 12

ST with Efficient (simple nice semantics exceptions) was Re: Proposal: Remove the bogus MonadFail instance for ST
by Carter Schonwald 21 Mar '18

21 Mar '18

Thanks for the shout out Gershom! I'd like to highlight that exceptions/effects as in the monad STE (aka ST + abort only semantics for exceptions) have a very very nice semantics: you can only handle the exceptions at the runMonad (runSTE :: (forall s. STE <https://hackage.haskell.org/package/monad-ste-0.1.0.0/docs/Control-Monad-ST…> e s a) -> (Either <https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Either.html#t:Ei…> e a -> b) -> b ) and you are *guaranteed* that the exceptions thrown are handled! I've used it in certain interpreter style code dumps where i (private to the ST style computation) want to use mutation, but also want to be able to efficiently do a sort of "unsafeFreeze and export the entire heap" style "core dump" for debugging/reproducible efforts when the program execution/ interpreter would other wise "crash" Monad-STE <https://hackage.haskell.org/package/monad-ste-0.1.0.0> is essentially STE s e a === ExceptT e (ST s) a, but where the throwError isn't catchable, except ONLY by runSTE :: (forall s. STE <https://hackage.haskell.org/package/monad-ste-0.1.0.0/docs/Control-Monad-ST…> e s a) -> (Either <https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Either.html#t:Ei…> e a -> b) -> b either way 1) it definitely hits a nice choice in mixing exceptions and state, because by the time you're handling the exception, THERES NO STATE, so it becomes radically simpler to handle errors because theres *NO* state to cleanup :) 2) to my knowledge, its the only monad that naturally has a Monad Throw instance (in the IO ish flavored class) but no monad catch instance 3) likewise, to my knowledge its the only known PrimBaseMonad aside from IO and the ST family 4) it'd be cool to have it in BASE, but i'm not sure whats the right way to advocate it, though its certainly meaningfully distinct from IO and ST in possible uses, though in a complimentary way that perhaps supports a "haskell is a great imperative programming tool" 5) and at the very least it can be used for pure codes which also want to have efficient abortive errors AND efficient binds (any error monad that Uses either needs to case for Left's to do failure handling, this doesn't) On Wed, Mar 21, 2018 at 12:41 AM, Gershom B <gershomb(a)gmail.com> wrote: > On March 20, 2018 at 3:53:24 PM, Zemyla (zemyla(a)gmail.com) wrote: > > To be honest, you could probably do safe throwing and catching in ST by > wrapping a thrown SomeException in some hidden exception type (call it > STException), not exporting that type, and then having the catch command be > like the IO version except it only catches and unwraps STException. > > Indeed, Carter has such a package here: https://hackage.haskell. > org/package/monad-ste-0.1.0.0 > > I wonder — could ST just be extended with some version of such > functionality directly? > > -g > > > > On Mar 20, 2018 01:40, "Jon Purdy" <evincarofautumn(a)gmail.com> wrote: > >> Just to add a couple cents, my informal intuition for “fail” is that I >> should be able to use it to “filter” things in do-notation or a monad >> comprehension: >> >> [x | Right x <- [Right "a", Right "b", Left 3]] :: [String] >> [x | Right x <- Data.Vector.fromList [Right "a", Right "b", Left 3]] :: >> Vector String >> [x | Right x <- Just (Left 3)] :: Maybe String >> >> The old “fail” implementation for Data.Vector used to throw an exception, >> and I nudged Bryan to accept a PR making it return an empty vector, so I >> could use monad comprehensions for vectors with the same expectations as >> list comprehensions. That does suggest MonadPlus as the “real” source of >> the semantics I want. >> >> But there just isn’t always a well-defined thing you can do within a >> given monad with only the type of “fail”. >> >> The fact that it raises an exception for IO is fine by me, because at >> least it can be caught in IO. On the other hand, I’d look at any code that >> actually catches pattern-match failure exceptions as pretty smelly. Still, >> in that context, to me the ideal solution is to also throw an exception in >> ST, as long as some mechanism exists for safely throwing and catching >> exceptions in ST. (I don’t know how hard that would be to add.) >> >> >> On Thu, Mar 15, 2018 at 9:53 AM, Edward Kmett <ekmett(a)gmail.com> wrote: >> >>> As one data point re: your lens, STM offers a meaningful retry. >>> >>> -Edward >>> >>> On Thu, Mar 15, 2018 at 3:46 PM, Carter Schonwald <carter.schonwald@ >>> gmail.com> wrote: >>> >>>> So this boils down to two concerns >>>> >>>> 1) should st support refutable pattern matches , and this in turn >>>> touches on pure exceptions and totality concerns >>>> >>>> 2) is monad fail actually the monad zero or just support for refutable >>>> patterns , which may sometimes use monad zero for implementation? >>>> >>>> I’m not sure one way or another. >>>> >>>> One lens for this is: how do the arguments for monad fail differ >>>> between ST and STM? >>>> >>>> >>>> On Thu, Mar 15, 2018 at 8:22 AM Michael Snoyman <michael(a)snoyman.com> >>>> wrote: >>>> >>>>> I also find your `Point` data type telling, but I think for the >>>>> opposite reason. I think most people would want to avoid letting a pattern >>>>> match silently turn into a bottom value in the `Point` data type. >>>>> >>>>> IMO, what all of this comes down to is the fact that `MonadFail` is >>>>> being used in this thread for two purposes: >>>>> >>>>> 1. By you to be the general purpose zero class >>>>> 2. By (I think) everyone else to be the class that allows you to do >>>>> refutable pattern matches >>>>> >>>>> Personally, I think `fail :: String -> m a` is a bad type for a >>>>> general purpose zero class; either MonadZero, or a type class using >>>>> `Exception` like `MonadThrow` in `exceptions, would be better. And >>>>> regardless, I don't think we should be encouraging further usage of bottom >>>>> values, even if the usage of a bottom is in fact law abiding. >>>>> >>>>> On Thu, Mar 15, 2018 at 10:34 AM, Edward Kmett <ekmett(a)gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mar 15, 2018, at 9:13 AM, Michael Snoyman <michael(a)snoyman.com> >>>>>> wrote: >>>>>> >>>>>> If the concern is a lack of ability to have the properly sequenced >>>>>> exception throwing, I would argue that the correct response is to provide a >>>>>> monomorphic `failST :: String -> ST s a` function to be explicit about the >>>>>> purpose. I'd personally go farther and make the function `throwST :: >>>>>> Exception e => e -> ST s a`. >>>>>> >>>>>> >>>>>> I definitely agree here. >>>>>> >>>>>> While it's true that `MonadFail (ST s)` obeys the laws, the point >>>>>> here is about the extra functionality provided by `MonadFail`, namely >>>>>> around pattern matching. I think the question can be boiled down to: do we >>>>>> want to make it easy to call `fail` when writing code inside `ST`? >>>>>> >>>>>> >>>>>> My point was more that this is rather distinct from the other cases >>>>>> mentioned in that it is a true legal instance, enabling things like a >>>>>> fail-based guard to actually protect against subsequent code in ST >>>>>> executing. >>>>>> >>>>>> I do find it telling that we can get into a similar situation >>>>>> completely without effects with >>>>>> >>>>>> data Point a = Point a >>>>>> >>>>>> ... >>>>>> >>>>>> instance Monad Point where >>>>>> return = Point >>>>>> Point a >>= f = f a >>>>>> >>>>>> instance MonadFail Point where >>>>>> fail = error >>>>>> >>>>>> the extra "point" added by using data rather than newtype and the >>>>>> strict pattern match in >>= plumbs the error out in the same fashion as ST >>>>>> here. >>>>>> >>>>>> I find the ability to explicitly construct bottoms at the right time >>>>>> to guard subsequent operations in those monads to be a piece of vocabulary >>>>>> that would be otherwise missing if we retroactively tried to impose some >>>>>> additional handling laws that aren't required by having a cancellative zero. >>>>>> >>>>>> On Thu, Mar 15, 2018 at 10:00 AM, Edward Kmett <ekmett(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> I'm a bit less convinced about the benefits removing the instance >>>>>>> for MonadFail (ST s). >>>>>>> >>>>>>> Playing devil's advocate here: >>>>>>> >>>>>>> Recall that throwIO is distinct from throw for a good reason, as it >>>>>>> ensures that the throwing occurs at the right step in the sequence of binds. >>>>>>> >>>>>>> The `fail` instance for ST can similarly be viewed as a perfectly >>>>>>> reasonable monotone function affecting the result of runST :: (forall s. ST >>>>>>> s a) -> a, which produces an `a` that is the appropriate bottom at the >>>>>>> right time when you take a certain branch in the ST calculation. This is >>>>>>> rather different than Identity, as you can't just ape this behavior by >>>>>>> calling 'error' instead as you need the smarter call. >>>>>>> >>>>>>> To achieve that functionality today _without_ fail, you need to >>>>>>> reach for unsafe operations `unsafeIOtoST . failIO` it to get the correct >>>>>>> semantics, which is a damn sight messier and scarier and importantly >>>>>>> removing the instance means this can't be something that is done by just >>>>>>> delegating to base monad transformer 'fail' as would be done through >>>>>>> something like `StateT s (ST s')`. This seems to create a false tension >>>>>>> between doing the most defined thing and doing the thing I want with a >>>>>>> stronger constraint, which I usually take as a sign that the building >>>>>>> blocks are wrong. >>>>>>> >>>>>>> Removing this instance comes at a real cost in terms of generality >>>>>>> of code that uses `MonadFail`: It does pass the left zero law! >>>>>>> >>>>>>> Overall, I'm -1, as I'm actually leaning against the removal of the >>>>>>> instance personally on the grounds above. >>>>>>> >>>>>>> -Edward >>>>>>> >>>>>>> On Wed, Mar 14, 2018 at 3:31 PM, Michael Snoyman < >>>>>>> michael(a)snoyman.com> wrote: >>>>>>> >>>>>>>> One possible "well behaved" intuition could be "cannot result in an >>>>>>>> exception thrown from pure code without usage of unsafe functions." By this >>>>>>>> definition: >>>>>>>> >>>>>>>> * Maybe's fail is well behaved: using `fail "foo"` results in a >>>>>>>> total Nothing value >>>>>>>> * List's: same thing, but with an empty list >>>>>>>> * IO: runtime exception, but the exception is _not_ in pure code, >>>>>>>> but rather from within IO, where exceptions are always to be expected >>>>>>>> * ST: `runST (fail "foo")` results in a pure value which, when >>>>>>>> evaluated, throws a runtime exception, breaking the well behaved definition >>>>>>>> * Identity: `Identity (fail "foo")` can only be a pure value which >>>>>>>> throws an exception, and is therefore not well behaved >>>>>>>> >>>>>>>> Note that I added the requirement of "without usage of unsafe >>>>>>>> functions," since `unsafePerformIO (fail "foo")` can result in a pure >>>>>>>> bottom value. >>>>>>>> >>>>>>>> On Wed, Mar 14, 2018 at 4:25 PM, Ryan Scott < >>>>>>>> ryan.gl.scott(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> Thanks, that makes more sense. I'm inclined to agree that MonadFail >>>>>>>>> instances should fail in a "well-behaved" way. (I wish I knew how >>>>>>>>> to >>>>>>>>> make the phrase "well-behaved" more formal, but I don't.) It might >>>>>>>>> be >>>>>>>>> worth adding this intuition to the Haddocks for MonadFail. >>>>>>>>> >>>>>>>>> That being said, one thing to consider before removing this >>>>>>>>> instance >>>>>>>>> is that there will be some breakage. Ben Gamari added this >>>>>>>>> instance in >>>>>>>>> [1] because apparently the regex-tdfa package needed it. Other than >>>>>>>>> that, though, I don't have any real objections to removing this >>>>>>>>> instance. >>>>>>>>> >>>>>>>>> Ryan S. >>>>>>>>> ----- >>>>>>>>> [1] https://phabricator.haskell.org/D3982 >>>>>>>>> >>>>>>>>> On Wed, Mar 14, 2018 at 9:58 AM, David Feuer < >>>>>>>>> david.feuer(a)gmail.com> wrote: >>>>>>>>> > I expect a MonadFail instance to have a well-behaved notion of >>>>>>>>> failure >>>>>>>>> > within the monad. An exception from "pure" code (which is what ST >>>>>>>>> > simulates) is not that. On the other hand, perhaps you're right >>>>>>>>> and >>>>>>>>> > the instance should be removed for IO as well; I don't have as >>>>>>>>> strong >>>>>>>>> > a sense of revulsion, but maybe users should be forced to be >>>>>>>>> explicit >>>>>>>>> > with throwIO. >>>>>>>>> > >>>>>>>>> > On Wed, Mar 14, 2018 at 9:46 AM, Ryan Scott < >>>>>>>>> ryan.gl.scott(a)gmail.com> wrote: >>>>>>>>> >> OK. You used the phrase "utterly contrary to the purpose of >>>>>>>>> >> MonadFail", so I'm trying to figure out exactly what you mean >>>>>>>>> here. >>>>>>>>> >> Prima facie, the purpose of MonadFail (at least, as explained >>>>>>>>> in its >>>>>>>>> >> Haddocks) is to provide a type class–directed way of desugaring >>>>>>>>> >> partial pattern matches in do-notation. With this in mind, the >>>>>>>>> current >>>>>>>>> >> MonadFail instance for ST doesn't seem too offensive. >>>>>>>>> >> >>>>>>>>> >> However, I think you have some additional property in mind that >>>>>>>>> you >>>>>>>>> >> feel the MonadFail ST instance runs afoul of. Do you mind >>>>>>>>> explaining >>>>>>>>> >> in further detail what this is? (I'm not trying to be snarky >>>>>>>>> here—I >>>>>>>>> >> genuinely don't know what you're getting at.) >>>>>>>>> >> >>>>>>>>> >> Ryan S. >>>>>>>>> >> >>>>>>>>> >> On Wed, Mar 14, 2018 at 9:41 AM, David Feuer < >>>>>>>>> david.feuer(a)gmail.com> wrote: >>>>>>>>> >>> I am not. I think that instance is fairly legitimate, as it >>>>>>>>> raises an >>>>>>>>> >>> IO exception that can be caught in IO. IO's Alternative >>>>>>>>> instance is a >>>>>>>>> >>> bit shadier, but that's not a topic for this proposal either. >>>>>>>>> ST is an >>>>>>>>> >>> entirely different story, and I'm sorry I accidentally mixed >>>>>>>>> it in. >>>>>>>>> >>> >>>>>>>>> >>> On Wed, Mar 14, 2018 at 9:05 AM, Ryan Scott < >>>>>>>>> ryan.gl.scott(a)gmail.com> wrote: >>>>>>>>> >>>> It's worth noting that the MonadFail instance for IO [1] also >>>>>>>>> simply throws >>>>>>>>> >>>> an error (by way of failIO). Are you proposing we remove this >>>>>>>>> instance as >>>>>>>>> >>>> well? >>>>>>>>> >>>> >>>>>>>>> >>>> Ryan S. >>>>>>>>> >>>> ----- >>>>>>>>> >>>> [1] >>>>>>>>> >>>> http://git.haskell.org/ghc.git/blob/ >>>>>>>>> cb6d8589c83247ec96d5faa82df3e93f419bbfe0:/libraries/base/ >>>>>>>>> Control/Monad/Fail.hs#l80 >>>>>>>>> >>>> >>>>>>>>> >>>> _______________________________________________ >>>>>>>>> >>>> Libraries mailing list >>>>>>>>> >>>> Libraries(a)haskell.org >>>>>>>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>>>>> >>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Libraries mailing list >>>>>>>>> Libraries(a)haskell.org >>>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Libraries mailing list >>>>>>>> Libraries(a)haskell.org >>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries(a)haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

1 0

Re: Proposal: Remove the bogus MonadFail instance for ST
by Ryan Scott 21 Mar '18

21 Mar '18

It's worth noting that the MonadFail instance for IO [1] also simply throws an error (by way of failIO). Are you proposing we remove this instance as well? Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/cb6d8589c83247ec96d5faa82df3e93f419bbfe…

12 24

What are the laws for Eq1, Eq2, Ord1, and Ord2?
by David Feuer 16 Mar '18

16 Mar '18

I was looking at the Eq2 instances for Data.Map and Data.HashMap, and the Eq1 instances for Set and HashSet, and I realized that they're a bit ... weird. My instinct is to remove these instances immediately, but I figure I should first check with the community (and Oleg, who added them to begin with) to make sure they don't make some sort of sense I don't understand. In particular, these instances compare keys in the order in which they appear in the container. That order may be completely unrelated to the given key comparison function. Data.Map example: suppose I have a Map k () and a Map (Down k) (), where Down is from Data.Ord. If I call liftEq2 (\x (Down y) -> x == y) (==), I will get what looks to me like a totally meaningless result. Data.HashMap example: suppose I have a HashMap Int () and a Hashmap String (). If I call liftEq2 (\x y -> show x == y) (==), that won't return True even if the strings in the second map are actually the results of applying show to the numbers in the first map. Intuitively, I think Eq1 f only makes sense if the shape of f x does not depend on the values of type x, and Eq2 p only makes sense if the shape of p x y does not depend on the values of types x and y. Is there a way to formalize this intuition with class laws? I believe that in the case of a Functor, parametricity will guarantee that liftEq eq (f <$> xs) (g <$> ys) == liftEq (\x y -> eq (f x) (g y)) xs ys Are there *any* legitimate instances of Eq1 or Ord1 that are not Functors? Are there *any* legitimate instances of Eq2 or Ord2 that are not Bifunctors? My intuition says no. We might wish we could write instances for unboxed arrays or vectors, but I believe that is totally impossible anyway. David

3 6

Proposal: offer a way to augment call stacks
by David Feuer 15 Mar '18

15 Mar '18

HasCallStack constraints give us a pretty good view of where we came from when an error occurs, but they don't always tell us enough about what was going on there at the time. I think we should add a small feature to the call stack interface to improve matters. == Motivating example == Suppose we have f :: Int -> Int f x = g (h x) If g throws an error because its argument is bad, we'd like to know how that happened. A HasCallStack constraint on g will reveal that g was called by f. Now we'd like to dig deeper. Was f supplied a bad argument? Did h calculate a bad value from it? If f is only called a few times, it's easy to work this out: just add a trace call to f reporting x. But if f is called thousands of times, that won't work at all. == Proposed change == I'd like to add a function (of whatever name) recordInCallStack :: forall (a :: TYPE rep) HasCallStack => String -> (HasCallStack => a) -> a We could then modify the above program thus: f :: Int -> Int f x = recordInCallStack msg (g (h x)) where msg = "x = " ++ show x Now when g throws an error, we'll see the message f recorded in its proper position in the call stack. == Implementation == I believe the cleanest approach would be to add a new constructor to CallStack (perhaps called Message): Message :: String -> CallStack -> CallStack Then recordInCallStack can look like recordInCallStack :: forall (a :: TYPE rep) HasCallStack => String -> (HasCallStack => a) -> a recordInCallStack s a = let ?callStack = Message s ?callStack in a == Questions == For performance reasons, I believe recordInCallStack should be lazy in its string argument. But this means that we could encounter another error in the process of printing a call stack. How if at all should we attempt to recover in this case? If we don't do anything special, I believe we may start printing a second call stack in the middle of the first. Kind of gross. Another option is to catch all exceptions when evaluating the message. Then we could note that the message couldn't be printed but continue with the rest of the call stack. David

2 2

Re: Proposal: Add inductively-defined Nat to base
by Daniel Cartwright 15 Mar '18

15 Mar '18

I believe that at the value level, Peano Nats can be optimised using pattern synonyms. The primary interest of Peano Nats, however, is in their use at the kind level - so I think two things are possible: 1. With -XDependentHaskell, one can define a pattern synonym allowing the optimisation of Peano Nats, 2. With type families, it _might_ be possible to define a weaker form of (1), provided it is possible to put a type synonym on the LHS of a type family. Question: Can a TypeApplication be used on the LHS of an injective type family? On Wed, Mar 14, 2018 at 9:05 PM, Daniel Cartwright <chessai1996(a)gmail.com> wrote: > The proposed addition is simple, add the following to base: > > data Nat = Zero | Succ Nat, > > i.e. Peano Nats - commonly used along with -XDataKinds. > > I will list the pros/cons I see below: > > Pros: > - This datatype is commonly defined throughout many packages throughout > Hackage. It would be good for it to have a central location > - The inductive definition of 'Nat' is useful for correctness (e.g. > safeHead :: Vec a (Succ n) -> a; safeHead (Cons a as) = a;) > - -XDependentHaskell is likely to bring this into base anyway > - I believe that it might be possible to eliminate a Peano Nat at some > stage during/after typechecking. I'm not well-versed in GHC implementation, > but something along the lines of possibly converting an inductive Nat to a > GMP Integer using some sort of specialisation (Succ -> +1)? Another > interesting, related approach (and this is a very top-level view, and > perhaps not totally sensical) would be something like a function 'f', that > given a data structure and a number system, outputs the representation of > that data structure in that number system (Nat is isomorphic to List (), so > f : List () -> Binary -> BinaryListRep) > > Cons: > - -XDependentHaskell will most likely obviate any benefit brought about by > type families defined in base that directly involve Nat > - Looking at base, I'm not sure where this would go. Having it in its own > module seems a tad strange. > > I am open to criticism concerning the usefulness of the idea, or if anyone > sees a Pro(s)/Con(s) that I am missing. > >

1 0

Proposal: Remove the bogus MonadFail instance for ST
by David Feuer 14 Mar '18

14 Mar '18

I just noted that ST is an instance of MonadFail, with fail throwing an error. This seems utterly contrary to the purpose of MonadFail! Can we please remove this instance? David Feuer

3 2

Re: Proposal: Add more exports to public array modules
by Ryan Scott 13 Mar '18

13 Mar '18

Sounds good to me. Ryan S.

1 0