On Thu, Jul 19, 2012 at 7:45 AM, Marc Feeley <feeley@iro.umontreal.ca> wrote:
> On 2012-07-18, at 6:20 PM, will@ccs.neu.edu wrote:
>
>> On Sun Jul 15 16:15:18 EDT 2012, Andy Wingo wrote:
>>
>>>>> Just as another data point, I've used and implemented both APIs.  I find
>>>>> the bytevector formulation more useful.  (Incidentally, the assertion
>>>>> that the "bytevector" name is without history is incorrect.)
>>>>
>>>> Fill us in on this, please?
>>>
>>> R6RS.
>>
>> Actually, the bytevector name and basic API date back to 1984 or 1985.
>> Bytevectors were provided by MacScheme (1985), and I believe they were
>> provided by PC Scheme (1984) as well.
>>
>> Will
>
> I want to point out that I was saying the proposed *API* for bytevectors has little history, i.e. bytevector-u8-ref, etc. The important point is that the u8vector API, where bytevectors are seen as a vector of bytes (as the name implies), has been widely implemented and there is lots of existing code and Scheme implementations (and 2 SRFIs) which use that API.
>
> Why should R7RS specify a less widely used API when the bytevector operations it defines are strictly those of a vector of bytes?

Note we plan to provide a separate rationale document, which
I realize now should have been offered along with the draft.
I'll try to make this a higher priority.

What we actually voted on was: http://trac.sacrideo.us/wg/wiki/BlobAPI
which is similar to R6RS but encodes the endianness in the
names for brevity and efficiency.  This was a WG2 proposal,
and the WG1 version of this was just the *-u8-* subset.
WG2 is not required to accept our recommendation, but
it is likely to if for no other reason than most of the members
are the same, and WG1 is bound to WG2 compatibility.

The original name was "blob", but many comments in the
vote suggested they liked the API but were unhappy with
the name.  A separate vote to clarify the name resulted
in "bytevector", which seemed natural since the WG1
subset was purely compatible with R6RS, even though the
WG2 API will differ slightly.

We are stuck in the unfortunate position that any
name we choose will make someone unhappy.

> If compatibility with R6RS is so important, why is the bytevector external representation not the same?  I.e. #vu8(...) .  It seems like the R7RS bytevectors are neither here nor there.

The decision here was based on the fact that names
are much easier to change than the reader now that
we have libraries, and that while we preferred the
R6RS-style API there was just too much existing
reader support for #u8(...).

Personally, I was baffled by the R6RS decision to
include the "v" prefix.  Given a SRFI-4-style API it
makes sense to use a single common prefix like "v"
since you otherwise need to take up too many
characters for #u8, #s16, #f32, #c64, etc.  Given
an R6RS-style API there's only one blob type and
this isn't needed.  The syntax change here just
seemed gratuitous.

--
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports