On 7/23/13 11:34 PM, Sean Champ wrote: […]
Personally and primarily, I've been interested in the possibility of developing an ABCL interface onto Apache Jena, and possibly an interface onto some JARs distributed by the GeoTools project - would like to develop a process of transforming an ESRI Shapefile into an OWL ontology, and it seemed that ABCL would be a good Common Lisp implementation to use for such a purpose.
See [jeannie][] for an initial wrapping of Jena with ABCL. It doesn't do much more than read RDF from a PATHNAME, but adding the rest is a matter of rolling up the proverbial sleeves.
[jeannie]: http://bitbucket.org/easye/jeannie
[…]
In looking at that idea, I'd been interested about how the CLOS support is implemented in ABCL, and whether and how MOP might be implemented, there.
As much of CLOS/MOP as possible has been implemented in Lisp: see clos.lisp. CLOS is mostly historical, evolving in fits and starts over the lifetime of ABCL. The MOP has been added mostly of the last year by Rudi Schlatte. Following his commits chronologically would give somewhat of an impression of how it is implemented.
[…]
(On a personal note: Between moving and returning to college, it's been a busy summer, frankly, but there are some bluesky ideas that one can focus on, I suppose)
No sweat: we should still be here when you get some time.
On 07/23/2013 03:10 PM, Mark Evenson wrote:
On 7/23/13 11:34 PM, Sean Champ wrote: […]
Personally and primarily, I've been interested in the possibility of developing an ABCL interface onto Apache Jena, and possibly an interface onto some JARs distributed by the GeoTools project - would like to develop a process of transforming an ESRI Shapefile into an OWL ontology, and it seemed that ABCL would be a good Common Lisp implementation to use for such a purpose.
See [jeannie][] for an initial wrapping of Jena with ABCL. It doesn't do much more than read RDF from a PATHNAME, but adding the rest is a matter of rolling up the proverbial sleeves.
Will take a look - I suppose, maybe it'll help towards an idea for how to get a start with extending other Java APIs, in Common Lisp.
[…]
In looking at that idea, I'd been interested about how the CLOS support is implemented in ABCL, and whether and how MOP might be implemented, there.
As much of CLOS/MOP as possible has been implemented in Lisp: see clos.lisp.
Took a look - so, MOP is implemented on the Lisp side, of course, and there's the documentation in clos.lisp denoting the Java classes effectively extended in the Common Lisp code - quite succinct.
I think that I should not be too embarassed to denote that I'd only looked so far as to consult the Java API, when trying to construct a UML model for the MOP implementation in ABCL - not being aware, then, that ABCL may sort of extend the concept of class specialization, effectively in specializing Java classes with Common Lisp
I think it's helpful to have a sense of where to start in studying the source code, then. Thank you.
-- Sean
On Jul 24, 2013, at 04:02, Sean Champ spchamp@me.com wrote:
On 07/23/2013 03:10 PM, Mark Evenson wrote:
On 7/23/13 11:34 PM, Sean Champ wrote: […]
In looking at that idea, I'd been interested about how the CLOS support is implemented in ABCL, and whether and how MOP might be implemented, there.
As much of CLOS/MOP as possible has been implemented in Lisp: see clos.lisp.
Took a look - so, MOP is implemented on the Lisp side, of course, and there's the documentation in clos.lisp denoting the Java classes effectively extended in the Common Lisp code - quite succinct.
I think that I should not be too embarassed to denote that I'd only looked so far as to consult the Java API, when trying to construct a UML model for the MOP implementation in ABCL - not being aware, then, that ABCL may sort of extend the concept of class specialization, effectively in specializing Java classes with Common Lisp
Some general remarks / rambling about the MOP implementation follows. The only necessary low-level change to add CLOS / the MOP to a Lisp is support for funcallable objects. These are used to implement functions that change their behavior but keep their identity (i.e., generic function objects, which dispatch to methods depending on the type of the arguments).
Everything else can in principle be implemented in Lisp -- but since the metaclass structure has lots of circularity (class objects reference slot objects which have classes themselves) some low-level hackery is required to set up this spaghetti structure. In ABCL the lowest-level classes (slots, standard-class, the standard condition classes, some others) are set up in Java, together with an implementation of find-class. This is contained mostly in the file StandardClass.java. The (defconstant ...) forms at the beginning of clos.lisp show which MOP metaclasses were defined in Java. The rest of the metaclass hierarchy is created, after some normal functions are defined, via the define-primordial-class macro, which is like defclass but with less error checking and options. Near the end of clos.lisp, many normal functions are replaced with generic functions, once we have implemented generic functions themselves.
In summary: Any Java-only analysis of abcl's structure will find an interlinked set of instances of StandardClass + some subclasses thereof; lots of the interesting stuff happens Lisp-side, where the aforementioned StandardClass instances implement classes like method-combination, standard-accessor-method, generic-function, etc. Also, UML does Java/Smalltalk-style OO best and didn't really play well with generic functions and multimethods last time I looked; I don't know if that has changed.
Rudi
armedbear-devel@common-lisp.net
-
Mark Evenson -
Rudi Schlatte -
Sean Champ