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)
|
> (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? > 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. The library loader can solve everything. It has access to the library source code, so it can do arbitrary transforms. E.g. map :123 to |123|. 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. More generally, Scheme implementations should have a loader that is fully customizable by the user. There are too many arbitrary and evolving conventions for a clean standard to address all use cases.