Re: [Scheme-reports] Bytevectors should be called u8vectors

[John Cowan <cowan@x>]

Marc Feeley scripsit:

> I would expect such an important question [as what implementations
> support bytevector-u8-ref vs. u8vector-ref] to merit a thorough analysis
> of current practice,

In fact I do not believe that it does.  In a library-based world,
it is not so essential to be careful to either use or avoid the names
provided by implementations.  It is perfectly reasonable for one name
to be available in one library and another name for the same thing in
another, all within the same implementation.

For example, WG1 decided to adopt the R6RS names `exact` and `inexact`
on the grounds that the R5RS versions are actively misleading:
`inexact->exact' implies that the argument must be inexact, but this
has never been true.  Nonetheless, the R5RS names are still available
through the R5RS compatibility library, which unlike its R6RS analogue
exports all the R5RS names (except `transcript-{on,off}`).

> 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 ?

Both the WG and I have avoided trying to specify which implementations are
"major" and which are not:  I have instead presented facts about the
implementations that I know about, and leave it up to the readers to decide
which ones matter to them and which do not.  Anyway, here's what I know about what
implementations *claim* to provide:

SRFI 4: Racket, Gauche, Gambit, Chicken, Bigloo, Guile, Kawa, Scheme48,
STklos, RScheme.  This information is probably out of date.

R6RS: Guile, Chez, Vicare, Larceny, Ypsilon, Mosh.

> 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.

These considerations go far beyond the remit of any Scheme standard.
> 
> 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 agree that it's better, but the WG voted otherwise.

> I am not saying I prefer it, but perhaps
> that's the name WG2 and the community will prefer for that data type.

It's unlikely in the extreme, given the mandate for full compatibility.

> 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.

Please don't conflate my personal position with the WG's decisions.

-- 
John Cowan   http://ccil.org/~cowan  cowan@x
[P]olice in many lands are now complaining that local arrestees are insisting
on having their Miranda rights read to them, just like perps in American TV
cop shows.  When it's explained to them that they are in a different country,
where those rights do not exist, they become outraged.  --Neal Stephenson

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