Re: accessing reader hash

[Jim Blandy]

> but `get-hash-procedure' is declared C static.  i was thinking...
> instead of exposing this proc, maybe we could have `read-hash-extend'
> return the current associated procedure (or #f if none).  at the moment
> its return value is unspecified.

Clearly, there should be ways to read the current hash table as well
as write it.

I think it's cleaner to expose a new procedure than to overload an
existing procedure with get/set functions.  While get/set functions
work well in certain limited contexts (I think dynamic-wind is one of
them), they're pretty clumsy in most.

Popping up a level, is your macro intended to allow people to define
local hash syntax, used like this?

        (understanding-c #\&
          (... some body in which we use &foo syntax ...))

If that's your intended application, it won't work.  The s-expression
has been read in, and all hash syntax interpreted, long before Scheme
macros get expanded.  (Sorry if this is obvious, and you had some other
use in mind.)

If you want local read macros, you're going to have to work out how
they interact with the parser, which I think is going to be
complicated.  Paul Wilson's group tried stuff like this, I think.
Perhaps they published some helpful papers.

> what do you think?  what other ways of localizing reader functionality
> exist that i'm missing?  why is reader extension a global issue in the
> first place -- does that make sense in light of lexical scoping?  what
> are the proposed reader semantics for the module system?

Reader macros are not exactly clean, exactly because they are
oblivious to lexical scoping.

However, we could certainly improve things.  For example, you could
certainly scope them on file boundaries, or top-level expression
boundaries.  But at the moment, it's just a global table.