> No, you can't use Scheme's `read` because it would sometimes interpret
> the text incorrectly (as shown by my emacs local variable example) or it
> would produce an error for unparsable datum comments, which can
> nevertheless be valid in their native DSL syntax.

We are pursuing different goals. I think generality is a mistake in this
case, and restricting the directives to those that can be represented as
Scheme datums is desirable.

And way to encode language-agnostic data in source files is going to end
up as a mess, due to the great variety of host language syntaxes you
have to accommodate, unless you stick to really simple stuff. I went
through the archive of magic comment samples I have, and once you get
into the hairier examples (e.g. ad hoc macro processors for languages
that don't have good macros of their own) the end result is a lost cause
from an aesthetic point of view. And largely from a usability point of
view as well, the two being correlated.

I think encouraging that trend is a mistake. Being able to faithfully
represent all data in Scheme is useful, but it's an anti-goal to
faithfully represent all the ad-hoc encodings of that data.

> The fundamental design flaw also shows up when you consider shebangs:
> You cannot parse them as you want to parse the rest of the "#! " syntax:
>
> #! /usr/bin/scheme -I 'a/b/c' -x (
> ...
>
> What happens to the quotes? The open parentheses would be unbalanced, etc.

IMHO this is a good example of the kind of thing we should not encourage :)

The portable Unix shebang lines are basically:

#! /bin/sh
#! /usr/bin/env foobar

Everything else is bound to hit some kind of problem or another. Even
the "/usr/bin/env" thing is an unfortunate hack since Unix kernels don't
know how to search PATH by themselves.