> You can't use `cond-expand' in R7RS top-level programs without importing
> `(scheme base)'. This happens already too late to distinguish, say, R6RS
> and R7Rs.

Good point. This suggests a SRFI on the topic should extend the
top-level program semantics, or use different semantics.

> Anyway, I still think it is very stupid to insist on a name already
> taken (whether for good or for bad) by a related dialect.
>
> Let me demonstrate it with another example: R6RS uses `library' for
> library definitions; after some discussion, WG 1 of R7RS decided against
> reusing `library' but came up with `define-library'. This now has the
> very fortunate consequence that both syntaxes can peacefully coexist in
> Scheme implementations. Depending on whether a library is introduced by
> `library' or `define-library', a Scheme implementation supporting both
> standards can load the library with R6RS or R7RS syntax and semantics.

I agree, but in the sense that allowing both to coexist is better than
nothing. If they could be merged, that would be even better.

> The same solution should work here as well, allowing implementations to
> both fully support R6RS with all appendices and the new standard you are
> creating here.

Would this work:

- The launcher looks for the S-expression with the declarations.

- If it's found, use the "new style" semantics.

- If it's not found, use the semantics in the R6RS appendix.

We could also consider some mild compromise, like looking for #!r6rs in
the script, and using R6RS appendix semantics in that case.

The launcher program can read the entire script file in advance, and
look for anything in it, so there's potentially quite a bit of flexibility.

> Call it `scheme-run', `scheme-exec', `scheme-program',
> `scheme-interpret', `scheme-load', `scheme-interpreter', `schemer',
> `scheme-loader'.
>
> In fact, the name `scheme-script' is not even a meaningful name because
> it names the interpreter and not the script that is being interpreted.

scheme-script is the most obvious name that has to do with Scheme and
scripts. (script-scheme would be another, but it sounds clumsy, and
having both scheme-script and script-scheme with different semantics
would be confusing).

It pays to reduce the set of available names and features where
possible, merging them, instead of adding new ones. This is often
painful, but the pain has to be felt once. The pain of proliferating
similar-but-different things is felt continually.