the problem:
slime currently loads things in the following order:
1) the backend
2) the lisp system's implementation of the backen
3) swank.lisp
initially i've defined everything in swank.lisp, which means that the swank-XYZ.lisp files can add methods but can't redefine the default methods :( (in particular it'd be nice to use the implementation's (inspected-parts T) method). however i can't just define the inspector directly in swank-backend because 1) the inspector uses the swank-mop package which each implementation must define, and 2) that'd be ugly.
suggestions? the only thing i can think of is a refactoring of the inspector part of swank.lisp into a general inspector file, one file defining the swank-mop package for each lisp and one file redefining inspector methods for each lisp, but this just feels wrong.
On Tue, 14 Sep 2004 11:33:34 +0200, "Marco Baringer" mb@bese.it said:
Marco> the problem:
Marco> slime currently loads things in the following order:
Marco> 1) the backend
Marco> 2) the lisp system's implementation of the backen
Marco> 3) swank.lisp
Marco> initially i've defined everything in swank.lisp, which means that the Marco> swank-XYZ.lisp files can add methods but can't redefine the default Marco> methods :( (in particular it'd be nice to use the implementation's Marco> (inspected-parts T) method). however i can't just define the inspector Marco> directly in swank-backend because 1) the inspector uses the Marco> swank-mop package which each implementation must define, and 2) that'd Marco> be ugly.
Marco> suggestions? the only thing i can think of is a refactoring of the Marco> inspector part of swank.lisp into a general inspector file, one file Marco> defining the swank-mop package for each lisp and one file redefining Marco> inspector methods for each lisp, but this just feels wrong.
Two possible things:
1) The overridable INSPECTED-PARTS methods such as T probably don't depend on the mop, so they could be placed in swank-backend.lisp.
2) The INSPECTED-PARTS generic function could be changed to specialize on an implementation object, allowing the default methods to be shadowed by the backend implementation. Actually, this could be done for the whole of the DEFINTERFACE/DEFIMPLEMENTATION mechanism.
__Martin
"Marco Baringer" mb@bese.it writes:
suggestions? the only thing i can think of is a refactoring of the inspector part of swank.lisp into a general inspector file, one file defining the swank-mop package for each lisp and one file redefining inspector methods for each lisp, but this just feels wrong.
The default method for inspected-parts doesn't look very complicated and could be defined in swank-backend.
It could also be useful to add a "mode" argument to inspected-parts. E.g., CLOS objects are often implemented with structures. One mode could display the high level view of the object with slots and such, and the other mode the implementation details with structures.
The modes could also be organized in some hierarchy, so that a backend can define the more specialized method, e.g. for hashtables, by defining a method with a more specialized mode than the method in swank.lisp.
Helmut.
-
Helmut Eller -
Marco Baringer -
Martin Simmons