[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
porting guide lucid -> allegro ??
> Does anyone have a guide for porting common lisp code from lucid cl to
> allegro? I'm doing a medium size system (qsim), and have already found two
> 1 - in lucid, byte pointers (as used by ldp and dpb) are
> self-evaluating, while in allegro they are sexprs, and definitely not
> self-evaluating. (By self-evaluating I mean they eval to themselves,
> as do numbers.)
> 2 - in lucid, it is feasible to use strings as case tags - e.g.
> (case "foo" ("foo 1)(otherwise 2))
> seems to give 1. In allegro, case compares tags with eql, and only strings
> that are eq are eql.
> DOes anyone have a longer list of such differences? Thanks.
I just wanted to promote the idea of programmers somehow conveying their
experiences with porting between Lisps, I don't know in what forum.
I spent much of August converting my Franz Allegro-developed program to work
on Symbolics/Lucid/akcl, and there were bunches of gotchas, some (many) my
fault, some not. Often they're just "features" that one compiler accepts but
another does not; I found the Allegro compiler more forgiving than the Lucid
one, which is both good and bad; the Allegro compiler allowed me to do a few
things that were semi-legal as I remember, but on the other hand I still have
one function that the Lucid type-checker balks at, and I don't know why
(sigh), it works on every other compiler I have access to. And a few
problems were things ClTL just doesn't cover carefully, maybe with 4.0 of
Franz/Lucid it will be less of a problem.
I didn't write them down, because I didn't know what I would do with them
(they're probably compiled away in subconsciousness), but they sure would be
useful for people. comp.lang.lisp??? I don't know. If anyone has specific
differences for Lucid vs. Franz, I'd be interested as well.
email@example.com NASA-Ames Research Center, Moffett Field, CA