Freja Nordsiek <fnord...@gmail.com> writes:
> 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.
Right. If it turns out that merging the VU8 and U8 element types for
bytevectors is problematic, this is probably the next best option,
combined with the auto-detection idea discussed in the other branch of
this thread.
> 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.
Yeah, I find it uncomfortable, but it may be that having different
top-level 'write' procedures for each language variant is the best
available approach. Unlike 'read', auto-detection is not an option
here.
At this point, I'm desperately seeking ways to avoid setting global
reader/printer options. That approach seems likely to lead to bad
consequences in a world where programs are composed of a mixture of
R6RS, R7RS and native Guile code. I sometimes wonder if we should
deprecate global reader options.
Mark
