[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Fahlman@C.CS.CMU.EDU
- Subject: Argument lists
- From: email@example.com
- Date: Tue, 1 Jul 86 10:13 EST
- Cc: common-lisp@SU-AI.ARPA
- Sender: mike@a
Date: Mon, 30 Jun 1986 23:25 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Perhaps we can try to converge on the argument-list business. Nick
Gall's proposal seems to be the leading contender for a low-cost
standard way of finding out how a function may legally be called. This
is an upward-compatible extension to the language:
I still think the right thing to do is to make (type-of <function>)
return a type signature for the function. Then the user's program can
conclude whatever it wants. If an implementation can do this, then it
can certainly do what is required below, and other things too,
depending on how specific the type signature is. I proposed this last
week sometime, and I saw only minimal feedback (which was positive).
Are there any good reasons why the type system isn't the right place
to garner this information?
The only real objection that I can see to this is that creating
function-specs may require consing them up, or storing them
There seems to be little enthusiasm for REQUIRING that an implementation
supply the function's original argument list or the names of the
parameters, especially for compiled code.
Agreed. I think this is a programming environment issue, not a
Language definition issue.
There remains the issue of
whether we should provide a standard way of asking for additional,
internal argument list information if it is available. Some
implementations would supply this information, others would not, and
others might supply it for some functions and not for others.
I personally believe that a standard format for getting at argument-name
information, if it is available, would be useful, but I don't like the
idea of returning the original lambda-list (or a copy of it). The
problem is that the lambda-list contains default-value forms that can be
very complex and that would be confusing when taken out of context.
Just the argument names can be misleading. A broken abstraction is a
broken abstraction. On the other hand, if you are going to allow
people the "documentation" value of knowing the formal parameter
names, I don't see why you draw the line at the default forms. They
can be useful to look at as well, for example to decide if you need
to calculate and pass an optional argument, or whether the default is
Would something like this be useful in the standard, or should we let
each implementation decide for itself wht format to use in providing
I don't see much agreement on this issue.