From: Alexey D. <ade...@co...> - 2003-06-04 03:44:10
|
Hello, 13:34:25 <Krystof> because I can't think of a particularly good way to turn it off, as I think our IF optimizer isn't smart enough to subtract out NULL from the type in the true branch :/ 13:34:35 <Krystof> at least, not in the general case. So things like 13:34:53 <Krystof> (let ((name (or (posix-getenv "FOO") (error))) 13:34:59 --- join: blitz__ (bl...@p5...) joined #lisp 13:35:01 <Krystof> (pos (position #\: name)) 13:35:16 <Krystof> don't get NAME to be blessed as a SIMPLE-BASE-STRING 13:35:53 <Krystof> and because NIL is a list and therefore valid as input to POSITION, sbcl whinges :-/ Hmm. COMPILE-FILE on (defun foo () (declare (optimize (speed 2))) (let ((name (or (posix-getenv "FOO") (error "")))) (position #\: name))) does not emit any notes for me (type check still may be performed if safety=3, because POSIX-GETENV may return an alien pointer). -- Regards, Alexey Dejneka "Alas, the spheres of truth are less transparent than those of illusion." -- L.E.J. Brouwer |
From: Christophe R. <cs...@ca...> - 2003-06-04 08:16:35
|
Alexey Dejneka <ade...@co...> writes: > 13:34:25 <Krystof> because I can't think of a particularly good way to > turn it off, as I think our IF optimizer isn't smart enough to > subtract out NULL from the type in the true branch :/ > 13:34:35 <Krystof> at least, not in the general case. So things like > 13:34:53 <Krystof> (let ((name (or (posix-getenv "FOO") (error))) > 13:35:01 <Krystof> (pos (position #\: name)) > 13:35:16 <Krystof> don't get NAME to be blessed as a SIMPLE-BASE-STRING > 13:35:53 <Krystof> and because NIL is a list and therefore valid as > input to POSITION, sbcl whinges :-/ > > Hmm. COMPILE-FILE on > > (defun foo () > (declare (optimize (speed 2))) > (let ((name (or (posix-getenv "FOO") (error "")))) > (position #\: name))) > > does not emit any notes for me (type check still may be performed if > safety=3, because POSIX-GETENV may return an alien pointer). Thanks for pointing me at my misdiagnosis. What I think is actually happening, then, is that in fact the type deriving mechanism isn't the problem. The code in CLX that's giving me this optimization note is (in the same file) (defun getenv (name) #+foo (foo) #+bar (bar) #+sbcl (sb-ext:posix-getenv name)) (defun get-default-display () (let* ((name (or (getenv "DISPLAY") (error "foo"))) (colon-i (position #\: name)) ...) ...)) And the problem is that, even with *DERIVE-FUNCTION-TYPES*, the types of the functions we compile in the same file aren't available, because they're only put into the INFO database at load time, so when GET-DEFAULT-DISPLAY is compiled, the compiler thinks it doesn't know enough about GETENV. This, then, would be another obstacle to be overcome in the quest for squeezing maximal speed out of COMPILE-FILE. Cheers, Christophe -- 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) |
From: Paul F. D. <di...@dl...> - 2003-06-07 13:11:31
|
Alexey Dejneka recently commited some changes that broke some of the gcl ansi-tests tests on eight functions ([n]sublis and [n]subst[-if[-not]].) These failures are apparently due to an interpretation that a 'tree' (as defined in CLtS) must be a cons. However, this interpretation is contradicted in other parts of the spec. In particular, on the pages for COPY-TREE and TREE-EQUAL the cases where the tree arguments are atoms are explicitly described. Paul |
From: Alexey D. <ade...@co...> - 2003-06-07 18:42:12
|
Hello, "Paul F. Dietz" <di...@dl...> writes: > Alexey Dejneka recently commited some changes that broke some > of the gcl ansi-tests tests on eight functions ([n]sublis and > [n]subst[-if[-not]].) > > These failures are apparently due to an interpretation that a 'tree' > (as defined in CLtS) must be a cons. However, this interpretation > is contradicted in other parts of the spec. In particular, on the > pages for COPY-TREE and TREE-EQUAL the cases where the tree arguments > are atoms are explicitly described. In fact the failures are due to inconsistent treating of type tree in type declarations for these functions, which are now checked: e.g. SUBST declares its tree argument to be of type T, but the result to be LIST. I didn't have time today, probably tomorrow I'll replace LIST with T. Glad to know that it agrees with your interpretation of CLHS. -- Regards, Alexey Dejneka "Alas, the spheres of truth are less transparent than those of illusion." -- L.E.J. Brouwer |
From: Paul F. D. <di...@dl...> - 2003-06-07 18:51:42
|
Alexey Dejneka wrote: > In fact the failures are due to inconsistent treating of type tree in > type declarations for these functions, which are now checked: > e.g. SUBST declares its tree argument to be of type T, but the result > to be LIST. I didn't have time today, probably tomorrow I'll replace > LIST with T. Glad to know that it agrees with your interpretation of > CLHS. Great, and thanks. A case could be made that NRECONC.2 (nreconc () 'a) ==> a isn't a valid test, but (IMO) the balance is toward accepting it. A problem is this sentence: The resulting list shares list structure with tail. which (in contradiction to the return type, which is 'object') appears to assert that NRECONC returns a list. Also, the equivalence to a form with NCONC would appear to mean that a list should be returned (see the definition of NCONC). Personally, I would want to interpret NRECONC and NCONC as returning the tail in the degenerate case where nothing was prepended to it, even if the tail were not a list. Paul |