Proposal: change the Bits instance for Bool to align with other basic types and support branchless calculations

Edward Kmett ekmett at gmail.com
Sun Sep 28 18:39:20 UTC 2014


That said, you *could* make them short-circuit as well when they are all 0s
or all 1s. I'm not saying we should, as I'm disinclined to introduce even a
cold branch for the check, but it is a possibility.

My main concern is that if (*sigh* probably when) we adopt this proposal we
collapse the whole waveform of possibilities in this space, perhaps
needlessly cutting off future growth directions.

I'm willing to lose the argument here, but I think we should eventually *have
the argument* rather than blindly take the 10%.

I also realize that if we have the argument today, it is probably a sealed
deal, and I'll lose.

Since this proposal is acting as a forcing function, and I don't think I
can stem the tide of opinion on this one I accept the fact that it will
probably go through.

I don't have the time right now to flesh out a full proposal, and I don't
even think it would be a good idea to adopt in the current state of the
Haskell.

If we're talking about a counter-proposal that makes sense in the 7.10 or
likely even 7.12 timeframe, I'm out.

As a fairly weak example:

Many of the other usecases that would be opened up by the alternative to
this proposal are also currently blocked or rendered ugly by the shape of
Bits and are complicated.

e.g. The alternative permits you to use (.&.) and (.|.) in EDSLs when you
need to capture the shape of your conditionals. (As long as you ignore
testBit)

An example of something lost if this proposal is adopted: Folks can't use
(.&.) and (.|.) for freely overridden logical connectives in finally
tagless EDSLs and have Bool just be the default interpreted case.

I can see the appeal of the proposal, it is simple.

I'm personally a weak -1 on the grounds that I think it prematurely forces
us to evaluate the possibilities in this space and takes us in a direction
that cuts us off from paths that could lead to greater generality in the
future.

On a more immediate front, I think the small constant factor performance
gain is counter-balanced by the asymptotic hit, and saying 'don't do that
then' is sweeping an asymptotic issue under the rug.

I also expect that these arguments aren't going to be strong enough to beat
the immediate obviousness of the proposal.

-Edward

On Sun, Sep 28, 2014 at 1:51 PM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Sun, Sep 28, 2014 at 1:34 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> I can envision a point in Haskell's future where we might want to let the
>> combinators in Data.Bits be the ones we use for Bool, where
>> &&/||/and/or/any/all/not/ just smash things together with Bits and we
>> generalize more of base.
>>
>> That would be an incredibly dumb thing to do with non-short-circuiting
>> versions of the operators.
>>
>> I for one don't want to cut off that possible future for a 10% gain for a
>> limited usecase.
>>
>
> My counter-question is: is it even worth considering this generalization
> if it only makes sense for the Bool case? Because none of the other
> instances short-circuit.
>
> --
> 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://www.haskell.org/pipermail/libraries/attachments/20140928/dd8a69b8/attachment.html>


More information about the Libraries mailing list