Serge D. Mechveliani wrote:
> 
> compiling
> 
>   )abbrev package MY-LIST MyList
>   MyList(T: Type) : with
>       intersperse : (T, List T) -> List T     
>     ==
>       add
>         intersperse(x: T, xs: List T) : List T ==
>                                              empty xs => []
> 
> -- (`empty' set erroneousely instead of `empty?'),
> 
> 
> fricas-1.1.5   reports
> 
> **********************************************************
>    Compiling FriCAS source code from file 
>       /home/mechvel/ghc/axiomInterface/fromA-aim/MyList.spad using old 
>       system compiler.
>    MY-LIST abbreviates package MyList 
> ------------------------------------------------------------------------
>    initializing NRLIB MY-LIST for MyList 
>    compiling into NRLIB MY-LIST 
>    compiling exported intersperse : (T$,List T$) -> List T$
> ****** comp fails at level 5 with expression: ******
> error in function intersperse 
> 
> (SEQ (LET #:G13576 (|empty| |xs|))
>  (|exit| 1 (IF #:G13576 (|construct|) |noBranch|)))
> ****** level 5  ******
> $x:= xs
> $m:= value
> $f:=
> ((((|xs| # #) (|x| # #) (|xs| #) (|#| #) ...)))
>  
>    >> Apparent user error:
>    Cannot coerce xs 
>       of mode (List T$) 
>       to mode value 
> **********************************************************
> 
> 
> Why does not it produce a reasonable report, something like
> "type mismatch in applying `empty' ..."
> ?

The 'Cannot coerce' message means that there is type mismatch
and compiler found no trivial way to eliminate the mismatch
(trivaly ways are treating NonNegativeInteger as Integer, or
treating branch of a Union as whole Union and few similar).
Note that message tries to be helpful telling you which
type compiler has "in hand" and which one it needs.
Unfortunately, compiler normally must consider several
alternatives, but prints info just about one (IIRC the
last one).  Last alternative is one which compiler could
not reject quickly, so it is a bit better that choosing
random alternative, but frequntly this gives surreal looking
messages because the person who wrote the code did not think
about alternative that compiler complains about.

The part of compiler which detected mismatch and produced
the message does not know that 'xs' is an argument to 'empty'.
This is a weakness in current compiler.  I have few ideas
how to improve error messages from the compiler.  For
example compiler could say something like:

  There is only one function with name 'empty' taking one
  argument od type 'Integer' and 'xs' which is of type
  'List T' can not be coerced to 'Integer'.

However, ATM it is not clear to me which messages would
be most helpful -- due to overloading there may be
hundreds of possibilities and listing them all probably
is useless.  Also, the only 'empty' with one argument
is not visible here -- so it may be better to say that
there is no visible 'empty' and mention that there is
one not visible (in case user forgort 'import').

BTW: Changing 'Cannot coerce' to 'Type mismatch' would
be easy, but the second one is less precise so I do
not think it would be good idea.  'Type mismatch, cannot coerce'
would be more informative, but I am not sure if information
gain is enough to warrant longer message.

-- 
                              Waldek Hebisch
[email protected] 

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/fricas-devel?hl=en.

Reply via email to