---
(defun foo (a)
  (values a 3.4 'a "x" t 1.0))

(defun bar ()
  (declare (ftype (function (double-float) (values double-float &rest
t)) foo))
  (multiple-value-bind (a b c d e f) (foo 2.0)
    (list a b c d e f)))

---

Is the VALUES declaration in BAR legal? Apparently, the meaning is: "foo
returns multiple values, of which the first is a double-float and the
rest can be of any type". I saw it used in a numerical integration
package, and it seems to comply with ANSI 4.4.22, although the
explanation there is not very clear to me. When I compile the file under
Allegro 6.1 I get the following warning:

  ; While compiling BAR:
  Warning: Ignoring declaration of unrecognized type: &REST

but the code works fine. Lispworks 4.1.20 gives no warnings, but
produces the following result:

Even changing the number of returned values or the values themselves,
the result is always that all the elements after the third one are NIL.
My guess is that LW doesn't recognize the &rest either, and seeing only
three symbols after 'values', decides to preserve only the first three
values and to replace the others with NIL. So my question is: is the
above one the correct way of using &rest in a (values) specifier,
(meaning that both ACL and LW are non-compliant in different ways), or
is the declaration wrong? Thanks,

  Yes.  (Although the term should be "conforming".)

| I saw it used in a numerical integration package, and it seems to comply
| with ANSI 4.4.22, although the explanation there is not very clear to me.

  Please note that entries in the dictionary clauses of the standard are
  not numbered.  You should be aware of this if you use Franz Inc's
  modified version of the text of the standard.  Please say "type specifier
  values" if that is the entry you are referring to.

| So my question is: is the above one the correct way of using &rest in a
| (values) specifier [...] or is the declaration wrong?

  It is the correct way of using &rest in a values type specifier.

| (meaning that both ACL and LW are non-compliant in different ways)

  File bug reports and complain vociferously about this.  Please let us
  know how the vendors respond.  The nervousness that results from not
  being able to use the specification to which the product purports to
  conform as the basis of your own coding and expectations is a major
  detractor from fully exploiting the language.  Just because nobody
  "needed" this sufficiently to make some vendor implement it so far, does
  not mean that it is not important.  The fact that they have "overlooked"
  such a feature means that other advanced and seldom-used features are
  probably also "overlooked", which again means that in order to feel safe
  about using a language that has a stable and unchanging standard and
  specification since 1995, one has to figure out where the "mainstream" is
  and make sure to stay within it.  That is _so_ not in the (Common) Lisp
  tradition.  We have advanced and seldom-used features in the language
  because they turn out to be very useful when they _are_ needed.

  Causing a conforming program to fail either compilation or execution is
  _really_ bad when it comes to declarations, because it teaches people not
  to use them and not to trust them, and this is communicated to other
  users, either by reading about problems like this on USENET now or using
  various search engines, or by dangerous "memes" that hang around much
  longer than the bugs do.  Like some incompetent C programmers feel _fear_
  around memory management issues because they have been bitten by memory
  leaks and problems that crashed their toy computers years ago, Common
  Lisp newbies will learn that using the full power of the language causes
  wrong results and other unexpected behavior.  This is detrimental to all
  the effort that went into creating a standard and a community around it.

This isn't material to your question, but I don't think your code's
correct, because I noticed that ECLS refused to produce a fasl file
for your code:

  ;;; Compiling (DEFUN BAR ...).
  ;;; Error: In a call to FOO, the type of the form 2.0 is SHORT-FLOAT, not LONG-FLOAT.
  ;;; No FASL generated.

Huh, so it isn't (2.0 a long-float, that is).