On 09/05/17 18:32, John Cowan wrote:
> The current order of bit generation or consumption in integer->list,
> list->integer, integer->vector, vector->integer, bits, bitwise-fold,
> bitwise-for-each, bitwise-unfold, and make-bitwise-generator is not
> entirely satisfactory.
>
> In SRFI 142, these were all defined to generate or consume bits in
> little-endian order: that is, bit #0 first, followed by bit #1, etc.
> However, this did not agree with the SLIB and SRFI 60 implementations,
> or indeed the implementation of SRFI 142 itself (since this
> implementation was taken directly from SRFI 60).  So in SRFI 151 I
> switched the definition to big-endian order.
>
> However, bitwise-fold, bitwise-for-each, bitwise-unfold, and
> make-bitwise-generator were first defined in SRFI 142, so I left them
> alone in SRFI 151.  This makes them inconsistent with the above group.
>
> Is this a problem?  Should I change them to be consistent?  This will
> involve changing make-bitwise-generator to produce a finite generator.
>
> Other comments?

I quite like the functions as they are.

I don't think the 'inconsistency', if it is that, matters.  The
fold/unfold/generator functions are different in feel to the list/vector
conversions, and naturally work from bit 0.

There's something satisfying and predictable about the visual order of:

sash[r7rs]> (integer->list 6)
(#t #t #f)

and it fits neatly with:

sash[r7rs]> (bitwise-fold cons '() 6)
(#t #t #f)

The only niggle to my mind is the difference between:

sash[r7rs]> (bit-set? 2 6)
#t
sash[r7rs]> (list-ref (integer->list 6) 2)
#f

which could be resolved if integer->list were little endian.

If you did want to change, I would prefer dropping SRFI 60
compatibility, and make everything little endian.

--
Peter Lane
http://peterlane.info/scheme.html