[Openmcl-devel] OpenMCL future

[Gary Byers]

On Fri, 6 Sep 2002, Sven Van Caekenberghe wrote:

> Gary,
>
> In one of your response you said '... the plan is to phase them in over
> the next few OpenMCL
> releases (details forthcoming; if anyone's curious, ask.) ...'. So here
> are some questions:
>
> What are the details for the next few openmcl releases ?

I'm not sure of exactly what'll happen when.  It is very likely that
0.14 will use "cooperatively scheduled POSIX threads" (POSIX threads
with locks+sempaphores so that a lisp scheduler can control their
execution) and a number of low-level architectural changes (deep-binding
of special variables, more-per-thread context kept on a per-thread
basis, etc.) that address many of the issues related to migrating to
native threads.  The adoption of native (preemptively scheduled) threads
will raise lots of other issues (in the GC and elsewhere), so I want
to sort of do this incrementally.

There are still known areas of ANSI incompatibility (ED isn't defined,
logical pathname translations maintain case-sensitivity when they
shouldn't, some conditions that're signaled are generic when the
spec requires something more specific) and there are almost certainly
unknown areas: I've never gone through the entire spec, generated
test cases for everything, and tried to ensure that it passed.  I'd
guess that the number of discrepancies that this would find are few
and minor, but at this point that's just a guess.

There are other areas of missing functionality (MOP support, or as
much of the MOP as can be supported without impacting performance)
and I think that some performance improvements (the compiler's
handling of unboxed arithmetic, at least in constrained cases) can
be accomplished in the short term.

The quantity and quality of available documentation could both
be improved.  Writing a really comprehensive manual is probably
a long-term project (and would ideally involve the participation
of people competent to do so.)  What's there could be better organized
and in some cases (the "internals" document) needs to be brought up
to date.

I'd like to be able to improve the Cocoa demo to the point where
(more) users could enhance it and contribute to its development.  (If
it got to that point, I'm sure that it would start to improve a lot
faster.)  I think that it's both important to be able to offer an
alternative IDE for people not comfortable/satifisfied with ILISP
and to develop a framework for delivery of UI-rich applications.

Someone asked me a few weeks ago when I thought that the version number
should change to 1.0 and the "beta" designation removed.  On the one
hand, I wouldn't feel entirely guilty about having done so for any
of the past few releases (I've seen, used, and worked on "released
products" that were even rougher around the edges); on the other
hand, I'd like it to continue to have a high degree of fluidity:
I'd like to feel able to change whatever implementation details
need changing whenever there's technical motivation to do so.

These are things that I have in mind; I'd certainly be interested
in hearing other people's ideas.

>
> Are you the only developer ? Can you keep this up ?

Gail Zacharias worked on sockets, pathnames, streams, and other
stuff in the last year; several other people have contributed
examples, bugfixes, and code.

Without going into a lot of detail, I get paid to (among other
things) work on OpenMCL, and the "other things" are often closely
related.

>
> Is the relationship with Digitool like a code split, or will openmcl
> become the core of MCL like Darwin is for Mac OS X ?

It's currently more like a code split.

Note that Digitool doesn't currently have a released OSX-native MCL,
and that fact makes it difficult to say much about the issue.

If it were possible to publicly discuss this, it would certainly be
interesting to do so ...


>
> ;-)
>
> Sven
>
> --
> Sven Van Caekenberghe - mailto:sven at beta9.be
> Beta Nine - software engineering - http://www.beta9.be
> .Mac - svc at mac.com - http://homepage.mac.com/svc
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel