Email list hosting service & mailing list manager

Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 04:28 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 05:50 UTC)
Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 06:26 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 06:46 UTC)
Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 06:59 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 07:17 UTC)
Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 07:35 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 08:31 UTC)
Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 09:01 UTC)
Re: Library names and sublibrary names John Cowan (22 Apr 2023 09:21 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 09:38 UTC)
Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 10:04 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 10:17 UTC)

Re: Library names and sublibrary names Lassi Kortela 22 Apr 2023 07:35 UTC

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