April 2015 - Libraries

Proposal: NF newtype
by Edward Z. Yang 02 May '15

02 May '15

I propose the following (abstract) data type, functions, and instance be added to deepseq (naming amenable to bikeshedding): newtype NF a = NF a -- abstract makeNF :: NFData a => a -> NF a getNF :: NF a -> a instance NFData (NF a) where rnf x = x `seq` () NF is an abstract data type representing data which has been evaluated to normal form; the guarantee specifically is, if NF is in whnf, then it is in nf. Crucially, when we have 'NF a', we ONLY need to seq it in order to assure that it is fully evaluated. This guarantee is sufficient for a variety of cases where normal data is necessary, e.g. when transmitting data over Channels. For example, from the monad-par library 'put_' could be used in place of 'put' with this type signature. put_ :: IVar (NF a) -> (NF a) -> Par () Cheers, Edward

12 25

Roles, GND, Data.Coerce
by David Terei 30 Apr '15

30 Apr '15

All, An issue that came up with GHC 7.8 was the design of Roles and Data.Coerce, with it's ability to break module abstractions by default, requiring programmers adopt explicit role annotations to enforce some types of invariants for abstract data types. Because of this issue, as of now, GND & Data.Coerce are still disabled in Safe Haskell. We'd like to change this but need feedback from everyone. I've written up a wiki page with lots of information on the issue: https://ghc.haskell.org/trac/ghc/wiki/SafeRoles Please read, it has information on how Roles work, the problem it raises and subtleties in the current system. Possible paths forward are also there, but I'll include below. Please be aware that this discussion is about Roles in general, not specifically how when using -XSafe. Ideally we'd come up with a solution that works regardless of if using Safe Haskell or not. I personally like option (3), although it isn't clear to me how hairy the implementation would be. == Possible Paths Forward for Roles == 1) Do Nothing -- Keep Roles & GND unchanged, keep them unsafe in Safe Haskell. 2) Accept as Safe -- Keep Roles & GND unchanged, accept them as safe in Safe Haskell and warn users that they neednominal role annotations on ADTs. 3) In-scope constructor restriction for lifting instances -- The newtype constructor restriction for unwrapping instances could be extended to both data types, and the lifting instances of Data.Coerce. This is, GND & Coercing under a type constructor is allowed if (a) all involved constructors are in scope, or (b) the constructors involved have been explicitly declared to allow coercion without them being in scope. I.e., (b) allows library authors to opt-into the current GHC behavior. This would require new syntax, probably just an explicit deriving Coercible statement. 4) Change default role to nominal -- This will prioritize safety over GND, and the belief is that it may break a lot of code. Worse, that it will be an ongoing tax as role annotations will be needed to enable GND. 5) Nominal default when constructors aren't exported -- When a module doesn't export all the constructors of a data type, then the type parameters of the data type should default to nominal. This heuristic seems to capture somewhat the intention of the user, but given the practice of defining an Internal module that exports everything, it seems of limited use. 6) Nominal default in future -- Add a new extension, SafeNewtypeDeriving that switches the default role to nominal, but continue to provide a deprecated GND extension to help with the transition. The claims in support of representational roles as default though believe that nominal by default has an ongoing, continuous tax, not just a transition cost. So it isn't clear that any scheme like this satisfies that argument. 7) Safe Haskell Specific -- Many of the above approaches could be adopted in a Safe Haskell specific manner. This isn't ideal as it makes safe-inference harder and Safe Haskell less likely to remain viable going forward. Richard suggests one such idea. == The belief by many people seems to be that (4) and (6) would be too much of burden. I'd like to avoid (7) if possible. It isn't clear to me if (7) ends up better than (2). I'm going to try to setup some infastructure for compiling Hackage so that we can measure how impactful these changes would be. Cheers, David

1 0

Agda 2.4.2.2. and cpphs 1.19
by Andrés Sicard-Ramírez 29 Apr '15

29 Apr '15

Hi, The current version of Agda (2.4.2.2) in Hackage doesn't install with the current version of cpphs (1.19) in Hackage due to the following restriction: build-tools: cpphs >= 1.18.6 && < 1.19 Although I'm a maintainer of Agda, using the Hackage web interface I couldn't increase the upper bound for cpphs to 1.20 because this upper bound is inside a cabal flag. Since this problem has been repeatedly reported by Agda's users, could some Hackage trustee fix the problem, please. Thanks, -- Andrés

2 2

monad-peel takeover
by Sergey Alirzaev 29 Apr '15

29 Apr '15

I'd like to take the maintenance of monad-peel as it's currently broken and Anders seems unavailable. -- () ascii ribbon campaign - against html mail /\ http://arc.pasp.de/ - against proprietary attachments

2 1

Proposal: Add exception info
by Michael Sloan 27 Apr '15

27 Apr '15

Control.Exception currently lacks a good way to supply extra information along with exceptions. For example, exceptions could be thrown along with their callstack[1] or implicit stack[2], but we have no generic way to include this information with exceptions. Proposed Solution ================= The proposed solution is to add a list of `SomeExceptionInfo` to the `SomeException` datatype. This list stores additional information about the exception. These `ExceptionInfo` instances use a mechanism which is pretty much identical to the dynamic way the `Exception` type works: data SomeException = forall e . Exception e => SomeExceptionWithInfo e [SomeExceptionInfo] data SomeExceptionInfo = forall a . ExceptionInfo a => SomeExceptionInfo a class Typeable a => ExceptionInfo a where displayExceptionInfo :: a -> String addExceptionInfo :: (ExceptionInfo a, Exception e) => a -> e -> SomeException addExceptionInfo x (toException -> SomeExceptionWithInfo e xs) = SomeExceptionWithInfo e (SomeExceptionInfo x : xs) `ExceptionInfo` lacks the to / from functions that `Exception` has, because I don't see much point in supporting a hierarchy for exception info. The `Typeable` superclass constraint supplies the necessary casting. `SomeExceptionInfo` could validly instead just use the constraint `(Typeable a, Show a)`. However, I believe it's good to have a new class for this so that: * The user can specify a custom `displayExceptionInfo` implementation, for when this extra info is presented to the user. This function would be invoked by the `show` implementation for `SomeException`. * Types need to opt-in to be usable with `SomeExceptionInfo`. Similarly to exceptions, I imagine that a type with a `ExceptionInfo` instance won't be used for anything but acting as such an annotation. Having a class for this allows you to ask GHCI about all in-scope exception info types via `:info ExceptionInfo`. Backwards Compatibility ======================= GHC 7.10 adds support for bidirectional pattern synonyms. This means that this change could be made without breaking code: pattern SomeException x <- SomeExceptionWithInfo x _ where SomeException x = SomeExceptionWithInfo x [] Note that consumers of this do not need to enable `-XPatternSynonyms`. Applications ============ Callstacks ---------- As mentioned at the beginning, this can be used to add callstacks to exceptions: newtype ExceptionCallStack = ExceptionCallStack { unExceptionCallStack :: [String] } deriving Typeable instance ExceptionInfo ExceptionCallStack where displayExceptionInfo = unlines . unExceptionCallStack throwIOWithStack :: Exception e => e -> IO a throwIOWithStack e = do stack <- currentCallStack if null stack then throwIO e else throwIO (addExceptionInfo (ExceptionCallStack stack) e) I see little downside for making something like this the default implementation `throwIO`. Each rethrowing of the `SomeException` would add an additional stacktrace to its annotation, much like the output of `+RTS -xc`. Unlike this debug output, though, the stacktraces would be associated with the exception, rather than just listing locations that exceptions were thrown. This makes it tractable to debug exceptions that occur in concurrent programs, or in programs which frequently throw exceptions during normal functioning. Throwing Exceptions in Handlers ------------------------------- Example: main = throwIO InformativeErrorMessage `finally` throwIO ObscureCleanupIssue While `InformativeErrorMessage` got thrown, the user doesn't see it, since `ObscureCleanupIssue` is thrown instead. This causes a few issues: 1. If the exception is handled by the default handler and yielded to the user, then the more informative error is lost. 2. Callers who expect to catch the "Informative error message" won't run their handlers for this exception type. Problem 1 can now easily be resolved by adding some info to the exception: data ExceptionCause = ExceptionCause { unExceptionCause :: SomeException } deriving Typeable instance ExceptionInfo ExceptionCause where displayExceptionInfo fe = "thrown while handling " ++ displayException (unExceptionCause fe) catch :: Exception e => IO a -> (e -> IO a) -> IO a catch f g = f `oldCatch` handler where handler ex = g ex `oldCatch` \(ex' :: SomeException) -> throwIO (addExceptionInfo info ex') where info = ExceptionCause (toException ex) This implementation of `catch` is written in a backwards-compatible way, such that the exception thrown during finalization is still the one that gets rethrown. The "original" exception is recorded in the added info. This is the same approach used by Python 3's `__context__` attribute[3]. This was brought to my attention in a post by Mike Meyer[4], in a thread about having bracket not suppress the original exception[5]. This doesn't directly resolve issue #2, due to this backwards compatibility. With the earlier example, a `catch` handler for `InformativeErrorMessage` won't be invoked, because it isn't the exception being rethrown. This can be resolved by having a variant of catch which instead throws the original exception. This might be a good default for finalization handlers like `bracket` and `finally`. Asynchronous Exceptions ----------------------- Currently, the only reliable way to catch exceptions, ignoring async exceptions, is to fork a new thread. This is the approach used by the enclosed-exceptions[6] package. I think it's quite ugly that we need to go to such lengths due to the lack of one bit of information about the exception! This would resolve ghc trac #5902[7]. base-4.7 added the `SomeAsyncException` type, but this doesn't enforce anything. Any exception can be thrown as a sync or async exception. Instead, we ought to have a reliable way to know if an exception is synchronous or asynchronous. Here's what this would look like: data IsAsync = IsAsync deriving (Typeable, Show) instance ExceptionInfo IsAsync where displayExceptionInfo IsAsync = "thrown asynchronously" throwTo :: Exception e => ThreadId -> e -> IO () throwTo tid = oldThrowTo tid . addExceptionInfo IsAsync The details of this get a bit tricky: What happens if `throwIO` is used to rethrow a `SomeException` which has this `IsAsync` flag set? I'm going to leave out my thoughts on this for now as the interactions between unsafePerformIO and the concept of "rethrowing" async exceptions. Such details are explained in a post by Edsko de Vries[8] and ghc trac #2558[9]. Issue: fromException loses info =============================== I can think of one main non-ideal aspect of this proposal: Currently, the `toException` and `fromException` methods usually form a prism. In other words, when `fromException` yields a `Just`, you should get the same `SomeException` when using `toException` on that value. For example, fail "testing 1 2 3" `catch` \(ex :: SomeException) -> throwIO ex is equivalent to fail "testing 3 4 5" `catch` \(ex :: IOError) -> throwIO ex However, with exception info added to just `SomeException`, and no changes to existing `Exception` instances, this doesn't hold. Exceptions caught as a specific exception type get rethrown with less information. One resolution to this is be to add `[SomeExceptionInfo]` as a field to existing `Exception` instances. This would require the use of non-default implementations of the `toException` and `fromException` instances. Another approach is to have variants of `catch` and `throw` which also pass around the `[SomeExceptionInfo]`. [1] https://hackage.haskell.org/package/base-4.8.0.0/docs/GHC-Stack.html#curren… [2] https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations [3] https://www.python.org/dev/peps/pep-3134/ [4] https://mail.haskell.org/pipermail/haskell-cafe/2014-July/114987.html [5] https://mail.haskell.org/pipermail/haskell-cafe/2014-July/114986.html [6] https://hackage.haskell.org/package/enclosed-exceptions [7] https://ghc.haskell.org/trac/ghc/ticket/5902 [8] http://www.edsko.net/2013/06/11/throwTo/ [9] https://ghc.haskell.org/trac/ghc/ticket/2558

13 39

Maintainship of edit-distance and lattices
by Oleg Grenrus 27 Apr '15

27 Apr '15

Hi, I’d like to help with maintaining of mentioned packages: - http://hackage.haskell.org/package/edit-distance <http://hackage.haskell.org/package/edit-distance> - http://hackage.haskell.org/package/lattices <http://hackage.haskell.org/package/lattices> Max doesn’t seem to be active on GitHub, there are - a PR to edit-distance fixing the build on GHC 7.10, open for 26 days: https://github.com/batterseapower/edit-distance/pull/3 <https://github.com/batterseapower/edit-distance/pull/3> - a PR to lattices opened at Jan 8 2015 (open for over 3 months already) https://github.com/batterseapower/lattices/pull/3 <https://github.com/batterseapower/lattices/pull/3> I could take over the maintainership of the packages, if Max doesn’t respond in two weeks - Oleg Grenrus

5 6

Exceptions with Context Re: Proposal: Add exception info
by Carter Schonwald 27 Apr '15

27 Apr '15

hrm, i like this proposal more, and it seems like with some fleshing out it can be strictly more extensible yet backwards compatible than michael's I'll need to mull it a bit more before I cast my vote, but this seems to sketch out a design that provides the same information, but in a more extensible/backwards compatible fashion (at least in a first cut of thinking about it) (i'm splitting this into a new thread so the discussions dont get mixed up) On Tue, Apr 21, 2015 at 9:40 PM, davean <davean(a)xkcd.com> wrote: > So, I've had a number of issues with exceptions. This has been one of > them. I don't really like this proposal as it stands though as it seems to > make catch a specific exception with said extra info more difficult. > > This is data Control.Exception can move around on its own though, right? > The problem really isn't passing it internal, we could just make a (Stack, > SomeException) tuple just fine, in theory I think (I'll admit I've not > actually reviewed the code, and this isn't meant as a complete proposal but > more a thought experiment). The problem is code handling the data and > working with old code while not losing any of the power of the current > system. > > So we start with: catch :: Exception e => IO a -> (e -> IO a) -> IO a > > Now this proposal allows: catch :: IO a -> (SomeException -> IO a) -> IO a > If we want access to the new information, but that's not really > satisfactory. > > Real code regularly wants to (picking an arbitrary instance of Exception) > do: catch :: IO a -> (IOError -> IO a) -> IO a > only we still want new data. > > Now one could do something like: catch :: IO a -> (Stack -> IOError -> IO > a) -> IO a > but that is not very upgradable and it breaks existing code. > > But this is just a matter of requesting information, so one could do > something like: catch :: IO a -> (WithStack IOError -> IO a) -> IO a > where: data WithStack e = WithStack Stack e > Or maybe one just addes: catchWithContext :: Exception e => IO a -> > (Context -> e -> IO a) -> IO a > Or: catchWithContext :: Exception => IO a -> (Context e -> IO a) -> IO a > > Now existing code continues to run and we can feed our exception handlers > the data they want, even when we want some specific exception instead of > just any exception. > > Now that still leave a hole in what I want out of exceptions. We're still > short of programmatic interrogating them, or even telling what the > exception was if we didn't expect it! > > Consider AssertionFailed > <https://hackage.haskell.org/package/base-4.8.0.0/docs/src/GHC-IO-Exception.…>. > Its show instance is "showsPrec _ (AssertionFailed err) = showString err", > so if we print out the SomeException, we get whatever string is in > AssertionFailed. Which is great if that string makes sense. But you see > that on your console and its a bit baffling if it doesn't. It could even be > a lie, I can make that say something that looks like its a different > exception. We can use the Typeable instance so the program can tell them > apart at least though. Which works as long as the exception is > single-constructor, or has a well-behaved show instance. What if we come > across a monstrosity like > http://hackage.haskell.org/package/http-conduit-2.1.5/docs/Network-HTTP-Con… > and it doesn't have a nice show instance that says which on it is? If > Exception added a Data constraint we could actually pull apart these > exceptions and start to make proper sense of them reliably. > > Once you have that there are quite a few useful things you can do with the > exceptions you didn't expect. Currently you could only do them by > enumerating every possible exception which of course doesn't work for the > unexpected. > > On Tue, Apr 21, 2015 at 6:24 PM, Michael Sloan <mgsloan(a)gmail.com> wrote: > >> No, this proposal is not specifically about stack traces, that is just >> one of the usecases. Instead, this is about a general mechanism for >> including extra information with exceptions. The core of this proposal is >> still relevant even if the behavior of error / throw / throwTo / etc remain >> unchanged. >> >> I'm not familiar with how the new dwarf stuff will interact with throwing >> / displaying exceptions. It seems like this would require having the >> debugger break at the throw site, and exceptions would still lack stack >> traces. Having informative stack traces is quite orthogonal to having a >> good place to store them. >> >> Note that in my original proposal text I mentioned that this is agnostic >> of the particular source of the stack trace. In particular, this could be >> used with a profiling stack trace, implicit callstack, or, indeed, these >> traces via dwarf. >> >> -Michael >> >> On Tue, Apr 21, 2015 at 3:06 PM, Carter Schonwald < >> carter.schonwald(a)gmail.com> wrote: >> >>> On a more important note: assuming ghc 7.12 has support for informative >>> stack traces via dwarf by default, wouldn't that eliminate the need for >>> this proposal? Namely : there perhaps should be some reasonable way to talk >>> about concatting stack traces perhaps? >>> >>> Phrased differently: how is the info that should perhaps be in >>> informative stack traces not subsuming the info of this proposal? >>> >>> >>> On Tuesday, April 21, 2015, Michael Sloan <mgsloan(a)gmail.com> wrote: >>> >>>> Ah, but it looks like Niklas does have a patch which adds implicit >>>> locations to such functions: https://phabricator.haskell.org/D861 >>>> >>>> However, there are some issues with changing the API of these >>>> functions: https://phabricator.haskell.org/D861#23250 >>>> >>>> (as mentioned in the "Backporting srcLoc to the GHC 7.10 branch" thread) >>>> >>>> On Tue, Apr 21, 2015 at 2:04 PM, Michael Sloan <mgsloan(a)gmail.com> >>>> wrote: >>>> >>>>> Hmm, that patch doesn't appear to add stack traces to 'Prelude.error', >>>>> which is what Carter wants here. Also, I think it would be done with >>>>> profiling callstacks rather than implicit callstacks. But it's certainly >>>>> also useful to have functions which do the same with implicit callstacks! >>>>> >>>>> >>>>> On Tue, Apr 21, 2015 at 1:55 PM, Evan Laforge <qdunkan(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Maybe I'm missing something, but isn't this already implemented? >>>>>> >>>>>> https://phabricator.haskell.org/D578 >>>>>> >>>>>> On Tue, Apr 21, 2015 at 1:37 PM, Michael Sloan <mgsloan(a)gmail.com> >>>>>> wrote: >>>>>> > On Thu, Apr 16, 2015 at 8:08 PM, Carter Schonwald >>>>>> > <carter.schonwald(a)gmail.com> wrote: >>>>>> >> >>>>>> >> if you can patch prelude error to include stack traces, i will owe >>>>>> you a >>>>>> >> >=1 beer each at the next two icfps. Thats all i want for >>>>>> christmas. :) >>>>>> > >>>>>> > >>>>>> > Sounds good! No promises, but I'll be giving this a try soon. >>>>>> Looking >>>>>> > forward to ICFP beers either way :D >>>>>> > >>>>>> >> i can't speak for how a different patch might work out, because >>>>>> thats not >>>>>> >> what I'd tried at the time. If you have a go, please share the >>>>>> results! >>>>>> >> -Carter >>>>>> >> >>>>>> >> On Wed, Apr 15, 2015 at 12:22 AM, Michael Sloan <mgsloan(a)gmail.com> >>>>>> wrote: >>>>>> >>> >>>>>> >>> Hi Carter! >>>>>> >>> >>>>>> >>> Interesting! This thread, right? >>>>>> >>> >>>>>> https://mail.haskell.org/pipermail/libraries/2014-December/024429.html >>>>>> >>> >>>>>> >>> I haven't tried this as a patch to base, but I'm certain that the >>>>>> core of >>>>>> >>> the proposal has no extra dependencies. Note that the proposal >>>>>> isn't about >>>>>> >>> stack traces in particular - that's just one application of being >>>>>> able to >>>>>> >>> throw exceptions with extra information. >>>>>> >>> >>>>>> >>> Even if `throwTo` isn't modified to throw exceptions with stack >>>>>> traces, >>>>>> >>> this functionality could be provided outside of >>>>>> `Control.Exception` (though, >>>>>> >>> that does seem like the right place to put it). I'm surprised >>>>>> that the >>>>>> >>> circularity was so problematic, though. Why isn't it sufficient >>>>>> to have an >>>>>> >>> hs-boot file for `GHC.Stack`, which exports `currentCallStack`? >>>>>> >>> >>>>>> >>> -Michael >>>>>> >>> >>>>>> >>> On Tue, Apr 14, 2015 at 7:55 PM, Carter Schonwald >>>>>> >>> <carter.schonwald(a)gmail.com> wrote: >>>>>> >>>> >>>>>> >>>> Hey Michael, >>>>>> >>>> I actually proposed something along these lines that got OK'd by >>>>>> >>>> libraries early this past fall, the main challenge we hit was >>>>>> actually doing >>>>>> >>>> the enginering to add the stack traces to exceptions! theres >>>>>> some nasty >>>>>> >>>> module cycles in base that happen when you try to weave things >>>>>> around so >>>>>> >>>> that the standard error "message here" call includes some stack >>>>>> trace info. >>>>>> >>>> Have you tried to do that simple starter patch to base? >>>>>> >>>> >>>>>> >>>> Chris Allen and I spent like 2 days trying to get it to work and >>>>>> just >>>>>> >>>> gave up because of the cycles. We (and others) would probably >>>>>> love some >>>>>> >>>> headway on that front. >>>>>> >>>> >>>>>> >>>> Theres also some in progress work to use the dwarf debugging >>>>>> info data >>>>>> >>>> in >7.10 to provide useful stack traces in the default builds >>>>>> for GHC afaik, >>>>>> >>>> 'cause the stack trace functionality you're pointing at >>>>>> currenlty only work >>>>>> >>>> on profiled builds >>>>>> >>>> >>>>>> >>>> cheers >>>>>> >>>> -Carter >>>>>> >>>> >>>>>> >>>> On Tue, Apr 14, 2015 at 2:38 PM, Michael Sloan < >>>>>> mgsloan(a)gmail.com> >>>>>> >>>> wrote: >>>>>> >>>>> >>>>>> >>>>> Control.Exception currently lacks a good way to supply extra >>>>>> >>>>> information along with exceptions. For example, exceptions >>>>>> could be >>>>>> >>>>> thrown along with their callstack[1] or implicit stack[2], but >>>>>> we have >>>>>> >>>>> no generic way to include this information with exceptions. >>>>>> >>>>> >>>>>> >>>>> Proposed Solution >>>>>> >>>>> ================= >>>>>> >>>>> >>>>>> >>>>> The proposed solution is to add a list of `SomeExceptionInfo` >>>>>> to the >>>>>> >>>>> `SomeException` datatype. This list stores additional >>>>>> information >>>>>> >>>>> about the exception. These `ExceptionInfo` instances use a >>>>>> mechanism >>>>>> >>>>> which is pretty much identical to the dynamic way the >>>>>> `Exception` type >>>>>> >>>>> works: >>>>>> >>>>> >>>>>> >>>>> data SomeException = forall e . Exception e => >>>>>> >>>>> SomeExceptionWithInfo e [SomeExceptionInfo] >>>>>> >>>>> >>>>>> >>>>> data SomeExceptionInfo = forall a . ExceptionInfo a => >>>>>> >>>>> SomeExceptionInfo a >>>>>> >>>>> >>>>>> >>>>> class Typeable a => ExceptionInfo a where >>>>>> >>>>> displayExceptionInfo :: a -> String >>>>>> >>>>> >>>>>> >>>>> addExceptionInfo >>>>>> >>>>> :: (ExceptionInfo a, Exception e) >>>>>> >>>>> => a -> e -> SomeException >>>>>> >>>>> addExceptionInfo x (toException -> SomeExceptionWithInfo e >>>>>> xs) = >>>>>> >>>>> SomeExceptionWithInfo e (SomeExceptionInfo x : xs) >>>>>> >>>>> >>>>>> >>>>> `ExceptionInfo` lacks the to / from functions that `Exception` >>>>>> has, >>>>>> >>>>> because I don't see much point in supporting a hierarchy for >>>>>> exception >>>>>> >>>>> info. The `Typeable` superclass constraint supplies the >>>>>> necessary >>>>>> >>>>> casting. >>>>>> >>>>> >>>>>> >>>>> `SomeExceptionInfo` could validly instead just use the >>>>>> constraint >>>>>> >>>>> `(Typeable a, Show a)`. However, I believe it's good to have a >>>>>> new >>>>>> >>>>> class for this so that: >>>>>> >>>>> >>>>>> >>>>> * The user can specify a custom `displayExceptionInfo` >>>>>> >>>>> implementation, for when this extra info is presented to the >>>>>> user. >>>>>> >>>>> This function would be invoked by the `show` implementation >>>>>> for >>>>>> >>>>> `SomeException`. >>>>>> >>>>> >>>>>> >>>>> * Types need to opt-in to be usable with `SomeExceptionInfo`. >>>>>> >>>>> Similarly to exceptions, I imagine that a type with a >>>>>> >>>>> `ExceptionInfo` instance won't be used for anything but >>>>>> acting as >>>>>> >>>>> such an annotation. Having a class for this allows you to >>>>>> ask GHCI >>>>>> >>>>> about all in-scope exception info types via `:info >>>>>> ExceptionInfo`. >>>>>> >>>>> >>>>>> >>>>> Backwards Compatibility >>>>>> >>>>> ======================= >>>>>> >>>>> >>>>>> >>>>> GHC 7.10 adds support for bidirectional pattern synonyms. This >>>>>> means >>>>>> >>>>> that this change could be made without breaking code: >>>>>> >>>>> >>>>>> >>>>> pattern SomeException x <- SomeExceptionWithInfo x _ where >>>>>> >>>>> SomeException x = SomeExceptionWithInfo x [] >>>>>> >>>>> >>>>>> >>>>> Note that consumers of this do not need to enable >>>>>> `-XPatternSynonyms`. >>>>>> >>>>> >>>>>> >>>>> Applications >>>>>> >>>>> ============ >>>>>> >>>>> >>>>>> >>>>> Callstacks >>>>>> >>>>> ---------- >>>>>> >>>>> >>>>>> >>>>> As mentioned at the beginning, this can be used to add >>>>>> callstacks to >>>>>> >>>>> exceptions: >>>>>> >>>>> >>>>>> >>>>> newtype ExceptionCallStack = >>>>>> >>>>> ExceptionCallStack { unExceptionCallStack :: [String] } >>>>>> >>>>> deriving Typeable >>>>>> >>>>> >>>>>> >>>>> instance ExceptionInfo ExceptionCallStack where >>>>>> >>>>> displayExceptionInfo = unlines . unExceptionCallStack >>>>>> >>>>> >>>>>> >>>>> throwIOWithStack :: Exception e => e -> IO a >>>>>> >>>>> throwIOWithStack e = do >>>>>> >>>>> stack <- currentCallStack >>>>>> >>>>> if null stack >>>>>> >>>>> then throwIO e >>>>>> >>>>> else throwIO (addExceptionInfo (ExceptionCallStack >>>>>> stack) >>>>>> >>>>> e) >>>>>> >>>>> >>>>>> >>>>> I see little downside for making something like this the default >>>>>> >>>>> implementation `throwIO`. Each rethrowing of the >>>>>> `SomeException` >>>>>> >>>>> would add an additional stacktrace to its annotation, much like >>>>>> the >>>>>> >>>>> output of `+RTS -xc`. Unlike this debug output, though, the >>>>>> >>>>> stacktraces would be associated with the exception, rather than >>>>>> just >>>>>> >>>>> listing locations that exceptions were thrown. This makes it >>>>>> >>>>> tractable to debug exceptions that occur in concurrent >>>>>> programs, or in >>>>>> >>>>> programs which frequently throw exceptions during normal >>>>>> functioning. >>>>>> >>>>> >>>>>> >>>>> Throwing Exceptions in Handlers >>>>>> >>>>> ------------------------------- >>>>>> >>>>> >>>>>> >>>>> Example: >>>>>> >>>>> >>>>>> >>>>> main = >>>>>> >>>>> throwIO InformativeErrorMessage `finally` >>>>>> >>>>> throwIO ObscureCleanupIssue >>>>>> >>>>> >>>>>> >>>>> While `InformativeErrorMessage` got thrown, the user doesn't >>>>>> see it, >>>>>> >>>>> since `ObscureCleanupIssue` is thrown instead. This causes a >>>>>> few >>>>>> >>>>> issues: >>>>>> >>>>> >>>>>> >>>>> 1. If the exception is handled by the default handler and >>>>>> yielded to >>>>>> >>>>> the user, then the more informative error is lost. >>>>>> >>>>> >>>>>> >>>>> 2. Callers who expect to catch the "Informative error message" >>>>>> won't >>>>>> >>>>> run their handlers for this exception type. >>>>>> >>>>> >>>>>> >>>>> Problem 1 can now easily be resolved by adding some info to the >>>>>> >>>>> exception: >>>>>> >>>>> >>>>>> >>>>> data ExceptionCause = ExceptionCause >>>>>> >>>>> { unExceptionCause :: SomeException } >>>>>> >>>>> deriving Typeable >>>>>> >>>>> >>>>>> >>>>> instance ExceptionInfo ExceptionCause where >>>>>> >>>>> displayExceptionInfo fe = >>>>>> >>>>> "thrown while handling " ++ >>>>>> >>>>> displayException (unExceptionCause fe) >>>>>> >>>>> >>>>>> >>>>> catch :: Exception e => IO a -> (e -> IO a) -> IO a >>>>>> >>>>> catch f g = f `oldCatch` handler >>>>>> >>>>> where >>>>>> >>>>> handler ex = g ex `oldCatch` \(ex' :: SomeException) -> >>>>>> >>>>> throwIO (addExceptionInfo info ex') >>>>>> >>>>> where >>>>>> >>>>> info = ExceptionCause (toException ex) >>>>>> >>>>> >>>>>> >>>>> This implementation of `catch` is written in a >>>>>> backwards-compatible >>>>>> >>>>> way, such that the exception thrown during finalization is >>>>>> still the >>>>>> >>>>> one that gets rethrown. The "original" exception is recorded >>>>>> in the >>>>>> >>>>> added info. This is the same approach used by Python 3's >>>>>> >>>>> `__context__` attribute[3]. This was brought to my attention >>>>>> in a >>>>>> >>>>> post by Mike Meyer[4], in a thread about having bracket not >>>>>> suppress >>>>>> >>>>> the original exception[5]. >>>>>> >>>>> >>>>>> >>>>> This doesn't directly resolve issue #2, due to this backwards >>>>>> >>>>> compatibility. With the earlier example, a `catch` handler for >>>>>> >>>>> `InformativeErrorMessage` won't be invoked, because it isn't the >>>>>> >>>>> exception being rethrown. This can be resolved by having a >>>>>> variant of >>>>>> >>>>> catch which instead throws the original exception. This might >>>>>> be a >>>>>> >>>>> good default for finalization handlers like `bracket` and >>>>>> `finally`. >>>>>> >>>>> >>>>>> >>>>> Asynchronous Exceptions >>>>>> >>>>> ----------------------- >>>>>> >>>>> >>>>>> >>>>> Currently, the only reliable way to catch exceptions, ignoring >>>>>> async >>>>>> >>>>> exceptions, is to fork a new thread. This is the approach used >>>>>> by the >>>>>> >>>>> enclosed-exceptions[6] package. I think it's quite ugly that >>>>>> we need >>>>>> >>>>> to go to such lengths due to the lack of one bit of information >>>>>> about >>>>>> >>>>> the exception! This would resolve ghc trac #5902[7]. >>>>>> >>>>> >>>>>> >>>>> base-4.7 added the `SomeAsyncException` type, but this doesn't >>>>>> enforce >>>>>> >>>>> anything. Any exception can be thrown as a sync or async >>>>>> exception. >>>>>> >>>>> Instead, we ought to have a reliable way to know if an >>>>>> exception is >>>>>> >>>>> synchronous or asynchronous. Here's what this would look like: >>>>>> >>>>> >>>>>> >>>>> data IsAsync = IsAsync >>>>>> >>>>> deriving (Typeable, Show) >>>>>> >>>>> >>>>>> >>>>> instance ExceptionInfo IsAsync where >>>>>> >>>>> displayExceptionInfo IsAsync = "thrown asynchronously" >>>>>> >>>>> >>>>>> >>>>> throwTo :: Exception e => ThreadId -> e -> IO () >>>>>> >>>>> throwTo tid = oldThrowTo tid . addExceptionInfo IsAsync >>>>>> >>>>> >>>>>> >>>>> The details of this get a bit tricky: What happens if `throwIO` >>>>>> is >>>>>> >>>>> used to rethrow a `SomeException` which has this `IsAsync` flag >>>>>> set? >>>>>> >>>>> I'm going to leave out my thoughts on this for now as the >>>>>> interactions >>>>>> >>>>> between unsafePerformIO and the concept of "rethrowing" async >>>>>> >>>>> exceptions. Such details are explained in a post by Edsko de >>>>>> Vries[8] >>>>>> >>>>> and ghc trac #2558[9]. >>>>>> >>>>> >>>>>> >>>>> Issue: fromException loses info >>>>>> >>>>> =============================== >>>>>> >>>>> >>>>>> >>>>> I can think of one main non-ideal aspect of this proposal: >>>>>> >>>>> >>>>>> >>>>> Currently, the `toException` and `fromException` methods >>>>>> usually form >>>>>> >>>>> a prism. In other words, when `fromException` yields a `Just`, >>>>>> you >>>>>> >>>>> should get the same `SomeException` when using `toException` on >>>>>> that >>>>>> >>>>> value. >>>>>> >>>>> >>>>>> >>>>> For example, >>>>>> >>>>> >>>>>> >>>>> fail "testing 1 2 3" `catch` \(ex :: SomeException) -> >>>>>> throwIO ex >>>>>> >>>>> >>>>>> >>>>> is equivalent to >>>>>> >>>>> >>>>>> >>>>> fail "testing 3 4 5" `catch` \(ex :: IOError) -> throwIO ex >>>>>> >>>>> >>>>>> >>>>> However, with exception info added to just `SomeException`, and >>>>>> no >>>>>> >>>>> changes to existing `Exception` instances, this >>>>>> >>>>> doesn't hold. Exceptions caught as a specific exception type >>>>>> get >>>>>> >>>>> rethrown with less information. >>>>>> >>>>> >>>>>> >>>>> One resolution to this is be to add `[SomeExceptionInfo]` as a >>>>>> field >>>>>> >>>>> to existing `Exception` instances. This would require the use >>>>>> of >>>>>> >>>>> non-default implementations of the `toException` and >>>>>> `fromException` >>>>>> >>>>> instances. >>>>>> >>>>> >>>>>> >>>>> Another approach is to have variants of `catch` and `throw` >>>>>> which also >>>>>> >>>>> pass around the `[SomeExceptionInfo]`. >>>>>> >>>>> >>>>>> >>>>> [1] >>>>>> >>>>> >>>>>> https://hackage.haskell.org/package/base-4.8.0.0/docs/GHC-Stack.html#curren… >>>>>> >>>>> [2] >>>>>> >>>>> >>>>>> https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations >>>>>> >>>>> [3] https://www.python.org/dev/peps/pep-3134/ >>>>>> >>>>> [4] >>>>>> >>>>> >>>>>> https://mail.haskell.org/pipermail/haskell-cafe/2014-July/114987.html >>>>>> >>>>> [5] >>>>>> >>>>> >>>>>> https://mail.haskell.org/pipermail/haskell-cafe/2014-July/114986.html >>>>>> >>>>> [6] https://hackage.haskell.org/package/enclosed-exceptions >>>>>> >>>>> [7] https://ghc.haskell.org/trac/ghc/ticket/5902 >>>>>> >>>>> [8] http://www.edsko.net/2013/06/11/throwTo/ >>>>>> >>>>> [9] https://ghc.haskell.org/trac/ghc/ticket/2558 >>>>>> >>>>> >>>>>> >>>>> _______________________________________________ >>>>>> >>>>> 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 >> >> >

3 6

Re: [Haskell-cafe] Class-like features for explicit arguments
by Carter Schonwald 25 Apr '15

25 Apr '15

Isn't your associated type here more like a dependent record field/ existential that we can kinda expose? This does seem to veer into first class module territory. Especially wrt needing first class types in a fashion. Have you had a chance to peruse the Andreas Rossberg 1ml paper on embedding first class modules into f omega that has been circulating? Perhaps there are ideas There that could be adapted. Especially since core is an augmented f omega On Saturday, April 25, 2015, Ertugrul Söylemez <ertesx(a)gmx.de> wrote: > >>> hrm, wouldn't your proposed extension be largely accomplished by > >>> using Record pun and Record WildCards? > >> > >> A part of it would, but it wouldn't preserve operators. For example > >> instead of `x r.<> y` you would have to write `(<>) r x y`. > > > > Not at all. > > > > three :: Integer > > three = > > let Monoid{..} = sum in > > 1 <> 2 > > Puns become tedious and error-prone as soon as you need to refer to > multiple records, when operators are involved. But it's not that > important actually. I can live with the current record syntax. > > The most useful features would be defaults, a more suitable syntax for > defining record types and potentially the following: > > > >> Other class features are not accessible, most notably type-level > >> features like associated types. > > > > Associated types become additional type variables of the record type. > > Indeed. However, when the type follows from other type arguments, it > would often be convenient not to spell it out and instead bring an > associated type constructor into scope. This is especially true when > the AT refers to a type that isn't used very often. > > record Extractor a where > type Elem a > extract :: a -> Maybe (Elem a, a) > > extractTwo > :: (e1 : Extractor a) > -> (e2 : Extractor a) > -> a > -> Maybe (e1.Elem a, e2.Elem a, a) > extractTwo e1 e2 xs0 = do > (x1, xs1) <- e1.extract xs0 > (x2, xs2) <- e1.extract xs1 > return (x1, x2, xs2) > > > > But the functional dependency is not enforceable on the value level > > (isn't the whole point of this discussion not to restrict what > > "instances" can be defined), so you end up with > > > > class C a t, > > > > a simple MPTC. > > I don't see a reason to enforce a dependency, since there is no > equivalent to instance resolution. Regular unification should cover any > ambiguities, and if it doesn't you need ScopedTypeVariables. > > > >> The idea is that a record would be completely equivalent to a class > >> with the only difference being that you define values instead of > >> instances, that there are no constraints on which values can exist > >> and that those values must be passed explicitly to functions as > >> regular arguments. > > > > Except we already have regular records (aka data types) which satisfy > > 90% of the requirements, and adding another language construct to > > satisfy those remaining 10% feels wrong to me. I'd rather improve the > > existing construct. > > That's actually what I'm proposing. The record syntax would simply be > syntactic sugar for single-constructor data types that is more suitable > for records, especially when defaults and other class-like features are > involved. Most notably it would support layout. There is no reason why > you shouldn't be able to use `data` to achieve the same thing, except > with a clumsier syntax and the option to have multiple constructors. > > > Greets, > Ertugrul >

1 0

Re: [Haskell-cafe] Class-like features for explicit arguments
by Roman Cheplyaka 25 Apr '15

25 Apr '15

On 25/04/15 15:51, Ertugrul Söylemez wrote: >> hrm, wouldn't your proposed extension be largely accomplished by using >> Record pun and Record WildCards? > > A part of it would, but it wouldn't preserve operators. For example > instead of `x r.<> y` you would have to write `(<>) r x y`. Not at all. {-# LANGUAGE RecordWildCards #-} import Prelude hiding (sum) data Monoid a = Monoid { empty :: a, (<>) :: a -> a -> a } sum :: Num a => Monoid a sum = Monoid 0 (+) three :: Integer three = let Monoid{..} = sum in 1 <> 2 > Other class features are not accessible, > most notably type-level features like associated types. Associated types become additional type variables of the record type. A class class C a where type T a is essentially equivalent to class C a t | a -> t But the functional dependency is not enforceable on the value level (isn't the whole point of this discussion not to restrict what "instances" can be defined), so you end up with class C a t, a simple MPTC. > Also defaults are not available. Now this is a good point. > The idea is that a record would be completely equivalent to a class with > the only difference being that you define values instead of instances, > that there are no constraints on which values can exist and that those > values must be passed explicitly to functions as regular arguments. Except we already have regular records (aka data types) which satisfy 90% of the requirements, and adding another language construct to satisfy those remaining 10% feels wrong to me. I'd rather improve the existing construct. Roman

1 0

Re: [Haskell-cafe] Class-like features for explicit arguments (was: Ord for partially ordered sets)
by Carter Schonwald 25 Apr '15

25 Apr '15

hrm, wouldn't your proposed extension be largely accomplished by using Record pun and Record WildCards? eg {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE RecordPuns #-} module Foo where data Relation a = Rel{related :: a -> a ->Bool,unrelated :: a -> a -> Bool} foo :: Relation A -> A -> A -> Bool foo Rel{..} x y = related x y ------ or am i over looking something? I do realize this may not quite be what youre suggesting, and if so, could you help me understand better? :) On Fri, Apr 24, 2015 at 4:26 PM, Ertugrul Söylemez <ertesx(a)gmx.de> wrote: > > 3. NonStrictPoSet, which is the class of all partially ordered > > set-like things, but without the requirement that a <= b and b <= a > > implies a Equal b. > > Those are preorders. An antisymmetric preorder is a non-strict poset. > > Also it's difficult to capture all of those various order types in > Haskell's class system. A type can have many orders and many underlying > equivalence relations in the case of partial and total orders, and there > are different ways to combine them. For example equality is a partial > order, modular equivalence is a preorder, etc. Those denote bags and > groups more than sequences or trees. > > Perhaps it's time to add a type class-like system to Haskell, but for > explicitly passed arguments: > > record Relation a where > related :: a -> a -> Bool > > unrelated :: a -> a -> Bool > unrelated x y = not (related x y) > > func1 :: Relation A -> A -> A -> A > func1 _ x y = ... related x y ... > > func2 :: Relation A -> Relation A -> A -> A -> A > func2 r1 r2 x y = ... r1.related x y ... r2.unrelated x y ... > > In a lot of cases this is much more appropriate than a type class, and > it would turn many things that are currently types into regular > functions, thus making them a lot more composable: > > down :: Ord a -> Ord a > down o = > Ord { compare x y = o.compare y x } > -- The remaining Ord functions are defaulted. > > Perhaps all we need is to generalise default definitions to data types > and add module-like dot syntax for records (mainly to preserve infix > operators). Formally speaking there is also little that prevents us > From having associated types in those records that can be used on the > type level. > > For actual record types (i.e. single-constructor types) we could even > have specialisation and get a nice performance boost that way, if we ask > for it: > > {-# SPECIALISE down someOrder :: Ord SomeType #-} > > This would be extremely useful. > > > > 4. Things like above, but with the requirement of a Zero, with the > > requirement of a One, and the requirement fo both a Zero and a One. > > Zero and one as in minBound and maxBound or rather as in Monoid and a > hypothetical Semiring? In the latter case I believe they don't really > belong into an additional class, unless you have some ordering-related > laws for the zeroes and ones. If not, you can always simply use an > Ord+Semiring constraint. > > There may be some motivation to make Bounded a subclass of Ord though. > > > Greets, > Ertugrul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >

1 0