From: Gerd Moellmann <gerd.moellmann@t...>  20030430 20:06:12

Christophe Rhodes <csr21@...> writes: > Absent any feedback on cmuclimp, I would like to commit the following > patch. However, there is a regression in the test suite: > > (assert (subtypep '(function) '(function (&optional * &rest t)))) > > I think the intent of this is that (FUNCTION (&OPTIONAL * &REST T)) is > equivalent to the universal function type. With some handwaving, I think one could get from The type specifier provided with &rest is the type of each actual argument, not the type of the corresponding variable. in System Class FUNCTION to (FUNCTION (&OPTIONAL * &REST T)) = (FUNCTION (&REST T)) Is (&REST T) in some way distinguishable from *? > I'm not sure, though, and before committing anything I'd like to > understand this. If this is equivalent to the universal function > type (FUNCTION * *), is (FUNCTION (&OPTIONAL * * &REST T)) likewise > equivalent? Is there an equivalent degree of freedom in the VALUES > type axis? Is (FUNCTION * (VALUES (&OPTIONAL * &REST T))) > equivalent to (FUNCTION * *)? It seems if one settles on an interpretation, the VALUES part should follow from The &optional and &rest markers can appear in the valuetype list; they indicate the parameter list of a function that, when given to multiplevaluecall along with the values, would correctly receive those values. 