<div dir="auto">Double-barreled continuations don't seem to work well when you want to abort construction of a recursive structure. Think about Data.HashMap.Strict.insert. We don't really want to have to walk all the way back up to the top if we discover that the value pointer we're inserting is the same as the I've already in the map.</div><div class="gmail_extra"><br><div class="gmail_quote">On Feb 22, 2018 2:55 PM, "Carter Schonwald" <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">David: <div>i'm inclined to agree with Doug here.</div><div><br></div><div>Phrased differently: what is the example change in overheads in micro or milliseconds? </div><div>what is an example tiny program where those overheads are a significant part of  program overhead?</div><div><br></div><div>why woulnd't they use something like <a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2007/10/compilingwithcontinuationscontinued.pdf" target="_blank">https://www.microsoft.<wbr>com/en-us/research/wp-content/<wbr>uploads/2007/10/<wbr>compilingwithcontinuationscont<wbr>inued.pdf</a>  aka the so called "double barrelled cps" transform?</div></div><div class="elided-text"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 21, 2018 at 11:21 PM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Because sometimes the sanctioned way is inefficient. throwIO always<br>
wraps its exception argument in a SomeException constructor before<br>
calling raiseIO# on the result. That extra baggage is likely enough to<br>
make the implementation I'm considering too slow to bother with, so I<br>
care right now in 2018. I'd very much prefer to get an<br>
officially-approved way to do what I want, but barring that I'll take<br>
one that works.<br>
<div class="m_7117007597241725740HOEnZb"><div class="m_7117007597241725740h5"><br>
On Wed, Feb 21, 2018 at 9:33 AM, Doug McIlroy <<a href="mailto:doug@cs.dartmouth.edu" target="_blank">doug@cs.dartmouth.edu</a>> wrote:<br>
><br>
>> > Can I use reallyUnsafePtrEquality# reliably to identify whether a value is<br>
>> a nullary constructor of a particular type?<br>
><br>
> Can this "optimization" possibly save enough time to justify<br>
> nonstandard trickery?<br>
> This kind of obscure brittle coding may have been OK 50 years<br>
> ago. But why do it now?<br>
><br>
> Doug<br>
> ______________________________<wbr>_________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a><br>
Only members subscribed via the mailman list are allowed to post.</div></div></blockquote></div><br></div>
</div></blockquote></div><br></div>