Hi Freja,
Freja Nordsiek <fnord...@gmail.com> writes:
> Was fiddling around with using Chibi's R7RS test-suite in Guile and
> found a major R7RS syntax feature currently missing from Guile. The
> feature is R7RS bytevector notation, which uses the #u8 prefix like
> SRFI-4 unsigned 8-bit integer vectors instead of the R6RS prefix #vu8.
This is mostly not an issue, because in Guile, SRFI-4 vectors are
actually just bytevectors. All of the bytevector operations work on
them, and 'bytevector?' returns true for them. So, I expect that the
overwhelming majority of R7RS code will work.
To support this, Guile's bytevectors include an additional field called
the "element type", which tells what kind of elements are in the
bytevector, e.g. SCM_ARRAY_ELEMENT_TYPE_U8, SCM_ARRAY_ELEMENT_TYPE_F64,
etc. See srfi-4.[ch] and bytevectors.[ch].
The only remaining issue is that, for some reason which I don't recall,
we have distinct element types for plain bytevectors (as produced by our
bytevector operations, and by reading #vu8(...)) and SRFI-4 unsigned
8-bit vectors (from reading #u8(...)), despite the fact that the
elements are actually the same type. In the C code, they are:
SCM_ARRAY_ELEMENT_TYPE_VU8
SCM_ARRAY_ELEMENT_TYPE_U8
This affects how bytevectors are printed, and it also affects equality
testing on bytevectors:
(bytevector=? #u8(1 2 3) #vu8(1 2 3))
=> #f
My preliminary attempt to mitigate this issue in 'r7rs-wip' was:
commit 84aebcaecb78ac87b0039451becf9623e3ddcce4
Author: Mark H Weaver <m...@netris.org>
Date: Sun Jan 12 04:44:39 2014 -0500
bytevector=?: #vu8(1 2 3) is equal to #u8(1 2 3).
* libguile/bytevectors.c (scm_bytevector_eq_p): Treat VU8 and U8 element
types as equivalent.
but I'm not sure it's the right solution. This alone will still result
in R7RS code ending up with a mixture of U8 and VU8 bytevectors: the
former for bytevector literals, and the latter as the results of other
bytevector constructors.
Perhaps the more obvious solution would be to completely eliminate the
distinction between SRFI-4 u8 vectors and normal bytevectors by merging
their element types, but there may be problems with that idea as well.
Andy Wingo wrote the bytevector and SRFI-4 implementations in Guile. I
remember talking to him about this issue several years ago, and I seem
to recall that he didn't like the idea of merging the element types, but
I don't remember his rationale. In any case, we should not proceed
without his input.
Andy, what do you think?
Regards,
Mark
