Requesting input on some possible low-level changes

On Wed, 2003-09-03 at 10:22, C Y wrote:

> Just so we have general idea, how hard would an interface be that
> doesn't require the output scanning?  It seems to me that scanning
> output would always be fragile way to handle things.  I suppose
> something different would have to be done at the lisp level?

In principle, adding a non-scanning interface is trivial. I did a simple
prototype using Corba a long time ago. The devil is in the details -- my
simple prototype would hang if you did anything that invoked an input
function other than the main one. That's why I think working on the
TeXmacs interface is a reasonable place to start -- it will force us to
identify and control all possible sources of input.


> > 1) The ordinary command input at the (C1) prompt. This one is
> > obvious.
> 
> Slightly less so when the input and output characters are changed from
> C and D.  Can that be handled?

My proposed plan is insensitive to prompts, so ... yes.

Actually, the C's and D's were really getting in my way today while
working with Maxima on a physics topic. We should make that change soon.


> > 	B.2) Create a minimal Maxima Lisp debugger loop as an
> > user-selectable alternate to the function in (B.1).
> 
> Um.  How would this be different from the current behavior?  

It would be different because we could add code to do the appropriate
output before the (read). I can't do that with the built-in debugger
loop.

> Would we
> have to create our own debugging environment?

Yes, but I would try to make it as thin a layer on top of the underlying
lisp as possible.

> Maybe the way to handle this would be to have a variable debugger-mode
> which could be set either to 0 (B.1 behavior), 1 (B.2 behavior), or 2
> (current behavior - full Lisp debugger.)  Don't know if that's
> practical, but it would keep most people out of harms way while making
> the option easy to change at need. 

ANSI Common Lisp already has a *debugger-hook* variable. I don't know if
we need a layer on top of that, or not.
 
> My main concern would be that putting a lot of work into making it
> easier to scan the output wouldn't be worthwhile if a better way exists
> but I don't really know and in any case I'm not the one doing it.

Most of the effort is really just in identifying the places that call
for input. That effort will not be wasted.

> In
> any case this direction sounds like a good one, and I definitely
> support not having users dumped to the debugger.

Thanks.

--Jim