Requesting input on some possible low-level changes

While I was at the Metz meeting I had a conversation with Joris van der
Hoeven about the interface between TeXmacs and Maxima. The
maxima-texmacs interface is fragile -- there are many ways to get the
interface to hang. I am sorry to say that the problem really is Maxima's
fault. I am interested in solving the problem from the Maxima side
because I think it is a good way to start on developing a robust
interface between Maxima and other applications.

The maxima-texmacs interface currently works by running a filter on the
Maxima output that looks for prompts. When a prompt is found, TeXmacs
knows that Maxima is ready for input. It would be preferable to have
Maxima emit an appropriate string when it is ready for input. (In
general, I would like to see an external interface that does not require
scanning through output streams, but that can come later.) Adding the
appropriate output strings to Maxima is not as simple as it sounds,
because Maxima waits for input in many different situations, not all of
which are currently under our control.

Here are the type of input I have identified:

1) The ordinary command input at the (C1) prompt. This one is obvious.

2) Questions encountered during a calculation, e.g., "Is  a  positive,
negative, or zero?" This one is pretty obvious, too.

3) Input from the info routines, e.g.,

--------------------------------------------------
(C3) ? ask

 0: ASKEXP :(maxima.info)Definitions for Simplification.
 1: ASKINTEGER :Definitions for Simplification.
 2: ASKSIGN :Definitions for Simplification.
Enter n, all, none, or multiple choices eg 1 3 :
--------------------------------------------------

4) Other inputs under Maxima control, including the Maxima debugger. I'm
not sure how many such routines there are. Anyone?

5) to_lisp() or ctrl-c send the user to the underlying Lisp's
read-eval-print loop.

6) Lisp errors send the user to the underlying Lisp's debugger.

While items (1)-(4) can easily be modified to send the appropriate
additional prompts, items (5) and (6) present a real problem. After
having thought about this for a while, I would like to propose the
following fundamental changes.

A) We create a generic Lisp read-eval-print loop for Maxima to use
instead of allowing access to the same loop in the underlying Lisp.
Doing so is pretty simple. I do not see any problems with this change so
far.

B) We avoid the underlying Lisp's debugger through a multi-tiered
approach.
	B.1) Set the ANSI Lisp *debugger-hook* to a function that automatically
returns to the Maxima input loop. I think this would be helpful for the
95% of users who have no idea what to do with the Lisp debugger, anyway.
	B.2) Create a minimal Maxima Lisp debugger loop as an user-selectable
alternate to the function in (B.1).
	B.3) Allow access to the underlying Lisp's debugger by modifying
*debugger-hook*. (This is really a no-op. I don't know how we would
avoid this possibility.) Accessing the Lisp debugger in this way would
break the external interface, but only advanced users would be likely to
use this option, anyway.

I have started on implementations of these proposals for ANSI Lisps. The
big problem here is that I do not know how to implement (B) in GCL. I
would really like to get some feedback on these ideas before I pursue
them any further.

Any input will be welcomed.

--Jim