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

[David Feuer]

I would think what you're trying to do would likely be better with a
different class, by another name, supporting things like .&&., .||., etc.,
or maybe even moving && and || into a class. Another direction is to look
at structures representing other sorts of logics. I just don't see that
Data.Bits is the right place to try to do these things.
On Sep 28, 2014 2:39 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

> 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/141a0fe7/attachment.html>