[scheme-reports-wg1] Re: [Scheme-reports] No (bytevector n ...) ?

[Alex Shinn <alexshinn@x>]

Following up only on the members list.

On Sun, Sep 2, 2012 at 2:46 AM, John Cowan <cowan@x> wrote:
> Alex Shinn scripsit:
>
> On Sat, Sep 1, 2012 at 3:54 PM, Christian Stigen Larsen
> <csl@x> wrote:
>>
>> is there no procedure to create bytevectors beyond using the reader syntax
>> #u8(n ...).  Will there be a (bytevector n ...) constructor in the final
>> R7RS?
>
>> This seems to be a oversight - we actually use `bytevector'
>> in a number of the examples.  I'll bring this up with the
>> members.
>
> The oversight was using it in the examples.  Version 4 of BlobAPI, which
> is what we voted for in the first and second ballots, contained this
> wording:
>
>     Because there is no preferred way to interpret the data in a blob,
>     there is no `blob` function analogous to `list` or `vector` and no
>     second argument to `make-blob`.
>
> However, when we overrode the second part in the third ballot (ticket #215)
> and added a second optional argument to `make-blob` (now `make-bytevector`),
> we didn't reconsider the first part.

I remember this now, and it seemed to make sense
at the time, but I think it was still inconsistent regardless
of the fill argument to make-blob.

Granted, the data type of a blob is ambiguous, but
for WG1 we are providing an otherwise complete u8
oriented API.  Thus to match blob-u8-ref and the
#u8(...) syntax we should have provided (blob-u8 ...).
After the renaming to R6RS compatibility this
becomes (bytevector ...).

-- 
Alex