LispReader

[Per Bothner]

Nic Ferrier wrote:
> At first glance I was affraid that the InPort might be adding logic
> to the stream and carrying some state in readState.

It's only used for prompting.

> I understand that it could be set on a props table for the object,
> but what I'm not sure about is why readState can't be a member of
> LispReader?

It would, but the prompter procederw is called by the port, not the
lexer, so you'd need a way to find the current lexer.  So that means
making the current lexer be a property associated with the port, so
we're back to needing a property mechanism for ports.  A possible
alternative is to make either the "state" or the "lexer" be fluid
(or thread--local) variables, and you'd be able to find them via the
current thread,  Either way we want to be careful to avoid unneeded
package dependences.  For example gnu.text is not allowed to depend
on gnu.mapping or gnu.expr, but gnu.kawa.lispexpr depends on all three.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/