[Gcl-devel] Re: a few questions about the status and direction of GCL

[mikel evins]

On Nov 16, 2004, at 12:57 PM, Camm Maguire wrote:

>

> For better or worse, I continue to be relatively 'existing-app'
> oriented, so yes, I would like to help time-permitting with making
> GCL work for your project.

Great! The mailing list ballooned to three dozen people in two days, 
and discussion has been hot and heavy. The main topic right now is 
which Lisp to use, so your reply is quite timely.

> > The new project is intended to build an open-source development system
> > that is similar in spirit and design to the SK8 system developed at
> > Apple's ATG in the late 80s and 90s. The original creator of SK8 is on
> > board, and we are having preliminary logisitical and goals 
> > discussions.
>
> Quick searching seems to indicate that the original SK8 was released
> in source form, no?

Yes, and it's still readily available, but its license is unclear, and 
its implentation is extremely (Classic) MacOS-centric.

> > One feature that Ruben (SK8's creator) insists on is Unicode
> > support. Is such support planned for any soon-to-be forthcoming
> > release of GCL?
>
> We hadn't discussed this much, but if there is interest, it would not
> be too hard from what I can tell, depending of course on what one
> means by 'support'.  Perhaps you could briefly describe how any other
> lisp system has done this to your satisfaction.  I'm hoping that we
> can add a layer of new functions rather than changing the behavior of
> existing functions.  There is also the impact on ANSI compliance if
> any, of which I am quite ignorant, and hope Paul can illuminate for
> us.

The main goal, I believe, is to support really good 
internationalization at the level of user interface, so I imagine that 
it would be acceptable if the support was in the form of added string 
types and functions to deal with them.

> > Probably the new project will also need MOP features. How well does
> > GCL support MOP-like features nowadays.
>
> Second time we've been asked about this in the last few days.  My
> understanding is that PCL implements MOP in addition to CLOS, and we
> use PCL in the ansi build.  In fact, our pcl files follow those in
> cmucl quite closely, at least when we're working on this.  Just
> browsed through the 'Art of the Metaobject Protocol' spec, and the
> functions specified therein all appear to be fboundp in the ANSI
> build.  But obviously, I don't use this myself, and so am no expert.
> Feedback always appreciated.
>
> We are also likely to be a bit more behind on the 'mop' than on the
> ANSI clos, as Paul's test suite to my understanding only covers the
> latter.

That looks pretty good.

Another very important question concerns support for multiple threads 
of control. Can you help us out here? I think absence of some sort of 
multithreading with reasonable performance characteristics is a 
show-stopper.

Thanks for the info.

--me