FriCAS - Wish List - Errors

I have put my complete 'wish list' on the page here. This page contains the replies to my issue about error codes.

Better Error Messages When Working on SPAD Code

I would like better error messages when using both interpreter and compiler. Also hide underlying Lisp nature of the program from users using interpreter and writing SPAD.

The error messages in the interpreter don't seem very helpful, for instance if I just type something in at random:

(1) -> a|b
   >> Error detected within library code:
   (1 . failed) cannot be coerced to mode (NonNegativeInteger)

Some error messages are even worse and expect user to understand the underlying Lisp nature of the program.

Error messages when writing code for SPAD are often different from the interpreter errors. These compiler errors can be even more difficult to find. Some errors, with the top level syntax, don't give any clue where the error might be in the whole code. Other errors display a whole chunk of lisp code.

It would be useful to have documentation with a list of all the possible errors and what might be done about them. I started to keep a list of the errors that I was getting, but soon gave up, see page here.

Reply From Waldek

What you wrote means: "a such that b is 0".  For the interpreter
this is syntactially OK and types look plausible ('a' is a symbol
and 'b' is a polyniomial) so it passes the data to the library.
More precisely, it tries to initialze 

SimpleAlgebraicExtension(Fraction(Polynomial(Integer)), _         
UnivariatePolynomial('a, Fraction(Polynomial(Integer))), b)

SimpleAlgebraicExtension assumes that polynomial has positive
degree and tries to subtract 1.  But in your case degree is 0
so subraction fails and produce the message above.

So, the error is detected only when running library code.  In
principle library should contain tests for possible errors and
print nicer error messages.  OTOH in this case wrong user
input is caught wher trying to interpret result as
NonNegativeInteger.  We could make the generic message a bit
nicer someting like:

   Wrong union branch detected: "failed" of type "failed" is
   not of type NonNegativeInteger

or maybe

   "failed" of mode Union(NonNegativeInteger, "failed") cannot
   be coerced to mode NonNegativeInteger

which is closer to original message.  Another thing is adding
more checks to the library.  But that is larger job...

Reply From Ralf

Waldek, if generating this last message would be easy, I would rather
want to have that instead of just "Error detected in library code".

If I am not completely wrong than such message very often just means
wrong user input.

Reply From Waldek

The message is 'Error detected within library code'.  I am not
an expert on English but my impression is that 'within' here means
the same as 'while executing'.  So, there are at least two

- there is an error in the library
- library found an error

AFAICS using 'in' as you did would mean the first possibility,
but actually the second is intended.  Namely, normally this message
is issued when library code find some unexpected data.  Core
reason may be due to user error or due to some bug in
library -- at the place where error is detected we can
not decide whom to blame.  So I think that message is
actually carefully chosen to be short and convey intended

Concerning change: I would keep the 'Error detected within library
code' part.  I am just thinking about changing what is written
below it.  Currently the code producing this message is rather
simple-minded: it just calls Lisp functions to get some printable
strings.  After little hacking I get:

   >> Error detected within library code:
   "failed" of mode Union(NonNegativeInteger,"failed") cannot be coerced to mode NonNegativeInteger

However, this depends on coercion to Output form and prefix2String.
I am not sure how robust they are (it woulb be embarasing to get
error during printing error message).  Also, values may be quite
big so it would be good to truncate output in such case.

Reply From Waldek

'System error:' comes from underlying Lisp and normaly means a bug,
either in FriCAS or the code FriCAS user wrote.  User can cause
it by improper use of 'pretend' or by calling internal low
level routines which to gain speed use reduced error checking.
Unless you were plying low level tricks this should be reported.

Reply From Ralf

Actually, it would certainly be easy to add something like:

  "Please report that problem to"

I don't know how much more traffic that would bring, but guiding the
user to a place where s/he can get help would probably be a good thing.

Reply From Waldek

Well, it is easy.  But there is one important case when the message
is not a bug.  Namely, we get it in case of division by 0.  This is
detected by hardware or lower level Lisp routines and reported via
Lisp error handler.  Trying to check before division would mean
extra code and loss of time.  IMHO ability to generate our
own error message does not justify the cost.  We could try to
check if error is division by zero, but this requires extra
work.  Not much, but more than just adding message in proper

metadata block
see also:
Correspondence about this page

This site may have errors. Don't use for critical systems.

Copyright (c) 1998-2023 Martin John Baker - All rights reserved - privacy policy.