(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.
