Since it was just a matter of removing things, I've changed both the SRFI and the code to remove all references to bitvector/bytevector conversions.  Of course the code will still be in git waiting to be resurrected.

I'm good to go for finalization.  Arthur, can you do your stuff?  (It'll be nice to get one more off my plate.)


On Sun, Aug 23, 2020 at 11:40 AM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
On 2020-08-22 20:37 +0200, Marc Nieper-Wißkirchen wrote:
> John Cowan <xxxxxx@ccil.org> schrieb am Sa., 22. Aug. 2020, 19:40:
> > As Marc pointed out, these would have to be called /be and /le or the
> > like.  I'm inclined to pull them out altogether, since they are not really
> > related to anything else, and put them somewhere else, perhaps named
> > pack-bits/be, pack-bits/le, unpack-bits/be, and unpack-bits/le, and able to
> > handle integers as well as bitvectors.
> >
>
> Okay. Some bytevector API for these low-level things makes sense.

Does this mean that we want to remove the (BE) bytevector conversions
currently in SRFI 178?

> > Well, not quite for that reason.  Using -1 for failure from
> > bitvector-first-bit is compatible with the integer equivalent first-set-bit
> > as defined by SRFIs 33, 60, R6RS, and 151.  I think that is determinative.
> >
>
> I didn't review those in detail. I agree that it does not make sense to
> change it to a more sensible value just here.

Thanks.  I agree.

Everything seems to be ready, otherwise.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"... if I found the right chair to work in, all compositional
problems would become nonexistant." --Morton Feldman