Proposals 2, 3, & 4

[Masinter.pa@Xerox.COM]

Argument lists in Interlisp are used for two purposed. One is for
applications that want a descriptive form, for printing out arguments on
the stack and in the editor; the other is for applications that need an
accurate list for advise, break and the like.

For most functions, the values returned are the same, but in some
situations, the descriptive arguments differ by being more elaborate,
having elipsis, arguments that aren't described (e.g., "secret"
optionals).

The language design principle that we have to be careful about with this
is that we want to retain some amount of modularity around exactly how a
function is implemented.

Currently

(defun foo (a) ...)

is equivalent to

(defun foo (&rest args)
	(if (> (length args) 1) (error 'too-many-arguments ...))
	(if (< (length args) 1) (error 'too-few-arguments ...))
	(let ((a (car args)))
		...)

Nothing so far in the language description prohibits that equivalence:
you can't "look inside" functions once they've been defined. We're now
adding something to the language that makes that equivalence no longer
valid, because you can tell what the parameter list is. Furthermore,
this example seems to contradict the assertion that the "semantics of
the language require the storage of the information returned by
FUNCTION-PARAMETERS, so every implementation must have some way to
access this information."  unless access of the information were to
parse the disassembly of the definition somehow.

Interlisp has had an ARGLIST function which gives you back the argument
list of a function, but ARGLIST is really part of the *environment*
rather than part of the *language*. I would feel much more comfortable
with all of these proposals if they were somehow classified as that part
of the environment that Common Lisp standardized on.

This isn't bad. Despite its title, CLtL directly contains a number of
functions and features that are logically part of an environment rather
than part of the language, in part so that people can write portable
environment tools. Things like the stepper, evalhook, room, trace, the
description of the top level loop, the +, ++, +++ variables, etc. are
all part of Common Lisp the Environment. While there are many parts of
the environment that we will find difficulty agreeing upon, those
features for which "most implementations have something like this" are
good candidates. We've identified a number of potentially portable
environment tools which could make good use of a well-defined
function-argument-list access method. 



Some specific comments on Proposal 2,3,4, given that they are part of
"environment" rather than "language":

There are two uses for argument lists in Interlisp: "accurate" argument
information  for program-modifying programs like ADVISE and BREAK, and
"descriptive" argument information for
program-creation-and-debugging-aid programs like the debugger and
what-are-the-arguments-to-the-function-I'm-typing.

For many objects of examination these are the same, but not always.
Macros and special forms might have "descriptive" arguments, for
example; its as valid to ask about format of macro calls as it is
function calls. In some cases, the descriptive arguments contain
sequences (X1 ... XN) while the "real" argument list is (the Interlisp
equivalent of) &REST.

The differing requirements of these two applications have caused most of
the polarization of the discussion.

I will attempt a specific proposal that I think addresses the needs
independently.