Requesting input on some possible low-level changes

I suggest that you disable the escape-to-lisp entirely if you want
a more robust interface.  That is, remove to_lisp(). Replace it
with  ??xyzzy_secret_escape_to_lisp().

Later you can consider your approach, but I suspect you will not
be able to do it in all lisps.

There is also a command that allows the user to request input, as well
as commands that allow the user to write some spoof of the synchronization
sequence. These will have to be considered.

There is a model for such communication; actually several.
(1) The interface between the commercial Macsyma front-end and
its kernel. Advantage: it was designed by someone who had the
time and the smarts to do this well. Disadvantage: it was designed
to run in a particular lisp (CLOE). Also possible disadvantage
is the interface spec may not be public.  (Though I think it might
be..)
(2) The Mathematica front-end/kernel communication.  I don't know
if this is the same as the stuff they push for inter-program
communication, but maybe it is.
(3) The Maple version of the same. I think this was called Irena
at one time.
(4) MathML's attempt to do the same. I disrecommend this approach
since it is probably not thought through for this purpose and is
extremely verbose.

There are, at a minimum, needs for the front-end to interrupt
the kernel, synchronizing notebook modes for input, editing
of output,  and also perhaps other things (e.g. now the mouse
is pointing to a section of the notebook with a plot in it, now
it is in a text portion).

Looking at the existing notebook interfaces (which Joris may
know a lot about??) should provide some requirements.

RJF


James Amundson wrote:

>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
>
>_______________________________________________
>Maxima mailing list
>Maxima@www.math.utexas.edu
>http://www.math.utexas.edu/mailman/listinfo/maxima
>  
>