Re: packages revisited

Also *read-eval-stream* would be added to my reader.
And one more thing that suggests itself:

read-eval binding for symbols.
This would allow do things like
sql:[ select * from foo ]

if sql:|[| has readtime-function
binding, without using macro characters.

Or even shorter:
select * from foo
where id=4 ; optional comment

There are two ways to implement it.
1. Add a function readtime-function which assignes
reader-time function of two arguments (symbol and a stream).
to a symbol.
2. (more general) allow for a custom token parser.
Custom token parser is associtated with a regexp and
does an evaluation based on its registers.
Thus, instead of assigning read-eval binding per
symbol, one could also assign it to a "class" of symbols.

Say, token from "note" package would
read as a note where optional part after
- is a duration designator.
note:C4.32
note:C4.5/16
note:[ would read a chord, with optional
note:play* is inherited from "music" package
and plays its arguments with optional
numeric duration

in-package :note
play* [C4 E4 G4 1/16] [G3 H3 D4 1/16]
Note that C4, E4, etc symbol names do not denote
real symbols. They are processed by custom
token parser to produce a note object and never
get interned as symbols.

So, it is suggested that custom token parser should
be installed with
set-custom-token-parser (package regexp fn &key priority)

Where fn have a signature like this.
custom-token-parser-fn (package stream &rest registers)

Custom token parser would likely check if symbol is
already interned. This allows note package to
contain symbols with special meanings which
match the regexp. So, note parser could look like this
(defun note-parser (package stream register &rest more-registers)
(let1 sym (find-symbol register package)
(if sym sym
(parse-note-name-and-duration register))))

(set-custom-note-parser :note "(.*)" 'note-parser :priority 2)
(set-custom-note-parser :note "\[" 'read-chord :priority 1)

But there is still a choice. Token parsers are
more flexible, but they're bit harder to use.
Priorities would likely to become messy at some point.

On the other hand, making both token parsers and read-eval
bindings seems to be superflous.

Flame is not welcome. It would be useful to
know about possible pitfalls and prior art.
.