On 2020-10-13 15:34 -0400, John Cowan wrote:
> On Tue, Oct 13, 2020 at 2:35 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
> wrote:
>
> > (1) We should clarify the meaning of bytestring->list's start/end
> > arguments.  I've assumed that start is inclusive, end exclusive, as
> > per usual.
>
> I take that for granted in all SRFIs.  It is formally specified in R7RS
> section 1.3.3 and explicitly in many older SRFIs.

Oops, I didn't notice that.  No change needed, then.

> > (2) Several (non-mutating) procedures have cases in which they might
> > return a bytevector with the same contents of one of their bytevector
> > arguments.  Should the result always be newly allocated?
>
> I would say no, that if there is doubt whether a newly allocated result is
> required, the text will say "newly allocated" (or in some cases "fresh" or
> "freshly allocated") if it is.

That rationale makes sense to me, but I wonder about possible
surprises resulting from these semantics.

I've followed the SRFI 13 sample implementation and returned the
original bytevector whenever possible.  This shortcutting means that,
for example, the bytevector elements of the list returned by
bytestring-break or -span are *usually* newly-allocated.  If you want
to mutate them safely, you'll have to check the length of the list
returned by bytestring-break.  Similar observations apply to the pad
and trim procedures.

> > (There's also a weird possible implementation of bytestring->list that
> > raises the same issue: it's perfectly valid for (bytestring->list bvec)
> > to return (list bvec).  But this seems like a weird corner case to me.)
> >
>
> Degenerate implementations are for degenerates.  :-)  But it does make me
> wonder if the result shouldn't be specified more precisely as a list of
> ASCII printable characters and/or exact integers.  I think that is the most
> useful case, and have added it (in a separate commit in case it is
> controversial).

OK, I'll make the necessary implementation change shortly, as the
current version just converts everything to integers.

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

"Industry has surrounded people with artifacts whose inner workings
only specialists are allowed to understand." --Ivan Illich