do tries to iterate into print output?

[mars0i]

Hi,

Is this a known bug? I don't have the expertise to describe the problem in a sensible way--I'm not even sure whether it has to do with 'do' per se--but you'll see what I mean. This is on: 1.6-r14468M (DarwinX8664)!

Line breaks added for readability:

? (setf (get 'sym1 'prop) '(this that theother))
(THIS THAT THEOTHER)
? (setf sym2 'sym1)
SYM1
? (do ((lst (symbol-plist 'sym1) (cdr lst))) 
      ((null lst) t) 
   (princ (car lst)))
PROP(THIS THAT THEOTHER)
T
? (do ((lst (symbol-plist sym2) (cdr lst))) 
      ((null lst) t) 
    (princ (car lst)))
;Compiler warnings :
;   In an anonymous lambda form at position 24: Undeclared free variable SYM2PROP(THIS THAT THEOTHER)
T
? 

Thank you for ccl, btw. It seems incredibly fast, which matters for my application.

Marshall

[gb]

In Common Lisp, "variables" can be "constant variables" (defined with DEFCONSTANT), "special variables" (variables for which a SPECIAL declaration applies, often established with DEFVAR or DEFPARAMETER), or "lexical variables" (variables bound by LET/LAMBDA in the surrounding context for which no SPECIAL declaration is in effect.

SYM2 in your code above fits into none of these categories. In CCL, it'll sort of be treated as a SPECIAL variable for the purposes of reference and assignment, but bindings of the variable will be (new) lexical bindings. Other implementations behave at least slightly differently, and most compilers will warn when such variables are encountered. (In CCL, the compiler refers to such variables as "Undeclared free varables": they're not lexically bound and not declared to be SPECIAL or CONSTANT variables.)

Most interpreters don't warn about use of these variables, and people are often casual about introducing such (formally undefined but practically harmless, usually) variables in forms that they type into the REPL; some books and tutorials are equally casual about this.

In CCL, some forms typed into the REPL are evaluated by a very simple interpreter; other forms are evaluated by compiling them and calling the resulting anonymous function. The simple interpreter doesn't warn about the use of SYM2 in

? (setf sym2 'sym1)

though the use of SYM2 there isn't (strictly speaking) well-defined. The compiler does warn about the use of SYM2 in the DO form, and the text of that warning precedes the other output.

There's no other difference in behavior between the two cases (besides the fact that the code in the second DO generated a compiler warning.) I can't quite understand your diagnosis of what you see, but I'm as confident as I can be in saying that you haven't discovered a bug in DO.

[mars0i]

Thank you for the detailed explanation, gb. I see your point about my example. I erred in two ways: I tried to reproduce an error in a simpler, clearer form, but failed to do so. I also misinterpreted the concatenation of a symbol name and princ's output as a symbol name--I thought that ccl thought there was a symbol whose name was SYM2PROP(THIS THAT THEOTHER). There still seems to be a problem that occurs in ccl but not some other implementations, but I'll try to isolate it better and submit another ticket if necessary. (Or maybe it's not a problem, but just permitted behavior.) Thanks.

Replying to mars0i:

Hi, Is this a known bug? I don't have the expertise to describe the problem in a sensible way--I'm not even sure whether it has to do with 'do' per se--but you'll see what I mean. This is on: 1.6-r14468M (DarwinX8664)! Line breaks added for readability: {{{ ? (setf (get 'sym1 'prop) '(this that theother)) (THIS THAT THEOTHER) ? (setf sym2 'sym1) SYM1 ? (do ((lst (symbol-plist 'sym1) (cdr lst))) ((null lst) t) (princ (car lst))) PROP(THIS THAT THEOTHER) T ? (do ((lst (symbol-plist sym2) (cdr lst))) ((null lst) t) (princ (car lst))) ;Compiler warnings : ; In an anonymous lambda form at position 24: Undeclared free variable SYM2PROP(THIS THAT THEOTHER) T ? }}} Thank you for ccl, btw. It seems incredibly fast, which matters for my application. Marshall

[gb]

This ticket should remain closed: DO doesn't "try to iterate into PRINT output", whatever that would mean.

You do not need to reopen the ticket in order to comment on it, if there were reason to do so.

[rme]

Replying to mars0i:

Thank you for the detailed explanation, gb. I see your point about my example. I erred in two ways: I tried to reproduce an error in a simpler, clearer form, but failed to do so. I also misinterpreted the concatenation of a symbol name and princ's output as a symbol name--I thought that ccl thought there was a symbol whose name was SYM2PROP(THIS THAT THEOTHER).

;Compiler warnings :
;   In an anonymous lambda form at position 24: Undeclared free variable SYM2PROP(THIS THAT THEOTHER)
T
? 

The reason that you get the all-run-together "SYM2PROP(THIS THAT THEOTHER)" is simply because the compiler warning wasn't printed with a trailing fresh line.

The recent trunk commit r14824 adds this trailing fresh line.