Mark,


That is a good point about the global effect of the reader and print options. I saw that ports can have their own separate reader options. Wondering i f there is a good way to set it on a per file basis without using a #!r7rs line. It is easier with libraries where if the r7rs syntax is used, the switches could be flipped (and the r6rs ones for the r6rs library syntax). But this means a default has to be chosen for guile style library declarations and chosing for scripts would be really ugly. In principle, it could be based on what is imported but that would fail the moment a script imports libraries both from r6rs and r7rs, or if one doesn't import anything.


Freja Nordsiek

On June 21, 2017 4:11:16 AM GMT+02:00, Mark H Weaver <mhw@netris.org> wrote:
>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.
>>
>> I wrote a patch for the r7rs-wip branch (attached) to add and
>> implement reader and print options to enable the use of R7RS
>> bytevector syntax, as well as add unit tests for the options and
>> update the documentation. I made a boolean option for both named
>> 'r7rs-bytevectors to enable the R7RS syntax (default is #f). They
>> syntax options are enabled with
>>
>> (read-enable 'r7rs-bytevectors)
>> (print-enable 'r7rs-bytevectors)
>>
>> Turning this syntax option on does mean that SRFI-4 unsigned 8-bit
>> integer vectors cannot be created with the #u8 prefix and that they
>> cannot be distinguished from bytevectors when printed with write or
>> display. The patch adds warnings about this in the Bytevectors and
>> SRFI-4 sections of the documentation.
>
>To supplement my earlier reply, I suppose I should explain why I would
>prefer to merge the #u8 and #vu8 bytevectors into a single type, or
>somehow render the differences negligible, instead of adding these read
>and print options as you suggest.
>
>The main reason is that the reader and printer are global facilities in
>Guile, whereas in general programs will be composed of a mixture of
>R6RS, R7RS, and native Guile code.
>
>Adding (read-enable 'r7rs-bytevectors) to the top of a source file is
>not a good approach, because it sets the read option for the remainder
>of the Guile session, and thus will affect the way future files are
>read, even if they do not contain R7RS code.  Also, there's no
>guarantee
>that (read-enable 'r7rs-bytevectors) will be evaluated before the rest
>of the file is read.
>
>One thing that we could do instead is to add a #!r7rs reader directive
>for use at the top of source files.  See 'scm_read_shebang' in read.c,
>which supports #!r6rs and other reader directives.  This would be
>guaranteed to affect the way subsequent datums are read, but only on
>that particular port.  I suppose it would be good to add this,
>regardless of how we handle the issue with literal bytevectors.
>
>However, it should be noted that unlike R6RS, which explicitly includes
>#!r6rs in its formal syntax and specifies its meaning, the R7RS formal
>syntax does not even allow for #!r7rs, so a compliant R7RS
>implementation may reject a file that contains it.  So, it would be
>good
>to avoid relying on this.
>
>By reusing the SRFI-4 syntax for its bytevectors, R7RS effectively
>requires that its implementations will treat SRFI-4 U8 vectors as
>equivalent to bytevectors.  If there's no compelling reason to avoid
>this, I think we should do it.
>
>       Mark