The extension should reflect the contents of the file.

.scm is for Scheme code.  define-library is not Scheme code, though sometimes Scheme code is nested inside it.
.sld is for Scheme Library Definitions.  For some impls, this is just a static define-library.  For Chibi, it is a full fledged language distinct from Scheme.

If you are proposing some metadata format which is not Scheme code, neither of the above extensions would be appropriate.

Personally, I think this is overkill either way.  One file per alias is simple to implement and simple to use.  Anyone can provide an alias for anything.  Putting multiple aliases into a single file begs the question who is maintains that file?

--
Alex

On Wed, May 27, 2020 at 6:41 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>> 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".

Unfortunately this zoo of extensions is very confusing to people who are
not Scheme experts. There are now at least 11 of them, and all of them
are cryptic acronyms.

Ideally there would be just one Scheme extension, and the file contents
would say what kind of Scheme file each is. Otherwise there will be no
end to the number of extensions we need to coin in the future.

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

I like ".scheme" a lot, but only if ".scm" is deprecated in favor of
".scheme" :) As a practical matter, ".scm" is very unlikely to be
deprecated, so I would prefer to stick with it for future Scheme stuff.

>> 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).

Fair enough.

> 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.

I agree. However, there shouldn't be a problem with sticking to one
extension for all kinds of Scheme S-expression files.