On 2012-07-03, at 3:49 AM, John Cowan wrote:

> Marc Feeley scripsit:
>
>> John, given that you have many Scheme implementations installed, can
>> you test how many currently support u8vector-ref and how many support
>> bytevector-u8-ref ?
>
> Not without considerable pain.  There is no invocation to bring in SRFI
> 4 that works on even a majority of Schemes, so I would have to look up
> the docs for each one, and there are currently 45 of them.

I would expect such an important question to merit a thorough analysis of current practice, but I understand that it may be too much work for you at this point.  Have you thought about polling the Scheme implementors?

When this issue was discussed and voted on by WG1, was there an analysis (possibly informal) of current practice?  Perhaps just an analysis of the major implementations?  If so, which implementations does WG1 know of which support u8vectors and which implementations support bytevector-u8-ref ?

>  What's more,
> it's trivial to implement SRFI 4 on top of R6RS bytevectors or vice versa.

I fail to see the relevance of this argument.  R7RS bytevectors can be implemented with u8vectors just as easily as implementing u8vectors with R7RS bytevectors.

> What's more, it's straightforward to support either on top of pure R5RS
> vectors, modulo the type predicates.

In a low-performance Scheme system it may be straightforward, but bytevectors exist for performance reasons (otherwise plain vectors would be adequate).  It is less straightforward in a high-performance Scheme system where primitives are inlined, constant-folded, optimized, etc.  There is also the problem of precise error reporting.  It would be suboptimal when evaluating the user code (u8vector-ref x -5) to give the error message "*** ERROR in bytevector-u8-ref -- index out of bounds".  Precise error reporting implies that the difference between the user code (u8vector-ref x y) and (bytevector-u8-ref x y) must be preserved all the way until run time.  This causes bloat in the system if both APIs are supported.

I have a feeling that the use of "bytevector" in the names of procedures in R7RS small is due to WG2 concerns of extending the set of operations on bytevectors to 16, 32, etc bit width access operations.  Alaric Snell-Pym and others have pointed out that "blob" is a better name for such a data type.  I am not saying I prefer it, but perhaps that's the name WG2 and the community will prefer for that data type.  So committing to the name "bytevector" in R7RS small is premature.  On the other hand, you say that in your WG2 bytevector proposal, you were proposing to support u8vectors and the other SRFI-4 names.  So I don't see your position of prefering to standardize in R7RS small the "bytevector" names instead of the "u8vector" names.

It seems to me the only arguments that remain are current practice and bloat (which are of course related).

Marc

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