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

[Edward Kmett]

That is the approach people are forced to take now. I currently do so in
Ersatz, though I'd intended ever since Bits shed Num to switch to Bits once
we obtained the Bool instance, Lennart does also uses a custom Boolean
class in at least one edsl he has online.

I'm okay if we collectively agree that this is a price we want to pay, I
just want to acknowledge that it there is a price.

You've made it clear you have a very tight vision for the role of Bits. I
personally haven't yet committed to your viewpoint, but I can see the merit
of it. Like I said, I suspect that I've lost this debate.

I feel much better about making a decision if I can see both the upside and
the downside, rather than just listen to the sales pitch, and wanted folks
who were giving it +1s to do so after considering the cost, not just after
considering the small performance benefit.

-Edward

On Sun, Sep 28, 2014 at 2:45 PM, David Feuer <david.feuer at gmail.com> wrote:

> 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/1ca05661/attachment-0001.html>