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