[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Bytevectors should be called u8vectors
Marc Feeley scripsit:
> I don't think we agree here. It is confusing to have two names for
> the same thing.
Somehow we have managed with both `call-with-current-continuation` and
`call/cc`, though. The latter name is available in Racket*, Gauche,
Gambit, Chicken, Bigloo, Guile*, Kawa, SISC, Chibi**, Chez*, Vicare*,
Larceny*, Ypsilon*, Mosh*, IronScheme*, NexJ, STKlos, KSi, SigScheme,
TinyScheme, Scheme 7, XLisp, XLisp, Rep, Schemik, Elk, UMB, Oaklisp,
Llava, SXM, Sizzle, Spark, Inlab, Owl Lisp. It is not available in MIT,
Scheme48/scsh, SCM, Shoe, Dream, RScheme, BDC, VX, FemtoLisp, Dfsch.
In reference to precise error reporting, the following
Schemes that support `call/cc` return different errors from
`(call-with-current-continuation 32)` and `(call/cc 32)`: Chicken,
Bigloo, Guile***, Chez, Vicare, Ypsilon***, XLisp, Oaklisp***.
[*] Required by R6RS
[**] Required by R7RS-small
[***] Differ only in a hex address for the procedure or opcode
> If it is a coincidence that two names exist for the same function
> (say an identity function in an assertion module, and an identity
> function in a combina tor module, or a particular function in a
> module implemented with and without tr acing) then that is reasonable.
> But here we are talking about two names for functions with the same
> with the same intent on the same data type.
I disagree entirely. In the overall context, one set of functions
picks a binary data type out of a blob and is indexed by byte.
The other set picks an element out of a homogeneous binary vector
view of the same blob. The u8 (as well as s8) versions are degenerately
the same, that's all.
> > 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.
> As I suspected, common practice would favor the SRFI-4 API.
I carelessly omitted Racket from the R6RS list.
> As a double-check I went to googlebattle.com and battled u8vector-ref
> and bytevector-u8-ref and u8vector-ref is 4 times more popular.
Unsurprising, given the relative publications dates of SRFI 4
(1999) and R6RS (2007). As someone said today, the future as well as
the past must be considered.
> A more thorough investigation which examines existing code bases would
> be interesting.
Alas, Google Code Search is no more.
> >> 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. And yet the R6RS editors chose to use "bytevector" as well as
providing those selfsame operations.
Verbogeny is one of the pleasurettes John Cowan <cowan@x>
of a creatific thinkerizer. http://www.ccil.org/~cowan
--Peter da Silva
Scheme-reports mailing list