Requesting input on some possible low-level changes

On Wed, 2003-09-03 at 14:53, Vadim V. Zhytnikov wrote:

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

I think it would be useful to distinguish between various kinds of
output. I would like to put off adding that sort of functionality until
after we have the basics working, however.

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

Yes. Good point.


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

Yes. I really think the Lisp debugger is only useful for a few of us.
 
> > 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?

So far, I have only relied on functionality defined in the ANSI spec,
specifically *debugger-hook* and with-simple-restart. The only testing I
have done with GCL is with GCL CVS as of yesterday. If I use the
traditional (non-ANSI) build, neither *debugger-hook* nor
with-simple-restart are defined. If I try the ANSI build, (1) my toy
program crashes and (2) Maxima fails to compile. I have spent very
little effort investigating these problems -- I wanted to wait until I
get enough feedback to decide that I'm on the right track with the
current approach.

--Jim