unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
To: Skyler Ferris via "Developers list for Guile,
	the GNU extensibility library" <guile-devel@gnu.org>
Cc: Maxime Devos <maximedevos@telenet.be>,
	 Skyler Ferris <dev@skyler-ferris.me>
Subject: Re: yeRemoving program-arities export
Date: Wed, 08 Jan 2025 21:21:19 +0100	[thread overview]
Message-ID: <87ldvlawg0.fsf@web.de> (raw)
In-Reply-To: <SXAcjGwx65sJpr5q7TEySKLXOUwnvOt9uAbvk_CmevVze-53BoPFuGvkvnsCQBAcXpUe48uJejSKz2y0iy8IYld4rLMOEcvS1ZA5Tgi5HEg=@skyler-ferris.me> (Skyler Ferris via's message of "Wed, 08 Jan 2025 11:23:14 +0000")

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

Skyler Ferris via "Developers list for Guile, the GNU extensibility library" <guile-devel@gnu.org> writes:

> I have 2 concerns that I want to address. The first concern is the bad
> user experience created by calling a procedure which is advertised in
> the manual only to be told that it does not exist. I consider this to
> be an urgent problem and would like to find a path to fix this
> quickly. Based on the above I still believe that removing
> program-arity (and updating the manual accordingly) makes sense.

Given that the program-arity / program-arities is documented, the more
pressing problem is that programs using it would be broken right now.
People may be holding off from updating Guile because they don’t have
the time to investigate breakage in programs that are working perfectly
fine in the old version. Which is the typical case for useful tools.

The worst user experience is seeing a working program break when
updating a dependency: if the docs are wrong, you’re still in the
context of your tool, but if it breaks on update, all that context has
been flushed out already — often years ago.

Is it viable to wrap the procedure and exactly preserve the API, so
existing programs keep working? If it’s a bit slower, that should not
cause pain (because hardware and Guile got faster in the meantime) but
it should not break.

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 --]

  reply	other threads:[~2025-01-08 20:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-29 11:16 Removing program-arities export Skyler via Developers list for Guile, the GNU extensibility library
2025-01-05 18:07 ` Maxime Devos
2025-01-06 11:01   ` Skyler via Developers list for Guile, the GNU extensibility library
2025-01-08 11:23     ` Skyler Ferris via Developers list for Guile, the GNU extensibility library
2025-01-08 20:21       ` Dr. Arne Babenhauserheide [this message]
2025-01-09  9:53         ` yeRemoving " Skyler Ferris via Developers list for Guile, the GNU extensibility library

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=87ldvlawg0.fsf@web.de \
    --to=arne_bab@web.de \
    --cc=dev@skyler-ferris.me \
    --cc=guile-devel@gnu.org \
    --cc=maximedevos@telenet.be \
    /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).