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 06:59 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.