Requesting input on some possible low-level changes

--- James Amundson <amundson@users.sourceforge.net> wrote:
> 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.

Yes, I think this is a very good first step.

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

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?

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

Slightly less so when the input and output characters are changed from
C and D.  Can that be handled?


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

Sounds good.

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

I definitely agree.

> 	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?  Would we
have to create our own debugging environment?

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

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

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.  In
any case this direction sounds like a good one, and I definitely
support not having users dumped to the debugger.

CY

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