Re: use *repl-stack* instead of *repl-level*

[Andy Wingo <wingo@pobox.com>]

Hi Tristan,

I'm currently travelling, so I'm not sure when this reply will go out;
apologies in advance. I had not intended to push the repl-stack thing
yet, as it wasn't finished, but it looked harmless. Did the subsequent
push not fix it for you?

FYI I am trying to simplify our REPL interface, by unifying the debugger
and the repl (as is the case in a few other Schemes). Debugger commands
will be meta-commands (comma-prefixed). There is obviously the drawback
that it will be ",bt" instead of "bt", but having a uniform repl
interface would seem to outweight the disadvantages.

On Tue 29 Jun 2010 13:42, Tristan Colgate <tcolgate@gmail.com> writes:

>   Also, the removal of #:welcome means that my shell app now display
> the Guile welcome message, which
> is a bit irritating. I use start-repl for my snmp-shell app in
> guile-snmp. It is true that it basically is guile with
> with some modules loaded and some symbol resolution magic started up.
> I've been thinking about it more
> as an app in it's own right though (for the purposes of docs, and
> presenting the user a less intimidating
> experience).
>
>   *version* and repl-welcome don't seem to be overridable (at least
> not via a let). Could they be made into
> fluids? or is the current "this is definitely guile", approach to be
> enforced? Iknow I could just re-implement
> start-repl and co, but that doesn't really seem in the spirit of things.

Good questions, all! The point is definitely not to restrict the
interface, but to make it more orthogonal, (re-)usable, documented, and
maintainable. Obviously that's not yet achieved for you ;) So I have
some questions for you:

 1. Are you using a custom language?

 2. Are you presenting your users with backtraces?

 3. What should happen for your users when an error happens: a
    backtrace? A simple error reporter? A debugger? A recursive repl?

 4. What about values printing: do you need value history support ($1,
    $2 et al)?

 5. What should happen if there is an error while reading the user's
    input (as opposed to evaluating it)?

 6. What sorts of interactive help do you need?

I think answering those will help us both to understand better what you
want from Guile's repl.

Andy
-- 
http://wingolog.org/