Jose A. Ortega Ruiz wrote:
Geiser takes full advantage of these capabilities (which i happen to
like a lot), and has the concept of current namespace, which defines the
environment of evaluations sent to the underlying scheme. When you're in
the REPL, the current namespace is the last you entered (using enter! in
PLT or an equivalent mechanism in Guile). When you're editing scheme
code, the current namespace is defined by the module the current file
belongs to; when you send code to be evaluated, geiser enters the
namespace, evaluates the code and sends back the result after returning
to the previous namespace. This provides a well-defined context for all
geiser commands (for instance, when you ask for completions you only get
identifiers visible in the module at hand). One can also, of course,
evaluate any form in the current namespace, not just definitions.
This actually sounds very nice.
So to make this concrete...
Let's say I'm working on libraries (abc) and (def), and a script
"xyz.sps" which uses them.
If the cursor is in 'abc.sls', I'm in that library's internal namespace.
I can use the buffer as a scratchpad, evaluating stuff in that
namespace. Similar for 'def.sls'.
But, if I switch to 'xyz.sps' (a script, not a library) which might
start with:
(import (chupacabra)
(abc)
(def))
stuff I evaluate from that buffer has the namespace populated by those
three libraries.
If that's the way it works, then this is very cool.
One tricky thing is, what if, when using a library file as a scratchpad,
you've got expressions which don't make sense in a library? Or that
might make the library loader complain? Maybe then it makes sense to
actually switch to the REPL, with that library as the namespace, to
continue the experiments.
Ed
