On Wed, 22 Mar 2000, Fergus Henderson wrote:
> Actually, that raises an interesting question:
> should instances of `==' be required to be hyperstrict
> in cases where they return `True'?
Certainly no.
First, using (==) for that purpose is a hack. Does not work for e.g. a
list of functions or IO actions. Is unnecessarily inefficient for sets
with non-unique representation and equality defined through conversion to
sorted lists. Does not work as expected if equality uses only a part of
value, which makes a perfect sense when e.g. the rest of a value contains
something that can be derived and is stored for efficiency only.
Second, the definition of hyperstrictness must be quite arbitrary for some
nonstandard extensions. What to do with Dynamic? With ForeignObj
containing StablePtrs inside?
If it is worth, it could be defined as a class, and could be even
automaticelly derivable. I must have seen it somewhere. I doubt it is
so useful though.
> Suppose Sven implements his `len' function as above, and furthermore
> implements a library which depends on this function being hyperstrict.
It generally cannot depend on it. Strictness only improves efficiency and
narrows cases when a function is defined, but it can never improve
correctness. There is no code that requires strictness to work at all.
Unless we use extensions like GHC's Exception or unsafePerformIO.
Or use hGetContents and want to explicitly close a file to work
around limits of concurrently open files, or to write to that file,
or to use Posix.forkProcess.
IMHO the behavior of hClose wrt. hGetContents should be changed. Currently
the result depends on whether something has been evaluated (at least with
GHC)! About the only such place in Haskell 98.
--
Marcin 'Qrczak' Kowalczyk
