From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Dr. Arne Babenhauserheide" Newsgroups: gmane.lisp.guile.devel Subject: Re: Name of the standard library Date: Sat, 20 Jul 2024 23:56:37 +0200 Message-ID: <875xszk9re.fsf@web.de> References: <20240629002027.13853-1-richard@freakingpenguin.com> <87h6co21qv.fsf@laura> <87r0bsxpoe.fsf@web.de> <4d9d9c2e-0830-4267-b8e5-1a50cb815508@msavoritias.me> <87a5ifyd0g.fsf@web.de> <20240719104617.pLmG2C00D4SnA1G01LmG1n@andre.telenet-ops.be> <87wmlgkyix.fsf@web.de> <15398dda-cb3e-4195-b2f8-263a59a73c68@lassi.io> <8734o4kte6.fsf@web.de> <4cc59aa4-755f-4dd3-a3b6-5d5d5edda053@lassi.io> <87plr8jcba.fsf@web.de> <20240720181139.psBf2C00D09gYMG06sBfG5@michel.telenet-ops.be> <87h6ckjagd.fsf@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5303"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Maxime Devos , Attila Lendvai , Greg Troxel , MSavoritias , "guile-devel@gnu.org" To: Lassi Kortela Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Sat Jul 20 23:57:19 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 1sVI4s-0001CU-LN for guile-devel@m.gmane-mx.org; Sat, 20 Jul 2024 23:57:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sVI4c-0006N2-Ue; Sat, 20 Jul 2024 17:57:02 -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 1sVI4b-0006Mf-Rg for guile-devel@gnu.org; Sat, 20 Jul 2024 17:57:01 -0400 Original-Received: from mout.web.de ([212.227.15.14]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sVI4Z-0004SV-Q6 for guile-devel@gnu.org; Sat, 20 Jul 2024 17:57:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=web.de; s=s29768273; t=1721512598; x=1722117398; i=arne_bab@web.de; bh=+g5+RM7YBqnpAatAOwrDM4SJ8ztQmGOgDxosyX/QtpY=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=Yv95HJnjcp8cJ/PZm005IP9cINgobkTnDwpo7DZS1Q6swoTaDihmZ8A/Opjqg01M eeEF7c5xKMuuXUeqyE+6Fv4zSY6DqGPjA4Z3rdKNFDG10kZbN0Dhm7oZjnIM9WYSI uCzNiLBRHck+BGfO1doOw6Egda+vmeGBLzrHjWo3ZJWGadQ5aSowqHKtRQkjKYLhd /R7Z+tzD81eqWbS8JHXJRCV5rHmvAOtbhH4FVBa4Fkjbz2DFnCixl92gmDuVLfDQ0 Ix4UDx/4GYcDOB/wIog8TD/2r3fXI1x9oD+Ew7xtAtWVSfQOQVqm1+9JSkNiYq5Gx f4huXfJBxyZIrgDhtw== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from fluss ([84.165.21.10]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1M6091-1sPVRF0pYJ-00Cq5x; Sat, 20 Jul 2024 23:56:38 +0200 In-Reply-To: (Lassi Kortela's message of "Sat, 20 Jul 2024 19:54:56 +0300") X-Provags-ID: V03:K1:jv0T4z2sqjBSWVGnN4YjmqI+5/Q8+Tlp0ARUBACWvVNKUM03Txh dm43bw8+nWDQm/cOXyja0/Nxshjcy72+W6sobr01US6qY7BkYpUHDa2pTorKXDu3JOJlUL0 VzWsGa6Va5tMKajpNZjzKIKssDtcLO221/Vr3phtVVIiQlBvsXJYn75wl27lOc5NNVIqcA9 aDU5fYkhy+eC870VWkWrA== UI-OutboundReport: notjunk:1;M01:P0:Ux8yPNeoA7U=;f6qeE4qDrYtMWEp8j91owAI/TaT ehUTvoHNnvG/11qG2CMYucsqVjEs+v+XWLgrr3gKiAgrUOnrpJOhffeq6fygxawQN7FgkMhG0 f7RAhyP44X2fL02YHwJt0qKu42d3BfcgJoM+UKPA4nnTpn7GXAEdthQSplaeYq7N8NjnQth3z VYb7ok2H+UO+1l2iDy2/YINTsKin3PQgRLOG0H6cayzbPJyor+KvnF5batRxvK/iQ8pec8Y2p GsCY7OyAB6MWrr58miUgjgEvD2uHXicE1JPQ1SSHtTLB/oT4OsWmgDorpWD/7xVc6tv8IjOk8 ugQzHCFtBy5s/z/kWCJWV7zRONnZvt6MfWVM1/UDd22xueogc5IhhcHYo6/MBRqu4JY8UQinG vGS/h2J+cDVxP3iRKPHV+sAS1LhV6W/7ZPVRVZwYd9BttEpoyJdt5FS3qbkDYHNl2bcdIUfZL bIspVWzkjXNf+l/4STqRAC/+PPQFjn+UkPQMZ+3BdPoqGjxoT0jf2PU7EVAob5+/LrazAmpZQ QdZWuc5JxFz7xU9MWcg+HwA37ma1LNIympB2/toKYdk9ypXgHDkLjWaZVlx8whPexfgx20208 7G07H7lthsFRD+iAf7G2nEswnGqmOYDdvwaN5XZfOLH+ScUZRpTWyH1dXZAuBAcfphWn4418L YBcbwWu+7SVxEnYrOT+cKaesWIhMJkOuSLDQxY2Xv6nIAAG5ux+4cVAi+yClD+ns55+aZP+4b GjOwMIvSnBBFvAAn1Mxcbi3pv7qimcRloBZf+EXlDAineVfQdSgDkZZKxyhrc8XP4mCmbmTn Received-SPF: pass client-ip=212.227.15.14; envelope-from=arne_bab@web.de; helo=mout.web.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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:22617 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Lassi Kortela writes: >>> That said, I think that in Scheme, standard is quite different from por= table =E2=80=93 if something standard is implemented, it will be (mostly) a= ccording >>> to the standard, so in this way it is =E2=80=98portable=E2=80=99, but t= hat=E2=80=99s a big =E2=80=98if=E2=80=99. For large Schemes (and small Sche= mes for which the RnRS or SRFI stuff is >>> implemented in a separate library that can easily be installed(*)), I d= on=E2=80=99t expect much trouble, but for very minimalistic (or outdated Sc= hemes, >>> but that holds for other languages as well) you might possibly be in tr= ouble. > > Indeed, Scheme doesn't have a clear separation between full-featured > RnRS implementations and subset implementation. Several people have > noted that this is confusing. Maybe the r7rs-benchmark preludes and postludes could be a start for documentation of that? https://github.com/ecraven/r7rs-benchmarks/tree/master/src Example: Guile3-prelude.scm: https://github.com/ecraven/r7rs-benchmarks/blob/master/src/Guile3-prelude.s= cm (use-modules (ice-9 rdelim)) (define-syntax import (syntax-rules () ((import stuff ...) (begin) ;; do nothing ))) (define flush-output-port force-output) (define current-second current-time) (define (jiffies-per-second) internal-time-units-per-second) (define current-jiffy get-internal-real-time) (define exact inexact->exact) (define inexact exact->inexact) (define (square x) (* x x)) (define (write-string str out) (display str out)) ; sufficient for tail= .scm (define (this-scheme-implementation-name) (string-append "guile3-" (ver= sion))) (read-enable 'r7rs-symbols) (print-enable 'r7rs-symbols) (use-modules (rnrs bytevectors) (rnrs base) (srfi srfi-9)) Could some of those be eligible to be merged into (guile-user) =E2=80=94 the interactive module of the REPL? > There are subsets of e.g. C, ML, Haskell, and Perl, but these are > clearly indicated s such. > >> Is (import (srfi :N)) portable in practice? > > AFAIK: > > (import (srfi :N)) is portable across all R6RS implementations. > > (import (srfi N)) - without the colon - is portable across all R7RS > implementations. > > Mnemonic SRFI imports - e.g. (srfi 1 lists) - are currently not > available in any R7RS implementation. > > In R6RS land, at least some implementations support mnemonic SRFI > imports using the form (srfi :1 lists). I'm not sure how many. There > are discrepancies in the names (e.g. "lists") among some R6RS > implementations. > > It's really a mess that should be cleaned up. Any technical problems > have been overcome - it's entirely a social issue. It should be > pursued on the srfi-discuss mailing list. Thank you for the overview! Do you want to cross-post this part of your answer to the srfi-list? (I think I should be on there =E2=80=94 but I still have to finish srfi-234 before committing to additional things) >> I switched from (use-modules ...) to (import ...) to get towards making >> my code easier to re-use on different Schemes, but I didn=E2=80=99t actu= ally try >> using it on another Scheme implementation. > > Thank you for making the effort. > > The current crop of portable code has been written by very few > schemers. With a few extra people we will rapidly get more impressive > results. In my experience, the foundation provided by R6RS and R7RS is > excellent and the few known practical problems can be solved. > > https://github.com/arcfide/chez-srfi is a notable project in R6RS > portability. Despite its name, it is not limited to Chez Scheme. > > R7RS has an (include "...") mechanism which R6RS lacks. chez-srfi adds > a similar mechanism on top of the R6RS library system. The chez-srfi > mechanism is widely portable in practice. Does that work the same as Guile=E2=80=99s (include "...")? From=20the reference manual: -- Scheme Syntax: include file-name Open FILE-NAME, at expansion-time, and read the Scheme forms that it contains, splicing them into the location of the =E2=80=98inclu= de=E2=80=99, within a =E2=80=98begin=E2=80=99. =20=20=20=20 If FILE-NAME is a relative path, it is searched for relative to the path that contains the file that the =E2=80=98include=E2=80=99 for= m appears in. =20=20=20=20 If you are a C programmer, if =E2=80=98load=E2=80=99 in Scheme is li= ke =E2=80=98dlopen=E2=80=99 in C, consider =E2=80=98include=E2=80=99 to be like the C preprocessor=E2=80= =99s =E2=80=98#include=E2=80=99. When you use =E2=80=98include=E2=80=99, it is as if the contents of the included= file were typed in instead of the =E2=80=98include=E2=80=99 form. =20=20=20=20 Because the code is included at compile-time, it is available to the macroexpander. Syntax definitions in the included file are available to later code in the form in which the =E2=80=98include=E2=80=99 appears, = without the need for =E2=80=98eval-when=E2=80=99. (*Note Eval When::.) =20=20=20=20 For the same reason, compiling a form that uses =E2=80=98include=E2= =80=99 results in one compilation unit, composed of multiple files. Loading the compiled file is one =E2=80=98stat=E2=80=99 operation for the compilation unit, = instead of =E2=80=982*N=E2=80=99 in the case of =E2=80=98load=E2=80=99 (once for each loaded source file= , and once each corresponding compiled file, in the best case). =20=20=20=20 Unlike =E2=80=98load=E2=80=99, =E2=80=98include=E2=80=99 also works = within nested lexical contexts. It so happens that the optimizer works best within a lexical context, because all of the uses of bindings in a lexical context are visible, so composing files by including them within a =E2=80=98(let () ...)=E2=80= =99 can sometimes lead to important speed improvements. =20=20=20=20 On the other hand, =E2=80=98include=E2=80=99 does have all the disad= vantages of early binding: once the code with the =E2=80=98include=E2=80=99 is compiled, = no change to the included file is reflected in the future behavior of the including form. =20=20=20=20 Also, the particular form of =E2=80=98include=E2=80=99, which requir= es an absolute path, or a path relative to the current directory at compile-time, is not very amenable to compiling the source in one place, but then installing the source to another place. For this reason, Guile provides another form, =E2=80=98include-from-path=E2=80=99, which looks for the = source file to include within a load path. Best wishes, Arne =2D-=20 Unpolitisch sein hei=C3=9Ft politisch sein, ohne es zu merken. draketo.de --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJEBAEBCAAuFiEE801qEjXQSQPNItXAE++NRSQDw+sFAmacMpUQHGFybmVfYmFi QHdlYi5kZQAKCRAT741FJAPD63PREACiz5Cu/HVFO0HYj7Yw39VFrfaj6QtTEU+E oymXsKn5723j+RUXVyH290uNymyLdtSX/bNO+ljUFoCAT7UVkKE4JVoWCRkRSXAo 3THc5M+i3UGYQESdwngreND+2e6K5gCgGmAyboyRYaHH1Gf1f36vVqAxK/DcjQmJ t6JDbo/8Is8uI1ZeR5Tu55pYJN27g4ZNevzddRAJ/yHZ3EWwGn1XWkA2Wwk9EREy 0ap0wF6485gf9+Nif5bih6KxHqPV3GxOskKRLRNhXXsYMME65igN3+fx+0RBswuA 4CqryCjBQLcnkF5mA8b4hjl5b7IldL46BwS42Fh3TIxqA5Q2Nrr3HFEVV9O/iqZz 11/tur5bpMIT28lKpf9bwNrXI32cW3NIO+ZyEwkxm1o1dgKap2DdNAd/ebgOEHLH l0+SI4Je0ur/DsapO2YcLBJrK+VWIch+UY+yGrlj1Cq5vV84FKE1jLz7yBE+dpk2 zLiLaxOQ6buCI3my0aiAT8Yf2gMxdGXQTcN2lqTdnxFQKJ2r3gQYyLWi+mZ4lxcF HlbfoV4CbRLGaBAJm1Dlqb/hN+vg+6MPeK4cb69c+dXZ9KPMaiJ9oiyjVAveMDjd cH5vTNOd6Ij42o15J3DvVPkAWYmxZyBHLLVy2Gg8BopaYIklIWFmC3FB9EDlUN1j Z7Fs21wx7IjEBAEBCAAuFiEE3Si95tmHXKvOSosd3M8NswvBBUgFAmacMpUQHGFy bmVfYmFiQHdlYi5kZQAKCRDczw2zC8EFSFXJA/9+oxh0vYP/XOS6Kz6MEX46LcHH 2Y9gdarIqMgCMpGVtLWGtGCfL3RkyBliV+UY1pYm8LomxeFgWL1j1tpA8d9itb+F UscWWFOcu9OFPWNp5x0/RvEUOV22jIvSz2y9noCCEvcnYvv4TRzZ8lGgcj19mKxD i9ZowzR8wYrTf86QGg== =8VCb -----END PGP SIGNATURE----- --=-=-=--