Re: guile-devel Digest, Vol 260, Issue 25

Re: guile-devel Digest, Vol 260, Issue 25

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 22639 bytes --]

I would like to comment on what I think are common misconceptions about the
RnRS library system.

1. The RnRS library system is neither a prerequisite for being able to
write portable code nor is it particularly helpful in this regard. The RnRS
library system should better be called a module system, as its primary
function is to create clean (top-level) lexical environments. The ability
to do so can help to write portable code, but it can also be a hindrance to
doing so. For example, the sample implementation of SRFI 9 is an R5RS
implementation that works by redefining some vector primitives. With the
module system of R6RS and R7RS, such an implementation strategy is no
longer possible.

2. To understand what's needed to easily write useful portable code, we
have to focus our attention away from the red herring called library
system. What is needed is, firstly, a broad-ranging standard (e.g. without
the necessary standardized primitives, you can never write a portable HTTP
library). Secondly, implementations need to adhere to the standard as
faithfully as possible. Thirdly, there needs to be an underlying model from
which one can draw efficiency expectations (e.g., as long as
implementations do not agree on implementing call/cc efficiently, useful
portable code cannot be centred around algorithms employing call/cc).

These conditions are in place for a programming language like C. While the
C standard itself is not that broad, implementers agree on an ABI for each
platform so that platform features can be added portably. C implementations
like GCC or Clang work hard to fix deviations from the standard. Lastly,
implementations typically agree on an implementation model so that the
programmer knows what kind of code is efficient and what kind of code is
not.

The Scheme world is different. Firstly, the standard is fairly minimal.
SRFIs try to broaden the standard, but they are not universally implemented
and accepted. Contrary to the standards, SRFIs ultimately only reflect the
opinion of their respective authors. Secondly, many implementations,
including many big implementations (like Guile), deviate from the standard
when it makes sense for them (e.g., Guile implements, first and foremost,
the Guile programming language and offers an implementation of RnRS on top
but would never compromise the further development of the Guile language
over pedantic adherence to RnRS). Thirdly, many Scheme implementations have
been created for interpreter/compiler research so that different
implementation models with different efficiency expectations come naturally
to the Scheme language.

3. The Scheme standards RnRS make no assumptions about the representations
of libraries on the filesystem. Not only is the encoding of the filename
undefined, but it is even unspecified whether a library has to reside on
the filesystem and whether libraries are loaded automatically (versus an
explicit load command to make the library definition known to the
implementation). This makes discussions about the encoding of, say, ":"
moot when it comes to portability. As far as the standard is concerned,
installing a library is, in general, more than just copying files. Package
managers like Akku or Snow can be used for this; they know about the target
implementation and can rename or move files as needed (moving is generally
necessary even for the R7RS, including syntax, which was mentioned because
R7RS does not prescribe where to find the file). This issue is orthogonal
to portability but no less important to make it convenient for the user.
Here, we have similarities to the C standard, which also does not prescribe
the system interface to the compiler.

4. The library names of the form "(srfi :1)" are non-standard but a
convention suggested in SRFI 97. Even if they are supported, only a part of
the SRFI effort is reflected because many features proposed by SRFIs are
not in the form of libraries. Allowing numbers in library names makes
certain syntactic extensions (as some found in Chez Scheme) impossible. In
the syntax-case model of R6RS (which is also the basis of Guile's
expander), only identifiers like ":1" carry lexical information (a set of
marks and substitutions in the R6RS model), numbers and other Scheme datums
do not. The authors of R7RS were presumably unaware of it. A unifying
approach would, therefore, be to use the ":1" version and to offer the
number version "1" solely for backwards compatibility with R7RS. As said
above, this has nothing to do with the encoding of the library name as a
path on the filesystem. An implementation can still look up "(srfi :1)"
under the path "srfi/1.sls" if it wishes to do so. Library definitions are
self-delimiting forms, so more than one library definition can be included
in a file.

Let me also add a personal remark about the "ice-9" namespace: I do not see
a particular problem with it. All that is needed is a well-known name
(well-known for those who have browsed which libraries are available) that
is sufficiently unique. Introducing a new name can be counterproductive as
it reduces the name recognition of the old name (which will still be
around). Moreover, it introduces friction: programmers who study existing
code will have to know both the old name and the new alias, making things
more complicated in the end. Unless there is a technical benefit to doing
so, I advise against replacing "ice-9" with "guile". Another reason for my
wariness is that not everything in the ice-9 namespace is Guile-specific in
the strict sense. For example, (ice-9 regex) seems to be a library that can
live outside of Guile's universe as well. Finally, talking about "ice-9"
(or even about names like "define-module2") feels like bikeshedding.

Cheers,

Marc

Am Sa., 20. Juli 2024 um 22:35 Uhr schrieb <guile-devel-request@gnu.org>:

> Send guile-devel mailing list submissions to
>         guile-devel@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/guile-devel
> or, via email, send a message with subject or body 'help' to
>         guile-devel-request@gnu.org
>
> You can reach the person managing the list at
>         guile-devel-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of guile-devel digest..."
>
>
> Today's Topics:
>
>    1. Portable imports (Lassi Kortela)
>    2. RE: Portable imports (Maxime Devos)
>    3. RE: Portable imports (Maxime Devos)
>    4. Encoding library names (Lassi Kortela)
>    5. RE: Encoding library names (Maxime Devos)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 20 Jul 2024 21:42:37 +0300
> From: Lassi Kortela <lassi@lassi.io>
> To: Maxime Devos <maximedevos@telenet.be>, "Dr. Arne Babenhauserheide"
>         <arne_bab@web.de>
> Cc: Attila Lendvai <attila@lendvai.name>, Greg Troxel
>         <gdt@lexort.com>, MSavoritias <email@msavoritias.me>,
>         "guile-devel@gnu.org" <guile-devel@gnu.org>
> Subject: Portable imports
> Message-ID: <04293f0f-3a83-4ebc-8413-1a936caaeb57@lassi.io>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> > I don’t know if ‘(import ...)’ is standard either (sure it is as part of
> > ‘define-library’, but I didn’t find it on its own in r7rs.pdf),
>
> (import ...) is standard in both R6RS and R7RS, and supported by every
> serious implementation of those standards. Please spread it.
>
> R7RS talks about "programs" and "libraries". These are technical terms
> with precise meanings.
>
> A "program" corresponds to your typical Scheme script. IIRC it _has_ to
> start with (import ...).
>
> A "library" is a (library ...) [in R6RS] or a (define-library ...) [in
> R7RS]. You can type (import ...) inside either.
>
> >  > https://srfi.schemers.org/srfi-97/srfi-97.html:
> >
> >  >A SRFI Library can be referenced by number, as in
> >
> >  >(srfi :1),
> >
> > (srfi 1) is problematic, since ‘1’ is not an symbol (#{1}# is, but
> > that’s not what has been choosen in SRFI 97).
>
> In R7RS non-negative integers can be library name parts. Since these
> library names look natural, it would be good to backport this to R6RS
> implementations.
>
> The colon causes endless grief when mapping library names to file names.
> For example, look at all the %3a in
> https://github.com/arcfide/chez-srfi. That's not even the worst of it.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 20 Jul 2024 21:18:53 +0200
> From: Maxime Devos <maximedevos@telenet.be>
> To: Lassi Kortela <lassi@lassi.io>,  "Dr. Arne Babenhauserheide"
>         <arne_bab@web.de>
> Cc: Attila Lendvai <attila@lendvai.name>, Greg Troxel
>         <gdt@lexort.com>,  MSavoritias <email@msavoritias.me>,
>         "guile-devel@gnu.org" <guile-devel@gnu.org>
> Subject: RE: Portable imports
> Message-ID:
>         <20240720211840.pvJf2C00709gYMG06vJgRX@michel.telenet-ops.be>
> Content-Type: text/plain; charset="utf-8"
>
> >In R7RS non-negative integers can be library name parts. Since these
> library names look natural, it would be good to backport this to R6RS
> implementations.
>
> Then (library [...] (import (srfi 1)) [...]) would work, and since
> ‘library’ is (R6RS) standard and reasonably portable it would then appear
> that (srfi 1) is (R6RS) standard and portable, whereas it isn’t R6RS, and
> hence not a good idea to backport.
>
> >The colon causes endless grief when mapping library names to file names.
> >For example, look at all the %3a in
> https://github.com/arcfide/chez-srfi. That's not even the worst of it.
>
> I don’t think this is a problem for Guile? I don’t recall to what extent,
> but (srfi ...) modules are somewhat special-cased in Guile (or maybe it was
> integers in general for define-library) – maybe its implementation of
> define-library translates (srfi 1) to (srfi srfi-1) (I don’t recall the
> specifics). Hence, the file can simply be named “srfi/srfi-1.scm”.
>
> For compatibility, both(**) (srfi srfi-N) (← non-standard Guile thingie)
> and (srfi :N) need to be supported anyway for ‘define-module’ (←
> Guile-specific interface), so which of them determines the file name is
> just a matter of convenience.
>
> Also, AFAIK that %3a encoding isn’t necessary (and neither recognised(^))
> in Guile – I don’t think Guile does any percent encoding(*). I think naming
> the file “srfi/:1.scm” would work fine, although it’s not something I’ve
> tried before. (There might be a problem with Makefile if ‘make’ doesn’t
> like the :, but I have some ideas for simple ways around that.)
>
> (*) implication: you can’t have two different modules (foo/bar) and (foo
> bar) in Guile.
> (^) (srfi %3a1) would mean the module has literally (srfi %3a1) as name.
> (**) not entirely true, only supporting (srfi srfi-N) (in define-module)
> would be compatible, but that does not seem to be the future.
>
> Best regards,
> Maxime Devos
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/guile-devel/attachments/20240720/deaf1eb8/attachment.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Sat, 20 Jul 2024 21:23:53 +0200
> From: Maxime Devos <maximedevos@telenet.be>
> To: Lassi Kortela <lassi@lassi.io>,  "Dr. Arne Babenhauserheide"
>         <arne_bab@web.de>
> Cc: Attila Lendvai <attila@lendvai.name>, Greg Troxel
>         <gdt@lexort.com>,  MSavoritias <email@msavoritias.me>,
>         "guile-devel@gnu.org" <guile-devel@gnu.org>
> Subject: RE: Portable imports
> Message-ID:
>         <20240720212340.pvPf2C00709gYMG01vPfWY@laurent.telenet-ops.be>
> Content-Type: text/plain; charset="utf-8"
>
> >R7RS talks about "programs" and "libraries". These are technical terms
> with precise meanings.
> >A "program" corresponds to your typical Scheme script. IIRC it _has_ to
> start with (import ...).
>
> I’ve found it in r7rs.pdf now:
>
> > 7.1.6. Programs and definitions
> > <program> → <import declaration>+ <command or definition>+
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/guile-devel/attachments/20240720/367b46f7/attachment.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Sat, 20 Jul 2024 22:46:27 +0300
> From: Lassi Kortela <lassi@lassi.io>
> To: Maxime Devos <maximedevos@telenet.be>, "Dr. Arne Babenhauserheide"
>         <arne_bab@web.de>
> Cc: Attila Lendvai <attila@lendvai.name>, Greg Troxel
>         <gdt@lexort.com>, MSavoritias <email@msavoritias.me>,
>         "guile-devel@gnu.org" <guile-devel@gnu.org>
> Subject: Encoding library names
> Message-ID: <80a09f9e-a84e-47ef-9fbd-72caf22fe948@lassi.io>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> >  > In R7RS non-negative integers can be library name parts. Since these
> > library names look natural, it would be good to backport this to R6RS
> > implementations.
> >
> > Then (library [...] (import (srfi 1)) [...]) would work, and since
> > ‘library’ is (R6RS) standard and reasonably portable it would then
> > appear that (srfi 1) is (R6RS) standard and portable, whereas it isn’t
> > R6RS, and hence not a good idea to backport.
>
> For the time being, (library ...) is only available in R6RS
> implementations. But the next report (tentatively titled R7RS-large) is
> on track to be a merger of R6RS and R7RS, and hence will most likely
> support both (library ...) and (define-library ...) while merging their
> semantics in some way.
>
> I would agree that interop between strict R6RS and other dialects of
> Scheme is important. To that end, the option to use numbers in R6RS
> library names using the : prefix is good to have. (R6RS does not have
> the vertical bar notation |123| to turn numbers into symbols, so strict
> R6RS code cannot even rely on that notation to encode numerical library
> name parts).
>
> A further complication is that :123 is a keyword in some Scheme
> implementations. (This syntax comes from Common Lisp and Emacs Lisp,
> perhaps going as far back as Maclisp.) It might be best if any leading
> colon in a library name part is simply removed.
>
> > > The colon causes endless grief when mapping library names to file
> names.
> > > For example, look at all the %3a in
> > > https://github.com/arcfide/chez-srfi. That's not even the worst of it.
> >
> > I don’t think this is a problem for Guile? I don’t recall to what
> > extent, but (srfi ...) modules are somewhat special-cased in Guile (or
> > maybe it was integers in general for define-library) – maybe its
> > implementation of define-library translates (srfi 1) to (srfi srfi-1) (I
> > don’t recall the specifics). Hence, the file can simply be named
> > “srfi/srfi-1.scm”.
> >
> > For compatibility, both(**) (srfi srfi-N) (ß non-standard Guile thingie)
> > and (srfi :N) need to be supported anyway for ‘define-module’ (ß
> > Guile-specific interface), so which of them determines the file name is
> > just a matter of convenience.
> >
> > Also, AFAIK that %3a encoding isn’t necessary (and neither
> > recognised(^)) in Guile – I don’t think Guile does any percent
> > encoding(*). I think naming the file “srfi/:1.scm” would work fine,
> > although it’s not something I’ve tried before. (There might be a problem
> > with Makefile if ‘make’ doesn’t like the :, but I have some ideas for
> > simple ways around that.)
>
> Guile should support non-negative integers in any library name, not only
> for the SRFI libraries. R7RS allows them anywhere.
>
> I would recommend implementing the %-encoding of arbitrary UTF-8 bytes
> (several Scheme implementations do it when translating library names to
> file names) but to avoid using it in practice.
>
> The : prefixes should be stripped before encoding a library name as a
> file name.
>
> FAT, NTFS (and probably other file systems) do not allow colons in file
> names. I am not aware of any file system that forbids the percent sign.
>
> > (*) implication: you can’t have two different modules (foo/bar) and (foo
> > bar) in Guile.
>
> Percent-encoding the slash solves this easily.
>
> > (^) (srfi %3a1) would mean the module has literally (srfi %3a1) as name.
>
> AFAIK that is allowed by RnRS.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 20 Jul 2024 22:35:35 +0200
> From: Maxime Devos <maximedevos@telenet.be>
> To: Lassi Kortela <lassi@lassi.io>,  "Dr. Arne Babenhauserheide"
>         <arne_bab@web.de>
> Cc: Attila Lendvai <attila@lendvai.name>, Greg Troxel
>         <gdt@lexort.com>,  MSavoritias <email@msavoritias.me>,
>         "guile-devel@gnu.org" <guile-devel@gnu.org>
> Subject: RE: Encoding library names
> Message-ID:
>         <20240720223521.pwbM2C00209gYMG01wbMcg@andre.telenet-ops.be>
> Content-Type: text/plain; charset="utf-8"
>
> >>  > In R7RS non-negative integers can be library name parts. Since these
> >> library names look natural, it would be good to backport this to R6RS
> >> implementations.
> >>
> >> Then (library [...] (import (srfi 1)) [...]) would work, and since
> >> ‘library’ is (R6RS) standard and reasonably portable it would then
> >> appear that (srfi 1) is (R6RS) standard and portable, whereas it isn’t
> >> R6RS, and hence not a good idea to backport.
>
> >For the time being, (library ...) is only available in R6RS
> implementations. But the next report (tentatively titled R7RS-large) is
> on track to be a merger of R6RS and R7RS, and hence will most likely
> support both (library ...) and (define-library ...) while merging their
> semantics in some way.
>
> This is not _yet_ the case – AFAIK R7RS-large is still in progress. So,
> too soon to implement it for ‘library’ yet – ‘library’ is currently R6RS.
>
> >I would agree that interop between strict R6RS and other dialects of
> Scheme is important.
> > To that end, the option to use numbers in R6RS
> library names using the : prefix is good to have. (R6RS does not have
> the vertical bar notation |123| to turn numbers into symbols, so strict
> R6RS code cannot even rely on that notation to encode numerical library
> name parts).
>
> In the case of SRFI, yes, since that’s what the relevant SRFI says the
> module names are, but you are formulating this much more generally.
>
> >A further complication is that :123 is a keyword in some Scheme
> implementations. (This syntax comes from Common Lisp and Emacs Lisp,
> perhaps going as far back as Maclisp.) It might be best if any leading
> colon in a library name part is simply removed.
>
> Guile isn’t one of those, so it’s not a problem. As I understand it, (a
> priori) (foo N), (foo :N) and (foo |N|) are three different module names,
> so this removal is simply incorrect (barring changes to RnRS). As such
> leading colons should be kept.
>
> As part of a ‘module name -> file name’ mapping it seems a reasonable
> choice, but that’s a different matter.
>
> (Not claiming that an implementation should in general support different
> (foo :N) (foo N) (foo |N|) modules, only that it should recognise them as
> different names.)
>
> >> [...]
> >Guile should support non-negative integers in any library name, not only
> for the SRFI libraries. R7RS allows them anywhere.
>
> I never claimed it should be restricted to SRFI libraries. My comment was
> about the colon and the problems it would cause (more precisely, the lack
> of problems) (and about not doing it for R6RS library forms).
>
> >I would recommend implementing the %-encoding of arbitrary UTF-8 bytes
> (several Scheme implementations do it when translating library names to
> file names) but to avoid using it in practice.
>
> Err, no, I recommend _not_ doing that. Unicode brought us the option to be
> able to just type characters without special tricks, I don’t want Guile to
> regress to ASCII here.
>
> Now, if Guile were to support both %-encoding (e.g. for : on Windows
> situations) but also supported (and preferred) just literally including the
> actual character in the filename (Unicode as intended, applied to file
> names), that would be fine, but since Guile’s current module implementation
> just directly maps module names to file names (+ search path), that’s
> currently not an option (start-up performance implications).  (I don’t
> think this is an unsurmountable problem, but it does require some
> reorganization in how Guile libraries are packaged and how Guile searches
> for .go/.scm.)
>
> (Other option: %-encode only disallowed characters so there is a unique
> corresponding file name (modulo search paths), but which characters are
> disallowed depend on file system and OS, so that’s not practical.)
>
> >The : prefixes should be stripped before encoding a library name as a
> file name.
> >FAT, NTFS (and probably other file systems) do not allow colons in file
> names. I am not aware of any file system that forbids the percent sign.
>
> NTFS supports colons just fine(*), it’s Windows that places restrictions
> on file names.
> So, some change is indeed necessary (but not necessarily just always
> stripping the :, other options exist as well.)
>
> (*) not completely sure – ‘:’ can refer to alternate data streams, but I
> don’t know whether that’s an NTFS or a Windows thing
>
> >> (*) implication: you can’t have two different modules (foo/bar) and
> (foo
> >> bar) in Guile.
> >
> >Percent-encoding the slash solves this easily.
>
> See above for how percent-encoding is a problem of its own.
>
> Best regards,
> Maxime Devos
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/guile-devel/attachments/20240720/7a7f4630/attachment.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> guile-devel mailing list
> guile-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/guile-devel
>
>
> ------------------------------
>
> End of guile-devel Digest, Vol 260, Issue 25
> ********************************************
>

[-- Attachment #2: Type: text/html, Size: 29663 bytes --]

Are library names data or syntax?

[Taylan Kammer]

Thank you for the comments. I agree especially with the part about RnRS needing to define a broad-ranging standard that allows writing useful libraries in a portable way. The lack of e.g. networking primitives is extremely limiting and this always greatly bothered me about RnRS.

I have questions about your point #4 though.

On 21.07.2024 11:54, Marc Nieper-Wißkirchen wrote:

> Allowing numbers in library names makes certain syntactic extensions (as some found in Chez Scheme) impossible.

Do you have a pointer to some resource that explains this in more detail? It's the first time I'm hearing about it and would like to learn more.

> In the syntax-case model of R6RS (which is also the basis of Guile's expander), only identifiers like ":1" carry lexical information (a set of marks and substitutions in the R6RS model), numbers and other Scheme datums do not.

I've always thought of library names as data, not identifiers...

In R7RS, both 'define-library' and 'import' kind of exist "outside" the rest of the language, in a sense, and treat library names as literals.

- 'define-library' must be the outermost form read from a file/stream/whatever, and neither the library name being defined nor any of the library names in 'import' sub-forms are subject to variable lookup or any such mechanisms that otherwise affect Scheme program evaluation; the library names are all treated literally, like data.

- 'import' (when not used a 'define-library' subform) must appear one or more times at the start of a sequence of forms read from a file/stream/whatever that describes a program, and the library name operands are again not subject to variable lookup or such, but rather treated literally as if data.

- The only other entity in R7RS that deals with library names, if I remember correctly, is the 'environment' procedure, which expects library names in the form of data (lists).

In what kind of situation might a library name be made up of identifiers (syntax objects) that might need to carry lexical information?


Cheers,

- Taylan

Re: Are library names data or syntax?

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 3657 bytes --]

Am Mo., 22. Juli 2024 um 10:13 Uhr schrieb Taylan Kammer <
taylan.kammer@gmail.com>:

> Thank you for the comments. I agree especially with the part about RnRS
> needing to define a broad-ranging standard that allows writing useful
> libraries in a portable way. The lack of e.g. networking primitives is
> extremely limiting and this always greatly bothered me about RnRS.
>
> I have questions about your point #4 though.
>
> On 21.07.2024 11:54, Marc Nieper-Wißkirchen wrote:
>
> > Allowing numbers in library names makes certain syntactic extensions (as
> some found in Chez Scheme) impossible.
>
> Do you have a pointer to some resource that explains this in more detail?
> It's the first time I'm hearing about it and would like to learn more.
>
> > In the syntax-case model of R6RS (which is also the basis of Guile's
> expander), only identifiers like ":1" carry lexical information (a set of
> marks and substitutions in the R6RS model), numbers and other Scheme datums
> do not.
>
> I've always thought of library names as data, not identifiers...
>
> In R7RS, both 'define-library' and 'import' kind of exist "outside" the
> rest of the language, in a sense, and treat library names as literals.
>
> - 'define-library' must be the outermost form read from a
> file/stream/whatever, and neither the library name being defined nor any of
> the library names in 'import' sub-forms are subject to variable lookup or
> any such mechanisms that otherwise affect Scheme program evaluation; the
> library names are all treated literally, like data.
>
> - 'import' (when not used a 'define-library' subform) must appear one or
> more times at the start of a sequence of forms read from a
> file/stream/whatever that describes a program, and the library name
> operands are again not subject to variable lookup or such, but rather
> treated literally as if data.
>
> - The only other entity in R7RS that deals with library names, if I
> remember correctly, is the 'environment' procedure, which expects library
> names in the form of data (lists).
>
> In what kind of situation might a library name be made up of identifiers
> (syntax objects) that might need to carry lexical information?
>

I was talking about certain syntactic extensions. In Chez Scheme, which is
an extension of R6RS (and strictly compatible with it modulo bugs),
"import" is also a keyword, and libraries can be imported into a local
environment. In this case, the library name is part of the syntax. To
correctly attach marks (in the R6RS syntax model) to the imported
identifiers, the expander needs marks associated with the library name (and
takes the marks of the last name part, which, therefore, must be an
identifier).

Local imports make perfect sense; they are just not standardised in current
RnRS versions, i.e., in R6RS and R7RS.  Likewise, future standards may
allow library forms within Scheme program text.  The R7RS choice of
allowing numbers is, thus, suboptimal because it may rule out certain
future extensions.

I guess there is another reason why R6RS disallows numbers as library
names: this can lead to confusion with library versions, which are also
numeric (and which R7RS does not have).  People coming from other
programming languages or environments are used to numbers as version
indicates (e.g., we have libguile-2.2.so and libguile-3.0.so), while "(srfi
1)" does not mean the first version of some SRFI library. (We really need a
better naming scheme for SRFI libraries that does not depend on assigned
numbers, but it is not clear to me how to implement one.)

Cheers,

Marc

[-- Attachment #2: Type: text/html, Size: 4656 bytes --]

Numbers in library names

[Lassi Kortela]

> To correctly attach marks (in the R6RS syntax model) to the imported 
> identifiers, the expander needs marks associated with the library name 
> (and takes the marks of the last name part, which, therefore, must be an 
> identifier).
Where does the decision to take the last library name part come from?

Only Chez Scheme? Any other implementations? Does R6RS address this?

Why not take the first library name part instead of the last? In 
practice, a numeric last part is useful and is already widely used. It's 
far less likely for a numeric first part to be useful.

Re: Numbers in library names

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

Am Mo., 22. Juli 2024 um 19:43 Uhr schrieb Lassi Kortela <lassi@lassi.io>:

> > To correctly attach marks (in the R6RS syntax model) to the imported
> > identifiers, the expander needs marks associated with the library name
> > (and takes the marks of the last name part, which, therefore, must be an
> > identifier).
> Where does the decision to take the last library name part come from?
>
> Only Chez Scheme? Any other implementations? Does R6RS address this?
>

As I wrote, this is a syntactic extension of Chez Scheme - but a very
useful one - and outside of the R6RS.  The Unsyntax expander I wrote also
implements it.


> Why not take the first library name part instead of the last? In
> practice, a numeric last part is useful and is already widely used. It's
> far less likely for a numeric first part to be useful.
>

The last name part is the most specific one.  In any case, the decision was
made before R7RS existed, and, as I mentioned, the R7RS authors were likely
unaware of the incompatibility of their proposal to allow numeric name
parts with existing implementations and language extensions.

I don't buy that numeric library parts are particularly useful; they are
just one option. The SRFI 97 convention works as well as the SRFI-0
convention of "srfi-N" names, which is basically also used by Guile.

[-- Attachment #2: Type: text/html, Size: 2212 bytes --]

Re: Numbers in library names

[Lassi Kortela]

> As I wrote, this is a syntactic extension of Chez Scheme - but a very 
> useful one - and outside of the R6RS.  The Unsyntax expander I wrote 
> also implements it.

If patching these two implementations to use the first library name part 
instead of the last is the only technical obstacle to numbers in library 
names, it seems the cost is trivial.

>     Why not take the first library name part instead of the last?
> 
> The last name part is the most specific one.

What does that mean, and what are the ramifications?

> the R7RS authors were 
> likely unaware of the incompatibility of their proposal to allow numeric 
> name parts with existing implementations and language extensions.

Implementation, singular.

> I don't buy that numeric library parts are particularly useful; they are 
> just one option. The SRFI 97 convention works as well as the SRFI-0 
> convention of "srfi-N" names, which is basically also used by Guile.

Aesthetics matter.

RE: Numbers in library names

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

>> the R7RS authors were 
>> likely unaware of the incompatibility of their proposal to allow numeric 
>> name parts with existing implementations and language extensions.
>
>Implementation, singular.

Implementations, plural, since Chibi seems to do the same ‘module name -> file name’ thing as Guile (so separate (foo 1) and (foo |1|) not practical). Going by what I’m reading at https://docs.racket-lang.org/guide/module-basics.html, the same appears to apply to Racket (it appears that in Racket, module names are strings with slashes instead of lists of strings).

AFAICT, neither Chibi nor Guile properly support slashes in name parts, so there is another incompatibility with multiple implementations.

>> I don't buy that numeric library parts are particularly useful; they are 
>> just one option. The SRFI 97 convention works as well as the SRFI-0 
>> convention of "srfi-N" names, which is basically also used by Guile.
>
>Aesthetics matter.

That’s one reason why I would prefer (srfi |1|) or (srfi srfi-1). That lone number next to an identifier in (srfi 1) is unaesthetic to me.

Best regards,
Maxime Devos.

[-- Attachment #2: Type: text/html, Size: 2885 bytes --]

Re: Numbers in library names

[Artyom Bologov]

Hi y'all,

I've been confused by the statements that R6/7RS don't have numbers in
library names. Because both kinda do.

R6RS seems to allow the last library name element to be a list (?) of
numbers explicitly reserved for library version:
See https://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html

R7RS doesn't specify the meaning of integers, but it allows them too:
> <library name> is a list whose members are identifiers and exact non-negative integers.
https://standards.scheme.org/corrected-r7rs/r7rs-Z-H-7.html#TAG:__tex2page_sec_5.6.1 

Am I missing something?

Thanks,
--
Artyom Bologov
https://aartaka.me

Re: Numbers in library names

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Am Mo., 22. Juli 2024 um 22:52 Uhr schrieb Artyom Bologov <mail@aartaka.me>:

> Hi y'all,
>
> I've been confused by the statements that R6/7RS don't have numbers in
> library names. Because both kinda do.
>
> R6RS seems to allow the last library name element to be a list (?) of
> numbers explicitly reserved for library version:
> See https://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html
>
> R7RS doesn't specify the meaning of integers, but it allows them too:
> > <library name> is a list whose members are identifiers and exact
> non-negative integers.
>
> https://standards.scheme.org/corrected-r7rs/r7rs-Z-H-7.html#TAG:__tex2page_sec_5.6.1
>
> Am I missing something?
>

The library version of R6RS is not part of the library name. An R6RS system
SHOULD not allow two library implementations with the same name but with
different versions to be loaded at the same time.  In contrast, in R7RS, a
number can be an ordinary part of a library name while it does not support
library versioning.

Does this help?

Your confusion is understandable and supports my earlier guess that R6RS
also disallows numbers in library names because it leads to, well,
confusion with the version numbers.

Marc

[-- Attachment #2: Type: text/html, Size: 2196 bytes --]

Re: Numbers in library names

[Artyom Bologov]

[-- Attachment #1: Type: text/html, Size: 2672 bytes --]

Re: Numbers in library names

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Am Mo., 22. Juli 2024 um 20:13 Uhr schrieb Lassi Kortela <lassi@lassi.io>:

> > As I wrote, this is a syntactic extension of Chez Scheme - but a very
> > useful one - and outside of the R6RS.  The Unsyntax expander I wrote
> > also implements it.
>
> If patching these two implementations to use the first library name part
> instead of the last is the only technical obstacle to numbers in library
> names, it seems the cost is trivial.
>

There are other costs involved, e.g., when mappings from library names to
the pathnames have to be specified. While it is straightforward to encode a
number of characters like "/" or ":", it is not so straightforward to
encode numbers differently from symbols that look like numbers.


> >     Why not take the first library name part instead of the last?
> >
> > The last name part is the most specific one.
>
> What does that mean, and what are the ramifications?
>

Intuitively and semantically, it makes more sense to derive the needed
lexical information from the most specific library name part than from a
generic top-level name part.


> > the R7RS authors were
> > likely unaware of the incompatibility of their proposal to allow numeric
> > name parts with existing implementations and language extensions.
>
> Implementation, singular.
>

Singular only insofar as Chez Scheme is the only affected implementation
that I know.  Ikarus was another existing implementation that may support
the Chez extensions as well as may any other implementation whose expander
is close enough to Chez's.


> > I don't buy that numeric library parts are particularly useful; they are
> > just one option. The SRFI 97 convention works as well as the SRFI-0
> > convention of "srfi-N" names, which is basically also used by Guile.
>
> Aesthetics matter.
>

Aesthetics matter when they are not mostly subjective.

[-- Attachment #2: Type: text/html, Size: 3062 bytes --]

Re: Numbers in library names

[Lassi Kortela]

> There are other costs involved, e.g., when mappings from library names 
> to the pathnames have to be specified. While it is straightforward to 
> encode a number of characters like "/" or ":", it is not so 
> straightforward to encode numbers differently from symbols that look 
> like numbers.

Why would symbols and numbers be encoded differently? What practical 
benefits are conferred by keeping them different, and what practical 
harm comes from treating them as equivalent?

>      > The last name part is the most specific one.
> 
>     What does that mean, and what are the ramifications?
> 
> Intuitively and semantically, it makes more sense to derive the needed 
> lexical information from the most specific library name part than from a 
> generic top-level name part.

Are the practical implications for Scheme programmers or implementers? 
It's the whole library name that is of interest. Any part ought not be 
interesting on its own.

> Singular only insofar as Chez Scheme is the only affected implementation 
> that I know.  Ikarus was another existing implementation that may 
> support the Chez extensions as well as may any other implementation 
> whose expander is close enough to Chez's.

Following the Chez lineage: Ikarus and Vicare are unlikely to have 
active users. Loko and Unsyntax are still young.

The existing, widely used support for numerical library name parts in 
R7RS is a big deal. Successive editions of RnRS should not vacillate in 
order to make abstruse technical points. There has to be a serious 
blocker. I am willing to hear if there is, but the obstacles explained 
so far seem to me either trivial or outside the remit of RnRS.

> Aesthetics matter when they are not mostly subjective.

There is more variety in taste than I expected. Nevertheless, the fact 
is that there are two widespread existing conventions. We should make 
them interoperate.

Re: Numbers in library names

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]

Am Di., 23. Juli 2024 um 17:06 Uhr schrieb Lassi Kortela <lassi@lassi.io>:

> > There are other costs involved, e.g., when mappings from library names
> > to the pathnames have to be specified. While it is straightforward to
> > encode a number of characters like "/" or ":", it is not so
> > straightforward to encode numbers differently from symbols that look
> > like numbers.
>
> Why would symbols and numbers be encoded differently? What practical
> benefits are conferred by keeping them different, and what practical
> harm comes from treating them as equivalent?
>

In R7RS, (srfi 1) and (srfi |1|) are different library names.


> >      > The last name part is the most specific one.
> >
> >     What does that mean, and what are the ramifications?
> >
> > Intuitively and semantically, it makes more sense to derive the needed
> > lexical information from the most specific library name part than from a
> > generic top-level name part.
>
> Are the practical implications for Scheme programmers or implementers?
> It's the whole library name that is of interest. Any part ought not be
> interesting on its own.
>

Parts of Scheme forms can be interesting even if they do not make sense as
stand-alone identifiers.


> > Singular only insofar as Chez Scheme is the only affected implementation
> > that I know.  Ikarus was another existing implementation that may
> > support the Chez extensions as well as may any other implementation
> > whose expander is close enough to Chez's.
>
> Following the Chez lineage: Ikarus and Vicare are unlikely to have
> active users. Loko and Unsyntax are still young.
>

Your reply is out of context. We were talking about the creation of R7RS,
which happened more than ten years ago.


> The existing, widely used support for numerical library name parts in
> R7RS is a big deal. Successive editions of RnRS should not vacillate in
> order to make abstruse technical points. There has to be a serious
> blocker. I am willing to hear if there is, but the obstacles explained
> so far seem to me either trivial or outside the remit of RnRS.
>
> > Aesthetics matter when they are not mostly subjective.
>
> There is more variety in taste than I expected. Nevertheless, the fact
> is that there are two widespread existing conventions. We should make
> them interoperate.
>

I agree with the last point; a future RnRS can special-case "(srfi N)",
demanding that the library described by it must be the same as the library
"(srfi :N)".  The latter would be the default and numbers in library names
otherwise deprecated.  Numbers would be reserved for versioning.

[-- Attachment #2: Type: text/html, Size: 3910 bytes --]

Re: Numbers in library names

[Lassi Kortela]

> In R7RS, (srfi 1) and (srfi |1|) are different library names.

What is the practical harm?

(If there is some obscure point whereby the semantics don't add up in an 
intuitive way, I would genuinely like to hear about it. In practice, I 
think library aliases will be a must-have feature eventually. It implies 
multiple library names resolving to the same library will be commonplace 
irrespective of what is done about numbers specifically.)

>     Are the practical implications for Scheme programmers or implementers?
>     It's the whole library name that is of interest. Any part ought not be
>     interesting on its own.
> 
> Parts of Scheme forms can be interesting even if they do not make sense 
> as stand-alone identifiers.

What is the practical difference?

Sounds like an esoteric point of spec-writing aesthetics.

> Your reply is out of context. We were talking about the creation of 
> R7RS, which happened more than ten years ago.

OK.

> I agree with the last point; a future RnRS can special-case "(srfi N)", 
> demanding that the library described by it must be the same as the 
> library "(srfi :N)".  The latter would be the default and numbers in 
> library names otherwise deprecated.

Thanks for the conceding that point.

But isn't this special case more complicated than a general rule?

I don't understand your fundamental motivation.

> Numbers would be reserved for versioning.

It's unwise to restrict versions to numbers only. Looking at package 
managers, non-numerical version parts always crop up eventually.

RE: Numbers in library names

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]

I haven’t received the e-mail you are responding too (in particular, I don’t know who you are responding to), but …

>> In R7RS, (srfi 1) and (srfi |1|) are different library names.
>
>What is the practical harm?
>
>(If there is some obscure point whereby the semantics don't add up in an 
intuitive way, I would genuinely like to hear about it. In practice, I 
think library aliases will be a must-have feature eventually. It implies 
multiple library names resolving to the same library will be commonplace 
irrespective of what is done about numbers specifically.)

As already has been answered:

The practical harm is (srfi |1|) is non-standard, but it looks standard because it contains ‘srfi’, so if someone were to type (srfi |1|) in their Scheme implementation and it gets automatically mapped to (srfi 1), then it appears to work, hence misleading the writer into thinking that (srfi |1|) is standard.

(For the same reason, Guile doing (srfi srfi-1) is problematic. It’s not just there for compatibility, it’s the main way of importing SRFI things.)

If (srfi |1|) were to be standardised via SRFI process or RnRS (maybe implicitly as a ‘module names equality is to be done modulo number/symbol conversions’ thing in a future R8RS), then (srfi |1|) would be fine, but such a thing.

Also, even if X would have no practical harm, that doesn’t imply X should be done.

>>     Are the practical implications for Scheme programmers or implementers?
>>     It's the whole library name that is of interest. Any part ought not be
>>     interesting on its own.
>> 
>> Parts of Scheme forms can be interesting even if they do not make sense 
>> as stand-alone identifiers.
>
>What is the practical difference?
>
>Sounds like an esoteric point of spec-writing aesthetics.

This has already been answered.

The practical difference, IIUC, is that esoteric point (IIUC, different lexical context stuff). If you misinterpret the esoteric stuff, then your library/program/... might not work properly, which is a practical concern.

(More precisely: lexical context of library name not necessarily the same as context of a name part.)

This is irrelevant to Guile though, Guile doesn’t have this extension.

Regards,
Maxime Devos

[-- Attachment #2: Type: text/html, Size: 5867 bytes --]

Re: Numbers in library names

[Lassi Kortela]

> I haven’t received the e-mail you are responding too (in particular, I 
> don’t know who you are responding to), but …

I was talking to Marc; it seems there is a delay in list traffic.

> As already has been answered:
> 
> The practical harm is (srfi |1|) is non-standard, but it looks standard 
> because it contains ‘srfi’, so if someone were to type (srfi |1|) in 
> their Scheme implementation and it gets automatically mapped to (srfi 
> 1), then it appears to work, hence misleading the writer into thinking 
> that (srfi |1|) is standard.
> 
> (For the same reason, Guile doing (srfi srfi-1) is problematic. It’s not 
> just there for compatibility, it’s the main way of importing SRFI things.)
> 
> If (srfi |1|) were to be standardised via SRFI process or RnRS (maybe 
> implicitly as a ‘module names equality is to be done modulo 
> number/symbol conversions’ thing in a future R8RS), then (srfi |1|) 
> would be fine, but such a thing.

Fair enough. Good points.

I'm in favor of defining such a rule via SRFI and/or RnRS.

> This has already been answered.
> 
> The practical difference, IIUC, is that esoteric point (IIUC, different 
> lexical context stuff). If you misinterpret the esoteric stuff, then 
> your library/program/... might not work properly, which is a practical 
> concern.
> 
> (More precisely: lexical context of library name not necessarily the 
> same as context of a name part.)
The issue was whether to take the first part or the last part of the 
library name. (The spec would stipulate that this part has to be an 
identifier.) I ahve the impression that every part of the same name has 
an equally useful lexical context.

RE: Numbers in library names

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

> If (srfi |1|) were to be standardised via SRFI process or RnRS (maybe 
> implicitly as a ‘module names equality is to be done modulo 
> number/symbol conversions’ thing in a future R8RS), then (srfi |1|) 
> would be fine, but such a thing.

Looks like I didn’t finish the sentence: ‘but such a thing -> but such a thing hasn’t happened yet’.


[-- Attachment #2: Type: text/html, Size: 1530 bytes --]

RE: Are library names data or syntax?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

> [...]
>
>In what kind of situation might a library name be made up of identifiers (syntax objects) that might need to carry lexical information?

As implied by the previous: never (in Guile, and probably most others).

The only exception I can think of, is if:

* ‘define-library’/’library’ is implemented as a macro (this is not part of RnRS, but AFAIK neither is it against the standard)
* hence, you can define a module from within another module (might be situationally useful, but comes with new difficulties for module lookup)
* there are multiple module namespaces
* to determine which module namespace to put the module in, ‘define-library’ uses lexical information
* in particular, it uses components of the name of the library for lexical information, even though there are other options like using the _whole_ name (i.e., (foo bar) itself instead of ‘foo’ or ‘bar’).

That’s a lot of ifs, and even then identifiers aren’t necessary, since (AFAIK) the name (foo bar) itself carries lexical information (not sure).

I’ve been assuming that numbers (in syntax) (say, #'3) don’t carry lexical info, but since ‘syntax numbers’ carry file name+position information, it’s not much of a stretch to potentially also include lexical information, so perhaps numbers would work just fine too! (Implementation-dependent, but ‘multiple module namespaces’ and ‘define-library as a macro’ are also implementation-dependent.)

Best regards,
Maxime Devos.

[-- Attachment #2: Type: text/html, Size: 3635 bytes --]

Re: Are library names data or syntax?

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

Maxime Devos <maximedevos@telenet.be> writes:
> * hence, you can define a module from within another module (might be
> situationally useful, but comes with new difficulties for module
> lookup)

I actually tried something in that direction in enter three witches —
and failed.

I wanted to add a macro that maps

SCENE I

to defining a module that cleanly separates different parts of a story.

But I didn’t get that to work well (because it would have had to add
automatic exports and canonical imports and all together caused more
problems than it solved.

Or maybe I didn’t understand well enough what I was doing. Generating
code that generates modules isn’t a good idea if there’s a similar
option that uses standard mechanisms.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Are library names data or syntax?

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

Arne, you may want to take a look at Chez's "module" syntax, see [1]. It is
orthogonal to our discussion about library names, but it may be what you
have in mind for your specific use case. A module is like a library but is
bound to an identifier, not to a library name.

Marc

--

[1] https://cisco.github.io/ChezScheme/csug10.0/syntax.html#./syntax:h5

Am Mo., 22. Juli 2024 um 23:05 Uhr schrieb Dr. Arne Babenhauserheide <
arne_bab@web.de>:

> Maxime Devos <maximedevos@telenet.be> writes:
> > * hence, you can define a module from within another module (might be
> > situationally useful, but comes with new difficulties for module
> > lookup)
>
> I actually tried something in that direction in enter three witches —
> and failed.
>
> I wanted to add a macro that maps
>
> SCENE I
>
> to defining a module that cleanly separates different parts of a story.
>
> But I didn’t get that to work well (because it would have had to add
> automatic exports and canonical imports and all together caused more
> problems than it solved.
>
> Or maybe I didn’t understand well enough what I was doing. Generating
> code that generates modules isn’t a good idea if there’s a similar
> option that uses standard mechanisms.
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein,
> ohne es zu merken.
> draketo.de
>

[-- Attachment #2: Type: text/html, Size: 2419 bytes --]

Re: Are library names data or syntax?

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

Am Mo., 22. Juli 2024 um 20:47 Uhr schrieb Maxime Devos <
maximedevos@telenet.be>:

> > [...]
>
> >
>
> >In what kind of situation might a library name be made up of identifiers
> (syntax objects) that might need to carry lexical information?
>
>
>
> As implied by the previous: never (in Guile, and probably most others).
>
>
>
> The only exception I can think of, is if:
>
>
>
> * ‘define-library’/’library’ is implemented as a macro (this is not part
> of RnRS, but AFAIK neither is it against the standard)
>
> * hence, you can define a module from within another module (might be
> situationally useful, but comes with new difficulties for module lookup)
>
> * there are multiple module namespaces
>
> * to determine which module namespace to put the module in,
> ‘define-library’ uses lexical information
>
> * in particular, it uses components of the name of the library for lexical
> information, even though there are other options like using the _*whole*_
> name (i.e., (foo bar) itself instead of ‘foo’ or ‘bar’).
>
>
>
> That’s a lot of ifs, and even then identifiers aren’t necessary, since
> (AFAIK) the name (foo bar) itself carries lexical information (not sure).
>
>
>
> I’ve been assuming that numbers (in syntax) (say, #'3) don’t carry lexical
> info, but since ‘syntax numbers’ carry file name+position information, it’s
> not much of a stretch to potentially also include lexical information, so
> perhaps numbers would work just fine too! (Implementation-dependent, but
> ‘multiple module namespaces’ and ‘define-library as a macro’ are also
> implementation-dependent.)
>

This would need a redefinition of what a syntax object is (see the R6RS).
In principle, this would be possible, but the result would be incompatible
with the R6RS. In R6RS, a macro transformer is allowed to output raw
numbers; this would not be allowed in a hypothetical Scheme version that
assumes that numbers necessarily carry a wrap (as identifiers do in the
R6RS).

Source location information is not mandatory information for the expander,
so this reasoning does not apply here.

Marc

[-- Attachment #2: Type: text/html, Size: 4132 bytes --]