implementing #!identifier in a reader

R6RS introduced #!identifier token which is a kind of meta notation
about the content that follows the token.
#!r6rs can be thought of telling the reader that the following content
is in r6rs syntax.
#!fold-case and #!no-fold-case tell the reader to switch the mode of
reading symbols, until the end of the
input stream or another instance of these token is read. It seems
natural to extend #!identifier to switching
various 'modes' of the reader in general.

However, this mode can't be a local state of 'read' procedure, since
it has to persist beyond a
single S-expression. Keeping the mode in the input port is a
plausible solution, but having
dependency between ports and reader doesn't seem 'clean' to me,
somehow. I'm curious
if somebody comes up a different implementation strategy.

Shiro Kawai wrote:
> #!r6rs can be thought of telling the reader that the
> following content is in r6rs syntax. #!fold-case and
> #!no-fold-case tell the reader to switch the mode of
> reading symbols, until the end of the input stream or
> another instance of these token is read. It seems
> natural to extend #!identifier to switching various
> 'modes' of the reader in general.
>
> However, this mode can't be a local state of 'read'
> procedure, since it has to persist beyond a single
> S-expression. Keeping the mode in the input port is
> a plausible solution, but having dependency between
> ports and reader doesn't seem 'clean' to me, somehow.
> I'm curious if somebody comes up a different
> implementation strategy.

It seems to me that some modes, such as case-folding,
pretty much have to be a property of individual ports;
otherwise you couldn't write programs that read from
two different ports, folding case on one but not the
other.

After you've implemented #!r6rs, #!fold-case, and
#!no-fold-case as properties of individual ports, then
it would be irregular to implement other #!identifier
modes differently.

The get-datum and read procedures would consult the
port-specific mode bits only when the mode is relevant
(as when you've just read a symbol, and you have to
know whether to fold its case).

Will

On 8¤ë20¤é, ¤È«á12:12, William D Clinger <cesur...@yahoo.com> wrote:
> The get-datum and read procedures would consult the
> port-specific mode bits only when the mode is relevant

That's pretty much what I've come up. What bothers me is that
there seems no clean way to write an alternative "read" within
R6RS; I can have a port with extra state using make-custom-*-port,
but no API is provided to access to the state.
(But R6RS isn't meant to cover all possible corners, I guess.
Maybe a srfi might be relevant here.)

Shiro Kawai wrote:
> What bothers me is that
> there seems no clean way to write an alternative "read" within
> R6RS; I can have a port with extra state using make-custom-*-port,
> but no API is provided to access to the state.

If you're implementing both ports and get-datum/read,
there's no problem.

If you're adding an after-market get-datum/read, you
have to implement mode-per-port state with something
like a global hashtable that maps ports to modes.

You'd like for that to be a weak hashtable, but the
R6RS offer no such thing, so the best you can do is
to go through the hashtable every so often to discard
closed ports. A lot of us are guilty of not bothering
to close string ports, so they'd never be removed from
the hashtable, but they're unlikely to be added to the
hashtable in the first place because most string ports
will use the default mode. It isn't ideal, but it's
the best you can do.

Will