Wed, 29 Sep 1999 11:43:06 +0200, George Russell <[EMAIL PROTECTED]> pisze:
> When that happens in my code it counts as a bug! Therefore error
> is appropriate. If you are in some larger Haskell universe calling
> component Haskell code it is unfortunate if a single error calls the
> entire universe to collapse, so you do need some way of recovering,
I agree to both of the above.
I only don't like the details about IOError. It's not extensible
and Dynamic is still not nice. I have no idea how to make it
better. Probably some general way of making extensible datatypes.
> but perhaps a function as mentioned of type
> a -> IO (Maybe a)
> which traps the error might suffice for this case.
How would it work with lazy evaluation? I guess it would simply be
strict in its argument, but what if `a' is a list and an error occurs
during computation of some further element? Probably it would just
fail with _|_.
BTW, can there make sense a universal variant of seq which
recursively seqs components of datatypes? `x == x' would sometimes
work in practice. But maybe it does not make sense theoretically:
does `const [0..]' _contain_ the list so it would be seqed? Maybe the
only sensible generic seq just evaluates the top constructor. But that
way (Bool,Bool) is not "isomorphic" to a four-valued enumeration wrt
seq effect. There are strictness annotations in datatypes, I think
they create isomorphic types, but they create _new_ types: a list
should not be strict all the times but it could make sense to catch
the errors inside the elements when needed. Hmm, a class SuperSeq,
probably automatically derivable? I'm confused. And I'm not sure if
it would be useful at all.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://kki.net.pl/qrczak/
\__/ GCS/M d- s+:-- a22 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-
