I generally agree. Make things right rather than dragged by historical baggage.

But this particular case, it would be pretty difficult-to-find bug when two APIs are mixed up. And I feel bits->list etc. are more descriptive, and also consistent to other procedures in this srfi.

On Tue, May 16, 2017 at 6:07 PM, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:

On May 16, 2017 8:49 PM, "Shiro Kawai" <xxxxxx@gmail.com> wrote:
If we redesign it ground-up, having consistent little-endian is the way. But I'm worried on the compatibility issue, given that SLIB and srfi-60 has been around for long time.

Speaking with my editor's hat off, I wonder whether we're too worried about compatibility. While there is some code that depends on SLIB and SRFI 60, let's hope that there's even more future code that depends on SRFI 151.

I'm reminded of the story from the author of Make that I've heard repeated: When asked why he chose to make the difference between space and tab significant in Make files, he responded that once he realized that it was a mistake, he already had ten users, and he didn't want to break their code.