I've looked at the CLHS and searched the web, but I still don't
understand why the CMUCL compiler seems not to infer that (num little)
is a fixnum in very-small-2:
(defclass little ()
((num :reader num
:type fixnum
:initarg :num)))
(defmethod very-small-1 ((little little))
(declare (optimize (speed 3)))
(let ((n (num little)))
(declare (fixnum n))
(< n 3)))
(defmethod very-small-2 ((little little))
(declare (optimize (speed 3)))
(< (num little) 3))
* (compile-file "test2.lsp")
Python version 1.0, VM version Intel x86 on 13 NOV 02 10:45:40 pm.
Compiling: test2.lsp 13 NOV 02 10:45:36 pm
Converted |(PCL::FAST-METHOD VERY-SMALL-1 (LITTLE))|.
Compiling DEFMETHOD VERY-SMALL-1 (LITTLE):
Byte Compiling Top-Level Form:
Converted |(PCL::FAST-METHOD VERY-SMALL-2 (LITTLE))|.
Compiling DEFMETHOD VERY-SMALL-2 (LITTLE):
File: test2.lsp
In: DEFMETHOD VERY-SMALL-2 (LITTLE)
(< (NUM LITTLE) 3)
Note: Unable to optimize due to type uncertainty:
The first argument is a REAL, not a FLOAT.
Note: Forced to do GENERIC-< (cost 10).
Unable to do inline fixnum comparison (cost 3) because:
The first argument is a REAL, not a FIXNUM.
Unable to do inline fixnum comparison (cost 4) because:
The first argument is a REAL, not a FIXNUM.
etc.
Byte Compiling Top-Level Form:
Compilation unit finished.
2 notes
1) Am I wrong in expecting the slot :type to be used by Python for
type inference?
2) Should I expect very-small-1 to be optimized well (i.e. will n be
optimized away?)
Thanks in advance,
Michael Naunton
···@bellatlantic.net writes:
> (defmethod very-small-2 ((little little))
> (declare (optimize (speed 3)))
> (< (num little) 3))
#'NUM is a generic function. Without whole-program analysis, and
without sealing classes and what not, I think there's no way a Lisp
could deduce that #'NUM always returns a fixnum.
In article <··············@gerd.free-bsd.org>,
Gerd Moellmann <··············@t-online.de> wrote:
>···@bellatlantic.net writes:
>
>> (defmethod very-small-2 ((little little))
>> (declare (optimize (speed 3)))
>> (< (num little) 3))
>
>#'NUM is a generic function. Without whole-program analysis, and
>without sealing classes and what not, I think there's no way a Lisp
>could deduce that #'NUM always returns a fixnum.
While I think this is true, it's unfortunate that we didn't specify things
a bit tighter.
The CLOS spec says that if a subclass specifies the type of an inherited
slot, the actual type is the intersection of the two types. So an
optimizer should be able to determine that the type of the NUM slot is at
subtype of FIXNUM.
The problem is that the NUM generic function might not necessarily be a
slot accessor. A subclass could provide its own method that does something
other than just access the slot, and this method might not return a subtype
of FIXNUM.
For type inferencing to have a better chance, the :TYPE slot option should
apply not only to the slot itself, but should also apply to the accessor
methods, and subclasses that override them should be required to obey the
type restriction. But I don't think the standard requires this.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.