[Haskell-cafe] Pointer equality for nullary constructors

[Brandon Allbery]

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 at 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 at 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 at 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 at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180222/912ad08a/attachment.html>