On Fri, Oct 25, 2002 at 10:31:00PM -0700, Alexey Dejneka wrote:
> Update of /cvsroot/sbcl/sbcl
> In directory usw-pr-cvs1:/tmp/cvs-serv10169
> Modified Files:
> BUGS make-genesis-2.sh make-host-1.sh make-host-2.sh
> Log Message:
> * Added #+cmu(ext:quit) to build scripts
Can't you run the scripts with SBCL_XC_HOST set to 'lisp -batch' (i.e.
./make.sh 'lisp -batch' or SBCL_XC_HOST='lisp -batch' sh
./make-host-1.sh)? [ or 'openmcl -b' if you're that way inclined?
> * Fixed SIMPLE-SUBTYPEP type method for FUNCTIONs
> + It causes insertion of wrong type assertions into generated
> + code. E.g.
> + (defun foo (x s)
> + (let ((f (etypecase x
> + (character #'write-char)
> + (integer #'write-byte))))
> + (funcall f x s)
> + (etypecase x
> + (character (write-char x s))
> + (integer (write-byte x s)))))
> + Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
> + (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
> + produce invalid code, but type checking is not accurate. Similar
> + problems exist with VALUES-TYPE-INTERSECTION.)
Neat :) You're very good at finding corner cases... I suppose the
difficulty in this type intersection problem is representing things like
the union of (function (integer) integer) and (function (base-char)
base-char); (function ((or integer base-char)) (or integer base-char))
has lost some constraint information, but is easier to work with (by
some degree, because of the special treatment of FUN-TYPEs) than
(or (function (integer) integer) (function (base-char) base-char)).
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)