[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[scheme-reports-wg1] Re: [Scheme-reports] No (bytevector n ...) ?
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
>> This seems to be a oversight - we actually use `bytevector'
>> in a number of the examples. I'll bring this up with the
> 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
> 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 ...).