Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

&REST in VALUES type specifier

7 views
Skip to first unread message

Alberto Riva

unread,
Dec 21, 2001, 1:26:20 AM12/21/01
to
Consider the following code:

---
(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:

> (bar)
(2.0 3.4 'A NIL NIL NIL)

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,

Alberto Riva
Children's Hospital
Informatics Program

Erik Naggum

unread,
Dec 21, 2001, 4:36:36 AM12/21/01
to
* Alberto Riva

| Is the VALUES declaration in BAR legal?

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.

///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.

Thomas F. Burdick

unread,
Dec 21, 2001, 8:50:19 PM12/21/01
to
Alberto Riva <Albert...@TCH.Harvard.edu> writes:

> Consider the following code:
>
> ---
> (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?

Yes, and it works as expected in CMUCL, CLISP, and GCL.

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).

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

0 new messages