> Why don't you hide this s-expression in a (list of) ";" comment(s) that
> is understood by every Lisp? The s-expression would have to include some
> magic bytes to recognize (just like Emacs's special comments):
>
> #! /usr/bin/env lila
>
> ;* (declare-file
> ;*   (language scheme)
> ;*   (implementations chicken gauche))
> It is to be understood that comments in the restricted s-expression
> language parsed by the launcher are not allowed to start with ";*".

Magic comments are exactly what I wanted to avoid.

Starting from first principles, the activity makes no sense:

- The Lisp family is well known for a syntax that is uniquely suited to
be arbitrarily extended in a clean way.

- We ignore the whole point of that syntax, and put stuff in comments,
which we then parse, even though comments are the one part of the host
syntax that is meant not to be parsed.

- The fact that we fail to re-use the host syntax, means we can't
leverage things like indenting and syntax highlighting in text editors,
we can't (read) the data, etc.

Emacs Lisp is only one dialect, with one main implementation, and still
they used magic comments instead of S-expressions for packaging and
variable declarations, with the predictable consequence that things are
brittle and hard to parse (which I know from personal experience).

You're viewing this as a near-term technical problem, instead of a
long-term social problem. It's not possible to solve large-scale
problems elegantly without a measure of social cooperation. In this
case, the necessary cooperation is to agree among Lisp dialects on a
common subset of S-expression syntax. I've tried to find one, and got
very useful results.

Generality is a good rule for things of timeless purity. For example,
it's good if Scheme's numbers are close to mathematical numbers. But a
syntax is an arbitrary human convention; if we prioritize accommodating
people who don't play along with reasonable conventions, then the
conventions will get more and more messy over time.

I'd rather have less generality, than enable some really kludgy variant
of S-expressions to work without a hitch, while making things uglier and
less convenient for the rest of us that use a reasonable version of
S-expressions. In practice, people respect "..." strings and
parenthesis-matching of () [] {} widely enough that we can get a lot of
mileage simply by observing those conventions.

>     +1, there's no obvious problem with allowing launcher
>     implementations to compile programs.
>
> It should be made a mandatory part of the launcher. Not for the sake of
> compiling, but for the sake of allowing more than one logical file
> (including libraries) in the script.

What do you think about launching a Scheme program from a tar file, like
Java .jar files? I rather like the idea, and it would be more generally
useful than a multi-file script.

> That's not the point; you can't rewrite it into a valid R6RS script or
> program. A valid R6RS program mustn't start with a "#!..." line (the
> reader of an R6RS without any extensions would raise a lexical
> violation). A valid R6RS script must start with "#!/usr/bin/env
> scheme-script" and not with "#!/usr/bin/env lila". (An optional space
> after "#!" can be inserted.)

The specific line "#! /usr/bin/env scheme-script" is not required: "The
script header syntax given above is the recommended portable form that
programmers should use. However, if the first line of a script begins
with #!/ or #!<space>, implementations should ignore it on all
platforms, even if it does not conform to the recommended syntax."