It seems like there should be somewhere to snip here, but where?
My remarks are at the end.
On Tue, Oct 15, 2002 at 02:08:39PM +0400, Alexey Dejneka wrote:
> Christophe Rhodes <csr21@...> writes:
> > I'm slightly baffled by our failure to signal an error on
> > (LDIFF 1.23 T)
> > if only because cmucl signals an error on what seems to be identical
> > code... the symptom is curable by adding a (declare (type list <foo>))
> > in the relevant place in src/code/list.lisp, but before doing so it
> > would be nice to understand what has caused this to be necessary.
> * (declaim (ftype (function (fixnum) *) myf))
> * (defun myf (x) x)
> * (myf nil)
> The problem is: where global FTYPE declarations should be checked?
> CMUCL checks them in the callee, SBCL does something similar, but not
> inside DEFUN. We can restore CMUCL behavior with something like
> (defmacro defun1 (name args &body body)
> `(flet ((,name ,args ,@body))
> (declare (ftype ,(type-specifier (info :function :type name)) ,name))
> (sb-impl::%defun ',name #',name nil)))
> but I doubt whether it is conformant.
> According to the definition of FUNCTION type specifier, it describes
> only uses of the function, but not its definition. So it seems that
> after compiling
> (eval-when (:compile-toplevel)
> (proclaim ' (ftype (function (fixnum)) myf)))
> (defun myf (x) x)
> and loading FASL into a new image, (MYF NIL) should not signal an
> error. In other words, DECLARE of argument types says to perform type
> checking in the callee, and global PROCLAIM -- in the caller. It also
> saves us from the bug 35. But this reading leads to necessity of
> double type declaring: internal -- to make type checking in indirect
> calls, and external -- to do compile-type type checking in the caller
> (of course, we can avoid it in the SBCL itself by playing with
> :WHERE-FROM), and also to double run-time type checking in safe
> code. At least, this double work would seem to be very unnatural to
> the newcomers from other languages.
> If we accept the CMUCL's meaning of proclamations, hand work will have
> to be done only once, but type checking should still be performed
> twice (see again bug 35).
> So, what do others think about it?
I've run into this before, and I'm very frustrated by it. ANSI went
out of their way here to make it difficult to implement
It's awkward enough that it's tempting to revise ANSI somehow to get
behavior we can implement safely. E.g. we could support a DECLAIM
SAFE-FTYPE or DECLAIM ASSERTED-FTYPE which we can compile efficiently
into safe code.
Short of that, I don't know what do with it.
William Harold Newman <william.newman@...>
overlooking factors of two in offsets and factors of three in
performance since 1982
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C