Argument lists

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

    I still think the right thing to do is to make (type-of <function>)
    return a type signature for the function. ... 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?

Sorry I didn't jump on this when it was first proposed.  Too much mail
went by in too short a time.

I really dislike this way of doing it.  Several reasons: First, this is
a very inconvenient interface.  We require the system to cons up a funny
list that the user then has to parse.  Second, it requires the type of
every argument to be available in explicit form; this may be too much to
ask of many systems.  Third, TYPE-OF has a lot of leeway in what it
returns for all other forms, and is the source of much confusion.  I've
seen several portable packages try to use this and get screwed up
because they expected STRING and got (SIMPLE-STRING 37) or something.  I
would like to promote the idea that TYPE-OF is useful mostly as an
interactive debugging interface, and if you ever see TYPE-OF in code it
is probably an error.
           
    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.
        
I don't see this as a broken abstraction.  The programmer needs to know
which arguments are supposed to do what, and the names are a quick way
of indicating that (or at least what the argument order is if the user
already knows what the function is supposed to do).  Documentation
strings typically say something like "Takes two arguments, ITEM and
LIST, and looks for the second occurrence of ITEM in LIST..."  The
proposed function would give you the first half of that.  It doesn't
tell you what's in the black box.  It doesn't tell you anything you
wouldn't get from an Ada function header.

If all the default forms were constants, I'd argue for including those
as well, but they are arbitrary forms of unbounded complexity that cross
the line into implementation in many cases.

-- Scott