Marco Baringer mb@bese.it writes:
i would like to make a change to slime which isn't directly related to slime as an emacs lisp IDE but related to slime's (unexpected) use as a generic debugger interface.
The function frame-locals currently returns the name and the value of a frame-local as strings, while this is great for emacs it makes it impossible for me[1] to usefully inspect those values in my debugging interface (built on slime but doesn't use emacs). The change i would like to propose is the make swank:frame-locals return, along with :value-string and :name, a :value and :name-value property.
is this ok or is it important that slime remain concentrated on being an emacs interface and not a general common lisp implementation abstraction layer? This particular change would be rather trivial but I can see this being the start of a road slime may not want to take.
I think this is the right direction. The backend functions should use proper objects instead of strings and natural conventions, e.g., return multiple values instead of lists. The conversion to strings should be done in the frontend.
E.g., FRAME-LOCALS should return a list of names (symbols) and a list of values. The current :id property is a CMUCLism and can probably be recreated from the list of names. Then we need a function in the front end, say SLDB-FRAME-LOCALS, to convert the values to a list of strings. It might even turn out that this separation removes some duplication in the various backends.
Helmut.