Comments on: Why Not Haskell?

By: dp

dp — Sat, 19 Jun 2010 04:18:09 +0000

here’s something that bothers me about haskell: data constructors appear to be functions but aren’t, in any traditional sense. example:

data NaturalNumber = NaturalNumber Integer

there isn’t anything restricting NaturalNumber to be greater or equal to zero. data constructors are functions you don’t define, which makes sense because if you did define them i’m not really sure where it all would end… but it’s still annoying that you can’t make any kind of assertions on the data that is given to your data constructors.

another thing, why isn’t there function type polymorphism. that is, i can’t define an operator -> because it’s taken, even if the type would be completely different. same goes for map. if you could do those things, making new operators wouldn’t be such a pain because you’d have better options.

By: antage

antage — Tue, 12 Jan 2010 05:29:44 +0000

@Curt, -XDisambiguateRecordFields does not solve Muri’s problem.

rectest.hs:

module Main where

data Rec1 = Rec1 { a :: Int, b :: Int }
data Rec2 = Rec2 { a :: Int, c :: Int }

$ ghc -c -XDisambiguateRecordFields rectest.hs

rectest.hs:4:19:
Multiple declarations of `Main.a’
Declared at: rectest.hs:3:19
rectest.hs:4:19

By: Curt Sampson

Curt Sampson — Wed, 09 Sep 2009 14:24:05 +0000

No, because GHC is the most common implementation testbed for most of the features going in to Haskell’ (pronounced “HASK-ell-PRIME”), the next version of the standard. For most of us using GHC extensions, we simply stop declaring that we’re using them when we start using Haskell’.

cjs@cynic.net

By: Dan

Dan — Wed, 12 Aug 2009 14:41:39 +0000

@Curt – One thing I do worry about though, is the amount of functionality that’s not actually “language standard” vs. “nice GHC extension.” In other words – the language standard seems to be “whatever the latest GHC supports.”

Does this make anybody else nervous?

By: Curt Sampson

Curt Sampson — Sat, 02 May 2009 06:35:30 +0000

Doh! As it turns out, Muri’s complaint was addressed at least two years ago, anyway, with a language extension that’s available in GHC now and will doubtless be part of the next Haskell standard: record field disambiguation:

http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#disambiguate-fields

cjs@cynic.net

By: Ebrahim

Ebrahim — Tue, 07 Apr 2009 22:33:03 +0000

Thanks
I’m now totally convinced that I must learn Haskell.

By: missy-film

missy-film — Tue, 24 Mar 2009 22:16:03 +0000

Nicely sorted, helped me understand haskell

By: QCon London 2009 - A huge breath of air before a long apnea in the IT real world « The Nameless One

Sun, 22 Mar 2009 21:22:24 +0000

[...] World Haskell book in my bag (Yeah I know, Erlang is cool and was well covered during QCon but a friend advised me to have a look at Haskell). At the end, I learnt many concepts and ideas that could be [...]

By: Jonathan

Jonathan — Fri, 27 Feb 2009 20:20:46 +0000

Only you could compare writing code to a honeymoon!

By: Eyal Lotem

Eyal Lotem — Sun, 22 Feb 2009 21:47:53 +0000

Moreover, the strategy Muri is suggesting is very destructive for type inference.

Consider the code:

int f(var blah) {
return blah.x;
}

How do you infer the type of f (specifically, the type of its argument “blah”)?

The globally unique names record fields have the important advantage of making the type clear for the type inference engine. If I’m not mistaken, this is one of the roadblocks holding C# global type inference from taking place.