Re: Handling branch cuts for hypergeometric function s

> This, I think is a very bad idea because now you've changed the
> behavior for every routine in maxima.  

That, actually, was the intent in this case. (I.e., it's not an unwanted or
unexpected side effect: I *wanted* to change the "interactive query"
behavior globally.)

The difference between this "forced" approach and a properly implemented
hook function is that a hook function could be "unhooked" when it's no
longer needed. Also, presumably a hook function would have the option of
doing nothing and allowing the original implementation to do its work,
whereas in my example, the original implementation of ask-integer was
effectively destroyed for the remainder of this Maxima session.

> Using catch/throw or conditions allows the dynamic behaviour
> that we would want

I don't think it would, because once an exception is thrown, the catch
routine cannot cause the calculation to resume.

In other words, it'd be possible to write a catch routine that does what my
example did and print an error, but it'd NOT be possible to write a catch
routine that, say, consults a database, determines if the sign of the
expression can be evaluated, calls ASSUME(), and then returns to the point
where the exception was thrown, to allow the calculation to resume. In fact,
I don't even know how you'd implement the current behavior this way, because
once you throw an exception, you'd never have a chance to ask an interactive
query; in the absence of a catch routine, the result would be an error.

> We need to decide on some policy.

What I am suggesting is a formalized hook function that would be called
before an ask... function resorts to an interactive query. Something like
this (please don't take it too literally, this is just pseudocode):

	function ask_pred(expression)
		if (pred can be evaluated) return result;
	+	if (hook_pred is defined)
	+		hook_pred(expression);
	+		if (pred can now be evaluated) return result;
	+	endif
		query the user;
		return result;
	end function

It is the lines I marked with plus signs that are "new" in the sense that
they'd have to be added to the existing definitions of the predicate query
functions if we choose to go in this direction.


Viktor