From: "Thompson, David" <dthompson2@worcester.edu>
To: Richard Sent <richard@freakingpenguin.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: The Guile junk drawer and a C plea
Date: Sat, 29 Jun 2024 19:51:48 -0400 [thread overview]
Message-ID: <CAJ=RwfbDvu6BK29312SGFhu=1sm4X9k3Ej+1+AuvycNNNfY2=w@mail.gmail.com> (raw)
In-Reply-To: <87cynzr2r8.fsf@freakingpenguin.com>
Hi Richard,
On Sat, Jun 29, 2024 at 3:02 PM Richard Sent
<richard@freakingpenguin.com> wrote:
>
> I see my little patch has ignited a comparatively oversized firestorm.
> Oops. ;)
I wasn't sure if my email would get 0 replies or a lot of replies...
but the latter happened. I just want to be clear that this is *not* a
judgement of your patch or saying that you made a mistake! A big
reason why I changed the subject line is because I wanted to separate
this discussion from the review of your patch. Thank you for sending a
patch to improve Guile!! And thank you for bringing some important
issues back to the front of my mind. :)
> The current discussion is above my paygrade so I'll largely stay out of
> it. (Although it's quite fascinating!)
>
> In the specific context of this patch I feel like the risks of namespace
> pollution and C maintenance burden are low since both are near identical
> to what already exists. But of course, someone else may argue that this
> is a death by a thousand cuts situation.
I agree that the risks are low in this case. It doesn't make sense to
have destructive list operations without nondestructive equivalents,
especially since mutation of pairs is strongly discouraged amongst
seasoned Schemers. If it were my call (and it's not, to be clear),
I'd say that they should just be implemented in Scheme, at least.
There really is no good reason to implement Scheme procedures in C
anymore.
> I will suggest that if a consensus is reached on what new code must
> adhere to (e.g. no (guile) namespace pollution, no new procedures
> written in C), it should be documented in the reference manual. There
> are traces of this but nothing concrete [1]. What little documentation
> exists is secreted away into the darkest corners of Texinfo. I believe a
> top-level "Contributing" section in a similar vein to GNU Guix would be
> a valuable addition.
Right, there is no consensus about this right now. It's been talked
about vaguely on IRC and in person over the years (maybe the mailing
list, too, but I don't feel like checking). I'm just prodding the
issue again (uh oh, did I prod a hornet's nest?) to see if it creates
some positive momentum.
> It's quite possible as a first-time contributor I am missing something
> that already exists. If so, oops again!
Nope! Not missing a thing. There's literally no way for you to know
that there's a desire amongst some Guilers to discourage implementing
new standard library procedures in C and expanding the default
namespace.
I really hope I haven't discouraged you from future contributions by
using your patch as a case study. Thank you again for hacking on
Guile!
- Dave
next prev parent reply other threads:[~2024-06-29 23:51 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-29 0:19 [PATCH] Add nondestructive delq1, delv1, and delete1 Richard Sent
2024-06-29 2:52 ` The Guile junk drawer and a C plea (was: [PATCH] Add nondestructive delq1, delv1, and delete1.) Thompson, David
2024-06-29 7:37 ` Mikael Djurfeldt
2024-06-29 8:12 ` The Guile junk drawer and a C plea Dr. Arne Babenhauserheide
2024-06-29 8:33 ` Damien Mattei
2024-06-29 9:59 ` Dr. Arne Babenhauserheide
2024-06-29 9:07 ` The Guile junk drawer and a C plea (was: [PATCH] Addnondestructive delq1, delv1, and delete1.) Maxime Devos
2024-06-29 10:41 ` Maxime Devos
2024-06-29 18:12 ` The Guile junk drawer and a C plea Dr. Arne Babenhauserheide
2024-06-29 18:18 ` Lassi Kortela
2024-06-29 18:27 ` Maxime Devos
2024-06-29 19:04 ` GRFI [was: The Guile junk drawer and a C plea] Matt Wette
2024-06-29 19:13 ` Lassi Kortela
2024-07-02 19:42 ` Jason Hemann
2024-06-29 19:39 ` Jean Abou Samra
2024-06-29 21:53 ` The Guile junk drawer and a C plea Philip McGrath
2024-06-29 22:41 ` Maxime Devos
2024-06-30 7:12 ` Dr. Arne Babenhauserheide
2024-06-30 9:45 ` Maxime Devos
2024-06-30 14:34 ` Dr. Arne Babenhauserheide
2024-07-01 9:06 ` Maxime Devos
2024-07-01 10:42 ` Dr. Arne Babenhauserheide
2024-06-30 6:16 ` #lang header Lassi Kortela
2024-06-30 0:17 ` The Guile junk drawer and a C plea Thompson, David
2024-07-17 2:25 ` The Guile junk drawer and a C plea (was: [PATCH] Add nondestructive delq1, delv1, and delete1.) Olivier Dion
2024-07-17 10:01 ` Library namespaces (guile ...) and (srfi ...) Lassi Kortela
2024-07-17 10:45 ` The Guile junk drawer and a C plea Dr. Arne Babenhauserheide
2024-07-17 10:53 ` MSavoritias
2024-07-17 11:12 ` Lassi Kortela
2024-07-17 15:44 ` Olivier Dion
2024-07-17 16:09 ` tomas
2024-07-17 16:29 ` Attila Lendvai
2024-07-17 20:32 ` Dr. Arne Babenhauserheide
2024-07-18 9:04 ` Attila Lendvai
2024-07-18 15:11 ` Dr. Arne Babenhauserheide
2024-07-17 20:33 ` Dr. Arne Babenhauserheide
2024-07-18 22:56 ` Greg Troxel
2024-07-19 8:46 ` Maxime Devos
2024-07-20 9:34 ` Attila Lendvai
2024-07-20 13:01 ` [PATCH] " Dr. Arne Babenhauserheide
2024-07-20 13:30 ` Name of the standard library Lassi Kortela
2024-07-20 14:52 ` Dr. Arne Babenhauserheide
2024-07-20 15:24 ` Lassi Kortela
2024-07-20 15:46 ` Dr. Arne Babenhauserheide
2024-07-20 16:04 ` Portable code Lassi Kortela
2024-07-20 16:24 ` Dr. Arne Babenhauserheide
2024-07-20 16:37 ` Lassi Kortela
2024-07-20 21:48 ` Dr. Arne Babenhauserheide
2024-07-26 9:21 ` Lassi Kortela
2024-07-20 16:11 ` Name of the standard library Maxime Devos
2024-07-20 16:26 ` Dr. Arne Babenhauserheide
2024-07-20 16:48 ` Maxime Devos
2024-07-20 18:42 ` Portable imports Lassi Kortela
2024-07-20 19:18 ` Maxime Devos
2024-07-20 19:46 ` Encoding library names Lassi Kortela
2024-07-20 20:35 ` Maxime Devos
2024-07-21 5:55 ` Portable imports tomas
2024-07-20 19:23 ` Maxime Devos
2024-07-20 16:54 ` Name of the standard library Lassi Kortela
2024-07-20 21:56 ` Dr. Arne Babenhauserheide
2024-07-26 9:38 ` Lassi Kortela
2024-07-20 15:43 ` Maxime Devos
2024-07-20 15:58 ` Lassi Kortela
2024-07-21 7:15 ` MSavoritias
2024-07-21 8:04 ` Dr. Arne Babenhauserheide
2024-07-26 16:37 ` Library names describe APIs Lassi Kortela
2024-07-21 16:50 ` Name of the standard library Ricardo Wurmus
2024-07-21 13:00 ` Attila Lendvai
2024-07-20 16:01 ` Maxime Devos
2024-07-20 16:27 ` Lassi Kortela
2024-07-20 16:55 ` Maxime Devos
2024-07-21 12:16 ` [PATCH] The Guile junk drawer and a C plea Attila Lendvai
2024-07-21 21:10 ` Dr. Arne Babenhauserheide
2024-07-22 14:52 ` Attila Lendvai
2024-07-20 15:26 ` Maxime Devos
2024-07-17 11:04 ` Lassi Kortela
2024-06-29 18:38 ` The Guile junk drawer and a C plea (was: [PATCH] Add nondestructive delq1, delv1, and delete1.) Jean Abou Samra
2024-06-29 19:02 ` The Guile junk drawer and a C plea Richard Sent
2024-06-29 23:51 ` Thompson, David [this message]
2024-06-30 7:23 ` Dr. Arne Babenhauserheide
2024-07-01 2:55 ` Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ=RwfbDvu6BK29312SGFhu=1sm4X9k3Ej+1+AuvycNNNfY2=w@mail.gmail.com' \
--to=dthompson2@worcester.edu \
--cc=guile-devel@gnu.org \
--cc=richard@freakingpenguin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).