Re: [Haskell-cafe] Pointer equality for nullary constructors
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. On Feb 22, 2018 2:55 PM, "Carter Schonwald" <carter.schonwald@gmail.com> wrote: David: i'm inclined to agree with Doug here. Phrased differently: what is the example change in overheads in micro or milliseconds? what is an example tiny program where those overheads are a significant part of program overhead? why woulnd't they use something like https://www.microsoft. com/en-us/research/wp-content/uploads/2007/10/compilingwithcontinuationscont inued.pdf aka the so called "double barrelled cps" transform? On Wed, Feb 21, 2018 at 11:21 PM, David Feuer <david.feuer@gmail.com> 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.
Yes, by the way, insert would be a poor use case, since the "same value pointer" case will be fairly rare. The actual use-case I have in mind is alterF, where that case is much more likely. On Feb 22, 2018 3:12 PM, "David Feuer" <david.feuer@gmail.com> wrote:
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.
On Feb 22, 2018 2:55 PM, "Carter Schonwald" <carter.schonwald@gmail.com> wrote:
David: i'm inclined to agree with Doug here.
Phrased differently: what is the example change in overheads in micro or milliseconds? what is an example tiny program where those overheads are a significant part of program overhead?
why woulnd't they use something like https://www.microsoft.com /en-us/research/wp-content/uploads/2007/10/compilingwithcont inuationscontinued.pdf aka the so called "double barrelled cps" transform?
On Wed, Feb 21, 2018 at 11:21 PM, David Feuer <david.feuer@gmail.com> 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.
participants (1)
-
David Feuer