[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] r7rs-wip branch: Add reader and print options to support R7R
Mark H Weaver
Re: [PATCH] r7rs-wip branch: Add reader and print options to support R7RS bytevector syntax.
Tue, 20 Jun 2017 22:11:16 -0400
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Freja Nordsiek <address@hidden> 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.