RICE@SUMEX-AIM.STANFORD.EDU (09/07/89)
Hello everyone, I just thought that I'd send a note to see if anyone else has had similar experiences to me concerning CL compatibility on Explorers or has any opinions on this matter. I've noticed two main symptons: a) The default value for sys:*inhibit-displacing-flag* is nil. This means that when you eval an expression that expression might be side effected as a result of macroexpansion/displacement. (defmacro foo (x) `(print ,x)) (setq bar '(print (foo 42))) (print bar) -> (PRINT (FOO 42)) (eval bar) -> 42 42 42 (print bar) -> (PRINT (SYS:DISPLACED (FOO 42) (PRINT 42))) !!!!!! This is a good optimisation feature since it makes the interpreter faster and reduces consing but it is definitely non CL. I got severely burned by this recently (I almost never interpret anything and found this in someone elses code). It took a long time to find the problem since I found it hard to believe that EVAL could be the thing that was trashing my data. I mentioned this problem to the chaps who turned up at IJCAI and a number of them had been burned similarly by this one. b) I have noticed on a number of CL implementations that they are strict with respect to the number of colons you use for symbols. Only yesterday did I discover the existence of sys:*restrict-internal-symbols*, which has a default value of Nil, even though CL would make you think that it should be T. (read-from-string "tv:foo") -> TV::FOO (let ((sys:*restrict-internal-symbols* t)) (read-from-string "tv:foo")) The symbol "FOO" is not external in the package #<Package TV 3723217> -> TV:FOO Neither of these magic variables are in the Profile tool. That's the main reason why I had never discovered them, I think. My point is that, even though there is a Lisp package, using which one can theoretically build portable CL programs, there are a number of other system level flags that affect the semantics of the CL and there is no coherent way to set a global switch to ensure CL behaviour in one's program. This is likely to become even more of a problem since the greater state of development and availability of TI's other CL standard stuff (CLOS/CLX/CLUE/CLCS) in release 6 means that one is more likely to want to use TI machines for the development of large portable CL systems. I think that not having the default system behaviour being strict CL is a major bug. Does anyone else have any opinion on this one? Rice.
miller@CS.ROCHESTER.EDU (Brad Miller) (09/07/89)
Date: Wed, 6 Sep 89 11:45:53 PDT
From: RICE@sumex-aim.stanford.edu
This is likely to become
even more of a problem since the greater state of
development and availability of TI's other CL standard
stuff (CLOS/CLX/CLUE/CLCS) in release 6 means that
one is more likely to want to use TI machines for the
development of large portable CL systems.
CLUE is a standard? How about CLIM then?
I think that not having the default system behaviour
being strict CL is a major bug. Does anyone else have
any opinion on this one?
I don't know about "major" bug, but I certainly think there should be a very
easy way to be "standard conformant", e.g. a fn that sets all the right
switches or some such.snicoud@ATC.BOEING.COM (Stephen Nicoud) (09/08/89)
Date: Wed, 6 Sep 89 11:45:53 PDT
From: RICE@sumex-aim.stanford.edu.ARPANET
Hello everyone,
I just thought that I'd send a note to see if anyone
else has had similar experiences to me concerning
CL compatibility on Explorers or has any opinions on
this matter.
...
My point is that, even though there is a Lisp package,
using which one can theoretically build portable CL
programs, there are a number of other system level
flags that affect the semantics of the CL and there is
no coherent way to set a global switch to ensure CL
behaviour in one's program. This is likely to become
even more of a problem since the greater state of
development and availability of TI's other CL standard
stuff (CLOS/CLX/CLUE/CLCS) in release 6 means that
one is more likely to want to use TI machines for the
development of large portable CL systems.
I think that not having the default system behaviour
being strict CL is a major bug. Does anyone else have
any opinion on this one?
I try to maintain strict CL code for Symbolics, Explorers and in Lucid,
and find things like this really do hinder development. TI should at
least document the incompatibility *and* provide a way to switch to
strict behavior.
As far as it not being the default mode, I'm ambivalent. Somehow, new
or incompatible extensions need to be introduced to users, and making
them the default can be that way, although that can be rather
presumptuous. But then if you don't *tell* the user, you're being a
very bad boy!DAVID%COUSTEAU@cs.umass.edu (David Forster) (09/08/89)
I don't see the setting of sys::*inhibit-displacing-flag* as a `bug' so much as a (possibly) faulty policy decision. I think the default ought to be whatever makes the machine run fastest, but it should definitely be settable in the profile. Forgive the analogy, but it's like DEC's FORTRAN compiler having a switch to check for adherence to ANSI standards -- their default is to use their own dialect, but you can force strict checks by setting the appropriate command line switch. I agree with the suggestion to have some easy way to force strict CL semantics. It might be specified as an extra parameter to ticl::turn-common-lisp-on. By the way, sys::*inhibit-displacing-flag* is documented, though deeply buried (section 18.5) in the lisp reference manual. I don't know if there's a section of the documentation labelled something like ``Strict Common LISP Compatibility,'' but there ought to be. It would be the ideal place for such items as this. - David
cerys@BBN.COM (Dan Cerys) (09/12/89)
b) I have noticed on a number of CL implementations that they are strict with respect to the number of colons you use for symbols. Only yesterday did I discover the existence of sys:*restrict-internal-symbols*, which has a default value of Nil, even though CL would make you think that it should be T. I think that not having the default system behaviour being strict CL is a major bug. Does anyone else have any opinion on this one? I'll also agree with Rice on this. CLtL sez that the reader should signal a correctable error when foo:bar (where BAR in an internal symbol of FOO) is read. It shouldn't be necessary to set some obscure variable (is it even documented?) to get this standard CL behavior. The current Explorer behavior was handy for conversion of Zetalisp programs, but I think we've gone beyond that. Change the default value to support Common Lisp properly. If Zetalisp is still important to some users (I would expect there are some), you may want to be ambitious and provide the external-symbol check on a per-package basis, as an attribute of the package. I believe another Lisp vendor does something like this. Of course, if you do this, make the default to be to enforce what CL specifies. Dan
acuff@SUMEX-AIM.STANFORD.EDU (Richard Acuff) (09/12/89)
I agree that SYS:*INHIBIT-DISPLACING-FLAG* should default to T, and should
be in Profile.
While I would like to see the Explorer catch the error of referring to an
internal symbol with a single colon name, I very much hope that it doesn't
fall into the error handler, as most other implementations annoyingly do, but
rather, when I type FOO:BAR I hope it says "There is no external symbol BAR in
package FOO. Do you mean FOO::BAR? (Y or N) ". It really bugs me that so
many "powerful" systems waste my time paging and fussing to fall into a
compilcated, screen trashing error handler for such a trivial error. Most of
them don't then even have a "I meant FOO::BAR" proceed option!
-- Rich
-------