[Openmcl-devel] Trunk and released version

Gary Byers gb at clozure.com
Thu Aug 13 08:56:20 PDT 2009


I'd call it a bug in the version of DOLIST that was in the trunk until
about an hour ago.  (It was establishing a new binding of VAR to NIL
around the result form, but inexplicably copying the declarations from
the main body into the body of the LET or LET* that established that binding.)
So something like:

(let* ((sum 0))
   (dolist (i list sum)
     (declare (fixnum i))
     (incf sum i)))

was expanding into something like:

(uninteresting-loop
   ...
   (declare (fixnum i)) ; OK
   ...
   (when done (let* ((i nil))
                (declare (fixnum i)) ; unintentional, I assume.
                 sum))

which certainly deserves a runtime error at high safety, probably
deserves a compile-time warning, and is a result of a bug in DOLIST.




On Thu, 13 Aug 2009, Ron Garret wrote:

> I'd call that a bug in the ANSI spec.  It violates the principle of least
> surprise for no benefit whatsoever.  If X is unconditionally bound to NIL
> then there is no point in even having it in scope when the result-form is
> evaluated.
> rg
> 
> On Aug 13, 2009, at 6:28 AM, Tim Bradshaw wrote:
>
>       On 13 Aug 2009, at 12:31, Arthur W Cater wrote:
>
>       a form like
>    (dolist (X list-of-xs    expr-not-using-X)
>        (declare (type mytype X))
>        stuff-involving-X)
>   provoking a complaint that NIL is not of type MYTYPE
> 
> 
> I'm pretty sure that's not a bug.  X is defined to be bound to NIL
> when the result-form is evaluated.  So unless NIL is an instance of
> MYTYPE your declaration is wrong.
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
> 
> 
> 
>



More information about the Openmcl-devel mailing list