[Haskell-cafe] Best idiom for avoiding Defaulting warnings with ghc -Wall -Werror ??

Derek Elkins derek.a.elkins at gmail.com
Fri Jun 22 21:43:14 EDT 2007

On Fri, 2007-06-22 at 17:39 -0700, Dave Bayer wrote:
> On Jun 22, 2007, at 4:37 PM, David Roundy wrote:
> > You get strongly-typed code whether or not you enable warnings.
> In my opinion it's delusional to think one is using strong typing if  
> one doesn't enable warnings. All the puffing about the advantages of  
> strong typing look pretty silly if code hangs up on an incomplete  
> pattern. Let's remember that the other side of this debate is rather  
> eloquent, be it Paul Graham or a Ruby enthusiast. People who don't  
> worry so much about types believe that they get things done. Is using  
> a strongly typed language like buying a hybrid car, it costs too much  
> but you're helping with "maybe someday...?"

Okay... people who don't worry so much about incomplete patterns believe
that they get things done.

There are trade offs in type systems about how much effort you want to
require of the user and how much the type system will catch.  Haskell's
type system is at a point that does a lot with very little.  You can do
ridiculously more if you don't mind requiring more from the user.

> I refuse to drink the Kool-Aid and recite precisely what I'm told a  
> type is in June, 2007; I'm hoping that types will evolve by the time  
> I die. For types to evolves, we need to step back a few feet and  
> think more loosely what a type really is.
> If someone writes working code with incomplete patterns, they're  
> effectively using a dependent type without being able to say so in  
> Haskell. They're using a specialization of the type they claim to be  
> using, in which the missing patterns are never needed. Filling in with
> 	_  -> error "I'm sweeping this under the rug so it's no longer the  
> type system's problem"
> just highlights the inadequacy of the type system. 

It's not an inadequacy, it's a trade off, but if you want, Epigram is
right over there.

More information about the Haskell-Cafe mailing list