Requesting input on some possible low-level changes

James Amundson writes:
> 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.
> 

Of course some general well thought kernel-frontend communication
protocol (like Richard suggests) would be ideal solution and
we need it sooner or later.  But I still think that some improvement
to text-filter protocol used by all presently available Maxima
frontends (TeXmacs, emacs modes, xmaxima) would be of great help.
With comparatively little effort it'll make all this frontends more 
robust.


> 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 :
> --------------------------------------------------

Maybe it is good idea to distinguish also various kinds
of Maxima output.  I see at lest two kinds

(1) mathematical expressions - maybe subject of
some special formatting on frontend side.

(2) other text output which should go verbatim (maybe just
other color or typeface). This includes: error and warning
messages, maxima debugging trace messages, describe/? output,
in general - all kinds of pure text informational messages.

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

Richard mentions also input request by user program.
Maybe we should provide the user with Maxima level
function which will do the magic according to expected
rules.

All input requests must use single prompt-formatting
function which will automatically insert special marks
(maybe different for different frontends) telling frontend
that Maxima is waiting for input (see Andrey's post).
This approach works quite well in Reduce.

> 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.
> 

IMHO, ordinary user should newer ever see underlying Lisp debugger 
prompt in Maxima.  It's distractive and even scaring.


> 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.
> 

Could you elaborate a bit - what kind of troubles you experience with 
GCL?  Some ANSI functionality is lacking?  Or in general B) is heavily
Lisp implementation specific?

> Any input will be welcomed.
> 


-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>