Am Mi., 27. Mai 2020 um 11:05 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> Emacs Lisp files have the extension `.el`, and some packages use `.eld`
> for "Emacs Lisp data" that is not loadable code.
>
> There is not a similar convention for Common Lisp's `.lisp` extension.
> CL data files tend to use the same extension I guess. We've been doing
> that with Scheme as well, using `.scm` for data.

Not optimal as Scheme library definitions get their own extension
while Scheme program files don't. We could reuse the R6RS (?)
extensions "sps" and "sls", of course. Or "spd" and "sld" to keep
"sld".

> The trouble with a generic S-expression extension is that there are
> different variants of S-expr syntax. The file would then have to stick
> to a portable subset. (If it isn't portable, we should probably use a
> Scheme-specific extension instead of a generic S-expression extension).

Yes; ".scheme" could be such an extension.

> Personally I'm in favor of fewer extensions overall and deducing more
> things from file contents instead. File name extensions are a hack to
> begin with; file contents should ideally be self-describing. `#!r6rs`
> and `#! /usr/bin/env fantastic-scheme` are two such useful identifiers.
> Perhaps the  `meta.scm` file can start with `#!metadata` or something.
> Would that be considered reader abuse?

Yes, in my opinion, yes. If, these files should identify themselves
through the s-expressions that are contained within (see my other
reply).

Apart from this, there also a number of (legacy) tools that make a lot
of use of file extensions (POSIX make is an important example; as are
various desktop environments and editors), so for quite a lot of time
to come, file extensions will remain to be important.