[Haskell-cafe] Re: [Haskell] View patterns in GHC: Request?for?feedback

[ChrisK]

Discussion continues below quoted text...

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 <haskell at list.mightyreason.com> 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.
> 
> 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