Re: [PATCH] r7rs-wip branch: Add reader and print options to support R7RS bytevector syntax.

[Freja Nordsiek]

Mark,

Hmm, well, I have thought of one way to implement this. If the main underlying write/print function took an extra-keyword option that said which syntax to print bytevectors/u8vectors in (would be best to use symbols 'r6rs and 'r7rs so as to not program ourselves into a corner with regards to future changes to Scheme) with the display and write functions in the R6RS and R7RS modules using setting the option to 'r6rs and 'r7rs respectively. Only tricky thing here is to decide the default in the base (guile) module. If bytevectors and u8vectors are unified, some level of backwards compatability will be broken with 2.2 and 2.0 since either u8vectors would get printed as #vu8 or bytevectors will get printed as #u8. If the types are not unified, backwards compatability is maintained but then using R7RS and SRFI-4 simultaneously becomes difficult unless we move the R7RS modules entirely over to using SRFI-4 u8vectors. Moving R7RS over to SRFI-4 u8vectors entirely them means we have two different kinds of bytevectors, R6RS and R7RS kinds, and the procedures from each set would have to only produce their respective kind and in some way handle when given the other kind of bytevector (ones that set them probably shouldn't change the type but for ones that return copies, it is hard to say which option is best).

It seems like none of these options are good.

Unifying the types and just having the display/write procedures be different poses some backwards compatibility issues and that when mixing SRFI-4 and R6RS together, things will get messy.

Making R7RS use SRFI-4 u8vectors as its bytevectors means that a lot more work needs to be done with R7RS's bytevector related functions to make them produce the right type and figure out how to handle cases when R6RS and R7RS bytevectors get mixed together as well as deal with making sure that these R7RS bytevectors behave reasonably with existing bytevector related functions (a lot of this has already been done with u8vectors since SRFI-4 has been in Guile quite a while).

I think that both of these options are better than my original proposal, which was reader and print options.

Freja

On Wed, Jun 21, 2017 at 5:58 PM, Mark H Weaver <address@hidden> wrote:

Freja Nordsiek <address@hidden> 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