Experiences porting applications from Symbolics

[Gumby@MCC.COM]

    Date: Tue, 27 Dec 88 11:12:21 -0500
    From: howell%community-chest.mitre.org@gateway.mitre.org

I have ported a large application which was originally developed on the
lisp machine to Lucid and the Explorer, and have people bringing it up
under VaxLisp and KCL.

    For example, did you encounter problems with variant semantics in different
    Common Lisp compilers?

The semantics of CL are reasonably well fixed, and the extension
mechanism (defmacro and defun) are well-defined, so I didn't really find
this a problem except in one case (see below):

			    What kind of support did the new host provide for
    mouse-sensitive bit-mapped graphics, and for access to them?

The interface part of our system is non-portable.  Today it's possibly
to write a portable interface using X windows and CLX.  I've even seen a
presentation system for CLX.  However the X implementation for the lisp
machine is still slow, although that's getting better.  In terms of IO,
it's best to keep your interface as high-level as possible, and do an
seperate port of your IO code.
								  Did you find
    that your application depended on Symbolics-provided function libraries or
    "OS services", or was your application relatively host-independent?
    Any big "gotchas" that you didn't expect?

I don't know if you have the opportunity to do so, but your life will be
a lot easier if you start coding your system with the intention of
keeping it portable.  Make your system's packages inherit from Lisp
rather than SCL, and just import the things you'll need.

Given that, there are a few things to worry about.  There are some
documented incompatibilities, like IF's taking more than one clause if
its predicate fails, or the lisp machine's allowing extra arguments to
certain functions.  Check these out carefully.  You can always play
games in the target port by shadowing symbols in your package (in our
case we shadow IF, so that we can use the lisp machine IF, for
instance).  Often times there are optimisations which can be "stubbed
out" in a target port, such as defining a macro called STACK-LET which
expands into let, for instance.  Doing a port doesn't have to mean
giving up features in the lispm version.

I use style-checking compiler warnings to catch some common cases of
incompatible or non-portable programming style.  You can play games with
these, having them check the value of *package* at compile-time, for
instance.

Watch out for IGNORE.  The lisp machine compiler allows one to have
several arguments named IGNORE which the compiler then assumes won't be
referenced.  Unfortunately you'll have to rename these and declare them
ignored explicitly.  Doing (proclaim (ignore ignore)) is dangerous,
since 1> the target compiler won't necessarily allow multiple
occurrences of IGNORE even then, and 2> more importantly there may be
system macros which use ignore as a perfectly good variable.

There's no CL condition system yet, which makes some simple things
complicated.  I generally get around it by binding lots of variables to
functions which callees funcall rather than using SIGNAL.

We have our own FASL format for our data files.  I had a couple of
problems with this:

 o - The size of fixnums.  You have to do explicit checks rather than
     (typep x 'fixnum).
 o - Package names.  Package names are case-insensitive on the lisp
     machine.  This means that the safest thing to do when making or
     finding a package is (find-package 'foo) rather than (find-package
     "foo").
 o - Also, (package-name (find-package 'lisp)) is "COMMON-LISP" on the
     lisp machine, not "LISP".  Beware of dependencies of this nature.
     In fact, if you do dump data files, be careful while dumping them
     that your data does not contain symbols in lispm packages (even the
     SYSTEM package is dangerous).  When we dump backquoted structure it
     dumps the symbols si::xr-bq-cons and si::xr-bq-list rather than
     cons and list.  This isn't a problem if you print your stuff with
     the printer and load it with the reader.

If you define your code with DEFSYSTEM you may find it hard to
recompile.  First of all, writing a package for computing the
dependencies is a pain, though I hear the unix people have a program
called "make" which is suppsoed to be pretty good in this area.  Of
course, you still have the problem that if you update one you have to
update the other.  Secondly, DEFSYSTEM deferrs undefined-function
warnings until the system has been compiled completely.  You may have to
spend a lot of time adding forward declarations to get your compiler to
shut up.

The of course there's the biggest problem which is that I have yet to
use an enviroment that is as conducive to code development as the lisp
machine.  I don't consider the other machines development machines, just
target machines.

Hope this is a start.  Good luck.