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 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.

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