But in most cases exceptions are the slow path. There's a few languages that use them heavily as what one could think of as a form of out of band dynamic typing for function results, and which have specific support for fast exceptions to support that. In most, exception handling is much heavier weight than the usual code path, and needs to be because it needs to unwind the stack and free up allocated temporaries (presumably that last doesn't apply to Haskell. The pattern match stack would need the same unwind cleanup though) and otherwise clean up any unfinished business that will never finish as a result, as it propagates looking for a handler. Since they also usually contain an execution trace, that makes them even heavier (again, ghc does this differently --- one could argue worse, since the price is paid by all functions with HasCallStack context. I think only Icon of other languages I know penalize the normal path the same way --- because it's also how &fail / retry semantics is implemented).

...looking at that again, maybe I'm too tired to do this. Hopefully you can unpack that concept hairball....

On Thu, Feb 22, 2018 at 6:15 AM, David Feuer <david.feuer@gmail.com> wrote:
Well, not always. They have special support in the RTS that seems worth experimenting with. setjmp/longjmp is what I'm after.

On Feb 21, 2018 11:24 PM, "Branimir Maksimovic" <branimir.maksimovic@gmail.com> wrote:
Hm, isn't that exceptions are exceptional?


On 22.02.2018. 05:21, David Feuer wrote:
Because sometimes the sanctioned way is inefficient. throwIO always
wraps its exception argument in a SomeException constructor before
calling raiseIO# on the result. That extra baggage is likely enough to
make the implementation I'm considering too slow to bother with, so I
care right now in 2018. I'd very much prefer to get an
officially-approved way to do what I want, but barring that I'll take
one that works.

On Wed, Feb 21, 2018 at 9:33 AM, Doug McIlroy <doug@cs.dartmouth.edu> wrote:
Can I use reallyUnsafePtrEquality# reliably to identify whether a value is
a nullary constructor of a particular type?
Can this "optimization" possibly save enough time to justify
nonstandard trickery?
This kind of obscure brittle coding may have been OK 50 years
ago. But why do it now?

Doug
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.



--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net