[Openmcl-devel] OpenMCL 1.0-rc1
gb at clozure.com
Mon Sep 26 02:33:55 EDT 2005
On Sun, 25 Sep 2005, R. Mattes wrote:
> On Sun, 2005-09-25 at 11:57 -0600, Gary Byers wrote:
>> :CORAL is almost a private joke (so private that no one gets it.)
>> It's actually still used in some old-but-occasionally-useful code
>> (MK-DEFSYSTEM), but I wouldn't be surprised if all such uses were
>> inappropriate for OpenMCL and if many were inappropriate for MCL as
>> :CCL- were used to select functionality introduced in MCL
>> 2.0, 3.0, and 4.0; they were intended to be used in user code
>> as well as the implementation, but they're probably not too
>> relevant to MCL anymore and never were too relevant to OpenMCL.
> Is there a place that list the meaning of the various OpenMCL-
> specific features?
Not that I know of.
There are at least two categories of things on *FEATURES*. (Wait
a second. Maybe that's "at least three categories.")
1) things which are mostly of interest when compiling OpenMCL itself:
things that describe the host and target processor and OS (the
"host" and "target" aren't necessarily the same. A lot of the
things in this category are only particularly useful when
2) things that're intended to be user-visible ways of selecting
I think that we can agree that :OPENMCL belongs on this list,
as does :UNIX. That -sounds- non-controversial, but I can imagine
that the reasons for wanting to conditionalize for #+/#-openmcl
are different now that they were 4 years ago (or 2 years ago),
and would -hope- that that holds true 2 or 4 years from now.
Something like :UNIX tells you a few things (e.g., absolute
physical pathname namestrings probably start with a forward-slash),
but probably can't be used for too much more than that.
3) Things that're supposed to indicate functionality that's introduced
in some particular release. (:OPENMCL-NATIVE-THREADS would be a
reasonable example of this.) I don't think that there are too
many people out there using a version of OpenMCL that doesn't
use native threads (I hope that there aren't, because I don't
really want to support such a version), so it's -currently- the
case that :OPENMCL implies :OPENMCL-NATIVE-THREADS and
:OPENMCL-NATIVE-THREADS seems redundant. A couple of years
ago, :OPENMCL-NATIVE-THREADS was a more useful/relevant feature
on which to conditionalize code than it is now. The same is
probably true of :OPENMCL-PARTIAL-MOP.
Wait; there's yet another category:
4) Things that were once in category 3 but whose relevance has
long since passed. (:CCL- are obvious examples of this;
:OPENMCL-NATIVE-THREADS and :OPENMCL-PARTIAL-MOP may be heading
in this direction.)
5) Things that may have once been intended to fit into (2), but
are now confusing/misleading (:MCL in OpenMCL).
6) Things that might have once seemed like a good idea, but are
almost useless in practice (:MCL-COMMON-MOP-SUBSET).
The new release has a new category (3) feature -
:OPENMCL-PRIVATE-HASH-TABLES - that indicate that it's possible to
create a hash table that can only be accessed by the calling thread
(avoiding some locking overhead on access.) For a while, this
read-time feature might help people conditionalize code that has
to run in older versions, but (hopefully) in a year or two we'll
see it as redundant ("well, of course OpenMCL has thread-private
hash tables. Didn't it always ?").
I tend to think that the right way to deal with some of this is to put
expiration dates on category (3) things - so that (for instance) a
year after the 1.0 release :OPENMCL-PRIVATE-HASH-TABLES disappears,
and :OPENMCL effectively means "a certain native thread API, a large
chunk of the MOP, the ability to create thread-private hash tables,
...". I think that that'd reduce the conceptual clutter some, and I
don't think that it's that unreasonable to put a time limit on the
transition period after new functionality is introduced before the
read-time feature that idenifies it is phased out.
Put another way: the time limit for :OPENMCL-PARTIAL-MOP has probably
expired. If you need to conditionalize MOP code for OpenMCL and
just use #+openmcl to do so, your wouldn't work in versions of
OpenMCL that're more than 1-1/2 years old (IIRC). Do you care about
that ? (I personally think that "no" is an acceptable answer to
> A lot of the porting i've done recently involved MOP and it's
> not really clear to me whether i should use :CCL or :OPENMCL-MOP-2
> or :OPENMCL-PARTIAL-MOP. BTW, what package should i use:
> openmcl-mop or ccl?
Ideally, if you do:
then THIS-APPLICATION-PACKAGE will be able to refer to all "MOP-related
symbols" without package qualifications but won't have to worry about
conflicting with a few hundred unrelated things that're also exported
from the "CCL" package.
Pascal Constanza has done some work on (among other things) trying to
identify the set of "MOP-related symbols". I think that the set of
symbols exported from OPENMCL-MOP currently includes everything that
he's identified, but that hasn't always been true.
> Thanks RalfD
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
More information about the Openmcl-devel