🚀 go-pugleaf

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.