Sat, 20 May 2000 13:13:53 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:
> f x = assert (p x) (...x...)
>
> where assert :: Bool -> a -> a
>
> If the boolean is False, you get an error message pinpointing the
> line in the file. Now, a function with an assert that always fails
> is indeed a good candidate for a compile-time error message.
This is a more specific instance of my criterion: applying a function
that does not always give bottom to a value for which it does give
bottom. (But the language semantics require at most a warning, at
least in my general case, not an error.)
There is a problem that creation of such applications by inlining is
not always a programmer error:
l:: [String]
l = ["foo", "bar", "baz", "", "last"]
g:: [String]
g = map tail l -- May be quite reasonable.
A criterion should catch cases where the programmer obviously should
have written this in another way if he really means this. Not simply
where bottom arises during inlining.
Maybe the right way is to perform the analysis only before any inlining.
Would it catch cases like
f x = case head x of ...
g = reverse . f . reverse
h x = ... g [] ...
? Theoretically yes: the analysis would mark f as bottom on [],
g too (because if the result of reverse is [] then its argument
must have been []) and the programmer should not have written g []
explicitly. Looks very hard in practice, and I don't remember if
I've ever made such error.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
