I haven’t received the e-mail you are responding too (in particular, I
don’t know who you are responding to), but …
I was talking to Marc; it seems there is a delay in list traffic.
As already has been answered:
The practical harm is (srfi |1|) is non-standard, but it looks standard
because it contains ‘srfi’, so if someone were to type (srfi |1|) in
their Scheme implementation and it gets automatically mapped to (srfi
1), then it appears to work, hence misleading the writer into thinking
that (srfi |1|) is standard.
(For the same reason, Guile doing (srfi srfi-1) is problematic. It’s not
just there for compatibility, it’s the main way of importing SRFI things.)
If (srfi |1|) were to be standardised via SRFI process or RnRS (maybe
implicitly as a ‘module names equality is to be done modulo
number/symbol conversions’ thing in a future R8RS), then (srfi |1|)
would be fine, but such a thing.
Fair enough. Good points.
I'm in favor of defining such a rule via SRFI and/or RnRS.
This has already been answered.
The practical difference, IIUC, is that esoteric point (IIUC, different
lexical context stuff). If you misinterpret the esoteric stuff, then
your library/program/... might not work properly, which is a practical
concern.
(More precisely: lexical context of library name not necessarily the
same as context of a name part.)
The issue was whether to take the first part or the last part of the
library name. (The spec would stipulate that this part has to be an
identifier.) I ahve the impression that every part of the same name has
an equally useful lexical context.
