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 Marc Nieper-Wißkirchen 22 Apr 2023 07:16 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).