Email list hosting service & mailing list manager

proposing a simpler mechanism R. Kent Dybvig (13 Nov 2009 03:00 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 04:23 UTC)
Re: proposing a simpler mechanism Taylor R Campbell (13 Nov 2009 04:31 UTC)
Re: proposing a simpler mechanism R. Kent Dybvig (13 Nov 2009 16:22 UTC)
Re: proposing a simpler mechanism Per Bothner (13 Nov 2009 16:56 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 04:54 UTC)
Re: proposing a simpler mechanism Alex Queiroz (13 Nov 2009 13:44 UTC)
Re: proposing a simpler mechanism Marc Feeley (13 Nov 2009 14:24 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 18:39 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 18:36 UTC)
Re: proposing a simpler mechanism Alex Queiroz (13 Nov 2009 19:08 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 19:21 UTC)
Re: proposing a simpler mechanism David Van Horn (13 Nov 2009 19:25 UTC)
Re: proposing a simpler mechanism Thomas Bushnell BSG (13 Nov 2009 19:36 UTC)
Re: proposing a simpler mechanism David Van Horn (13 Nov 2009 19:58 UTC)
Re: proposing a simpler mechanism Arthur A. Gleckler (13 Nov 2009 20:25 UTC)
Re: proposing a simpler mechanism David Van Horn (12 Jan 2010 18:51 UTC)

Re: proposing a simpler mechanism David Van Horn 13 Nov 2009 19:58 UTC

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