SRFI 33, 60, 151: bitwise operations on integers

[lassik]

• SRFI 151: Bitwise Operations (2017)
  https://srfi.schemers.org/srfi-151/srfi-151.htm
• SRFI 60: Integers as Bits (2005)
  https://srfi.schemers.org/srfi-60/srfi-60.html
• SRFI 33: Integer Bitwise-operation Library (2003, withdrawn)
  https://srfi.schemers.org/srfi-33/srfi-33.html

[lassik]

I'll implement 151. It's planned to be part of R7RS-large.

[feeley]

Will you also tackle SRFI 121 (Generators) that is used by SRFI 151?

To simplify your work I can implement the following natively: bitwise-eqv, bitwise-nand, bitwise-nor, bitwise-andc1, bitwise-andc2, bitwise-orc1, and bitwise-orc2 .

[lassik]

Will you also tackle SRFI 121 (Generators) that is used by SRFI 151?

121 has been withdrawn in favor of 158 (Generators and Accumulators). Personally, I love these abstractions and think 158 is definitely worth having. If 158 is a compatible superset of 121, I guess it doesn't hurt to have both. However, if there isn't much existing Scheme code depending on 121, it may be best to encourage everyone to switch to 158.

To simplify your work I can implement the following natively: bitwise-eqv, bitwise-nand, bitwise-nor, bitwise-andc1, bitwise-andc2, bitwise-orc1, and bitwise-orc2 .

Awesome! That would be much appreciated.

[lassik]

Aha, seems this bitwise SRFI (151) only refers to 121 by returning a generator from one procedure. No special support for 121 or 158 is needed to return a generator - it's just a closure taking no arguments and returning some objects followed by end-of-file, like read.

Anyway, 158 would be nice to have more generally since it has convenient higher-order functions for working with generators.

[lassik]

Would it be worth supporting all the hash-table SRFIs and all the bitwise SRFIs in the next Gambit release? There are not many of them, and they can all share the same internals.

[lassik]

We could probably implement large parts of the bitwise SRFIs by simply re-exporting identifiers from Gambit's core. Does Gambit currently support (only ...) and (rename ...) inside define-library import clauses, and can ## identifiers be imported in this way? Can we re-export from the (gambit) library?