[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
- Subject: Void
- From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
- Date: Mon, 12 May 1986 18:27:00 -0000
- Cc: Common-Lisp@SU-AI.ARPA
- In-reply-to: Msg of 12 May 1986 06:28-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Monday, 12 May 1986 06:28-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Sun, 11 May 1986 21:06 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
The only places where a void expression may be legal are:
1] Any place where the value is immediately discarded: PROGN, etc.
2] Any place in a function that can return multiple values. In
addition to tail-recursive positions, this includes the protected
form of UNWIND-PROTECT and the values form for
MULTIPLE-VALUE-PROG1 when these forms are in such a
I'm sorry, but I find this completely ridiculous. Many valid
programs can be written which use `void' values in ways other than
this without being ill-formed.
Note that in either case, a void value may be illegal because the
result was declared to be of some other type:
(proclaim '(function frob-foo (foo) void))
(defun frob-foo (foo) ...)
(proclaim '(function make-foo ((member t nil)) foo))
(defun make-foo (frob-p)
(let ((foo (cons-a-foo)))
Suppose that FROB-FOO puts the FOO on the heap somewhere. Then suppose that
I have a function, CREATE-FOO, which is the only call of MAKE-FOO and is
(DEFUN CREATE-FOO (STASH-P)
(VALUES NIL NIL))
(VALUES (MAKE-FOO NIL) T))))
There's nothing ill-formed about the collection of programs which include
my program and yours.
Not true. I declared that MAKE-FOO *always* returns a FOO. VOID is
not a FOO, ever.
The programming problem you're worried about is a common one, but
the technique you're proposing for fixing it is just not
practical. This situation comes up in legitimate code (especially
when macros are involved) all the time.
I am aware of the macro problem that you describe, but I am not
convinced that it is significant. Any macro in Common Lisp which has
an implicit PROGN cannot get this effect by saving the value in a
variable, since the body might want to return multiple values. A
macro which knows nothing about its body must place it in a
multiple-value context. This is why there is a relation between
multiple-value contexts and legal VOID expressions.
Consider the following common situation: I have a macro MYBLOCK
which binds the variable * to the value of the previous
computation at the same level. For example:
(DEFMACRO MYBLOCK (&BODY FORMS)
`(LET ((* *))
,@(MAPCAR #'(LAMBDA (FORM) `(SETQ * ,FORM)) FORMS)))
In my reality, this macro assumes that each body form is not VOID.
I don't really see all these bad implications of adding a VOID type.
If you think that declaring things VOID crimps your style, then don't
do it. If the compiler barfs because you are using the value of
something that some other bozo declared VOID, then you can always say
(PROGN xxx NIL).