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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
