[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: a few questions about the status and direction of GC
Re: [Gcl-devel] Re: a few questions about the status and direction of GCL
22 Nov 2004 10:33:08 -0500
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
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
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
> Thanks for the info.
> Gcl-devel mailing list
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah