>> And if an output port knows its settings, we can have a
>> `write-port-settings` (better name welcome) procedure that writes the
>> corresponding #! directives to the output port. Then you can easily
>> write files that self-describe what syntax they are using.
>
> To mimic the behavior of "read", I wouldn't add a procedure that
> writes the directives explicitly but would rule that it is the
> responsibility of the "write" procedure to output these directives
> whenever it observes a change in the current flags.

That brings us to a related topic: custom implementations of `write` for
user-defined data types, i.e. a Scheme procedure that is called with a
port and an object of that type, and writes a representation of the
object to the port. Similar to `print-object` in Common Lisp
(http://www.lispworks.com/documentation/HyperSpec/Body/f_pr_obj.htm).

If we let users install such procedures, those procedures can call
`write` recursively. If the port settings have changed in the meantime,
the new #! directives would be written in a nested part of a top-level
S-expression :) That probably even makes sense, as long as proper
closing of parentheses and string quotes is followed.

> That's a good point. "Textual" could also appear in the name of such
> setter. I would propose to have a general mechanism, which rules that
> each textual port has a dictionary (an alist?) mapping symbols to
> datums (mostly #t or #f). Read and write have to be aware of these
> settings (and we need a "#!" syntax for settings with non-boolean
> values, e.g. number precision or default base). SRFIs like SRFI 207
> could then hook into this general API.

Textual ports can also have settings that are not directly related to
Scheme syntax, e.g. character encoding and whether or not to do line
buffering. For maximum clarity and symmetry with the available #!
directives, it could be best to keep the settings affecting Scheme
syntax in a wholly separate list.

Giving arguments to #! directives will be an interesting discussion that
will probably polarize opinions :) We explored it some time last year
and invented `#!(precision n)` vs `#!precision n`. In any case, the `n`
part has to be an S-expression. So if we represent all the enabled
syntax settings as a list on the Scheme side, any S-expression can be a
member of that list. Perhaps something like:

 > (port-syntax (current-input-port))
'(case-fold)

 > (set-port-syntax! (current-input-port) '(precision 25))
'(case-fold (precision 25))

 > (set-port-syntax! (current-input-port) 'no-case-fold)
'((precision 25))   ; no-case-fold is the default so it's not present