Hi Marc,

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

If you are going to have one data type for blobs, the bytevector API is
pretty OK.  Often one finds oneself dealing with heterogeneous data --
not uniform vectors, bytevectors.  The SRFI-4 API does provide for
aliasing a u8vector to an s8vector, and so the more explicit bytevector
API is more fundamental.

Also, bytevectors are not simply for performance.  If you are packing
network frames, sure speed is important, but the simple semantic ability
to address (sequences of) bytes, possibly in different byte orders, is
more important.  The whole system hangs together better when built on
bytevectors.

SRFI-4 uniform vectors have their uses.  The ability to address
multi-byte elements by index is handy.  But they are not fundamental
like a bytevector type can be.

Finally, I note that "name bloat" is not an issue for R7RS systems,
which have libraries precisely to allow the user to choose the names she
likes.

Regards,

Andy
--
http://wingolog.org/

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