[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Resuming SRFI-33 discussion

This page is part of the web mail archives of SRFI 33 from before July 7th, 2015. The new archives for SRFI 33 contain all messages, not just those from before July 7th, 2015.

I have gone over all unresolved issues from the old discussions.
Below, the resolutions. I will send the current draft in a following
message; Francisco can install it in the right place at his convenience.

  - NAND & NOR are no longer n-ary. Only associative ops are.
  - Sticking with SIZE/POSITION field specs over FROM/TO.
  - Staying with "op-curry" convention for param order.
  - ANY/ALL lexemes switched to more standard/more-parallel ANY/EVERY for
  - New pair of complementary functions
    replaces unbalanced TEST-BIT-FIELD?.
  - "BIT-FIELD" lexeme consistently moved to front of name for
    (Is everyone agreeable to this?)

    From: Bengt Kleberg <eleberg@xxxxxxxxxxxxxxx>

    i have no objection to the functionality/set of operations offered by
    the "Integer Bitwise-operation Library" by Olin Shivers. instead i
    would like to change function names and argument order to make them
    slightly more reminiscent of the string and vector operations.

    1 would it be possible to change
      arithmetic-shift i count -> exact-integer
      bit-shift-left i count -> exact-integer
      bit-shift-right i count -> exact-integer

This doesn't seem sufficiently compelling to warrant further stewing around.
I'm going to leave things with the traditional "arithmetic shift"

    2 would it be possible to change
      bit-set? index i -> boolean
      any-bits-set? test-bits i -> boolean
      all-bits-set? test-bits i -> boolean
      first-set-bit i -> exact-integer
      bit-set? i index -> boolean
      bit-set-any? i test-bits -> boolean
      bit-set-all? i test-bits -> boolean
      bit-set-smallest i -> exact-integer

No, I think this would be a bad idea, since the convention to which you are
suggesting we hew is one that implies we are thus operating on a
data-structure called a "bit set." But we aren't. Sets of bits are a pretty
boring data structure -- there are only four such sets! Rather, we are
checking to see if any bits in a bit string are set.

    3 would it be possible to change
      extract-bit-field size position i -> exact-integer
      test-bit-field?   size position i -> boolean
      clear-bit-field   size position i -> exact-integer
      replace-bit-field size position new-field i -> exact-integer
      copy-bit-field    size position from to     -> exact-integer
      bit-field-extract i size position -> exact-integer
      bit-field-test?   i size position -> boolean
      bit-field-clear   i size position -> exact-integer
      bit-field-replace i size position new-field -> exact-integer
      bit-field-copy   from to size position     -> exact-integer

Your param order issue is the "op-currying" vs. "data-structure accessor"
parameter convention. See below.

Your names seem more in tune with Scheme conventions, so I am converting to
them. If people don't like this, speak up.

    4 i have been unable to find a better name for
      integer-length i -> nonnegative-exact-integer
    but would really like to have a 'bit' prefix here too.

Nothing leaps to mind for me, either. It is the traditional name.
It works fine. 

- Are NAND & NOR n-ary?
  I am frankly somewhat divided on this issue.
  Given that Al Petrofsky now supports going with the simple
  associative-ops-are-the-n-ary-ops design heuristic, I have 
  gone with this. I don't think it's a big deal, either way.

  I have also just noticed that this split is precisely what
  Common Lisp does.

  I went with SIZE/POSITION. Here is the rationale from the SRFI.

  SIZE/POSITION vs. FROM/TO field specs
  Several functions in this library
      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
  specify a contiguous "field" of bits in a bitstring. There are two
  conventions we might use to do so: 

      E.g., "the 8-bit field beginning at bit 3", and

    - FROM/TO 
      E.g., "the field from bit 3 up to, but not including, bit 11", or, perhaps,
            "the field from bit 3 up to bit 10, inclusive."

  FROM/TO specs are conventionally and most usefully "half-open" specs, meaning
  "all i such that FROM <= i and i < TO" -- the FROM index is included and the
  TO index is excluded.

  I have chosen to use SIZE/POSITION instead of FROM/TO for this library.
  Doing so eliminates any possibility of fencepost errors on the TO endpoint.
  It is also the convention chosen by Common Lisp.

  It is not, however, a widely-used convention within Scheme. Most ranges
  in Scheme are specified with half-open intervals of the [from,to) form
  (e.g., (substring s from to)). One might argue that SIZE/POSITION is still
  the right thing for bit fields, as they are, in practice, frequently of fixed
  size, unlike element ranges in strings or vectors.

- ANY/ALL lexemes -> standard ANY/EVERY lexemes
  I have noticed that the ANY-BITS-SET? / ALL-BITS-SET? pair of functions
  do not follow the Scheme naming convention of using ANY and EVERY.
  Also, ALL is a word that pairs with SOME; ANY pairs with EVERY.
  So I have renamed them:
  Notice the "bit-set" lexem is now consistently singular, which is
  both more consistent with other names and grammatically correct.

  TEST-BIT-FIELD tests for *any* bit in the field being set; it should be 
  complemented with a function to test for *all* bits in the field being
  set. So I have replaced it with the pair of functions
  Note that you can also check for any/every bit in the field being clear,
  as well, by negating these functions.

  This name choice is also closer to Bengt's preferred choices.