Requesting input on some possible low-level changes

--- Richard Fateman <fateman@cs.berkeley.edu> wrote:
> 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().

I don't think that command is too much of a problem - people using it
in theory would want to go to the lisp level.  The problem from a user
standpoint is when they are dumped unwillingly there.  Of course, maybe
that feature isn't important enough compared to the interface concerns,
but I don't think we really want to remove the ability to drop to lisp,
do we?

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

Do some of them not allow the debugger to be disabled or rerouted?

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

I haven't seen any such documentation - if it is public I haven't found
it.

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

How useful would this be, given the differences in the system?  Or do
you mean the mechanism it uses, rather than the protocal?

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

I think the major point will be interrupting the kernel - I'm not at
all sure how to do that short of killing and restarting the kernel
process.  Unless the kernel itself stops whatever it is doing to check
for a termination signal every so often, wouldn't it be blind to
external communication as long as it is processing a command? 
Otherwise, it seems to be a design problem to decide what the kernel
needs to know about the GUI and vice versa, and how each tells the
other what's going on.

CY

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


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com