Development environments such as Slime benefit from being able attach additional source location information (eg. buffer associations) to functions. Currently Slime does this by patching SBCL in order to be able to attach its own plists to SB-C::DEBUG-SOURCE structures.
I propose we add :SOURCE-PLIST option to WITH-COMPILATION-UNIT, with the following tentative spec:
:SOURCE-PLIST Plist-Form
Attaches the value returned by the Plist-Form to internal source location information of functions and definitions compiled in within the dynamic contour. Primarily for use by development environments, in order to eg. associate function definitions with editor-buffers. Can be accessed as SB-INTROSPECT:DEFINITION-SOURCE-PLIST. If multiple, nested WITH-COMPILATION-UNITs provide :SOURCE-PLISTs, they are appended togather, innermost left, unless :OVERRIDE is true, in which case previous :SOURCE-PLISTs are ignored.
The space-costs of this are nominal: size of DEBUG-SOURCE structures is increased by one slot/word, but there is only one of those per compiled file -- though one per function loaded from source or entered at the toplevel.
I think calling it a :SOURCE-PLIST is a reasonable compromise between more abstract names such as :INFO, the documentary nature of the -PLIST vrt. the appending behaviour, by YMMW.
To illustrate the usage, the significant part of SWANK-COMPILE-STRING[*] could eg. become
(with-compilation-unit (:source-plist (list 'emacs-buffer buffer 'emacs-string string 'emacs-position position)) (with-input-from-string (s string) (load s))))))
I've the SBCL parts of this implemented in my local tree, and most of swank-sbcl adapted for this.
The questions to SBCL and Slime folks respectively:
1. Does the interface seem sane and something we would be happy to support? Are the non-slime use cases this doesn't reasonably cover?
2. Does this fit the needs of Slime? If this existed on other platforms as well, would you be tempted to use this instead of whatever you currently use?
[*] To nitpick, I venture the opinion that SWANK-COMPILE-STRING is a misnomer, as as far as I can tell the intention is something like "evaluate the forms contained in this string as if they had been entered at the toplevel, but making sure all functions are compiled".
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Nikodemus Siivola nikodemus@random-state.net writes:
- Does this fit the needs of Slime?
Yes.
If this existed on other platforms as well, would you be tempted to use this instead of whatever you currently use?
I don't quite understand the question. Currently, no other implementation uses with-compilation-unit for this feature and I don't expect this to change any time soon. Some implementations have something that's essentially a declaration and in CMUCL we can supply our source info to compile-from-stream. For SLIME we will use whatever works best for a particular implementation.
Helmut.
On Tue, 31 May 2005, Helmut Eller wrote:
If this existed on other platforms as well, would you be tempted to use this instead of whatever you currently use?
I don't quite understand the question. Currently, no other implementation uses with-compilation-unit for this feature and I don't
Sorry, that was badly phrased on my part. I essentially ment to ask "do you feel that the approaches provided by other implementations are cleaner, better, etc?".
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Nikodemus Siivola nikodemus@random-state.net writes:
Sorry, that was badly phrased on my part. I essentially ment to ask "do you feel that the approaches provided by other implementations are cleaner, better, etc?".
Well, CMUCL's compile-from-stream is exactly what we need for SLIME. A declaration (or proclamation) also sounds like a reasonable approach. But as always:
Do not ask how. Ask rather why. Once you know your reason, your method will be obvious. -- The book of Bears (zen scheme, ch 1 verse 22)
Helmut.