
On Tue, Jul 31, 2007 at 04:04:17PM -0700, Stefan O'Rear wrote:
On Tue, Jul 31, 2007 at 03:31:54PM -0700, David Roundy wrote:
On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
ChrisK
writes: And the readability is destroyed because you cannot do any type inference in your head.
If you see
{ Matrix m = ....; Matrix x = m * y; ...; }
Then you know very little about the possible types of y since can only conclude that:
[snippage] This is all very horrid, but as far as I can tell what I was proposing wouldn't lead to such a mess, except possibly via defaulting, which, as the least important aspect of the idea could easily be abandoned.
What your suggestion would do would be to make the type inferred for every pattern-matched function polymorphic, which means that in order to determine the correctness of a function you'd need to examine all other modules. Similarly, if you fail to include a type signature in some simple pattern-matched function in a where clause, adding an import of another module could make that function fail to compile (with an undeterminable type error).
Excuse me? One of the most critical properties of type classes is that adding new instances can never make old code that uses old instances stop compiling; the worst you could get is a definition conflict.
I see that I was wrong. I was thinking of something like foo :: C a => Int -> a bar :: C a => a -> Int baz :: Int -> Int baz = bar . foo and that this would compile if there was only one instance of class C. But I see that in fact it will fail to compile regardless, which makes sense. -- David Roundy Department of Physics Oregon State University