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