Olaf Chitil <[EMAIL PROTECTED]> writes:
> Runtime errors could be more informative than just stating
> "Program error: <erroneous term>"
> e.g.
> No matching pattern
> in definition of function: f
> for argument: <arg>
>
> Actually warnings at compile time about incomplete patterns would be
> very helpful (however, I remember that Mark Jones mentions already in
> his Gofer implementation documentation that this doesn't fit into
> Gofer's design; the code generator doesn't produce messages).
I absolutely agree.
I'm currently working on a program of about 1000 non-comment lines
with a variety of nested patterns, explicit case expressions, local
function definitions, etc. and I have absolutely no idea what has gone
wrong when I get an error message of the form:
Program error: v1234 (v435 []) (Var (v23 v1765))
(especially if the arguments to v1234 are very long or contain a cycle).
A simple way to fix the problem would be to modify the frontend
so that it adds the following alternative to the end of every pattern
match.
_ -> error "Pattern match failure at line 42 of file \"Foo.hs\""
[Optimisations:
1) To avoid filling up the Text table with a large number of almost
identical strings, we instead generate:
_ -> hugs_pmf 42 "Foo.hs"
where hugs_pmf is defined in the obvious way.
2) Extend the pattern matching compiler (??) to detect redundant
patterns so that it can delete most of these error messages.
It might be good to give a warning message if it finds a
redundant pattern which isn't of the above form. The warning
message could extract a line number from the call to hugs_pmf.
It would also be easy to (optionally) give a warning message
whenever it is unable to delete the call to hugs_pmf - since
that indicates a possibly incomplete pattern match failure.
Again, the line number can be obtained from the call to hugs_pmf.
3) The call to hugs_pmf could include a tuple of the function
arguments. (It'd be hard to make this typecheck - but we can
probably insert the call to hugs_pmf sometime after typechecking
so it doesn't need to typecheck.)
]
(Other designs are possible - especially those that involve keeping
line number info into later stages of the compiler.)
So,
Good news: We know how to fix it.
Bad news: We're probably not going to do it right now.
Good news: We'll do it the next rainy Sunday afternoon.
Bad news: Here in New Haven, that will probably be sometime in September.
> The module structure should influence runtime error messages. Inside the
> error message "Program error: <erroneous term>" only unqualified names
> are used. This can be very confusing when the error occurs inside an
> imported module, the top level module does not import some names of the
> erroneous term, and possibly the names are even defined differently in
> the top level module.
I guess it ought to use the current "evaluation module" (as set by the
":m" command) to decide which names it can use unqualified and which
it must qualify. This would be tedious but is a good idea.
--
Alastair Reid Yale Haskell Project Hacker
[EMAIL PROTECTED] http://WWW.CS.Yale.EDU/homes/reid-alastair/
