Removing program-arities export

Removing program-arities export

[Skyler via Developers list for Guile, the GNU extensibility library]

Hello,

I am working on a patch for a bug I recently found in guile. The `program-arities` function is exported from the `(system vm program)` module and documented in the manual, but it is no longer defined (it was removed in commit 1c33be992e8120abd20add8021e4d91d226f5b6a).  It is only used in the `program-arity function`, which is not called anywhere in the Guile repository (and calling it with valid inputs results in an error due to the `program-arities` being undefined). See the shell session at the end of this email for details.

Removing those functions is simple, but the `arity:` accessors have more users, and since they're just pattern-matching on a list I'm concerned that they have been used for the new functions (eg, find-program-arity) so I'm not sure if it's safe to just remove them. In particular, `arity->arguments-alist` uses them unconditionally. However, `arity->arguments-alist` only has two callers, `program-arguments-alist` and `program-arguments-alists` (that's not a typo, the second one is pluralized), which call it conditionally. The conditions are different but both require that the given code passes the `primitive-code?` predicate. These functions are called from a few different places so it'll take a little more time to figure out if it's safe to remove them (or possibly just remove the logic conditioned by `primitive-code?`, if that is no longer in use, and leaving the rest of the function intact).

In solidarity,
Skyler

user@foreign-guix /d/shm> cat channels.scm
%default-channels

user@foreign-guix /d/shm> guix time-machine --channels=./channels.scm -- shell --container --nesting guile-next guile-readline
user@foreign-guix /dev/shm [env]$ guix describe
  guix 4a4a8c9
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 4a4a8c9d2621d4871c4b9c8857bfb0e6e53d7e56

user@foreign-guix /dev/shm [env]$ guile -q
GNU Guile 3.0.9-0.3b76a30
Copyright (C) 1995-2024 Free Software Foundation, Inc.
                                                                                                              
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
                                                                                   
Enter `,help' for help.
scheme@(guile-user)> (module-variable (resolve-module '(system vm program)) 'program-arities)
$1 = #<variable 734b7c40e940 value: #<undefined>>

scheme@(guile-user)> (use-modules (system vm program))
scheme@(guile-user)> (program-arity car #f)
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
Unbound variable: program-arities

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

RE: Removing program-arities export

[Maxime Devos]

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

>It is only used in the `program-arity function`, which is not called anywhere in the Guile repository (and calling it with valid inputs results in an error due to the `program-arities` being undefined).

This is untrue, it (i.e. program-arities) is also used in the manual.

>Removing those functions is simple, but the `arity:` accessors have more users, […]

It shouldn’t be removed, rather a replacement should be provided somewhere.
Regardless of the changes to the VM, compiled procedures still exist, and by definition that’s what a ‘program’ is, so ‘programs’ still exist, and hence many of the procedures in that module still make sense, including  program-arities. In particular, arity information is still recorded (in .guile.arities), so it should be made / kept accessible somewhere.

Best regards,
Maxime Devos


[-- Attachment #2: Type: text/html, Size: 2333 bytes --]

RE: Removing program-arities export

[Skyler via Developers list for Guile, the GNU extensibility library]

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

On Sunday, January 5th, 2025 at 6:07 PM, Maxime Devos <maximedevos@telenet.be> wrote:

>>It is only used in the `program-arity function`, which is not called anywhere in the Guile repository (and calling it with valid inputs results in an error due to the `program-arities` being undefined).
>
> This is untrue, it (i.e. program-arities) is also used in the manual.

Fair point.

>>Removing those functions is simple, but the `arity:` accessors have more users, […]
>
> It shouldn’t be removed, rather a replacement should be provided somewhere.
>
> Regardless of the changes to the VM, compiled procedures still exist, and by definition that’s what a ‘program’ is, so ‘programs’ still exist, and hence many of the procedures in that module still make sense, including program-arities. In particular, arity information is still recorded (in .guile.arities), so it should be made / kept accessible somewhere.

I agree that this information should be available. I should have explicated my assumption that the similarly-named function "find-program-arities" was a suitable replacement. It is defined in "system/vm/debug.scm" and references .guile.arities. I will interrogate this assumption more thoroughly before submitting a patch, the email was meant as an early notification that this is something that I'm starting to look at in case someone else is already looking at it. I am fine with changing the direction of the patch if that turns out to make sense (perhaps by turning program-arities an alias for find-program-arities).

>

[-- Attachment #2: Type: text/html, Size: 2938 bytes --]

RE: Removing program-arities export

[Skyler Ferris via Developers list for Guile, the GNU extensibility library]

(switching to the correct sending address; I was previously sending from skyvine due to a misconfiguration in my client)

It looks like there are 2 potential candidates for aliasing, but both of them have some problems. When aliasing to "find-program-arities" I am unable to get the arity of any procedure which passes the "primitive-code?" predicate; it just returns #f. When aliasing to "program-arguments-alists" I get results for primitive code, but they are not accurate. For example, try calling it on the "count" procedure from SRFI 1. It is using the "fallback" helper which hardcodes unknown values for missing information. Also, the alists it returns do not provide the information needed for "arity:start" and "arity:end".

I believe that program-arguments-alists is the intended replacement for program-arities, based on this timeline of relevant commits:

- eb2bc00fb3863986927f0bade97487209b6d6a5b (16 May 2013): Added program-arguments-alist, commit message states "New helper, implemented also for RTL procedures."
- 27337b6373954e1a975d97d0bf06b5c03d65b64d (18 October 2013): Added fallback logic, commit message states "Fix up various arity-related things for primitives, which don't use ELF arity info."
- 8bd261baaa96eba005517eef5fb8d5d08f22720a (also 18 October 2013): Exported program-arguments-alist, commit message states "Export this interface.  Fall back to grovelling through procedure-minimum-arity if the program has no arities, as might be the case for continuations."
- (1c33be992e8120abd20add8021e4d91d226f5b6a, 8 November 2013): Removed program-arities implementation, commit message states "Remove old program code." The header of the commit states "Remove stack programs, objcode, and the old VM."

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. However, if we want to keep this as a separate interface I could do something like throw an error that explicitly states "this is currently unimplemented, we are aware of the problem and are looking at it." I don't have a strong opinion about keeping it or removing it. I just want to make sure that callers have a good experience with whatever APIs exist.

The second concern is ensuring that arity information is available for all procedures. However, I would like to delay that discussion until after I spend more time studying how different programming languages handle arguments.

Re: yeRemoving program-arities export

[Dr. Arne Babenhauserheide]

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