PowerLoom 3.0.2.beta and SBCL 0.8.8 Redux

Hans Chalupsky <[email protected]>
Newsgroups gmane.comp.ai.powerloom
Message-ID <[email protected]>
Hi Paul,

thanks for investigating this.  We have indeed hit somewhat similar
problems with CMUCL, however, only for types that the STELLA
Lisp translator declares explicitly such as CL:STRING.  The solution
was to generate null values of the particular type such as
NULL-STRING.  SBCL seems to be even pickier by also checking the
(implicit) type declaration of the first method argument.  The
general problem is that Lisp doesn't have a universal null value that
is safe to use for all types of objects (such as Java).  Actually, I'm
not completely sure about that - `nil' might be - but even if it is we
couldn't use it, otherwise we can't distinguish the empty fron the
undefined list.  One could work around the problem by generating a
null-value for each defined type and class or by introducing an
untyped auxiliary `self' variable but I'd rather not go there.  If
setting SAFETY to 0 does the trick for SBCL, we'll use that until (if
ever :-) we come up with a more principled solution.

Hans

>>>>> Paul Snively <[email protected]> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Folks,

> OK, I solved the problem.

> It turns out that CMU CL and SBCL share an interesting property: for 
> SAFETY levels > 0, they adhere (to a considerable extent) to a 
> philosophy of "declarations are assertions." That is, type declarations 
> are checked. Since, by default, PowerLoom 3.0.2.beta is compiled with 
> SAFETY 1, this exercised a TYPE-ERROR in LENGTH on KV-CONS: eventually 
> the parameter becomes NULL, whose value is :NULL_VALUE, which is of 
> course of type KEYWORD, not KV-CONS. SBCL quite rightly throws a 
> TYPE-ERROR condition here, and I have to imagine that CMU CL would 
> also.

> The obvious solution was just to change SAFETY to 0, so I did.

> Now, an interesting ramification of this is that SBCL is proving how 
> successful STELLA is at being strongly typed: at SAFETY 1, LENGTH on 
> KV-CONS was the only method that I encountered that threw a TYPE-ERROR. 
> So another approach, besides compiling at SAFETY 0, might be to change 
> KV-CONS to be even more type-safe than it already is. I recommend 
> testing PowerLoom and STELLA against either CMU CL and/or SBCL in the 
> future, since those compilers seem to be excellent testbeds for type 
> safety issues.

> In any case, thanks again for all your hard work on PowerLoom and 
> STELLA. I look forward to exploring them further shortly.

> Best regards,
> Paul Snively
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)

> iEYEARECAAYFAkBqd6cACgkQbot1wzHBQBUfewCfYpJJFuy3absFgnMqf0LwLz+k
> YN4An30xtaDCzRxXg/haa0Xe811QVRBf
> =13UA
> -----END PGP SIGNATURE-----

> _______________________________________________
> powerloom-forum mailing list
> [email protected]
> http://mailman.isi.edu/mailman/listinfo/powerloom-forum
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.