From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: The Guile junk drawer and a C plea (was: [PATCH] Add nondestructive delq1, delv1, and delete1.) Date: Sat, 29 Jun 2024 09:37:55 +0200 Message-ID: References: <20240629002027.13853-1-richard@freakingpenguin.com> Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000efd139061c027110" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3657"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Sent , guile-devel , Mikael Djurfeldt To: "Thompson, David" Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Sat Jun 29 09:38:33 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 1sNSfI-0000hc-Gk for guile-devel@m.gmane-mx.org; Sat, 29 Jun 2024 09:38:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNSey-0001st-3o; Sat, 29 Jun 2024 03:38:12 -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 1sNSew-0001sW-Qn for guile-devel@gnu.org; Sat, 29 Jun 2024 03:38:10 -0400 Original-Received: from mail-vk1-f175.google.com ([209.85.221.175]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sNSev-0006yh-0s for guile-devel@gnu.org; Sat, 29 Jun 2024 03:38:10 -0400 Original-Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-4ef765e6dcaso436702e0c.1 for ; Sat, 29 Jun 2024 00:38:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719646687; x=1720251487; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nQmkOLYJVXQcoAQlaXHN+JQ0ae52AMMSGkLBxH+jnNg=; b=xQsb4d4ueLY8xj1KLZ3xKAg8UQZzf4HrWbYyDpujrAl1aW2ysg6R9bGPHPFML+o90G B7pK87+J/eptQ2D7QWfa42UEbd2Kuk2KLgtQ//+ntEmb1g26mYOmWt90hUpaPJJjrvNb tAOkEN77vRWgqIRVlz7l3QN4Mkuge9ZQqIFRypW4+m7k7uJtNhCnpARAukVoH3ek+kRb JAb5NalNN+q1K8dmfywPdvxKQ4hKC+zYURQC8jSSfgEG2NtA8otMZ4Hu0l1PI+S/D7zX t+h8XP56QpRg1YuI/4M609gaP/P3n8PlbLLbOuoHsI7qWPV1bc3smw7QF+7Z7oSqeg6S qOaA== X-Forwarded-Encrypted: i=1; AJvYcCX/aJLQlITuU1gmCesbnfIS2fgW9nz6DQmYEZBl3n1DzlqaXzggK7AgUWDuCPyb2SNDJXmc9CPMpIo8A/Nb+3PtYpsR X-Gm-Message-State: AOJu0Yx6YrCQ7y/p+wcN5wA+FGKG++kVQvU7ZrTch8NuLvSqy3naUpSv wimJ9GrvYX4tYiBP6BtowWzbiTiOMnknx+dE8uunYMgk0fPuTyXwRdl/uw/VKj6MvvEQt4Hf6OK I5jqGDotfYu5t7bYzb2X0jbBLtUN7og== X-Google-Smtp-Source: AGHT+IGSGdRXqK/8/9giTIdnZuL1ENh2W28AD6BBVG1cM+nXgaidiTYfSEDnpyEqu0d/iz7sQG/Iu7fGawxyAhgmFPo= X-Received: by 2002:a05:6122:d1e:b0:4ef:61c2:6331 with SMTP id 71dfb90a1353d-4f2a563c321mr245747e0c.1.1719646687316; Sat, 29 Jun 2024 00:38:07 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=209.85.221.175; envelope-from=mdjurfeldt@gmail.com; helo=mail-vk1-f175.google.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:22497 Archived-At: --000000000000efd139061c027110 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your two points sound good. However, I personally hope that Guile will continue to be friendly towards those using it as an embedded language. There, a C API is important. There *is* a downside in moving to Scheme from that perspective, but that is fine as long as it is easy to call Scheme from C. The typical use case is when a binding in the application which use Guile as embedded language needs to manipulate Scheme data in its arguments in order to interpret them. Regarding the junk, I very much agree. I also look forward to getting rid of ice-9 :). As has been spoken about here previously, I suggest that we design a new module hierarchy, introduce aliases for module bindings, and still supply the old module hierarchy during a few years for backward compatibility. I don't see any harm in applying Richards patch, though, as things look right now. Best regards, Mikael Den l=C3=B6r 29 juni 2024 04:53Thompson, David s= krev: > Hi Richard and all other Guilers, too, > > What follows is not code review, but your patch felt like an > opportunity to provide some commentary about the trajectory of Guile > development that I've wanted to share for awhile. > > First, I think Guile's default environment is a total mess. It's the > very definition of a junk drawer. There's over 1000 names in the > (guile) module! Contrast this with R7RS-small's (scheme base) module > that only has 200ish. Guile is an old project and I'm sure stuff just > accumulated over the years, but having so much in the default > environment makes it hard to know what a program actually uses because > many things that ought to be explicit imports are not. This makes it a > challenge to move Guile in a more "least authority" direction. As a > rule, I think Guile should *not* add any additional names to the > default environment without an extremely good reason. Because (guile) > is imported implicitly, new names can cause clashes with existing code > that require #:replace to suppress the warning about shadowing core > bindings. For example, the newish 'spawn' procedure collides with > 'spawn' in (goblins core) in the Goblins project. I think Guile needs > a (multi-year, multi-major version) plan to deprecate cruft and move > the good stuff into different modules. Give a hoot, don't pollute > (the default environment)! > > Second, please please please, no more C! Guile's substantial amount of > C code is a legacy of its origins decades ago, and we need to make it > clear to new users and contributors that new code should be written in > Scheme! The procedures in Richard's patch would be much more elegantly > written in Scheme and it would allow the compiler to gnaw on the code, > too. Those experienced with Guile know that writing Scheme procedures > in C has all sorts of issues, like non-resumable continuations if a C > stack frame is captured, but we could probably do more to discourage > writing C in the docs and stuff. It's also just no fun at all. Who > actually wants to use that C API? Furthermore, every procedure > implemented in C is a challenge for bringing Guile to new places like, > say, WebAssembly. Hoot is unable to import any module from Guile that > loads a C extension. Did you know that (srfi srfi-1) loads a C > extension? Argh! I'm hoping we on the Hoot team will fix that > particular issue soon. > > Okay I should be going to bed instead of writing emails. That's all for > now! > > - Dave > > --000000000000efd139061c027110 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your two points sound good.

However, I personally hope that Guile will continue to= be friendly towards those using it as an embedded language. There, a C API= is important. There *is* a downside in moving to Scheme from that perspect= ive, but that is fine as long as it is easy to call Scheme from C. The typi= cal use case is when a binding in the application which use Guile as embedd= ed language needs to manipulate Scheme data in its arguments in order to in= terpret them.

Regarding = the junk, I very much agree. I also look forward to getting rid of ice-9 :)= . As has been spoken about here previously, I suggest that we design a new = module hierarchy, introduce aliases for module bindings, and still supply t= he old module hierarchy during a few years for backward compatibility.

I don't see any harm in = applying Richards patch, though, as things look right now.

Best regards,
Mik= ael

Den l=C3=B6r 29 juni 2024 04:53Thompson, David <dthompson2@worcester.edu> skrev:
Hi Richard and all other Guilers, too,

What follows is not code review, but your patch felt like an
opportunity to provide some commentary about the trajectory of Guile
development that I've wanted to share for awhile.

First, I think Guile's default environment is a total mess.=C2=A0 It= 9;s the
very definition of a junk drawer.=C2=A0 There's over 1000 names in the<= br> (guile) module!=C2=A0 Contrast this with R7RS-small's (scheme base) mod= ule
that only has 200ish.=C2=A0 Guile is an old project and I'm sure stuff = just
accumulated over the years, but having so much in the default
environment makes it hard to know what a program actually uses because
many things that ought to be explicit imports are not. This makes it a
challenge to move Guile in a more "least authority" direction.=C2= =A0 As a
rule, I think Guile should *not* add any additional names to the
default environment without an extremely good reason. Because (guile)
is imported implicitly, new names can cause clashes with existing code
that require #:replace to suppress the warning about shadowing core
bindings.=C2=A0 For example, the newish 'spawn' procedure collides = with
'spawn' in (goblins core) in the Goblins project.=C2=A0 I think Gui= le needs
a (multi-year, multi-major version) plan to deprecate cruft and move
the good stuff into different modules.=C2=A0 Give a hoot, don't pollute=
(the default environment)!

Second, please please please, no more C! Guile's substantial amount of<= br> C code is a legacy of its origins decades ago, and we need to make it
clear to new users and contributors that new code should be written in
Scheme! The procedures in Richard's patch would be much more elegantly<= br> written in Scheme and it would allow the compiler to gnaw on the code,
too.=C2=A0 Those experienced with Guile know that writing Scheme procedures=
in C has all sorts of issues, like non-resumable continuations if a C
stack frame is captured, but we could probably do more to discourage
writing C in the docs and stuff.=C2=A0 It's also just no fun at all.=C2= =A0 Who
actually wants to use that C API?=C2=A0 Furthermore, every procedure
implemented in C is a challenge for bringing Guile to new places like,
say, WebAssembly. Hoot is unable to import any module from Guile that
loads a C extension. Did you know that (srfi srfi-1) loads a C
extension?=C2=A0 Argh!=C2=A0 I'm hoping we on the Hoot team will fix th= at
particular issue soon.

Okay I should be going to bed instead of writing emails. That's all for= now!

- Dave

--000000000000efd139061c027110--