From ben at well-typed.com Thu May 7 21:54:31 2020 From: ben at well-typed.com (Ben Gamari) Date: Thu, 07 May 2020 17:54:31 -0400 Subject: Decorating exceptions with backtrace information Message-ID: <87r1vv1kdx.fsf@smart-cactus.org> Hi everyone, After a nice discussion on IRC about the unfortunate state of error reporting in Haskell, I felt compelled to write down some long-lingering thoughts regarding backtraces on exceptions. The result is GHC proposal #330 [1]. I think the approach is viable and perhaps even straightforward. I have the sketch of an implementation here [2]. Please have a look at the proposal and leave your comments. If there is consensus it is possible that we could have this done for 8.12. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/330 [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From carter.schonwald at gmail.com Fri May 8 13:32:41 2020 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 May 2020 09:32:41 -0400 Subject: Decorating exceptions with backtrace information In-Reply-To: References: <87r1vv1kdx.fsf@smart-cactus.org> Message-ID: ben, could you please email the libraries list with this too? This seems like a core libraries / base change rather than a ghc-the-compiler change On Thu, May 7, 2020 at 6:57 PM Michael Sloan wrote: > Thanks so much for making a proposal for this, Ben!! It's great to see > progress here. > > I'm also glad that there is now a proposal process. I made a fairly > similar proposal almost exactly 5 years ago to the libraries list - > https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - but > without the subtlety of particular backtrace representations. Skimming the > ensuing thread may still be informative. > > In particular, there is one thing I would like to highlight from that old > proposal. I think it'd be good to have a standard way to represent a chain > of exceptions, and build this into `catch` and `finally`. Python and Java > both have a mechanism for this, and both refer to it as a "cause" > exception. When an exception is thrown during exception handling, the > exception being handled is preserved as its "cause". I find this mechanism > to be incredibly useful in Java, it has made the underlying issue much > clearer in many cases, and in other cases at least provides helpful > context. I have no doubt such a mechanism would have saved me many hours > of debugging exceptions in Haskell systems I've worked on in the past. > > I considered commenting about that directly on the proposal, but I figure > this is a better place to suggest expanding the scope of the change :) . > Totally understandable if you want to keep this proposal focused on > stacktraces, but I think it'd be good to consider this as a potential > future improvement. > > -Michael > > On Thu, May 7, 2020 at 3:55 PM Ben Gamari wrote: > >> >> Hi everyone, >> >> After a nice discussion on IRC about the unfortunate state of error >> reporting in Haskell, I felt compelled to write down some long-lingering >> thoughts regarding backtraces on exceptions. The result is GHC proposal >> #330 [1]. I think the approach is viable and perhaps even >> straightforward. I have the sketch of an implementation here [2]. >> >> Please have a look at the proposal and leave your comments. If there is >> consensus it is possible that we could have this done for 8.12. >> >> Cheers, >> >> - Ben >> >> >> [1] https://github.com/ghc-proposals/ghc-proposals/pull/330 >> [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236 >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri May 8 13:33:51 2020 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 May 2020 09:33:51 -0400 Subject: Decorating exceptions with backtrace information In-Reply-To: References: <87r1vv1kdx.fsf@smart-cactus.org>

Message-ID: On Fri, May 8, 2020 at 9:32 AM Carter Schonwald wrote: > ben, could you please email the libraries list with this too? This seems > like a core libraries / base change rather than a ghc-the-compiler change > > On Thu, May 7, 2020 at 6:57 PM Michael Sloan wrote: > >> Thanks so much for making a proposal for this, Ben!! It's great to see >> progress here. >> >> I'm also glad that there is now a proposal process. I made a fairly >> similar proposal almost exactly 5 years ago to the libraries list - >> https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - >> but without the subtlety of particular backtrace representations. Skimming >> the ensuing thread may still be informative. >> >> In particular, there is one thing I would like to highlight from that old >> proposal. I think it'd be good to have a standard way to represent a chain >> of exceptions, and build this into `catch` and `finally`. Python and Java >> both have a mechanism for this, and both refer to it as a "cause" >> exception. When an exception is thrown during exception handling, the >> exception being handled is preserved as its "cause". I find this mechanism >> to be incredibly useful in Java, it has made the underlying issue much >> clearer in many cases, and in other cases at least provides helpful >> context. I have no doubt such a mechanism would have saved me many hours >> of debugging exceptions in Haskell systems I've worked on in the past. >> >> I considered commenting about that directly on the proposal, but I figure >> this is a better place to suggest expanding the scope of the change :) . >> Totally understandable if you want to keep this proposal focused on >> stacktraces, but I think it'd be good to consider this as a potential >> future improvement. >> >> -Michael >> >> On Thu, May 7, 2020 at 3:55 PM Ben Gamari wrote: >> >>> >>> Hi everyone, >>> >>> After a nice discussion on IRC about the unfortunate state of error >>> reporting in Haskell, I felt compelled to write down some long-lingering >>> thoughts regarding backtraces on exceptions. The result is GHC proposal >>> #330 [1]. I think the approach is viable and perhaps even >>> straightforward. I have the sketch of an implementation here [2]. >>> >>> Please have a look at the proposal and leave your comments. If there is >>> consensus it is possible that we could have this done for 8.12. >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> [1] https://github.com/ghc-proposals/ghc-proposals/pull/330 >>> [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236 >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri May 8 15:37:36 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 8 May 2020 17:37:36 +0200 (CEST) Subject: [Haskell-cafe] Decorating exceptions with backtrace information In-Reply-To: References: <87r1vv1kdx.fsf@smart-cactus.org>

Message-ID: There seem to be multiple beginnings of the discussion. What is currently discussed? If someone says "exceptions" and "backtrace" in one sentence, I suspect like many times before, that again confusion of the concepts of exceptions and errors is ahead. Errors already support call stacks. Why should exceptions get them, too? Exceptions should carry information that is useful for a user, but a callstack is not useful for a user. I can imagine that it would be helpful for the user to get a stacked exception information like: Parse error on line 42, column 23 while reading file "foo/bar" while traversing directory "blabla" But since you refer to the CallStack feature of GHC, this seems not to be addressed in the proposals. On Fri, 8 May 2020, Carter Schonwald wrote: > I have no doubt such a mechanism would have saved me many hours of > debugging exceptions in Haskell systems I've worked on in the past. If you must debug exceptions, then this sounds like exceptions were abused for programming errors. Ben writes in: http://www.well-typed.com/blog/2020/04/dwarf-3/ "Unfortunately, the untyped nature of Haskell exceptions complicates the migration path for existing code." Actually, it only proves again, that it was wrong from the beginning to hide information about potential exceptions in the IO monad instead of making them explicit via ExceptionalT, ExceptT or the like. From lemming at henning-thielemann.de Fri May 8 17:32:54 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 8 May 2020 19:32:54 +0200 (CEST) Subject: [Haskell-cafe] Decorating exceptions with backtrace information In-Reply-To: <0c11ba4f-90af-b56e-e21d-6c4b1eba9144@nh2.me> References: <87r1vv1kdx.fsf@smart-cactus.org>

<0c11ba4f-90af-b56e-e21d-6c4b1eba9144@nh2.me> Message-ID: On Fri, 8 May 2020, Niklas Hambüchen wrote: > On 5/8/20 5:37 PM, Henning Thielemann wrote: > >> a callstack is not useful for a user. > > Call stacks have been very useful to me as a user of non-Haskell tools > so far, because they are excellent for attaching to bug reports and > usually led to developers fixing my problems faster. This confirms that they are not for you, but you only forward them to the developer. Can someone please give me examples where current state lacks and how they are addressed by the proposal(s)? From lemming at henning-thielemann.de Fri May 8 17:52:13 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 8 May 2020 19:52:13 +0200 (CEST) Subject: [Haskell-cafe] Decorating exceptions with backtrace information In-Reply-To: <56a36bd0-3c98-29fd-ad26-8ca4f99d8d66@nh2.me> References: <87r1vv1kdx.fsf@smart-cactus.org>

<0c11ba4f-90af-b56e-e21d-6c4b1eba9144@nh2.me> <56a36bd0-3c98-29fd-ad26-8ca4f99d8d66@nh2.me> Message-ID: On Fri, 8 May 2020, Niklas Hambüchen wrote: > On 5/8/20 7:32 PM, Henning Thielemann wrote: > >> Can someone please give me examples where current state lacks > > * Currently stack traces are not printed, so users cannot forward them > to the developer, even if both the users and the developers would like > that. We are talking about the HasCallStack stack traces, yes? How is their emission addressed by extending exceptions with stack traces? > * Developers cannot easily produce stack traces do debug unintended > exceptions. What are "unintended exceptions"? What is an example of an "unintended exception"? From ben at well-typed.com Fri May 8 18:03:41 2020 From: ben at well-typed.com (Ben Gamari) Date: Fri, 08 May 2020 14:03:41 -0400 Subject: [Haskell-cafe] Decorating exceptions with backtrace information In-Reply-To: References: <87r1vv1kdx.fsf@smart-cactus.org>

<0c11ba4f-90af-b56e-e21d-6c4b1eba9144@nh2.me> Message-ID: <87mu6i1eyw.fsf@smart-cactus.org> Henning Thielemann writes: > On Fri, 8 May 2020, Niklas Hambüchen wrote: > >> On 5/8/20 5:37 PM, Henning Thielemann wrote: >> >>> a callstack is not useful for a user. >> >> Call stacks have been very useful to me as a user of non-Haskell tools >> so far, because they are excellent for attaching to bug reports and >> usually led to developers fixing my problems faster. > > This confirms that they are not for you, but you only forward them to the > developer. > > > Can someone please give me examples where current state lacks and how they > are addressed by the proposal(s)? We can debate whether partial functions like `fromJust` should exist; however, the fact of the matter is that they do exist and they are used. Furthermore, even `base`'s own IO library (e.g. `openFile`) uses synchronous exceptions to report errors. This becomes particularly painful when building large systems: Even if I am careful to avoid such functions in my own code, as my dependency footprint grows it becomes more likely that some transitive dependency will expose a partial interface (perhaps even without my knowledge). This is a problem that industrial users are all too familiar with. Perhaps this helps to shed some light on the motivation? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Fri May 8 18:18:38 2020 From: ben at well-typed.com (Ben Gamari) Date: Fri, 08 May 2020 14:18:38 -0400 Subject: [Haskell-cafe] Decorating exceptions with backtrace information In-Reply-To: References: <87r1vv1kdx.fsf@smart-cactus.org>

<0c11ba4f-90af-b56e-e21d-6c4b1eba9144@nh2.me> <56a36bd0-3c98-29fd-ad26-8ca4f99d8d66@nh2.me> Message-ID: <87k11m1e9z.fsf@smart-cactus.org> Henning Thielemann writes: > On Fri, 8 May 2020, Niklas Hambüchen wrote: > >> On 5/8/20 7:32 PM, Henning Thielemann wrote: >> >>> Can someone please give me examples where current state lacks >> >> * Currently stack traces are not printed, so users cannot forward them >> to the developer, even if both the users and the developers would like >> that. > > We are talking about the HasCallStack stack traces, yes? > How is their emission addressed by extending exceptions with stack > traces? HasCallStack stack traces are one type of backtrace that the proposal supports. However, it's not the only (nor is it even the most useful sort, in my opinion). Other mechanisms include cost center stacks from the cost-center profiler and native stack unwinding. > >> * Developers cannot easily produce stack traces do debug unintended >> exceptions. > > What are "unintended exceptions"? > What is an example of an "unintended exception"? For instance, * Somewhere deep in my code a colleague used `fromJust` due to a miscommunicated invariant * Somewhere in my system a `writeFile "tmp" $ repeat 'a'` failed due to filling the disk * Somewhere in my system I have a partial pattern match in a module which was compiled without -Wall * Somewhere in my system I `div` by zero due to lack of input validation * I use a record selector on a sum. * A logic error results in an assertion failure deep in my program, but it's unclear which path my program took to arrive at the assertion This list could go on and on... Currently the proposal does not cover asynchronous exceptions but it wouldn't be particularly hard to extend it in this direction. This would allow far better reporting of heap/stack overflows and MVar deadlocks (which are particularly hard to debug at the moment). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Mon May 11 15:48:09 2020 From: ben at well-typed.com (Ben Gamari) Date: Mon, 11 May 2020 11:48:09 -0400 Subject: Decorating exceptions with backtrace information In-Reply-To: References: <87r1vv1kdx.fsf@smart-cactus.org> Message-ID: <87blmu1nih.fsf@smart-cactus.org> Michael Sloan writes: > Thanks so much for making a proposal for this, Ben!! It's great to see > progress here. > > I'm also glad that there is now a proposal process. I made a fairly > similar proposal almost exactly 5 years ago to the libraries list - > https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - but > without the subtlety of particular backtrace representations. Skimming the > ensuing thread may still be informative. > Thanks for the reference, Michael! My feeling is that the proposal in that thread is a bit too dynamic. That being said, I can see the argument for wanting, for instance, a robust way to determine that an exception is asynchronous. > In particular, there is one thing I would like to highlight from that old > proposal. I think it'd be good to have a standard way to represent a chain > of exceptions, and build this into `catch` and `finally`. Python and Java > both have a mechanism for this, and both refer to it as a "cause" > exception. When an exception is thrown during exception handling, the > exception being handled is preserved as its "cause". I find this mechanism > to be incredibly useful in Java, it has made the underlying issue much > clearer in many cases, and in other cases at least provides helpful > context. I have no doubt such a mechanism would have saved me many hours > of debugging exceptions in Haskell systems I've worked on in the past. > > I considered commenting about that directly on the proposal, but I figure > this is a better place to suggest expanding the scope of the change :) . > Totally understandable if you want to keep this proposal focused on > stacktraces, but I think it'd be good to consider this as a potential > future improvement. > Indeed I can see the point. I'll keep this point in the back of my mind. I'm not eager to further expand the scope of the proposal at the moment, but we should be certain that the backtrace design doesn't unintentionally close the door to this use-case. However, one question I would have is whether the exception-chaining use-case *needs* to be handled in SomeException. For instance, you could rather leave this to user code. You might even give this pattern a typeclass. For instance, class HasChainedException e where getChainedException :: e -> Maybe SomeException data MyException = MyException { causedBy :: SomeException } instance HasChainedException MyException where getChainedException = causedBy Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From lemming at henning-thielemann.de Tue May 12 20:55:08 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 12 May 2020 22:55:08 +0200 (CEST) Subject: [Haskell-cafe] Decorating exceptions with backtrace information In-Reply-To: <517044fa-4fb2-cde6-3a8c-b1013f7b06f0@nh2.me> References: <87r1vv1kdx.fsf@smart-cactus.org>

<0c11ba4f-90af-b56e-e21d-6c4b1eba9144@nh2.me> <56a36bd0-3c98-29fd-ad26-8ca4f99d8d66@nh2.me> <517044fa-4fb2-cde6-3a8c-b1013f7b06f0@nh2.me> Message-ID: On Fri, 8 May 2020, Niklas Hambüchen wrote: >> What are "unintended exceptions"? >> What is an example of an "unintended exception"? > > A recent example from my production server: > > hPutBuf: resource vanished (Broken pipe) Ok, I lookup the Haddock comment of hPutBuf and it says: "This operation may fail with: * ResourceVanished if the handle is a pipe or socket, and the reading end is closed." That is, ResourceVanished is part of the public interface and in no way unexpected (or what "unintended" may be). I would prefer to make this explicit in the type of hPutBuf: hPutBuf :: (ResourceVanishedException e) => Handle -> Ptr a -> Int -> ExceptT e IO () Now, what do you intend to do with the call-stack? Isn't it something you can attach to the e value? From lemming at henning-thielemann.de Tue May 12 21:06:35 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 12 May 2020 23:06:35 +0200 (CEST) Subject: [Haskell-cafe] Decorating exceptions with backtrace information In-Reply-To: <87mu6i1eyw.fsf@smart-cactus.org> References: <87r1vv1kdx.fsf@smart-cactus.org>

<0c11ba4f-90af-b56e-e21d-6c4b1eba9144@nh2.me> <87mu6i1eyw.fsf@smart-cactus.org> Message-ID: On Fri, 8 May 2020, Ben Gamari wrote: > We can debate whether partial functions like `fromJust` should exist; however, > the fact of the matter is that they do exist and they are used. That's not my point. I say: fromJust on Nothing is a programming error, ok. We must debug this. HasCallStack helps here. However, it does not have to do with exceptions or with the proposals as I understand them. > Furthermore, even `base`'s own IO library (e.g. `openFile`) uses > synchronous exceptions to report errors. Right. I say: Such exceptions are part of the public interface and should be expressed in types. If you encounter any problems when not doing this, I would first try to solve the problem with exceptions explicit in the type. E.g. Haddock for openFile says: This operation may fail with: * isAlreadyInUseError ... * isDoesNotExistError ... * isPermissionError ... Thus the type should be: openFile :: (AlreadyInUseException e, DoesNotExistException e, PermissionException e) => FilePath -> IOMode -> ExceptT e IO Handle > Perhaps this helps to shed some light on the motivation? Unfortunately no. I only see the immortal confusion about (programming) errors vs. (IO) exceptions. And I think that part of this confusion is that IO exceptions in 'base' are hidden in the IO type and that there are hybrid functions like 'throw' that can be called like 'error' but they cause IO exceptions that can be caught by 'catch'. From lemming at henning-thielemann.de Tue May 12 21:29:19 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 12 May 2020 23:29:19 +0200 (CEST) Subject: [Haskell-cafe] Decorating exceptions with backtrace information In-Reply-To: <87k11m1e9z.fsf@smart-cactus.org> References: <87r1vv1kdx.fsf@smart-cactus.org>

<0c11ba4f-90af-b56e-e21d-6c4b1eba9144@nh2.me> <56a36bd0-3c98-29fd-ad26-8ca4f99d8d66@nh2.me> <87k11m1e9z.fsf@smart-cactus.org> Message-ID: On Fri, 8 May 2020, Ben Gamari wrote: > Henning Thielemann writes: > >> We are talking about the HasCallStack stack traces, yes? >> How is their emission addressed by extending exceptions with stack >> traces? > > HasCallStack stack traces are one type of backtrace that the proposal > supports. However, it's not the only (nor is it even the most useful > sort, in my opinion). > > Other mechanisms include cost center stacks from the cost-center > profiler and native stack unwinding. Interesting. That's a completely new thing. >>> * Developers cannot easily produce stack traces do debug unintended >>> exceptions. >> >> What are "unintended exceptions"? >> What is an example of an "unintended exception"? > > For instance, > > * Somewhere deep in my code a colleague used `fromJust` due to a > miscommunicated invariant That's a programming error. > * Somewhere in my system a `writeFile "tmp" $ repeat 'a'` failed due to > filling the disk Hm, that's also a programming error, but it ends in an IO exception. If it would not end in an IO exception (e.g. writing to /dev/null) it would go to an infinite loop. Anyway, it is a programming error. However it is an unchecked one. That is, there is no warranty that you can catch it by a debugger. So I do not think you can achieve much with callstacks here. > * Somewhere in my system I have a partial pattern match in a module > which was compiled without -Wall Programming error and btw. before thinking about a GHC extension I would enable -Wall ... > * Somewhere in my system I `div` by zero due to lack of input > validation Programming error > * I use a record selector on a sum. Programming error > * A logic error results in an assertion failure deep in my program, but > it's unclear which path my program took to arrive at the assertion Sounds like Programming error > This list could go on and on... >From your list of examples I deduce that the proposal is about programming errors. But we have HasCallStack for that one. How does the proposal improve or alter the HasCallStack solution? And how does it relate to the IO exception system with hierarchical exceptions and SomeException and so on? > Currently the proposal does not cover asynchronous exceptions but it > wouldn't be particularly hard to extend it in this direction. This would > allow far better reporting of heap/stack overflows and MVar deadlocks > (which are particularly hard to debug at the moment). Hm, what kind of heap or stack overflow are you thinking of? A stack overflow sounds like unlimited recursion and thus like a programming error. In contrast to that, a program must be prepared for a failure of "malloc". Memory exhaustion is an IO exception, it should be explicit in the type. Are MVar deadlocks always detected by the runtime system? From ben.franksen at online.de Wed May 13 14:15:17 2020 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 13 May 2020 16:15:17 +0200 Subject: [Haskell-cafe] Decorating exceptions with backtrace information In-Reply-To: References: <87r1vv1kdx.fsf@smart-cactus.org>

<0c11ba4f-90af-b56e-e21d-6c4b1eba9144@nh2.me> <56a36bd0-3c98-29fd-ad26-8ca4f99d8d66@nh2.me> <87k11m1e9z.fsf@smart-cactus.org> Message-ID: Am 12.05.20 um 23:29 schrieb Henning Thielemann: > A stack overflow sounds like unlimited recursion and thus like a > programming error. Perhaps it was just one recursion to many? Computer memory is limited. Heap overflow is also quite possible even with a program that is provably terminating. I have used 'ulimit -v' in the past to force ghc to fail rather than having to reboot my machine :-/ > In contrast to that, a program must be prepared for a > failure of "malloc". I don't see any essential difference between allocation by the runtime and explicit allocation using malloc. I think this is a good thing that in Haskell you /can/ recover from such a condition. > Memory exhaustion is an IO exception, it should be > explicit in the type. Then it must be explicit in all types, since in general all computations may exhaust the available memory. And then what use would that type information have? > Are MVar deadlocks always detected by the runtime system? My guess is that deadlock detection in general is undecidable i.e. with more than one MVar present, but I may be wrong about that. Cheers Ben From twhitehead at gmail.com Thu May 14 16:06:37 2020 From: twhitehead at gmail.com (Tyson Whitehead) Date: Thu, 14 May 2020 12:06:37 -0400 Subject: [Haskell-cafe] Decorating exceptions with backtrace information In-Reply-To: References: <87r1vv1kdx.fsf@smart-cactus.org>

<0c11ba4f-90af-b56e-e21d-6c4b1eba9144@nh2.me> <56a36bd0-3c98-29fd-ad26-8ca4f99d8d66@nh2.me> <87k11m1e9z.fsf@smart-cactus.org> Message-ID: On Tue, 12 May 2020 at 17:30, Henning Thielemann < lemming at henning-thielemann.de> wrote: > From your list of examples I deduce that the proposal is about programming > errors. But we have HasCallStack for that one. How does the proposal > improve or alter the HasCallStack solution? And how does it relate to the > IO exception system with hierarchical exceptions and SomeException and so > on? > As a parallel item, maybe it would be good if incomplete patterns could have a HasCallStack constraint so the current "Non-exaustive patterns in function foo" message could be extended with a helpful backtrace? If a programmer doesn't want this, then they could use complete matches? -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Sun May 17 02:18:27 2020 From: juhpetersen at gmail.com (Jens Petersen) Date: Sun, 17 May 2020 10:18:27 +0800 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.10.1 released In-Reply-To: <87zhc5aimf.fsf@smart-cactus.org> References: <87369xbxuo.fsf@smart-cactus.org> <87zhc5aimf.fsf@smart-cactus.org> Message-ID: Hi, late question, I just noticed: Is it intentional that the text library in 8.10.1 is older than the one in 8.8? (1.2.3.2 vs 1.2.4.0 ) Thanks, Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Mon May 18 05:13:00 2020 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 18 May 2020 13:13:00 +0800 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.10.1 released In-Reply-To: References: <87369xbxuo.fsf@smart-cactus.org> <87zhc5aimf.fsf@smart-cactus.org> Message-ID: On Sun, 17 May 2020 at 10:18, Jens Petersen wrote: > Is it intentional that the text library in 8.10.1 is older than the one in > 8.8? > Ben pointed me at https://gitlab.haskell.org/ghc/ghc/issues/17956 in irc. Thanks, Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: