It would be on the level of syntax objects. Have you implemented a
library loader that deal with all this and local imports in macro
expansion contexts in working fashion? We have to be careful about
claims that this is just a simple source code mapping. (I am not
talking about the mapping between library names and files, which is,
in fact, part of the loader.)
I recall you said at least one library name part has to be a symbol.
So these would all work:
(import (foo))
(import (foo 1))
(import (foo 1 2))
(import (1 foo 2))
(import (1 2 foo))
These would work too:
(import (|1|))
(import (|1| 2))
(import (1 |2|))
But these would not:
(import ())
(import (1))
(import (1 2))
If the above is correct, then the loader wouldn't even need a code
walker. Users would just need to avoid library names with only numbers.
(And even all-numerical names could be used with |123| symbol notation.
Both are just mappings from numbers to symbols. The latter has the
advantage that it is already "standardized" in SRFI 97. There's no
need to invent a new convention here that does not have any advantage
(except for highly subjective claims of aesthetics).
Using a plain number like 123 is not a new convention. R7RS has done it
for years. Whether the object is a number, a symbol, or a string is a
concern on a different level. The file system mapping turns all library
name parts into strings anyway.
I don't buy these "subjectivity" arguments, but that's a book-length
debate at worst.
