Split into core and interactive systems

[aartaka]

Now that I've made Trivial Toplevel Commands, the model of "always in debugger/inspector" that Allegro employs is quite tempting. Given this, custom command processors that Graven Image defines feel like a bleak parody of the real implementation REPLs. Might be useful to rewrite it with actual REPL commands.

But, to make that possible, Graven Image has to either:

• Split into two separate systems:
  • graven-image/core with things like function-lambda-expresion* and fields*,
  • and graven-image/interactive (or /interface) for interactive functions like inspect*.
• Or at least not redefine/pretend to be standard functions.
  • Which is almost the same as doing nothing, because this "Graven Image + Commands" library will probably use a different naming convention or no naming convention altogether, only relying on commands?

Still, won't hurt to split the library into two separate components so that using core doesn't come with using opinionated (even if modeled after implementation-specific) inspect* etc.

This is not much of a problem, but it will become one when there's more interactive functions: ed*, step*, whatever.

[fstamour]

Could you explain a bit more what do you mean by the model of "always in debugger/inspector" that Allegro employs, for someone who never used Allegro?

[aartaka]

Sure.

1. The standard requires (I'm not sure, but most implementations are suspiciously consistent in that regard) that debugger loop should be a full-blown REPL, akin to the toplevel one.
2. In case of SBCL this debugger REPL is even more featureful than the toplevel one.
3. Allegro goes a step further: it treats toplevel loop as a debugger/inspector one. So when you invoke inspect, Allegro simply sets a global variable and allows you to use toplevel commands like :istep to recurse into inspected object.
4. Same for debugger. You can always print backtrace or inspect frames, even if you're outside debugger loop.

Which is pretty simple yet convenient—no need for custom REPLs (like inspect*), ability to act on on inspected/debugged state with the non-debugging commands etc. It's a powerful Idea that's worth exploring, I think.