<div dir="ltr"><div>Likewise: very supportive, a few holes that I'd like to address before fully committing.</div><div><br></div><div>Contrary to Simon M, though, I think I prefer the implicit parameter design to the pattern-synonym design.<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 9 Mar 2023 at 11:23, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>High-level we definitely want this, I added a couple of comments to the GitHub thread to discuss details.</div><div><br></div><div>One slightly suboptimal aspect of the proposal is the use of implicit parameters. The design in <a href="https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst#82exception-hierarchy-design-alternative-two" target="_blank">Section 8.2</a> seems much nicer and is only prevented by issues with pattern synonyms. Couldn't we fix pattern synonyms so this would work?<br></div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 6 Mar 2023 at 13:44, Vladislav Zavialov <<a href="mailto:vlad.z.4096@gmail.com" target="_blank">vlad.z.4096@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Committee,<div><br></div><div>Ben Gamari has proposed #330 "Decorate exceptions with backtrace information". Read it here:<br></div><div><br></div><div><a href="https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst" target="_blank">https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst</a><br></div><div><br></div><div>The proposal attaches contextual information to thrown exceptions. This information includes (but is not limited to) backtraces, making it possible to debug uncaught exceptions more effectively.</div><div><br></div><div>This is a very nuanced change, since it modifies SomeException, throw, catch, and other exception-related definitions whose use is extremely widespread. We might end up affecting our users in unexpected ways. Because of that, I ask the committee to review the proposal with the appropriate amount of care.</div><div><br></div><div>I am recommending acceptance because adding observability to our programs is an important part of developer ergonomics. From the proposal discussion, I have got the impression that there are numerous commercial users who would benefit from this.</div><div><br></div><div>Please take a look at the proposal text and share your thoughts either here or directly on GitHub.</div><div><br></div><div>- Vlad </div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>