Re: [Jscheme-user] are JScheme and GOOPS compatible?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Let me try to answer this, question:

At 05:48 AM 5/1/2003 -0400, Geoffrey Knauth wrote:
>Are JScheme and GOOPS compatible? 
>http://www.gnu.org/software/goops/goops.html ]

as well as: 

 It seems to me there are a number of slightly different Scheme object representations or conventions floating around.  I'm trying to pick one that would fit best with JScheme [for LL3 Fuels].  Do you have a favorite convention?

The short answer is "no" for both.

GOOPS is so similar to STKlos that it has a compatibility module to support STKlos syntax.  Both are based on Tiny CLOS (recommended reading) http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Tiny+Clos but are extensions.  To make Tiny CLOS useful, you need to extend it in sevral ways.  The first is to make metaobjects less anonymous.  For several reasons, instances are implemented as anonymous procedures so things are very hard to debug.  Both GOOPS and STKlos have some of the meta level code in C.  It looks like GOOPS is about 1/2 C and 1/2 Scheme, about 3500 lines each.  GOOPS at least has before and after methods (Tiny only has next), and #:keywords, which i don't think are really necessary.

JScheme has multimethods on Java classes, but it does not have a MOP.  It has several ways to define Java classes in Scheme, however.

To be compatible across Schemes there are at least two approaches:

A1:  Define your own language extension as macros that expand into the underlying object system that the target Scheme uses.  This is how people wrote portable Lisp before Common Lisp.  You'll need to pick a subset of the underlying languages.

A2:  Start with Tiny CLOS, add extensions that are easy to implement and compatible with the other object systems. I have a version of Tiny, from 1998 JScheme, which we could use as a starting point.  

A3:  Think outside the CLOS box.  I have two implementations of simple prototype languages that should be quite portable.  In additional to normal scheme you'll need a hashtable and maybe a record type.  Implementations are only 1 or 2 pages.  I can send you these separately.

k 