May 2020 - Glasgow-haskell-users

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1 released
by Ben Gamari 18 May '20

18 May '20

Hello all, The GHC team is happy to announce the availability of GHC 8.10.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1/ GHC 8.10.1 brings a number of new features including: * The new UnliftedNewtypes extension allowing newtypes around unlifted types. * The new StandaloneKindSignatures extension allows users to give top-level kind signatures to type, type family, and class declarations. * A new warning, -Wderiving-defaults, to draw attention to ambiguous deriving clauses * A number of improvements in code generation, including changes * A new GHCi command, :instances, for listing the class instances available for a type. * An upgraded Windows toolchain lifting the MAX_PATH limitation * A new, low-latency garbage collector. * Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running `xattr -cr .` on the unpacked tree before running `make install`. This situation will hopefully be improved for GHC 8.10.2 with the resolution of #17418 [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17418

2 4

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Henning Thielemann 14 May '20

14 May '20

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"?

4 4

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Henning Thielemann 12 May '20

12 May '20

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)?

2 2

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Henning Thielemann 12 May '20

12 May '20

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?

1 0

Re: Decorating exceptions with backtrace information
by Ben Gamari 11 May '20

11 May '20

Michael Sloan <mgsloan(a)gmail.com> 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

1 0

Re: Decorating exceptions with backtrace information
by Carter Schonwald 08 May '20

08 May '20

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 <mgsloan(a)gmail.com> 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 <ben(a)well-typed.com> 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(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

2 2

Decorating exceptions with backtrace information
by Ben Gamari 07 May '20

07 May '20

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

1 0