Martin Baker wrote:
>
> Since compiler error messages have been mentioned I was wondering what
> is your approach to improving error messages?
> I seem to remember Waldek saying that the only way to improve the poor
> error messages is to fix them on a case-by-case basis?
> If so, do you want unhelpful error messages reported here?
>
> For instance messages like this are not very helpful:
>
> >> System error:
> The index 2 is too large.
>
> I have seen this caused when attempting to extend some category or
> domain in an incompatible way.
> For instance, several times I have unintentionally used the name of an
> existing library category when I was intending to create a new name.
> This sort of error is easy to make so helpful error message would
> improve things.
>
> I have reconstructed this type of error in the 3 examples below.
>
> Just to be clear, I know these are errors, its just the unhelpfulness of
> the message that I'm talking about.
>
> Martin
>
> ----------------------------------------------------------------
> Example 1: gives: The index 2 is too large.
> ----------------------------------------------------------------
> )abbrev category ERR1 Error1
> Error1: Category == Integer with
> myFn:(NNI) -> Boolean
> ----------------------------------------------------------------
> Example 2: gives: The value #(<snip>)is not of type LIST.
> ----------------------------------------------------------------
> )abbrev category ERR2 Error2
> Error2: Category == Integer with
> myFn:(Boolean) -> Boolean
> ----------------------------------------------------------------
> Example 3: gives: >> System error: The index 2 is too large.
> ----------------------------------------------------------------
> )abbrev domain ERR3 Error3
> Error3() : Exports == Impl where
> Exports ==> Integer with
> myFn : (Boolean) -> Boolean
> Impl ==> add
> myFn(inp:Boolean)==inp
With last commit compiler now catches the error. For the first
two the message is:
Semantic Errors:
[1] cannot form Join of: ((Integer) (CATEGORY package (SIGNATURE myFn
((Boolean) NNI))))
****** comp fails at level 2 with expression: ******
(|Join| | << | (|Integer|) | >> |
(CATEGORY |package| (SIGNATURE |myFn| ((|Boolean|) NNI))))
****** level 2 ******
$x:= (Integer)
$m:= (Category)
$f:=
(((($ #) (|Error1| #) (|$DomainsInScope| # #))))
>> Apparent user error:
cannot compile (Integer)
Still not nice, but to the point: compiler now complains that
it can not compile 'Integer' to give it type 'Category', which
is exactly the error.
For the third we get:
cannot produce category object:
(|Join| (|Integer|)
(CATEGORY |package| (SIGNATURE |myFn| ((|Boolean|) (|Boolean|)))))
>> Apparent user error:
cannot produce category object
which is less direct, but still says that there something wrong
with categories.
Note: Both example print 'Join', while there is no explicit
'Join' in the program. However,
..... Integer with
myFn:(Boolean) -> Boolean
is transformed to 'Join' before typechecking, and that is what
compiler sees. Changing that is harder than the change I made.
BTW. Please come with specific problems. General statements
like 'error messages are bad' are hard to fix. In many cases
specific problems can be fixed quickly.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
