Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!ATC.BOEING.COM!snicoud
From: snicoud@ATC.BOEING.COM (Stephen Nicoud)
Newsgroups: comp.sys.ti.explorer
Subject: CL compatibility.
Message-ID: <19890907175801.3.SLN@SKAGIT.atc.boeing.com>
Date: 7 Sep 89 17:58:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 39


    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!