Mark,


I saw the stuff in the bytevectors code where the SRFI-4 u8 vectors and bytevectors are essentially the same but with different flavors. The reader option was to make #u8 make bytectors that are exactly the same as #vu8.

Merging the two types solves the reading problem completely since it doesn't matter how they are made, they will be the same type. But, it does still leave the printing problem since there are still two ways to print them, R6RS and R7RS. And it introduces the issue that SRFI-4 u8 vectors would print as #vu8 in R6RS code. One potential solution to this would be to have two different print functions essentially, an R6RS one and an R7RS one and which one one gets depends on which libraries one imports from (R6RS or R7RS), though I can imagine ugliness that this would cause. It really is kind of a tough problem that R6RS didn't go with #u8 notation but R7RS did.


Freja Nordsiek

On June 21, 2017 3:13:07 AM GMT+02:00, Mark H Weaver <mhw@netris.org> wrote:
>Hi Freja,
>
>Freja Nordsiek <fnordsie@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 <mhw@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