[Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_31-base-183-gf44d669



Leo Butler <l_butler at users.sourceforge.net> writes:
> Yes, I re-read the git diffs and re-built Maxima with the commits and
> I don't see a problem with the first commit.
>
> My original message is partly down to haste and confusion on my part,
> and partly down to a genuine interest in keeping this part of Maxima
> stable and backwards-compatible.

Great! I should say that I was being quite careful to keep things
backwards compatible. Indeed, that's what motivated the design - more
notes below.

Sorry that the git commit logs were less clear than they could have
been: I'm aware that when I'm not concentrating, I sometimes have a
habit of writing things that make perfect sense, but only if you were
the person that wrote them...

> If I understand your first commit, you have centralized all references
> to *prompt-suffix* and *prompt-prefix* into format-prompt.

Yep (or at least, that was the plan!)

> If this is the case, then you could do a replacement like
>
> *prompt-prefix* --> (funcall-or-eval *prompt-prefix*)
>
> where
>
> (defun funcall-or-eval (x)
>        (cond ((stringp x) x)
>              ((functionp x) (funcall x))
> 	     ;; other cases
> 	     (t (error ...))))
>
> and similarly for the suffix. I am not sure about the wisdom of such a
> change, but it would a relatively unobtrusive way to add more hooks...

I'm a little confused. Firstly, note that funcall-or-eval is going to
need some unwind protection machinery to avoid nasty infinite loops
(otherwise if something goes belly-up, Maxima throws and displays a new
prompt and the error happens again...).

>>   Also, I'm not convinced about the "complexity of the display machinery"
>>   argument. Perhaps Leo refers to the complicated-looking UNWIND-PROTECT
>>   form in my PROMPT-NOTES function? But the point is that, if you want the
>>   user to be able to supply something that does a computation before a
>>   prompt, you need to make sure that it doesn't end up in an infinite
>>   loop... I'm pretty certain that logic would need to appear somewhere
>>   whatever the proposed mechanism.
>
> No, the whole prompt-notes business seems unnecessarily complicated
> and unneeded in src code when it can be accomplished with the existing
> *alt-display.d* hooks or something like that above.

My second point of confusion is, given the funcall-or-eval mechanism you
suggest, how can a user add something to the prompt display and be
reasonably sure he/she won't completely break an existing
*prompt-suffix* (or *prompt-prefix*). The obvious solution is to stick a
list of stuff to display in front of the string of an existing
suffix... which is what last night's patch does! Is there really a
simpler option?

Note that, once you've written something that prepends lists and
something else that adds unwind protection, you've just rewritten last
night's patch.

>>   >>   The third (f44d66) (revised to make use of existing
>>   >>   machinery) seems like it would be suitable for a collection of
>>   >>   solved problems or how-to cookbook -- not sure if it should be in
>>   >>   share.
>>
>>   Fair enough: I don't have any strong feelings about this. Can you
>>   suggest a good place for it to go?
>
> http://sourceforge.net/apps/phpbb/maxima/viewforum.php?f=3
> github

Wow, I didn't know this existed! Cool! I'm not convinced that PHP-BB is
really the ideal way to share snippets of code, but I guess that's
firmly off-topic for this mail thread.


Rupert
-------------- 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/20131205/87e195d2/attachment.pgp>;