I'm trying to convert the LispView source code to work on Allegro Common Lisp. It's
currently written for Lucid Common Lisp. I'm having a bit of trouble going from the
LCL: package to the Allegro packages. Is there anyone who can point me to a good
source for assistance in this?
Thanks in advance. I'd prefer e-mail as a response since I'm not sure if I'll
remember to check this group anytime soon.
Chad Woodford
Clarkson University
In article <·····················@news.clarkson.edu>,
Chad Woodford <········@mercury.ece.clarkson.edu.soe> wrote:
>I'm trying to convert the LispView source code to work on Allegro
>Common Lisp. It's currently written for Lucid Common Lisp. I'm
>having a bit of trouble going from the LCL: package to the Allegro
>packages. Is there anyone who can point me to a good source for
>assistance in this?
Making CL code run in a number of implementations is pretty tricky in
these days of shifting standards. It can be done, but it requires a
lot of patience, planning, and attention to detail. Here are some of
the things I have done to make a really big CL system easy to port:
o Decide that draft proposed ANS CL is the language standard to abide
by. Any deviation from the standard that affects the system is
treated as something that has to dealt with at a low level rather than
by sticking a lot of #+FOO-CL's in "user" code. This way subtle
implementation differences can be stuck in a single, known place.
Reader conditionalizations in mainline code are evil and cause
infinite porting and maintenance problems.
Note that total standard compliance is virtually impossible given the
informality of the standard, but one can get asymptotically close.
And some parts of the standard that are "intentionally vague" (LOOP
stuff, pathname wildcards, etc.) need to be resolved one way or the
other if one wants to avoid future headaches.
o Go through CLtL2 looking at the change bars to see what problems
await as far as standard-compliance goes.
o Get copies of the X3J13 committee's change proposal files (from
parcftp.xerox.com) for ready reference. A lot of the issues deal with
portability problems. Reading the arguments (and noting what company
each arguer was working for at the time) is a good way of
understanding where the traps are (and what vendors will screw you on
what issues.)
o Make a package, say "MY-LISP," that exports all the symbols in the
current draft standard. (A handy list is available on parcftp.)
Import into it symbols from various system packages as needed. For
example, the current Lucid CL has symbols denoting various dpANS CL2
constructs spread out over its LISP, CLOS, and LCL packages. I use
this package in my system's package in preference to the
implementations' LISP (or CL, but that's another hassle) package.
I cribbed this idea from the CLIM source code, which, if you have
access to it, is really good to study to learn what portability traps
await you. Check out the CLX code, too.
o For each implementation (and sometimes different versions of
implementations), have a source file for low-level implementation-
specific changes necessary to bring it up to snuff. For example,
FUNCTIONP still has its CLtL1 meaning in a number of implementations,
and so for these I shadow the symbol from the implementation package
and define my own version. Some functions have been renamed in dpANS
CL2, and so older implementations may need trampolines from the new
name. (I got this idea from the PCL code.)
o Use a defsystem utility that someone else has gone to the trouble of
porting to a lot of implementations you have never heard of.
o Use a test suite that stresses various parts of the system. There
is also a nice big CL-testing suite in the clisp distribution that I
plan to start using to test for conformance.
o For things that haven't been standardized but are in most of the
major CL's (multithreading, TCP streams, patching, etc), define code
that accesses them in one place (reader conditionalizations are OK
here) and use them in preference to the implementation-specific ones.
o There are some things that still can't be resolved with these
method. For example, I still haven't figured out how to deal with
character types and string arrays in a clean fashion. Some things,
like MAKE-LOAD-FORM, just can't be done without implementation
support.
This is probably a lot more work than you would have hoped for, but if
you take a bit of trouble with the first port, later ones will go much
more smoothly. Besides, I'd love to get LispView running under clisp
on my Linux box at home and wouldn't mind having the job made easier
:-). The key is not thinking in terms of what particular
implementations do, but rather in thinking of what they are supposed
to do.
--David Gadbois