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

[Mark H Weaver <mhw@netris.org>]

Hi Freja,

Freja Nordsiek <fnordsie@gmail.com> writes:

> 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

It's true that we could implement something like this, and it might even
be the best approach among the available options, none of which are
pleasant.  It would be rather gross to implement though :-(

> but that would fail the moment a script imports libraries
> both from r6rs and r7rs, or if one doesn't import anything.

In R6RS and R7RS, importing nothing is not an option.  Both of those
standards explicitly require that *every* program begin with at least
one 'import' form, which is needed anyway because in those languages,
there are no bindings at all, not even core syntax, until they are
imported.

Both of those languages include base libraries that must be imported
explicitly: R6RS has (rnrs base), and R7RS has (scheme base).  In
principle, a program might not import either of them, but rather some
other library that exports a different set of core bindings, but in
practice I suspect that's exceptionally rare.  So, for programs we could
make the decision based on which base library is imported.

For libraries it is easy to reliably detect R6RS or R7RS, based on
whether (library ...) or (define-library ...) is found.

If the first datum in a file or stream is not (import ...),
(library ...), or (define-library ...), then we can reliably conclude
that the file is not valid R6RS or R7RS code.

The reason this would be gross to implement is that the auto-detection
logic would have to be integrated in the reader itself.  The reader
reads an entire datum at a time, but R6RS and R7RS libraries are fully
contained in only one datum.  So, at least for libraries, the reader
would have to be called with some kind of "auto-library-detect" flag,
and would need to switch its own reader options in the middle of reading
the datum.

Thoughts?

      Mark