Am Di., 16. Juni 2020 um 21:59 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> On Tue, Jun 16, 2020 at 3:14 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

> I haven't, and that's what led to the small but significant change in wording from "if proc definitely cannot be called with k arguments" to "if the implementation can prove that proc definitely cannot be called with k arguments".  (You may have to refresh your browser to get the latest version at srfi.schemers.org as opposed to GitHub.)

Thanks. I have that in my browser now!

>> (define (procedure-arity-mask n) #b101010) ; decimal 42
>
>
> That definition says that for any procedure whatever, the implementation can prove that it cannot be called with 0, 2, 4, or 6 or more arguments.  No RnRS-conformant implementation can construct such a proof, because (for example) + can in fact be called with 0 arguments.  So this is not a SRFI 191 conformant implementation.

My point is that "cannot be called with 0, 2, 4, or 6 or more
arguments" has no well-defined meaning in the Scheme semantics. (The
spec even says "definitely cannot" but this augmentation only
seemingly tries to blur the problem.)

Of course, I may be blind, and the phrase actually has a meaning. In
that case, please define it in terms of the semantics of the R7RS.

The naive idea "A procedure cannot be called with N arguments when it
is an error to call the procedure with N arguments" is obviously wrong
because "it is an error" has no meaning Scheme's evaluation semantics.
"A procedure cannot be called with N arguments when it an error is
signaled when the procedure is called with N arguments" looks better
because "an error is signaled" actually has a meaning in terms of
exception handlers in the Scheme semantics. However, it doesn't do
what we want. This would allow

(procedure-arity-mask raise) => 0

> In order for an implementation to return a kth bit of 0 for a procedure p, it must be able to introspect on p to determine that p's (case-)lambda list does not allow it to be invoked on k arguments.  This can be done by computing the integer at compile time and associating it with p iat run time, or by making the lambda-list itself available along with p.  If the implementation cannot introspect like this, it must return 1 as the kth bit.

A lambda (or case-lambda) form evaluates to a procedure, but a
procedure is not a lambda or case-lambda. Thus, while the phrase
"determine that p's (case-)lambda list" may make sense for a
particular implementation, it cannot be given sense in the abstract
R7RS semantics. Of course, I understand the intent of SRFI 191 (and
likewise of SRFI 102), but I would like to see it worded in a sound
way, if possible. And if it cannot be made sound, it has to be
revisited before it becomes finalized.

All this is not at all academic. I am planning a procedure
documentation SRFI with Arthur. It is easy to associate documentation
strings to syntactic lambda or case-lambda forms, but the relationship
to the procedures resulting from evaluation is not at all clear. For
example, the syntax expander may rewrite each lambda term by wrapping
it in another lambda, which shows that in the R7RS there is no
semantic connection of a procedure to the syntactic form from which it
was evaluated.

>> But none of the issues of SRFI 102 have been discussed nor resolved.
>
>
> If you can point to the emails containing issues you think are significant, I'll attempt to add language addressing them.

I will come back to this later. It's almost 11 pm here. :)

Marc