"Simon Peyton-Jones"
In which case we could report ambiguity a bit less often. How useful this would be I don't know.
A lot. Any time one is testing the empty case of a bulk type. If you're coding data structures work (and most first and second year CS classes will) that happens all the time. It comes up in situations as simple as making sure your functions return [] when you expect them to. So a clever solution to this problem would make hugs, ghci, etc. far more usable. It would also allow the monomorphism restriction to be relaxed at absolutely no cost in certain cases. Earlier, Simon says:
Indeed, if none of the classes have a method that returns an a-value without also consuming one (urk-- strictly, I think, sigh) then the same holds.
Strictness alas matters. Here's the witness: class Num a => ZeroList a where consZero :: a -> [a] consZero _ = 0:xs instance ZeroList Int instance ZeroList Double Now: (consZero (error "no type")) :: (ConsNum a) => [a] show (consZero (error "no type")) :: (ConsNum a) => String Do we get "[0]" or "[0.0]"? OK, we have a problem worth addressing, and a non-obvious (or absent) solution. I'd love to hear what our resident type theorists have to say. -Jan-Willem Maessen Eager Haskell Project
On Wed, Oct 03, 2001 at 11:52:30AM -0400, Jan-Willem Maessen wrote:
Earlier, Simon says:
Indeed, if none of the classes have a method that returns an a-value without also consuming one (urk-- strictly, I think, sigh) then the same holds.
Strictness alas matters. Here's the witness:
class Num a => ZeroList a where consZero :: a -> [a] consZero _ = 0:xs
Err, "Num a" is already a bad context by Simon's criterion because of "fromInteger", which is what ultimately causes the problem in this case. I don't see how strictness can be relevant, since it is a property of a class instance, not a class. Best, Dylan
participants (2)
-
Dylan Thurston -
Jan-Willem Maessen