From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Newsgroups: gmane.lisp.guile.devel Subject: Re: guile-devel Digest, Vol 260, Issue 25 Date: Sun, 21 Jul 2024 11:54:12 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e3cc54061dbee93d" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3500"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Maxime Devos , Lassi Kortela , Arne Babenhauserheide To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Sun Jul 21 11:54:53 2024 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sVTHI-0000ib-MP for guile-devel@m.gmane-mx.org; Sun, 21 Jul 2024 11:54:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sVTH3-0002vf-LI; Sun, 21 Jul 2024 05:54:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sVTH2-0002vR-AY for guile-devel@gnu.org; Sun, 21 Jul 2024 05:54:36 -0400 Original-Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.219]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sVTGx-00021g-1R for guile-devel@gnu.org; Sun, 21 Jul 2024 05:54:36 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1721555666; cv=none; d=strato.com; s=strato-dkim-0002; b=djc6Wv1Frlv3DSKWkxikRRWQOH38MqnkjuXXkWNmwCYvZxP5mnIZ9q9Tsnq2btBl4D CuJgLtbGQlpPfpV9r4iV/f4v7EvaKZaDlg2rdF5ygNy7Ed8L44//Agy0fk+5/+5ZGEES 8qJdCIYdS9bzxdCXlLzdmlCiVfcy9X2VFB2y2yGdBOLR7uzXWnONnW0EPBWvAO8lsdOK 1VbU7A/5bdlXnR7rKE5anz+EXSlKxW3i69gvEfNcYncpk4zVLJUgBNGButXb7nKVRIj+ GLsv328uTrH8jjlvOiiwUrj06EHQJ/My/vmgonGIHJWmC2owJMicCfk2BGM/aPCvvUe1 9oqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1721555666; s=strato-dkim-0002; d=strato.com; h=Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:Cc:Date: From:Subject:Sender; bh=XU+4uY0MaWLhXPVDwJ1no8Er2fDqrXMVH2wYvZCxAiQ=; b=crh1zbVHI8wzCIWLZgf16s/awEtFFB+FEaVbAIkja6GaHODyhyNqVXxcDrOBoHhWTS k9nfGKjNpX3utgHr5LJMVGb3k0FYA9fLHLNQ8GWhlzDeXeNTqsizRNH4y40DPUafk5EA uvQngCrvaUH3xkf/Jjg29gJ8COWAIMD1h97eaTRiyYpvrhnuI4HqBEIYFyhFVZsz1xVv 1d9Q7Y7xDNIrIdjSoRRJ/+h0+iipK8VNMwpIxUrudSDtfC6rPjYaYyePiOc0/SLwLW5u rXKOnys4aCBjJ/6GsINUGXcihwtHvwT1Ud/v1ZGf3uXPicNRY1VcOGmpr4kg8sIEBulI FfXQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1721555666; s=strato-dkim-0002; d=nieper-wisskirchen.de; h=Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:Cc:Date: From:Subject:Sender; bh=XU+4uY0MaWLhXPVDwJ1no8Er2fDqrXMVH2wYvZCxAiQ=; b=JlhtNpZEC5VNVrX+GzmJrW8VlBP7Q+2JVbXVzdbV0hoPTUcTOiLV764W9ZNvhFdaHB jkIT6/wMDncAfDnmcMoahlCur8dmZQaUkmmZluAnamjgZB+KvJju7WgddyqAxEw8ydNb blaRNV3JE4Ej9/Ro5+sfL0251zqAC1vlJu688EBrD6G4m95l/ybr1Hku9vpkS4QPceqo LMdA0i4m8C+btmtOz1hedXJJFD8QRcO+S1dCkyM19Kb0yDWBChpZxQZkHQnsPLfD+2QZ KtjuNTs+2RhOOqjJWSBh1We+a250jMjSb1jYNoXyXDpxqlIOKed2iYI4n7B19rE1bECm 1X7g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1721555666; s=strato-dkim-0003; d=nieper-wisskirchen.de; h=Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:Cc:Date: From:Subject:Sender; bh=XU+4uY0MaWLhXPVDwJ1no8Er2fDqrXMVH2wYvZCxAiQ=; b=ukC4gW9QHuJXAE6NTPoic0IMMtVK0X6apOihSl5DC8ijnjuwHEDF4sb2Z4lX7rb0Fz D64E8wW98Oa5vBUueOCQ== X-RZG-AUTH: ":IW0WdmCmcvpIrP2+VJuPtIhjJvc4Ig+QdhX22iZVwSDOx4Kp3cYsBVGy6CZgmO/guIaKV8J57pRr" Original-Received: from mail-ej1-f41.google.com by smtp.strato.de (RZmta 50.5.0 AUTH) with ESMTPSA id nd440206L9sP1l4 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Sun, 21 Jul 2024 11:54:25 +0200 (CEST) Original-Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-a77e2f51496so334990066b.0 for ; Sun, 21 Jul 2024 02:54:25 -0700 (PDT) X-Gm-Message-State: AOJu0Yw4gu9Dkmp47pcyNZKeYYbRJrD4u+k2Z3Un/+bOkUcG7/do3A/t Bkj9gZywYzQ3/nboZxkPieRTXVnQ7cDVpt2Otk2WOIa/y//7BWsdd4lCsKjltHH0TvyDqGLlzSK YvQYdn1+wKcNXME028dztO3dj+GM= X-Google-Smtp-Source: AGHT+IHIFhQmTjDIMssin7w/3kLEFRqej1vVba6cmAURaaXpeGywwcEkydYSxLCnDZTQ5aYoKaaOjsqByadwX4Z7/qc= X-Received: by 2002:a17:907:3f23:b0:a77:cc6f:e791 with SMTP id a640c23a62f3a-a7a4c103466mr236707166b.38.1721555665271; Sun, 21 Jul 2024 02:54:25 -0700 (PDT) In-Reply-To: X-Gmail-Original-Message-ID: Received-SPF: none client-ip=81.169.146.219; envelope-from=marc@nieper-wisskirchen.de; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22622 Archived-At: --000000000000e3cc54061dbee93d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 : > 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 > To: Maxime Devos , "Dr. Arne Babenhauserheide" > > Cc: Attila Lendvai , Greg Troxel > , MSavoritias , > "guile-devel@gnu.org" > Subject: Portable imports > Message-ID: <04293f0f-3a83-4ebc-8413-1a936caaeb57@lassi.io> > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > > > I don=E2=80=99t know if =E2=80=98(import ...)=E2=80=99 is standard eith= er (sure it is as part of > > =E2=80=98define-library=E2=80=99, but I didn=E2=80=99t find it on its o= wn 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 =E2=80=981=E2=80=99 is not an symbol (#{= 1}# is, but > > that=E2=80=99s 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 > To: Lassi Kortela , "Dr. Arne Babenhauserheide" > > Cc: Attila Lendvai , Greg Troxel > , MSavoritias , > "guile-devel@gnu.org" > Subject: RE: Portable imports > Message-ID: > <20240720211840.pvJf2C00709gYMG06vJgRX@michel.telenet-ops.be> > Content-Type: text/plain; charset=3D"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 > =E2=80=98library=E2=80=99 is (R6RS) standard and reasonably portable it w= ould then appear > that (srfi 1) is (R6RS) standard and portable, whereas it isn=E2=80=99t R= 6RS, 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=E2=80=99t think this is a problem for Guile? I don=E2=80=99t recall= to what extent, > but (srfi ...) modules are somewhat special-cased in Guile (or maybe it w= as > integers in general for define-library) =E2=80=93 maybe its implementatio= n of > define-library translates (srfi 1) to (srfi srfi-1) (I don=E2=80=99t reca= ll the > specifics). Hence, the file can simply be named =E2=80=9Csrfi/srfi-1.scm= =E2=80=9D. > > For compatibility, both(**) (srfi srfi-N) (=E2=86=90 non-standard Guile t= hingie) > and (srfi :N) need to be supported anyway for =E2=80=98define-module=E2= =80=99 (=E2=86=90 > Guile-specific interface), so which of them determines the file name is > just a matter of convenience. > > Also, AFAIK that %3a encoding isn=E2=80=99t necessary (and neither recogn= ised(^)) > in Guile =E2=80=93 I don=E2=80=99t think Guile does any percent encoding(= *). I think naming > the file =E2=80=9Csrfi/:1.scm=E2=80=9D would work fine, although it=E2=80= =99s not something I=E2=80=99ve > tried before. (There might be a problem with Makefile if =E2=80=98make=E2= =80=99 doesn=E2=80=99t > like the :, but I have some ideas for simple ways around that.) > > (*) implication: you can=E2=80=99t have two different modules (foo/bar) a= nd (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/deaf1= eb8/attachment.htm > > > > ------------------------------ > > Message: 3 > Date: Sat, 20 Jul 2024 21:23:53 +0200 > From: Maxime Devos > To: Lassi Kortela , "Dr. Arne Babenhauserheide" > > Cc: Attila Lendvai , Greg Troxel > , MSavoritias , > "guile-devel@gnu.org" > Subject: RE: Portable imports > Message-ID: > <20240720212340.pvPf2C00709gYMG01vPfWY@laurent.telenet-ops.be> > Content-Type: text/plain; charset=3D"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=E2=80=99ve found it in r7rs.pdf now: > > > 7.1.6. Programs and definitions > > =E2=86=92 + + > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/guile-devel/attachments/20240720/367b4= 6f7/attachment.htm > > > > ------------------------------ > > Message: 4 > Date: Sat, 20 Jul 2024 22:46:27 +0300 > From: Lassi Kortela > To: Maxime Devos , "Dr. Arne Babenhauserheide" > > Cc: Attila Lendvai , Greg Troxel > , MSavoritias , > "guile-devel@gnu.org" > Subject: Encoding library names > Message-ID: <80a09f9e-a84e-47ef-9fbd-72caf22fe948@lassi.io> > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > > > > 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 > > =E2=80=98library=E2=80=99 is (R6RS) standard and reasonably portable it= would then > > appear that (srfi 1) is (R6RS) standard and portable, whereas it isn=E2= =80=99t > > 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=E2=80=99t think this is a problem for Guile? I don=E2=80=99t reca= ll to what > > extent, but (srfi ...) modules are somewhat special-cased in Guile (or > > maybe it was integers in general for define-library) =E2=80=93 maybe it= s > > implementation of define-library translates (srfi 1) to (srfi srfi-1) (= I > > don=E2=80=99t recall the specifics). Hence, the file can simply be name= d > > =E2=80=9Csrfi/srfi-1.scm=E2=80=9D. > > > > For compatibility, both(**) (srfi srfi-N) (=C3=9F non-standard Guile th= ingie) > > and (srfi :N) need to be supported anyway for =E2=80=98define-module=E2= =80=99 (=C3=9F > > Guile-specific interface), so which of them determines the file name is > > just a matter of convenience. > > > > Also, AFAIK that %3a encoding isn=E2=80=99t necessary (and neither > > recognised(^)) in Guile =E2=80=93 I don=E2=80=99t think Guile does any = percent > > encoding(*). I think naming the file =E2=80=9Csrfi/:1.scm=E2=80=9D woul= d work fine, > > although it=E2=80=99s not something I=E2=80=99ve tried before. (There m= ight be a problem > > with Makefile if =E2=80=98make=E2=80=99 doesn=E2=80=99t 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=E2=80=99t 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 > To: Lassi Kortela , "Dr. Arne Babenhauserheide" > > Cc: Attila Lendvai , Greg Troxel > , MSavoritias , > "guile-devel@gnu.org" > Subject: RE: Encoding library names > Message-ID: > <20240720223521.pwbM2C00209gYMG01wbMcg@andre.telenet-ops.be> > Content-Type: text/plain; charset=3D"utf-8" > > >> > In R7RS non-negative integers can be library name parts. Since thes= e > >> library names look natural, it would be good to backport this to R6RS > >> implementations. > >> > >> Then (library [...] (import (srfi 1)) [...]) would work, and since > >> =E2=80=98library=E2=80=99 is (R6RS) standard and reasonably portable i= t would then > >> appear that (srfi 1) is (R6RS) standard and portable, whereas it isn= =E2=80=99t > >> 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 =E2=80=93 AFAIK R7RS-large is still in progres= s. So, > too soon to implement it for =E2=80=98library=E2=80=99 yet =E2=80=93 =E2= =80=98library=E2=80=99 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=E2=80=99s what the relevant SRFI say= s 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=E2=80=99t one of those, so it=E2=80=99s not a problem. As I und= erstand 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 =E2=80=98module name -> file name=E2=80=99 mapping it seems = a reasonable > choice, but that=E2=80=99s 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 b= e > able to just type characters without special tricks, I don=E2=80=99t 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 t= he > actual character in the filename (Unicode as intended, applied to file > names), that would be fine, but since Guile=E2=80=99s current module impl= ementation > just directly maps module names to file names (+ search path), that=E2=80= =99s > currently not an option (start-up performance implications). (I don=E2= =80=99t > 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=E2=80=99s 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=E2=80=99s Windows that places restr= ictions > on file names. > So, some change is indeed necessary (but not necessarily just always > stripping the :, other options exist as well.) > > (*) not completely sure =E2=80=93 =E2=80=98:=E2=80=99 can refer to altern= ate data streams, but I > don=E2=80=99t know whether that=E2=80=99s an NTFS or a Windows thing > > >> (*) implication: you can=E2=80=99t 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/7a7f4= 630/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 > ******************************************** > --000000000000e3cc54061dbee93d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 pri= mary function is to create clean (top-level) lexical environments. The abil= ity to do so can help to write portable code, but it can also be a hindranc= e to doing so. For example, the sample implementation of SRFI 9 is an R5RS = implementation that works by redefining some vector primitives. With the mo= dule 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 ha= ve 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 nece= ssary 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 ca= n draw efficiency expectations (e.g., as long as implementations do not agr= ee on implementing call/cc efficiently, useful portable code cannot be cent= red around algorithms employing call/cc).=C2=A0

These conditions are in place for a prog= ramming language like C. While the C standard itself is not that broad, imp= lementers agree on an ABI for each platform so that platform features can b= e added portably. C implementations like GCC or Clang work hard to fix devi= ations from the standard. Lastly, implementations typically agree on an imp= lementation model so that the programmer knows what kind of code is efficie= nt 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 univer= sally implemented and accepted. Contrary to the standards, SRFIs ultimately= only reflect the opinion of their respective authors. Secondly, many imple= mentations, including many big implementations (like Guile), deviate from t= he standard when it makes sense for them (e.g., Guile implements, first and= foremost, the Guile programming language and offers an implementation of R= nRS on top but would never compromise the further development of the Guile = language over pedantic adherence to RnRS). Thirdly, many Scheme implementat= ions 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 repr= esentations of libraries on the filesystem. Not only is the encoding of the= filename undefined, but it is even unspecified whether a library has to re= side on the filesystem and whether libraries are loaded automatically (vers= us an explicit load command to make the library definition known to the imp= lementation). This makes discussions about the encoding of, say, ":&qu= ot; 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 targe= t implementation and can rename or move files as needed (moving is generall= y necessary even for the R7RS, including syntax, which was mentioned becaus= e 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. H= ere, 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 t= hey 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 numb= ers in library names makes certain syntactic extensions (as some found in C= hez 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 ba= ckwards 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 implement= ation can still look up "(srfi :1)" under the path "srfi/1.s= ls" if it wishes to do so. Library definitions are self-delimiting for= ms, so more than one library definition can be included in a file.

Let me also add a per= sonal remark about the "ice-9" namespace: I do not see a particul= ar 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 rep= lacing "ice-9" with "guile". Another reason for my wari= ness 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 li= ve outside of Guile's universe as well. Finally, talking about "ic= e-9" (or even about names like "define-module2") feels like = bikeshedding.

Cheers,

Marc

Am Sa., 20. Juli 2024 um 22:35=C2=A0Uhr schrieb <guile-devel-reque= st@gnu.org>:
Send guile-devel mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 guile-devel@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.gnu.org/= mailman/listinfo/guile-devel
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 guile-devel-request@gnu.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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:

=C2=A0 =C2=A01. Portable imports (Lassi Kortela)
=C2=A0 =C2=A02. RE: Portable imports (Maxime Devos)
=C2=A0 =C2=A03. RE: Portable imports (Maxime Devos)
=C2=A0 =C2=A04. Encoding library names (Lassi Kortela)
=C2=A0 =C2=A05. 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"=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <arne_bab@web.de>
Cc: Attila Lendvai <attila@lendvai.name>, Greg Troxel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <gdt@lexort.com>, MSavoritias <email@msavoritias.me>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "guile-devel@gnu.org" <guile-devel@gnu.org>
Subject: Portable imports
Message-ID: <04293f0f-3a83-4ebc-8413-1a936caaeb57@lassi.io&g= t;
Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed

> I don=E2=80=99t know if =E2=80=98(import ...)=E2=80=99 is standard eit= her (sure it is as part of
> =E2=80=98define-library=E2=80=99, but I didn=E2=80=99t 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 _h= as_ to
start with (import ...).

A "library" is a (library ...) [in R6RS] or a (define-library ...= ) [in
R7RS]. You can type (import ...) inside either.

>=C2=A0 > https://srfi.schemers.org/srfi-97/srfi= -97.html:
>
>=C2=A0 >A SRFI Library can be referenced by number, as in
>
>=C2=A0 >(srfi :1),
>
> (srfi 1) is problematic, since =E2=80=981=E2=80=99 is not an symbol (#= {1}# is, but
> that=E2=80=99s 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 t= he worst of it.



------------------------------

Message: 2
Date: Sat, 20 Jul 2024 21:18:53 +0200
From: Maxime Devos <maximedevos@telenet.be>
To: Lassi Kortela <l= assi@lassi.io>,=C2=A0 "Dr. Arne Babenhauserheide"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <arne_bab@web.de>
Cc: Attila Lendvai <attila@lendvai.name>, Greg Troxel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <gdt@lexort.com>,=C2=A0 MSavoritias <email@msavoritias.me>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "guile-devel@gnu.org" <guile-devel@gnu.org>
Subject: RE: Portable imports
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <20240720211840.pvJf2C= 00709gYMG06vJgRX@michel.telenet-ops.be>
Content-Type: text/plain; charset=3D"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 =E2=80= =98library=E2=80=99 is (R6RS) standard and reasonably portable it would the= n appear that (srfi 1) is (R6RS) standard and portable, whereas it isn=E2= =80=99t 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 t= he worst of it.

I don=E2=80=99t think this is a problem for Guile? I don=E2=80=99t recall t= o what extent, but (srfi ...) modules are somewhat special-cased in Guile (= or maybe it was integers in general for define-library) =E2=80=93 maybe its= implementation of define-library translates (srfi 1) to (srfi srfi-1) (I d= on=E2=80=99t recall the specifics). Hence, the file can simply be named =E2= =80=9Csrfi/srfi-1.scm=E2=80=9D.

For compatibility, both(**) (srfi srfi-N) (=E2=86=90 non-standard Guile thi= ngie) and (srfi :N) need to be supported anyway for =E2=80=98define-module= =E2=80=99 (=E2=86=90 Guile-specific interface), so which of them determines= the file name is just a matter of convenience.

Also, AFAIK that %3a encoding isn=E2=80=99t necessary (and neither recognis= ed(^)) in Guile =E2=80=93 I don=E2=80=99t think Guile does any percent enco= ding(*). I think naming the file =E2=80=9Csrfi/:1.scm=E2=80=9D would work f= ine, although it=E2=80=99s not something I=E2=80=99ve tried before. (There = might be a problem with Makefile if =E2=80=98make=E2=80=99 doesn=E2=80=99t = like the :, but I have some ideas for simple ways around that.)

(*) implication: you can=E2=80=99t 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) wo= uld 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/deaf1eb= 8/attachment.htm>

------------------------------

Message: 3
Date: Sat, 20 Jul 2024 21:23:53 +0200
From: Maxime Devos <maximedevos@telenet.be>
To: Lassi Kortela <l= assi@lassi.io>,=C2=A0 "Dr. Arne Babenhauserheide"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <arne_bab@web.de>
Cc: Attila Lendvai <attila@lendvai.name>, Greg Troxel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <gdt@lexort.com>,=C2=A0 MSavoritias <email@msavoritias.me>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "guile-devel@gnu.org" <guile-devel@gnu.org>
Subject: RE: Portable imports
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <20240720212340.pvPf2= C00709gYMG01vPfWY@laurent.telenet-ops.be>
Content-Type: text/plain; charset=3D"utf-8"

>R7RS talks about "programs" and "libraries". These = are technical terms
with precise meanings.
>A "program" corresponds to your typical Scheme script. IIRC i= t _has_ to
start with (import ...).

I=E2=80=99ve found it in r7rs.pdf now:

> 7.1.6. Programs and definitions
> <program> =E2=86=92 <import declaration>+ <command or d= efinition>+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <= https://lists.gnu.org/archive/html/guile-devel/attachments/20240720/367b46f= 7/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"=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <arne_bab@web.de>
Cc: Attila Lendvai <attila@lendvai.name>, Greg Troxel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <gdt@lexort.com>, MSavoritias <email@msavoritias.me>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "guile-devel@gnu.org" <guile-devel@gnu.org>
Subject: Encoding library names
Message-ID: <80a09f9e-a84e-47ef-9fbd-72caf22fe948@lassi.io&g= t;
Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed

>=C2=A0 > In R7RS non-negative integers can be library name parts. Si= nce these
> library names look natural, it would be good to backport this to R6RS<= br> > implementations.
>
> Then (library [...] (import (srfi 1)) [...]) would work, and since > =E2=80=98library=E2=80=99 is (R6RS) standard and reasonably portable i= t would then
> appear that (srfi 1) is (R6RS) standard and portable, whereas it isn= =E2=80=99t
> 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 n= ot even the worst of it.
>
> I don=E2=80=99t think this is a problem for Guile? I don=E2=80=99t rec= all to what
> extent, but (srfi ...) modules are somewhat special-cased in Guile (or=
> maybe it was integers in general for define-library) =E2=80=93 maybe i= ts
> implementation of define-library translates (srfi 1) to (srfi srfi-1) = (I
> don=E2=80=99t recall the specifics). Hence, the file can simply be nam= ed
> =E2=80=9Csrfi/srfi-1.scm=E2=80=9D.
>
> For compatibility, both(**) (srfi srfi-N) (=C3=9F non-standard Guile t= hingie)
> and (srfi :N) need to be supported anyway for =E2=80=98define-module= =E2=80=99 (=C3=9F
> Guile-specific interface), so which of them determines the file name i= s
> just a matter of convenience.
>
> Also, AFAIK that %3a encoding isn=E2=80=99t necessary (and neither > recognised(^)) in Guile =E2=80=93 I don=E2=80=99t think Guile does any= percent
> encoding(*). I think naming the file =E2=80=9Csrfi/:1.scm=E2=80=9D wou= ld work fine,
> although it=E2=80=99s not something I=E2=80=99ve tried before. (There = might be a problem
> with Makefile if =E2=80=98make=E2=80=99 doesn=E2=80=99t like the :, bu= t 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=E2=80=99t 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 nam= e.

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 <l= assi@lassi.io>,=C2=A0 "Dr. Arne Babenhauserheide"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <arne_bab@web.de>
Cc: Attila Lendvai <attila@lendvai.name>, Greg Troxel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <gdt@lexort.com>,=C2=A0 MSavoritias <email@msavoritias.me>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "guile-devel@gnu.org" <guile-devel@gnu.org>
Subject: RE: Encoding library names
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <20240720223521.pwbM2C0= 0209gYMG01wbMcg@andre.telenet-ops.be>
Content-Type: text/plain; charset=3D"utf-8"

>>=C2=A0 > In R7RS non-negative integers can be library name parts= . Since these
>> library names look natural, it would be good to backport this to R= 6RS
>> implementations.
>>
>> Then (library [...] (import (srfi 1)) [...]) would work, and since=
>> =E2=80=98library=E2=80=99 is (R6RS) standard and reasonably portab= le it would then
>> appear that (srfi 1) is (R6RS) standard and portable, whereas it i= sn=E2=80=99t
>> 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 =E2=80=93 AFAIK R7RS-large is still in progress.= So, too soon to implement it for =E2=80=98library=E2=80=99 yet =E2=80=93 = =E2=80=98library=E2=80=99 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=E2=80=99s 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=E2=80=99t one of those, so it=E2=80=99s not a problem. As I under= stand it, (a priori) (foo N), (foo :N) and (foo |N|) are three different mo= dule names, so this removal is simply incorrect (barring changes to RnRS). = As such leading colons should be kept.

As part of a =E2=80=98module name -> file name=E2=80=99 mapping it seems= a reasonable choice, but that=E2=80=99s a different matter.

(Not claiming that an implementation should in general support different (f= oo :N) (foo N) (foo |N|) modules, only that it should recognise them as dif= ferent names.)

>> [...]
>Guile should support non-negative integers in any library name, not onl= y
for the SRFI libraries. R7RS allows them anywhere.

I never claimed it should be restricted to SRFI libraries. My comment was a= bout 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=E2=80=99t want G= uile to regress to ASCII here.

Now, if Guile were to support both %-encoding (e.g. for : on Windows situat= ions) but also supported (and preferred) just literally including the actua= l character in the filename (Unicode as intended, applied to file names), t= hat would be fine, but since Guile=E2=80=99s current module implementation = just directly maps module names to file names (+ search path), that=E2=80= =99s currently not an option (start-up performance implications).=C2=A0 (I = don=E2=80=99t think this is an unsurmountable problem, but it does require = some reorganization in how Guile libraries are packaged and how Guile searc= hes for .go/.scm.)

(Other option: %-encode only disallowed characters so there is a unique cor= responding file name (modulo search paths), but which characters are disall= owed depend on file system and OS, so that=E2=80=99s not practical.)

>The : prefixes should be stripped before encoding a library name as a <= br> 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=E2=80=99s Windows that places restric= tions on file names.
So, some change is indeed necessary (but not necessarily just always stripp= ing the :, other options exist as well.)

(*) not completely sure =E2=80=93 =E2=80=98:=E2=80=99 can refer to alternat= e data streams, but I don=E2=80=99t know whether that=E2=80=99s an NTFS or = a Windows thing

>> (*) implication: you can=E2=80=99t 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/7a7f463= 0/attachment.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
guile-devel mailing list
guile-devel@gnu.or= g
https://lists.gnu.org/mailman/listinfo/guile-devel=


------------------------------

End of guile-devel Digest, Vol 260, Issue 25
********************************************
--000000000000e3cc54061dbee93d--