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

Re: arity failures

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.



On Fri, 2009-11-13 at 14:05 -0500, David Van Horn wrote:
> Thomas Bushnell BSG wrote:
> > Also, "failing" an arity check doesn't mean that you will get any kind
> > of error or exception as a result.
> [...]
> > So, to recap:
> > 
> > Being told that a procedure takes, say, exactly three arguments, does
> > not mean that
> >   1) You won't get an error for passing three arguments;
> >   2) You will get an error for passing other than three arguments.
> 
> I'm confused -- the intent of the proposal is if you apply a procedure 
> to a number of arguments it is reported not to accept, you will get an 
> error.  Why is this not the case?

Sorry, there are two ways to go, and I was assuming one branch rather
than spelling out both.  I'm sorry for not being clearer.

A Scheme system may allow secret extra arguments if it wishes.  That is,
it is an error for a programmer to say (define (x a b) ...) and then
call x as (x 1 2 3).  But a system is free to give an implementation
defined meaning to expressions like (x 1 2 3) in that context.

So for a system which does that, there are several choices it could
make:

When it sees (define (x a b) ...) it could *report* that the arity is
indefinite.  That means that programmers cannot predict in a standard
fashion what the arity procedure returns for the lambda expressions they
write.

Or (what I was assuming) it could return an arity object which documents
the syntax of the lambda expression which created the procedure, but
then, an "arity mismatch" would not guarantee an error would be
returned.

I was assuming that the second is the choice implementers would choose
(hence my email's wording).  I made that assumption because the only
meaning I can assign to "arity" is the one based upon the syntax of the
formals in the defining lambda expression.

Thomas