I second the suggestion to keep order consistent in the name of avoiding bugs.
Neither order is inherently more natural than the other as a consequence of history. English prose is written left-to-right, Arabic numbers are written right-to-left, and source code blends both traditions. It's an evergreen source of confusion.
One option is to have two versions of each offending procedure, e.g. both integer->le-list and integer->be-list, bitwise-fold-le, bitwise-fold-be, etc. This is pragmatic, and makes the programmer's ordering expectations explicit, but also increases the surface area of the SRFI.
Or, we could choose one ordering over the other, knowing it will be awkward for some use cases. When a user needs the other order they'd have to reverse things on their own. Actually that's probably not prohibitively expensive since these bit strings are expected to be short (ordinarily at most 64 bits).
Of the two orders, I think lsb-first is more convenient to the programmer since in lsb-first, the first bit is always index 0, consistent with how indexes work for Scheme lists and vectors. With msb-first the first index is variable, depending on the most significant bit of the integer in question. So lsb-first iteration is implicitly "anchored."
KW
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
To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=g4qkhP7wQv7YRpNF2PegOQ3XgjU718gZ