> I like the idea of allowing arbitrary s-exps following "#!" (i.e.
> "#!(precision 25)" instead of "#!precision=25") so that "#!" can be
> parsed as datum comments "#;".

Glad to hear that :)

> Note that Scheme ports are stateful. Directives like "#!fold-case"
> change the port's state for subsequent read (and principally also for
> write) operations. If something like "#!(encoding ...)" is ever
> standardized it should change the state of the port as well and should
> affect not only "read" but also "read-char", "write-char", etc.

True. Most likely an #!(encoding ...) would be too clever for our own
good :) The purpose of any in-file encoding tag is to give the encoding
for the whole file so the file can then be re-read from the start with
that encoding. That's conceptually different from "read after this point
using encoding X". In particular, mixing #!(encoding ...) with
ASCII-incompatible encodings like UTF-16 would have weird semantics.

> Independently of the encoding question, we should have another SRFI
> that specifies how the Scheme reader handles "#!" directives.

Agreed.

> I am thinking of a parameter object bound to a procedure that is called
> with the port and the s-exp following the "#!" directive whenever the
> reader encounters a "#!" directive. The procedure should be able to
> tail-call a success or a failure procedure. On such a SRFI, we can
> portably build many reader extensions.

That would be simple and generic, but we should probably also have a
standard way to dispatch on the symbol in the #!(symbol ...) form. It
could be some kind of symbol->procedure mapping, or we could have a
chain of #! handler procedures and a handler could defer to the next
handler in case it doesn't recognize the form.

If it ever makes sense to have more than one directive combined into one
#!(...) form then we will need a syntax like this:

     #!((thing1 value1) (thing2 value2) (thing3 value3))

Or something like this:

     #!(many-things (thing1 value1) (thing2 value2) (thing3 value3))

It seems weird and excessive now, but maybe not in the future.

> This SRFI should also expose a
> way to inspect and modify the state of ports (in particular whether
> case-folding is enabled, but also being able to access column and row
> counters makes sense).

No opinion on this one. It sounds reasonable.

Based on this whole discussion, we could have all of these SRFIs:

- Extensible #!(list ...) read syntax
- Float precision as #!(precision ...)
- Extensible (declare-file ...) and/or #!(declare-file ...) form
- In-file encoding tag (no unproblematic approach found so far)
- Unicode lambda

Quite a lot for one thread :D