[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Type Specifier: (OR (FUNCTION ...) ...)



	
    Date: Sun, 20 Apr 86 16:14 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>
    
	Date: 19 Apr 1986 17:08-EST
	From: NGALL@G.BBN.COM
	    
	    Date: Sat, 19 Apr 1986  16:24 EST
	    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
	
	    Regarding your proposal that we allow forms like the following
	
		(or (function (list) list)
		    (function (vector) vector))
	
	    as a way of specifying that the output type of a function matches its
	    input type...
    	...
    
    I don't think it is a proposal.  I can find nothing in CLtL that forbids
    using such a form right now.  I find no justification in CLtL for a
    compiler's insisting that a type specifier given to FTYPE be of the form
    (FUNCTION ...).  

What I said in my original letter was:

"Unfortunately, it is not clear from pg. 158 whether or not the
following is legal: ...  It is not legal in VaxLisp, and my guess is
that there aren't any implementations that would do the right thing
with it. So I would like to propose that such a use of OR/FUNCTION be
considered legal CL."

I guess I should have said "So I would like to propose that pg. 158 be
'clarified' to explicitly state that such a use of OR/FUNCTION be
considered legal CL."  To be more explicit: Clarify the def. of FTYPE
(pg. 158) by changing (FTYPE type ...)  to (FTYPE function-type ...)
and defining function-type to either (FUNCTION ...),
(NOT function-type), (AND function-type ...), or (OR function-type ...).

I would still like to know if there are any implementations that do
consider (OR (FUNCTION ...  meaningful!

    Unless a compiler can prove that a declaration is
    actually inconsistent, it should not signal an error.  (Warnings are
    another matter and, as always, subject to judements of taste.)  A compiler
    is not justified in signalling an error just because it doesn't know
    how to make use of a perfectly legitimate declaration.
    
					    ... If someone were to say
	
	    (or (function (list sequence) foo)
		(function (sequence list) bar))
	
	    then what do we do?  
    
	According to the definition of the OR type-spec on pg. 45, "it always
	tests each of the component types in order from left to right and
	stops procesing as soon as one component of the union has been found
	to which the object belongs."
    
    But hold on here, now.  That specification applies specifically to the case
    of TYPEP processing the type specifier, not to the case of using the type
    specifier in a declaration.  Also, do not make the mistake of thinking
    that one can decide which of several function type specifiers applies to
    a function call by examining the argument types only.  If function BAZ has
    the type shown above, then we are entitled only to conclude that the
    call (BAZ '(a) '(b)) will return an object of type (OR FOO BAR).

I stand corrected.

    But here is a more subtle point.  The above type states that BAZ is either
    a function of type (FUNCTION (LIST SEQUENCE) FOO) or a function of type
    (FUNCTION (SEQUENCE LIST) BAR).  Assume FOO and BAR to be disjoint types.
    Suppose BAZ is called twice in succession, and the result of the first call
    is determined to be of type FOO:
	    (WHEN (TYPEP (BAZ '(a) '(b)) 'FOO)
	      (BAZ '(c) '(d)))
    
    We have no cause to believe that BAZ will change between the two calls,
I disagree for the same reason as REM.
    and so we are entitled to deduce that the second call to BAZ, if
    executed, will necessarily return a FOO and not a BAR, because the first
    call produced a FOO and thus BAZ is of type (FUNCTION (LIST SEQUENCE) FOO).

    So maybe Nick isn't actually expressing quite what he wanted to in the
    first place.
    --Guy

No I guess I'm not.  But I am quite happy with Guy's correction.  I
can still do things like:

(proclaim '(ftype (or (function (t list &rest t) list)
                      (function (t vector &rest t) vector))
                  remove))

And expect that a very good compiler would be able to deduce that the
call (remove 1 '#(1 2 3 4)) will return a vector.  I think I will now
try to come up with a declaration for +.

	-- Nick