[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