From: Douglas K. <do...@go...> - 2013-09-18 11:27:13
|
I found this case because CCL totally chokes on it. (In addition to other error I mentioned about TYPECASE in general). In fact they disagree that SBCL's treatment of consecutive (let's not say "nested") conditionals is right. See bug report I filed: #1112: #[-+] reader macros don't nest correctly --------------------------------+------------------------------------------- Reporter: dkatzman | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: ANSI CL Compliance | Version: trunk Keywords: | --------------------------------+------------------------------------------- This function prints (C), (B), (B), (A) as tested under SBCL and CLISP on x86/darwin. {{{ (defun test () (print (read-from-string "#-x86 #-darwin (a) (b) (c)")) (print (read-from-string "#-x86 #+darwin (a) (b) (c)")) (print (read-from-string "#+x86 #-darwin (a) (b) (c)")) (print (read-from-string "#+x86 #+darwin (a) (b) (c)")) (values)) }}} CCL prints (B), (C), (B), (A) by the following rationale: In the first test, 'x86' is true so a form must be discarded. 'darwin' is true so the '(a)' reads as NIL due to read-suppress being T. NIL is the expression skipped by the #-x86 making (b) the next expression. etc. This is probably what you want: {{{ Index: l1-reader.lisp ============= --- l1-reader.lisp (revision 15900) +++ l1-reader.lisp (working copy) @@ -2950,7 +2950,7 @@ (values))))) (defun read-feature (stream) - (let* ((f (let* ((*package* *keyword-package*)) + (let* ((f (let* ((*package* *keyword-package*) (*read-suppress* nil)) (read stream t nil t)))) (labels ((eval-feature (form) (cond ((atom form) }}} Clozure CL <ope...@cl...> 5:19 AM (2 hours ago) to openmcl-trac #1112: #[-+] reader macros don't nest correctly --------------------------------+------------------------------------------- Reporter: dkatzman | Owner: gb Type: defect | Status: assigned Priority: normal | Milestone: Component: ANSI CL Compliance | Version: trunk Keywords: | --------------------------------+------------------------------------------- Changes (by gb): * owner: => gb * status: new => assigned Comment: I don't know of anything in the spec that says anything about how nested conditionals like those in your example should be handled. If you know of such things, I'd be interested in hearing of them. You can certainly say that CCL differs from other implementations in its handling of cases like this; as I said, I'm not sure that that either behavior is any more or less correct than the other (or than other plausible behaviors.) <http://www.franz.com/support/documentation/8.2/doc/implementation.htm #nested-conditionals-3> discusses how Franz addressed the fact that their implementation had different behavior than other implementations (and than CCL), and I think that their solution is probably reasonable. (There's no compelling reason to be arbitrarily different from other implementations in this case, but changing an implementation's behavior could break existing code and there likely needs to be some simple way to revert to traditional behavior.) If we don't do this, it's likely only a matter of time before someone says "this behavior is incorrect, because it's not what I see in Acme Common Lisp", and it's not worth having that argument. On Wed, Sep 18, 2013 at 6:27 AM, Christophe Rhodes <cs...@ca...> wrote: > Douglas Katzman <do...@go...> writes: > > > This function attempts to read an expression that resembles a similar one > > in DUMP-I-VECTOR: > > Right. Whoops. I've rewritten DUMP-I-VECTOR to remove the specific > problem (not a problem in practice because of the constraints on the > cross-compiler, but even so) and make the function more comprehensible > in general. > > > A few things would make this kind of construct more concise and legible: > > 1. Avoid #![-+] when the feature expression following is just (AND) or > (OR) > > stuffed in by a read-time eval of an arbitrary Lisp form. It makes no > > difference whether that "feature" is evaluated with respect to host or > > target features. Better still, add a :64-bit feature which replaces the > > somewhat obscure expression > > (cl:if (cl:= 64 sb!vm:n-word-bits) '(and) '(or)) > > with just > > #!+64-bit > > Or #!+#.(sb-cold:64-bit) if we want to avoid namespace issues, but yes. > > > 2. Avoid nesting of the macros - it's not very clear. > > Indeed. How did you find this case? I toyed this morning with trying > to write something which prohibited nesting #- inside #!- (and the > converse) but couldn't really convince myself that it was completely > desireable. > > Thanks, > > Christophe > |