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

[Camm Maguire]

Greetings!

mikel evins <address@hidden> writes:

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

I'd think it would be worth your while trying to clarify the license.

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

GCL has no threading capability at present.  Multiple processes and
MPI are options.  Select based multitasking a la cmucl is a simple
addition.  But my understanding is that lisp threading issues are
non-trivial.  This said, if you can outline a clear implementation
strategy, this will accelerate matters.  We do want to get to it
eventually

Take care,

> 
> Thanks for the info.
> 
> --me
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah