
Discussion continues below quoted text... Stefan O'Rear wrote:
On Tue, Jul 31, 2007 at 03:31:54PM -0700, David Roundy 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
On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote: 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.
Stefan
That is true, and it is one of of the perfect things about type classes. But that is not the problem with some of the proposals to make normal syntax patterns always look for a View inference. The problem is that to read any pattern match I have to know which View instance was chosen. So each and every pattern match requires me to run a type checker in my head which draws on all the View instances which were implicitly imported into the current module. That adding another invisible instance does not break the code is irrelevant, the problem is that huge amount of effort it takes the human reader to prove to herself or himself that any particular pattern match has been correctly understood. It should require a new syntax to invoke this complexity. -- Chris