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)
|
Am Sa., 22. Apr. 2023 um 08:59 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>: > > > (srfi :41) is just an abbreviation for the compound library (srfi :41 > > streams). That's all, and that's fine. > > Should sublibraries have similar abbreviations or not? Not neccessary and not necessarily, IMO. > > SRFIs designed for R7RS haven't used the SRFI 97 convention. The SRFI > > 97 convention also uses the pluralized names of R6RS, which R7RS > > doesn't. > > We should unify R6RS and R7RS here. > > >> Making the :123 hack equivalent to 123 is something that should be > >> solved on an ad hoc basis in the library loader. Hacks shouldn't go into > >> RnRS. > > > It's no hack; it would be a convention. You can't solve it externally > > in the library loader alone as I tried to explain above because you > > need to fabricate lexical context for some syntactic extensions. > > "somehow map a number like 227 internally to :227" > > Source code transformations. 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.) > The transform which maps the number 123 to the symbol |123| makes > aesthetic sense (or at least I can't see any problems there). 123 is > already standardized in R7RS because it is useful and looks sensible. > > The transform which maps :123 to |123| makes no aesthetic sense. The ":" > is there only as a workaround. Add to that all the other problems it > causes. This should remain a convention outside RnRS. 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).