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

David Roundy droundy at darcs.net
Sat Jun 23 18:16:42 EDT 2007

On Fri, Jun 22, 2007 at 05:39:10PM -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...?"

Depends on the definition of strong typing, I suppose.  I'd say that using
the conventional definition is reasonable, rather than using the definition
which defines strong typing to mean some language that hasn't ever been
written.  Enabling warnings gains you some protection, but you need a new
language (lacking head, tail, error, etc) if you want to statically avoid
all runtime errors.

It's silly to claim or believe that "strong typing" means that code which
type-checks cannot fail.  Maybe such a language exists, but I haven't heard
of it.

> 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.

When talking about Haskell on Haskell mailing lists, it makes communication
easier if you use Haskell terminology.  e.g. when you use the word type, if
you mean the thing that is called a type in the Haskell language.

> If someone writes working code with incomplete patterns, they're  
> effectively using a dependent type without being able to say so in  
> Haskell. [...]

So what you're talking about is that Haskell doesn't have a type that is
capable of describing a total function? That any function can return
bottom? That would definitely be nice to have.  As I understand it, in
Haskell non-termination is considered bottom (the result of error or failed
pattern matches), and I don't see how we could avoid all non-terminating
code in the type system (I believe that's known to be undecideable?), so
what you want is to get rid of the existence of error? ...which I believe
is what pattern match failure desugar to.

That's be nice in many ways, but I suspect it would reduce once again the
number of correct programs that could be written.
David Roundy

More information about the Haskell-Cafe mailing list