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

Leo Butler <l_butler at users.sourceforge.net> writes:
>>   > (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...).
>
> Nope, I don't agree. The alt-display hooks don't try to protect the
> user from himself, and I don't see why other display hooks should
> either. It seems reasonable that the hook itself can do all the work
> you want to assign to the caller.

The problem I was trying to solve is that without some sort of
protection like this, it's possible for the user to make Maxima
completely unusable. I can understand if you believe that user code
should never be run when drawing a prompt, but I don't agree that it's
sensible to run user code per prompt without some sort of protection.

With the *prompt-suffix* and *prompt-prefix* logic, no user-provided
code needs to be run in order to draw a prompt. I am very strongly
against hooking in a call to funcall-or-eval like you suggest, since
this makes it quite easy for a user to unrecoverably hose their entire
Maxima session. Well, unless we wrap it in an unwind protect.

Notice that, unlike the alt-display hooks (which I understand are to
help other programs to interface with Maxima more easily), the whole
point of this was to allow a Maxima user to configure things. And, of
course, I wanted to expose this to code in the Maxima language, not just
lisp.

Maybe a middle ground would be to ditch the logic that allows multiple
elements in the hook, so the code becomes something like (sketch!)

  (let ((success nil))
    (unwind-protect
        (prog1 (if *custom-input-prompt*
                   (funcall-or-eval *custom-input-prompt*)
                   (standard-input-prompt))
          (setf success t))
      (unless success (setf *custom-input-prompt* nil))))

This no longer has the complexity of multiple possible elements hooking
in. My experience with hooks in Emacs is that this sort of thing is
useful, but I don't have incredibly strong feelings about that. The
names in the snippet above suggest that the code replaces the standard
input prompt. In that case, I guess we'd also want to expose the
standard prompt as a function (returning a string maybe) to avoid people
rewriting it. Alternatively, the hook could specify a string to write
after the standard prompt, which might make more sense.

Have I understood your stand-point correctly? Or am I talking at
cross-purposes to you?

>>   Is there really a simpler option?
>
> Yes, funcall-or-eval. It is simpler, at least as capable, and is similar in
> spirit to the alt-display hooks.

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.

>>   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.
>
> No, you've over-engineered the system. If you want to add a hook that
> unwind-protects you and maintains a push-pop list of prefixes and
> suffixes and so on, please do so. But I don't see the need for that in
> src.

If you still feel that way, let me know and I'll write a variant that
can only be accessed through lisp and works in the way you
describe. Then I'll stick a package in share/contrib that adds the
interface from my current patch (or something equivalent) in a way that
code written in the Maxima language can access. This would replace my
code that's currently sitting in share/contrib, which I agree probably
doesn't belong there.


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/20131206/2ab7ed7f/attachment.pgp>;