[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposing a simpler mechanism

This page is part of the web mail archives of SRFI 102 from before July 7th, 2015. The new archives for SRFI 102 contain all messages, not just those from before July 7th, 2015.



Thomas Bushnell BSG wrote:
Case-lambda is not a part of standard scheme.

Case-lambda is a part of standard Scheme.

http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-6.html#node_idx_262

If you mean srfi-16,
notice the way the reference implementation works.  It defines a
procedure with a formals list that looks like this:

(lambda args ....)

That would be an arity of "0, #t" in my system.

Yes, and the same information could reported by an implementation of the current SRFI. However, the proposal leaves open the possibility of better arity reporting for case-lambda forms in systems where case-lambda is treated as a primitive form.

Indeed, the
Now, the procedure it generates happens to do
  (error "Wrong number of arguments to CASE-LAMBDA.")
under various circumstances.

I assume you want to pretend that this error is the "same" as the error
one gets for calling (lambda (x) ...) with other than exactly one
argument.  But why?

I do not want to pretend this, so I don't see how to answer your question.

*Exactly* which errors are the errors referred to by this arity checking
thing?

If you mean "the parameters in the lambda specification", then
case-lambda defines procedures with entirely indefinite arity (just look
at the lambda expressions!).

Alternatively, if you want to insist that case-lambda arities must be
the "expected" ones for the metaphysical notion of arity, then please
add to srfi 102 mention that the reference implementation of srfi 16 is
now incorrect, and indeed, cannot be portably implemented together with
srfi 102.

Nowhere do I insist that case-lambda arities must be the "expected" ones, only that they may be.

There is nothing wrong with the reference implementation of SRFI 16 and it is not fundamentally at odds with anything in the proposal or portable reference implementations of it. It would be perfectly acceptable for an implementation of this SRFI to report that every procedure constructed with case-lambda accepts 0 or more arguments. An implementation may do this for any procedure, in fact. On the other hand, an implementation that supports better arity information for case-lambda procedures may say a function accepts "1 or 3 arguments" for example. But this is only correct if applying the function to any number of arguments that is neither 1 nor 3 results in an error.

David