Leo Butler <l_butler at users.sourceforge.net> writes:
> I would like to reach some sort of agreement on the remainder of these
> works. Based on my reading of
> http://www.math.utexas.edu/pipermail/maxima/2013/034687.html
> we are close.
Yep, I agree. In fact, I think it probably makes more sense to revert
my commits on the "prompt-work" branch and start with yours. This
weekend has been busier than I expected, and I'm off to a rehearsal and
concert this afternoon / evening, so I'm not going to get around to this
until Tuesday, I fear. If you fancy doing it, feel free!
> Let me start by explaining in more detail the patch I sent:
>
> -$set_alt_display provides a simple, functional way to set/reset the
> *alt-display1/2d* hooks from the Maxima repl.
>
> -define_alt_display is a macro that provides some translation from
> Maxima variable names to Lisp ones, to make writing a hook in Maxima
> easier. It also encases the Maxima code in some error handling shell.
>
> -$set_prompt provides a simple, functional way to control the input
> prompt decorations from the Maxima repl without exposing the *prompt-*
> variables directly.
>
> The 1st+2nd functions provide a means to manage and write alt-display
> hooks as Maxima code [1]. **These answer a real need**: we have had a few
> requests in the last year where users wanted to massage Maxima's
> output, each of which were solved via alt-display hooks.
Yes, I agree. This is a good move.
> In addition, as I showed in the commit notes, one can dynamically
> update the prompt pre/suffix with an alt-display hook, so the code
> provides a means to achieve the effects of prompt-notes, too. Indeed,
> prompt-notes can be effected in Maxima on top of these two functions.
Ah, I see. I think I misunderstood what you'd written.
> One last point about my patch: alt-display is meant to be a contrib
> package (see the patch I sent). Contrib packages are experimental
> and/or less stable than src code.
I'm not convinced by that reasoning, to be honest. Consider
share/contrib/diag.mac, for example. I spent some time fixing silly bugs
in it a while ago (and making it faster and easier to read as well). The
API is godawful, but I don't think that we can plausibly change it
without breaking people's scripts that use it.
To be honest, I reckon that once one releases code, it's only ok for it
to have an unstable API if no-one uses it...
> Finally, concerning safety and a hook in format-prompt.
>
> I am not really convinced a separate hook in format-prompt is needed,
> given set_alt_display/define_alt_display, but...
>
> Maxima generally provides little by way of safety. If you want to bork
> your session, try
>
> f([x]):=f(x,x);
> f(1);
>
> gcl segfaults on a second call after recovering from the first; sbcl
> borks on one call. I imagine we could "fix" that by policing arglist
> length, but Maxima does not.
I agree. I've thought about this a little bit and think I've understood
my personal taste in the matter: Maxima should try to be as safe as
possible, without massively sacrificing performance. Policing arglist
length would cause a significant slowdown in Maxima code, so it's
definitely not OK.
However, the cost of a sanity check that runs once per input/output
display is computationally irrelevant, so I think we should pay it for
the added safety.
> In my experience working on the format-prompt hook, it was useful to
> run swank+slime+Maxima. That let me do things that a try-catch wrapper
> can't. (Ever wonder why Lisp has no try-catch macro?
> http://gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html)
Yep, I did that from the third time onwards... :-) And, yes, I do know
how the CL condition system works.
> If you *absolutely* must have safety beyond that provided by those
> tools, then how about, in format-prompt,
>
>
> (cond ($format_prompt
> (handler-bind ((error (lambda(msg) (setq $format_prompt nil) (merror ....)))))
> (mfuncall $format_prompt ....))
> (t
> ....)))
Yep, let's do something like that. I'll prepare a patch early this week
or, if you have a chance before, we could work from that.
> You are right, if we expose this hook, then it makes sense to expose
> the standard input prompt as a Maxima function returning a string. The
> default clause can then invoke it.
>
> (I use a Maxima variable name because it is intended that format_prompt
> be accessible from the Maxima repl.)
Great! And, yes, I agree with the Maxima variable names.
We probably also need to write some documentation. (Even if the info
system is slightly borked at the moment - another thing I intended to
look at this weekend :-/)
Rupert
PS: About the footnote:
> [1] - you claim otherwise in
> http://www.math.utexas.edu/pipermail/maxima/2013/034687.html, but look
> at the examples I showed and you'll see this is mistaken.
I think you probably mean this paragraph:
>> As I've just written above, I intended to provide hooks that were
>> available in the Maxima language and, as such, believe that the
>> alt-display code isn't an appropriate solution.
My point was that you couldn't access the alt-display stuff from the
Maxima language. With the patch we're discussing, you can. Great!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20131215/745a0b1e/attachment.pgp>;