Re: [Sbcl-devel] cl-kanren-trs breakage with recent-ish SBCL

[Paul K. <pv...@pv...>]

sourceforge rejects Stas's mails. So here's his reply.

Paul Khuong <pv...@pv...> writes:

> On 2012-02-23, at 10:04 AM, Zach Beane wrote:
> 
>> Commit d7e55b41, "Fix EQL constraint propagation on constant assigned
>> closure variables", causes a build failure in cl-kanren-trs (available
>> in quicklisp). The error:
>> 
>>   ; caught ERROR:
>>   ;   Objects of type FUNCTION can't be dumped into fasl files.
>> 
>> Is this likely cl-kanren-trs's fault? Or is it something that should be
>> adjusted in SBCL?
> 
> (defconst +succeed+ 
>  #'(lambda (subst) 
>      (unit subst)))
> 
> (defconst +fail+ 
>  #'(lambda (subst)
>      (declare (ignore subst))
>      (mzero)))
> 
> defconst is yet another version of defconstant-eql. The spec is clear that we can evaluate constant values at compile and load times. However, I'm not sure what the expected interactions are between compile-time evaluation and non-dumpable objects. I could try and weaken MEMBER types, but, if possible, I'd like to track values back to their defconstant instead, and refer to that binding in fasls.
 A reference to a constant variable in source code is equivalent to a reference to a 
 literal object that is the value of the constant variable.
from http://www.lispworks.com/documentation/lw50/CLHS/Body/03_bbc.htm

-- 
With best regards, Stas.