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)
|
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