[Openmcl-devel] OpenMCL 1.0-rc1

[Gary Byers]

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
>> well.
>>
>> :CCL-[234] 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
    they differ.)

2) things that're intended to be user-visible ways of selecting
    platform-specific functionality.

    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-[234] are obvious examples of this;
    :OPENMCL-NATIVE-THREADS and :OPENMCL-PARTIAL-MOP may be heading
    in this direction.)

And:

5) Things that may have once been intended to fit into (2), but
    are now confusing/misleading (:MCL in OpenMCL).

And even:

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
that question.)


> 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:

(defpackage "THIS-APPLICATION-PACKAGE"
   (:use "OPENMCL-MOP")
   ...)

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
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
>