In article <····················@erg.sri.com> ·····@erg.sri.com (Kerry
Koitzsch) writes:
shouldnt *gensym-counter* be in the common-lisp-user package,
rather than in LCL (for Lucid) or FUTURE-COMMON-LISP (for
Symbolics) ?
Ehm, no. Actually it should be exported from the COMMON-LISP package.
That way you would see it in COMMON-LISP-USER, but also in all other
packages that use COMMON-LISP (which is the default).
This essentially means for portable code,
(defun GET-GENSYM-COUNTER ()
#+lucid lcl::*gensym-counter*
#+lispm future-common-lisp::*gensym-counter*
.....
)
I always write something like this
#+(or Allegro CMU) (defpackage "MINE" (:use "COMMON-LISP"))
#+Genera (fcl:defpackage "MINE" (:use "FUTURE-COMMON-LISP"))
#+Lucid (in-package "MINE" :use '("LISP" "LUCID-COMMON-LISP"))
(in-package "MINE")
#+Lucid (defmacro declaim ... :-)
Allegro 4.1 and CMU CL (at least here :-) do it right:
* (find-all-symbols "*GENSYM-COUNTER*")
(*GENSYM-COUNTER*)
* (mapcar #'symbol-package *)
(#<The COMMON-LISP package, 1469/1933 internal, 1038/1305 external>)
The problem is not restricted to *GENSYM-COUNTER* - it's all symbols
that have been added since CLtL1 up to now (CLtL2-dpANS-...).
I like Allegro's approach best - they put everything into COMMON-LISP
and make this synonymous with the LISPpackage. This encourages
programmers to make their stuff standards-conformant (maybe the other
vendors are more conservative and don't want to break to much older
code while the standard isn't official yet). CLtL2 or the dpANS draft
work quite well as a reference for Allegro. (Of course there are a
couple of things that are still in flux, and there are some
differences between CLtL2 and dpANS, and between dpANS and the
standard when it will be finished...). There are some
incompatibilities with respect to CLtL1, of course, but there's
backward compatibility support contained in another package ("CLTL1").
Allegro also seem to have more of dpANS' new functions than the other
Lisps, including pretty-printing and the new conditions. Lucid 4.1
doesn't even have e.g. DECLAIM anywhere, and the conditions have a
different syntax. Genera has many symbols that are exported from more
than one package, and unfortunately they also have a historical
COMMON-LISP package that is quite different from the COMMON-LISP
package defined by X3J13, so they have to call there standard
COMMON-LISP package "FUTURE-COMMON-LISP"...
If you want your Lisp programs to run easily under Lisps that conform
to the future ANSI standard, I recommend porting them to a recent
version of Allegro or CMUCL. I think it's funny that Lucid and
Symbolics seem to be better represented at the X3J13 meetings, while
Allegro and CMU actually implement the results... I don't know how the
other Common Lisps (Harlequin, MCL etc.) handle the transition issue.
Regards,
--
Simon Leinen.
Laboratoire d'Intelligence Artificielle
Ecole Polytechnique Federale de Lausanne
In article <··················@liasg2.epfl.ch> ·····@lia.di.epfl.ch (Simon Leinen) writes:
Allegro 4.1 and CMU CL (at least here :-) do it right:
MCL does it right, too.
Allegro also seem to have more of dpANS' new functions than the other
Lisps, including pretty-printing and the new conditions.
In my experience MCL wins over Allegro 4.1. In a project that uses
those lisps all portability problems have been Allegro's problems and
not MCL's. E.g. reduce without :key and lack of logical pathnames.
If you want your Lisp programs to run easily under Lisps that conform
to the future ANSI standard, I recommend porting them to a recent
version of Allegro or CMUCL.
Or MCL.
--
Hallvard Traetteberg
Dept. of Knowledge Based Systems
SINTEF SI (Center for Industrial Research)
Box 124 Blindern, 0314 Oslo 3
NORWAY
Tlf: +47 22 06 79 83 or +47 22 06 73 00
Fax: +47 22 06 73 50
Email: ···················@si.sintef.no
In article <················@monsun.si.no> ···@si.no (Hallvard Tretteberg) writes:
In my experience MCL wins over Allegro 4.1. In a project that uses
those lisps all portability problems have been Allegro's problems and
not MCL's. E.g. reduce without :key and lack of logical pathnames.
True, our REDUCE doesn't accept the :key argument yet. However, we
have had a patch to Allegro CL 4.1 that implements logical and wild
pathnames (in fact, all the remaining ANSI pathname items) for quite
some time. Send mail to ····@franz.com if you want the patch.
--
Kevin Layer, Franz Inc. 1995 University Avenue, Suite 275
·····@Franz.COM (internet) Berkeley, CA 94704 USA
Phone: (510) 548-3600 FAX: (510) 548-8253
In article <··················@liasg2.epfl.ch> ·····@lia.di.epfl.ch (Simon Leinen) writes:
If you want your Lisp programs to run easily under Lisps that conform
to the future ANSI standard, I recommend porting them to a recent
version of Allegro or CMUCL. I think it's funny that Lucid and
Symbolics seem to be better represented at the X3J13 meetings, while
Allegro and CMU actually implement the results... I don't know how the
other Common Lisps (Harlequin, MCL etc.) handle the transition issue.
Harlequin appears to follow CLtL2, presumably on the grounds that it's
an easily accessible, fixed point of reference. (Logical pathnames
are indeed quite handy.) CLtL1 compatibility is maintained as far as
possible, as an extension.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
From: Jeff Dalton
Subject: Re: Standardization and *gensym-counter*
Date:
Message-ID: <8553@skye.ed.ac.uk>
In article <··················@liasg2.epfl.ch> ·····@lia.di.epfl.ch (Simon Leinen) writes:
>If you want your Lisp programs to run easily under Lisps that conform
>to the future ANSI standard, I recommend porting them to a recent
>version of Allegro or CMUCL. I think it's funny that Lucid and
>Symbolics seem to be better represented at the X3J13 meetings, while
>Allegro and CMU actually implement the results... I don't know how the
>other Common Lisps (Harlequin, MCL etc.) handle the transition issue.
CMU CL (up to 16d at least) is pretty good at handling "old-style"
code. I have significantly more trouble with Allegro, though there
are some (well, at leats one) compatibility flags that can be set.
I certainly think it's a good idea for implementations to contain
all the new features. But I also think it's easy to underestimate
how much of a pain even minor incompatibilities with earlier versions
can be. I usually have a choice about which Common Lisp I use,
and I've stopped using some implementations for significant periods
because of fairly minor changes that required more time to handle
than I had to spend.
-- jd