What really are semantics of (OR ...) type specifier??

[Robert Elton Maas <REM%IMSSS@SU-AI.ARPA>]

G> Date: Sun, 20 Apr 86 16:14 EST
G> From: Guy Steele <gls@THINK-AQUINAS.ARPA>
G> Subject: Re: Type Specifier: (OR (FUNCTION ...) ...)

	    (or (function (list) list)
		(function (vector) vector))
	as a way of specifying that the output type of a function matches its
	input type...
G> ...
G> But here is a more subtle point.  The above type states that BAZ is either
G> a function of type (FUNCTION (LIST SEQUENCE) FOO) or a function of type
G> (FUNCTION (SEQUENCE LIST) BAR).  Assume FOO and BAR to be disjoint types.
G> Suppose BAZ is called twice in succession, and the result of the first call
G> is determined to be of type FOO:
G> 	(WHEN (TYPEP (BAZ '(a) '(b)) 'FOO)
G> 	  (BAZ '(c) '(d)))
G> We have no cause to believe that BAZ will change between the two calls,
G> and so we are entitled to deduce that the second call to BAZ, if
G> executed, will necessarily return a FOO and not a BAR, because the first
G> call produced a FOO and thus BAZ is of type (FUNCTION (LIST SEQUENCE) FOO).
G> So maybe Nick isn't actually expressing quite what he wanted to in the
G> first place.

Very good analysis. (:- I'm glad such subtle points were carefully
studied before anybody publishes an official standard in book form -:)
My guess is nobody thought of this before, so the manual is ambiguous
and needs to be fixed (your interpretation, or his, or it's not legal CL).

One possible cook of your analysis, it's possible that since BAZ is
defined globally it may get defined out from under this program loop.
I.e. the code must fetch the function definition of BAZ twice rather
than fetch it once and use that fetched&cached value twice, so there's
nothing to stop BAZ from redefining itself each time it is called.
This is PSL but:
 (DE BAZ1 (A B) (PROGN (COPYD 'BAZ 'BAZ2) ...))
 (DE BAZ2 (A B) (PROGN (COPYD 'BAZ 'BAZ1) ...))
 (COPYD BAZ 'BAZ1) ;; Initialize the flip-flop function