Re: [Chicken-hackers] bit-set? is inconsistently specified

[Thomas Bushnell BSG]

I think this argument is fallacious.  Chicken Scheme is not consistent
in using the data-structure order (alist-ref, alist-update!, rassoc,
compress, tail?) and also has cases where it should use the currying
order but doesn't.

The order of SRFI-60's bit-set?, by the way, seems to have originated in
the (withdrawn) SRFI-33, which has the following explanation.  I would
say as well that the question is fundamentally unimportant, and it is
far more important to aim for consistency where possible.  As it is, I
can see no way a piece of Chicken code can reliable use bit-set?, since
it is unspecified in what order included units are run; you can't
predict whether using srfi-60 or library will take precedence.

It seems as if you're saying that compatibility has absolutely no weight
with you.  If that's true, can you explain why?  If it's not true, can
you describe what weight you think compatibility should play?  (Are
there *any* Scheme systems with a bit-set? in Chicken's order?)

Thomas



** Order of arguments for non-bitstring parameters
==================================================
The "bitwise boolean" functions such as BITWISE-AND only take bitstring
parameters. But the following 10 functions are different in that they take
other *kinds* of parameters (masks, indices, field sizes) that indicate *the
exact operation to perform* on the bitstring parameter(s):
    arithmetic-shift i count -> integer
    bitwise-merge mask i0 i1 -> integer
    bit-set? index i -> boolean
    any-bits-set? test-bits i -> boolean
    all-bits-set? test-bits i -> boolean
    extract-bit-field size position i -> integer
    test-bit-field?   size position i -> boolean
    clear-bit-field   size position i -> integer
    replace-bit-field size position new-field i -> integer
    copy-bit-field    size position from to     -> integer
Note that in all of these functions, with the sole exception of
ARITHMETIC-SHIFT, the bitstring parameter comes last. This is consistent
with an "operation currying" convention, wherein the arguments that determine
the operation come first, and the actual value upon which we operate comes
last. MAP and FOLD, for example, work this way, too. (The "op currying"
convention is actually useful in SML; in Scheme, its utility is almost
entirely as a mnemonic convention to aid programmers in remembering argument
order.)

ARITHMETIC-SHIFT is entrenched by long and consistent tradition in the
indicated parameter order; it would be a mistake to alter this. Every
implementation of Scheme I have checked that offers a bit-shift operation on
integers (PLT Scheme, slib, Bigloo, Scheme 48, and MIT Scheme), as well as
Common Lisp, uses the "i count" argument order.

As an alternative to the "op currying" order, we could use the "data-structure
accessor" convention, wherein the data-structure being accessed (the
bitstring) comes first, and the "selector" arguments come after. For example,
this is the convention used for the functions VECTOR-REF and STRING-REF. One
could make the argument that this convention could be reasonably applied to
some of these operators, such as BIT-SET?

I recommend leaving things as they are, for maximal consistency with a simple
rule. This also provides consistency with Common Lisp, whose bitwise functions
uniformly use the ops-curry convention (see the "related designs" summary
below).



On Tue, 2009-08-04 at 01:38 +0200, Thomas Chust wrote:
> 2009/8/4 Thomas Bushnell BSG <address@hidden>:
> > On Tue, 2009-08-04 at 00:34 +0200, Thomas Chust wrote:
> >> [...] However the convention of passing the
> >> composite object first and the index after it is much more widespread
> >> than what SRFI-60 apparently does. By the principle of least surprise
> >> I would always have expected to find the parameters in the order
> >> CHICKEN currently uses!
> >
> > I agree completely that, if this were being designed from the beginning,
> > the Chicken order is better than the srfi-60 order.  Yet, I don't think
> > we get to deal with that. [...]
> 
> Hello,
> 
> as far as I can see, CHICKEN neither claims to implement SRFI-60 nor
> does it implement a large subset of procedures specified there. Also a
> SRFI is not a binding standard document, but a *request* for
> implementation.
> 
> Given all that and the fact that CHICKEN's choice of API convention is
> probably better than that of SRFI-60 here, I don't see any reason at
> all, why this behaviour should be changed.
> 
> However, that is just my personal opinion :-)
> 
> cu,
> Thomas
> 
>