Re: [Reduce-algebra-developers] error reporting

[Rainer S. <rai...@gm...>]

On Mon, 22 Dec 2014 at 18:14 -0000, Jarmo Hietarinta wrote:

 > > I observe that I can generate a diagnostic as follows
 > > 
 > > 1: deg (sin x/cos y, x);
 > >
 > >       sin(x)
 > > ***** -------- invalid as polynomial
 > >        cos(y)
 > >
 > > so you can track through and see the (symbolic mode) code for the function
 > > typerr that arranges to be able to embed an algebraic expression within a
 > > message that gets sent back to the user.
 > 
 > When I deal with very large expressions I do not want error report to be of type
 > 
 > **** ((hundreds of lines of expression )) is not a polynomial,
 > 
 > I would rather prefer a more laconic form, such as
 > 
 > **** expression given to factorize is not a polynomial
 > 
 > Can one control the output of error reporting by a switch?

It wouldn't be too difficult to implement something like this for the case in 
question, since the error message is handled by the procedure typerr in 
alg/intro.red. E.g., with the switch toggled it would print

 ***** expression invalid as polynomial

and store the faulty expression in a global variable.

However, that wouldn't help for all other cases. For example, a lot of error 
messages come from calling rederr. It prints its argument, ie there is no way to 
know which part is the error message proper, and which part may be a big 
expression to be suppressed.

So, if someone were to come up with a better concept for error reporting 
functions, we could start by implementing it, and eventually convert all error 
reporting to call the new functions.

To give an existing example: at one point rerror was introduced it takes three 
arguments: a module name, an error code, and a error message to be passed to 
rederr. I believe the idea behind it was to interface with interactive help to 
show the documentation for this error.  To be effective, every call to rederr 
should be converted to call rerror instead - but then one has to manage the 
error codes and link them to the documentation. This is tedious work - partly 
because the error codes right now are integers. It would be better to have 
symbolic names for the errors. These names could be referenced in the manual and 
automatically converted to links to the help.

 Rainer