March 2018 - Libraries

Deprecating fromIntegral
by Niklas Hambüchen 12 Aug '20

12 Aug '20

This is not a joke. I just found a bug in base (https://ghc.haskell.org/trac/ghc/ticket/14262) import System.IO hWaitForInput stdin 4294968296 This code should wait for 49.something days, but it waits for 1 second. It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt` (where CInt = Int32), causing an overflow. I argue that `fromIntegral` causes unnoticed data corruption without any warning, and thus are worse than partial functions. In this case, this data corruption occurs in the most fundamental code that we all use and have to rely upon (`base`). So I propose that we add a deprecation pragma to `fromIntegral` (however, keeping it forever, like Java does, as there's no benefit to removing it, we just want that people use safer functions over time), and instead provide a `safeFromIntegral` that can only widen ranges, and one or more `unsafeFromIntegral` or appropriately named functions that can error, wrap, return Maybe, or have whatever desired behaviour when the input value doesn't fit into the output type. For some inspiration, `foundation` provides ideas in that direction: http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-IntegralCon… It is a bit funny how we argue that Haskell is good for high assurance programming, and we build all sorts of fancy constructs to eliminate more run-time errors, when in fact we do worse than C in detecting errors in the most basic types a computer can use, such as converting between 64-bit and 32-bit integers. Let's fix that. It avoids real problems in real production systems that are difficult to debug when they happen (who writes a unit test checking that a timeout of 50 days still works? This is the kind of stuff where you have to rely on -- very basic -- types). I'd like to probe support for such a change before doing any work on it. Niklas

18 58

Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
by Matt Renaud 05 Jan '19

05 Jan '19

*What* *====* Rename unordered-container's Data.HashMap.lookupDefault <https://hackage.haskell.org/package/unordered-containers-0.2.8.0/docs/Data-…> to findWithDefault. findWithDefault :: (Eq k, Hashable k) => v -> k -> HashMap k v -> v Note: There are no functionality changes, this is purely a rename. *Why* *===* This aligns the Data.HashMap API with containers' Data.Map.findWithDefault <https://hackage.haskell.org/package/containers-0.5.11.0/docs/Data-Map-Stric…> . Data.Map.findWithDefault :: Ord k => a -> k -> Map k a -> a The map APIs provided by the two packages are *almost* drop in replacement compatible if you aren't using any of the implementation specific functions (like ordering based functions from Data.Map), this change brings us one step closer. API consistency reduces the cognitive overhead when learning a new package. Having to learn different function names for the same functionality depending on which "map" implementation you're using is a poor developer experience. We chose the containers' name findWithDefault over unordered-containers' lookupDefault for two reasons: 1. Existing lookupX functions returns a Maybe value, while findX functions return a non-wrapped value. 2. The containers package ships with GHC and is a "core" package. *Pros:* *-----* - Consistent API between different "map" implementations (Data.Map, Data.IntMap, Data.HashMap). This makes switching implementations an import change. - Naming matches other similar functions (lookupX return Maybe-wrapped values) *Cons:* *-----* - API change requires users to update their code + unordered-containers has A LOT of users: 358815 total (13325 in the last 30 days) *How* *===* https://github.com/tibbe/unordered-containers/pull/176/commits/152f8818ee13… *Code Changes:* *-------------* - Rename the function in Data.HashMap.Base (and expose it from Strict and Lazy modules) - Make lookupDefault an INLINE alias of findWithDefault - Add DEPRECATION notice to lookupDefault - Bump unordered-containers version to 0.2.9.0 *Migration - Option 1:* *---------------------* *- *Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit thread, etc.) - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function - Code can be updated by find and replace: s/lookupDefault/findWithDefault/ - lookupDefault with deprecation notice remains for 1 year (subject to change) - after 1 year the lookupDefault function is removed, unordered-containers version bumped to 0.3.0.0 (major version bump due to breaking change) *Migration - Option 2:* *---------------------* - Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit thread, etc.) - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function - Code can be updated by find and replace: s/lookupDefault/findWithDefault/ - lookupDefault function is never removed *Discussion: * *===========* I would like to get some comments on this proposal. In particular: - Is the small API churn worth the increase in consistency? - Should migration option 1 (completely remove the old function) or 2 (keep old function indefinitely) be taken? We can punt on this and go with option 2 to start and revisit later if desired. I hope a decision about the proposal can be reached by 2018-02-09. Thanks!

6 10

Proposal: Add inductively-defined Nat to base
by Daniel Cartwright 06 Apr '18

06 Apr '18

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.

9 13

Proposal : Data.Graph performance improvements (graph creation and lookups when nodes keys are consecutive)
by Olivier S. 30 Mar '18

30 Mar '18

Hello, This is a 3-part proposal for improving the time performance of Data.Graph. The related PR for proposal I is https://github.com/haskell/containers/pull/549, including some graph benchmarks. Reading the PR may be a good introduction to this material, if you're not yet familiar with Data.Graph! I'm by advance sorry for the length of this mail, but since these are all related proposals I thought it was best to keep them together. I may be wrong, if you feel the number of issues addressed herein is too big, I can start a thread with just Proposal I for example. Note that I may or may not have time to do more work than done in the current PR, but I hope this discussion will be of use to anyone wanting to follow-up on this. That being said, I'm looking forward to hearing what the community thinks of these proposals! - Proposal I : Optimize the time complexity of (key -> Maybe Vertex) lookups and graph creation. Currently, (key -> Maybe Vertex) lookups returned by graphFromEdges consist of a binary search on an array, with a time complexity of O(log V) (I will use V for "Count of vertices", E for "Count of edges"). When key is Integral, and keys (of nodes passed to the graph creation function) form a set of /consecutive/ values, we can have an O(1) lookup by substracting the value of the smallest key, and checking for bounds. Hence, graph creation complexity is improved, and user algorithms using (key -> Maybe Vertex) lookups will see their complexity reduced by a factor of up-to O(log V). The PR introduces this lookup and uses it for functions graphFromEdgesWithConsecutiveKeys and graphFromEdgesWithConsecutiveAscKeys. Note that in this PR, graphFromEdges in unchanged, so it doesn't benefit from these improvements (see Proposal II below). Here is a summary of complexities as they stand in the current state of the PR: ------------------------------------------------------------------------------------- | | Time complexities | | Functions |--------------------------------------------- | | graph creation | (key -> Maybe Vertex) | ------------------------------------------------------------------------------------- | graphFromEdges | O( (V+E) * log V ) | O(log V) | | graphFromEdgesWithConsecutiveKeys | O( E + (V*log V) ) | O(1) | | graphFromEdgesWithConsecutiveAscKeys | O( V+E ) | O(1) | ------------------------------------------------------------------------------------- - Proposal II : Make users of graphFromEdges benefit from performance improvements "for free" when they use Integral keys that are consecutive. We could use a rewrite rule to redirect graphFromEdges (when key is Integral) to a function checking if the keys are successive or not, to decide if the optimized lookup can be used. The problem with this is that some potential optimizations would be hidden-away, consider this example: -- 'userAlgorithm' doesn't have the (Integral a) constraint userAlgorithm :: (Ord a) => ... userAlgorithm = (...) -- hence, the rewrite rule here will never fire: graphFromEdges ... userProgram :: (Integral a, Ord a) => a -> ... userProgram input = userAlgorithm input -- Eventhough input /is/ Integral (and its keys may be consecutive), -- a potential optimization is lost because 'userAlgorithm' doesn't have the (Integral a) constraint. To address this, I propose to introduce the following a breaking change : instead of using a rewrite rule, just add an (Integral key) constraint on graphFromEdges, and do the check (wether optimized lookups can be used) in graphFromEdges itself. Then, in the previously described scenario, the user would see a compilation error indicating that (Integral a) could not be deduced from the context. Hence, the user would be more likely to just add the Integral constraint on myAlgorithm (and benefit from optimizations) than to use graphFromEdgesOld, which will have been added to do exactly what graphFromEdges does today, and which is intended to be used when the key is genuinely not Integral. And for completeness, note that we could have the idea of the rewrite rule on graphFromEdgesOld, eventhough I'm not sure it will benefit any real use case (but who knows...). - Proposal III : Deprecate `graphFromEdges` taking [(node, key, [key])] in favor of `graphFromMap` taking (Map key (node,[key])) While working on the PR, I found two arguments in favor of this change: -a) Today in graphFromEdges, if we pass the same key twice, it is undefined which node for that key will actually be used. graphFromMap, taking a (Map key (node,[key]) would alleviate this issue. -b) "sortBy is expensive, even on sorted input": I became aware of this as I looked at these 2 benchmarks: benchmarking Degree_Zero/1000_ascending_graphFromConsecutiveAscKeys time 53.55 μs (52.44 μs .. 54.76 μs) 0.991 R² (0.986 R² .. 0.995 R²) mean 57.41 μs (55.02 μs .. 61.75 μs) std dev 10.64 μs (5.100 μs .. 17.09 μs) variance introduced by outliers: 95% (severely inflated) benchmarking Degree_Zero/1000_ascending_graphFromConsecutiveKeys time 75.34 μs (73.79 μs .. 76.85 μs) 0.992 R² (0.987 R² .. 0.995 R²) mean 74.67 μs (72.29 μs .. 77.47 μs) std dev 8.335 μs (6.692 μs .. 10.70 μs) variance introduced by outliers: 85% (severely inflated) In the second benchmark, we do the same work as in the first benchmark, except for an initial sortBy on an already sorted list, which introduces a 30% overhead! Looking at the implementation of sortBy, I saw that there was no initial check to see if the list was sorted or not. Since we use sortBy in graphFromEdges, we could check wether the input is sorted or not, before using sortBy. But also, if we used a Map (this is the reason I use this example here), there would be no need to sortBy because Map.toAscList gives exactly the sorted list we want. This constitutes another argument for this proposal. Note that graphFromEdgesWithConsecutiveKeys and graphFromEdgesWithConsecutiveAscKeys would also be deprecated in favor of graphFromConsecutiveMap, because they have the same a) and b) issues. Naming proposal N1: - graphFromEdges (takes a List, deprecated, existing function) - graphFromEdgesInMap (takes a Map) - graphFromEdgesInConsecutiveMap (takes a Map with consecutive keys) Naming proposal N2: - graphFromEdges (takes a List, deprecated, existing function) - graphFromMap - graphFromConsecutiveMap with these, to reflect the Map / List duality in the naming scheme: - graphFromList (takes a List, deprecated, redirects to graphFromEdges) - graphFromConsecutiveList (takes a List, deprecated, redirects to graphFromEdgesWithConsecutiveKeys) - graphFromConsecutiveAscList (takes a List, deprecated, redirects to graphFromEdgesWithConsecutiveAscKeys) -- Olivier Sohn PS : when writing the criterion graph benchmarks, I discovered that Graphs can be evaluated to normal form by criterion only when they are acyclic. Cyclic graphs will make the evaluation loop infinitely. I wonder why that is, if anyone has an explanation on that subject I'd be happy to hear it! Or should I submit a bug report at criterion?

1 0

Proposal: Add a wrapped applicative type to Data.Monoid
by Daniel Cartwright 28 Mar '18

28 Mar '18

I see this as being generally (as in, to the users of Haskell as a whole) useful: newtype Ap f a = Ap { getAp :: f a } deriving (Applicative, Eq, Foldable, Functor, Generic, Generic1 ,Monad, Ord, Read, Show, Traversable) Some hand-written instances: instance (Applicative f, Semigroup a) => Semigroup (Ap f a) where (Ap x) <> (Ap y) = Ap $ liftA2 (<>) x y instance (Applicative f, Monoid a) => Monoid (Ap f a) where mempty = Ap $ pure mempty

5 6

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