Argument lists

[mike%gold-hill-acorn@mit-live-oak.arpa]

    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
previously. 
       
    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
good enough.
    
    Would something like this be useful in the standard, or should we let
    each implementation decide for itself wht format to use in providing
    arglist info?

I don't see much agreement on this issue.
    
    -- Scott

...mike