Haskell Is Exceptionally Unsafe | Hacker News Reader

Haskell Is Exceptionally Unsafe

existentialtype.wordpress.com

86 pointsjohndcook50 comments

The author is complaining about two language extensions which are present in GHC. These extensions are not part of the Haskell language, which is defined at http://www.haskell.org/onlinereport/haskell2010/ .

The first language extension is the function 'unsafePerformIO', defined in the module 'System.IO.Unsafe'. It's not defined in the language spec, and is unsafe by design because it's intended for very rare and specific use cases in performance-critical code.

The second language extension is the 'Data.Typeable' module, which defines a mechanism of dynamic typing. The standard way to use Typeable is to let the compiler define the instance, which is both safe and much easier to type. It's well-known that implementing a Typeable instance manually is unsafe; for example, see Oleg's post from 2007 http://okmij.org/ftp/Haskell/types.html#unsound-typeable .

Again, these are extensions to the language, implemented as experiments by a particular compiler. A program which uses them is no longer standard Haskell.

His code does not compile when built in standard Haskell mode:

  $ ghc --make exc.hs -hide-all-packages -package haskell2010

  exc.hs:2:8:
      Could not find module `Data.Typeable'

While what you say is true, GHC is the de facto Haskell standard. At least the last time I looked, most widely used and well respected Haskell code would only work in GHC using various extensions. That's the actual state of Haskell: GHC with non-standard extensions is the effective standard.

There are widely used extensions and there are avoided extensions:

http://stackoverflow.com/questions/801785/should-i-use-ghc-h...

An extension that GHC provides, and therefore part of the effective standard, is Safe Haskell (http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/safe-...). A Safe (compiled with -XSafe, containing the LANGUAGE Safe pragma, or inferred) module may not define any manual instances of Typeable.

This is all true, but his actual point is that exception handling should not involve Data.Typeable (or any type casting) at all. I do feel this is an extremely obscure point that does not justify this hyperbole, but it is his blog and he is free to decide what is important there.

From his post, it appears that ML handles exceptions by allowing code to add new constructors to the 'exc' type at run-time. This is effectively indistinguishable from the GHC implementation of dynamic typing, which uses typeclasses.

Without some sort of dynamic type casting as used in ML or Haskell, then it's not possible to implement an exception handler that can extract information (such as type) about an exception. All you'd be able to determine is "some exception was thrown".

Yes, ML is adding new constructors to exn type at runtime, but this is different from GHC implementation of dynamic typing which uses typeclasses, because GHC does not add typeclasses at runtime. Take a look at ezyang(who is a GHC developer)'s comments in the post.

I repeat that this is extremely obscure and probably only interesting to people like ezyang. He is engaged in the discussion, so I guess the post was not pointless.

It's not hyperbole as I read it, it's just a bad pun.

He somewhat obscures that point with tangentially-relevant grumbling and dead-horse-beating, if indeed that's the point he was trying to make (I guess I can see it, looking at the submission again with that interpretation in mind) -- you've made it more clearly in a paragraph than he did in a whole blog post.

[edit]

Also, Haskell does have type-safe exceptions -- using MonadError (http://hackage.haskell.org/packages/archive/mtl/latest/doc/h...).

Actually, as far as I'm aware, IO exceptions don't see much use in practice -- they aren't considered very "Haskell-y". In fact, that's partly because of the dynamic typing aspect that this whole discussion centres around; but also because their behaviour is dependent on evaluation order, and because the possibility of an expression throwing one isn't encoded in that expression's type. None of that is really in the spirit of idiomatic Haskell.

As such, MonadError is the way exception-like behaviour tends to be handled, AFAIK.

Indeed, this problem has absolutely nothing to do with exceptions, other than that exceptions require the Typeable typeclass. I suspect the author only roped exceptions into his exposition to give him an excuse for that linkbaity title.

The problem isn't even caused by Typeable itself per se, it's caused by wilfully ignoring that you're not meant to define an instance of it manually, you're meant to tell the compiler to derive one automatically. As far as I'm aware, writing your own Typeable instance causes undefined behaviour according to the very specification of the typeclass.

So, yes, Haskell's types are unsafe, if you deliberately go out of your way to subvert them. I'm left wondering... "So what?"

I would say `unsafePerformIO` exist for calling C code. Since the Haskell type system can't prove that the C function you're calling is pure, the programmer needs to assert this fact by using `unsafePerformIO` at the call site. There are other possible uses of course, but I'd say this is the main one.

I suspect the reason why this is being upvoted and what it actually says have nothing to do with each other. This is a bit of an academic debate about very precise details of exception handling, not some sort of takedown of the Haskell hype.

In the event that you really are interested in the topic at hand, you probably ought to read the followups on http://www.reddit.com/r/haskell/comments/y74vn/robert_harper... .

"Like most of Harper's articles about Haskell, this is both mostly true and an elaborately constructed troll where it's impossible to tell whether he's getting some lulz or merely piqued that nobody uses ML."

Indeed.

Bob Harper is a pillar of PL research, I think the credentials of his detractor deserve just a tiny bit more scrutiny. It's one thing to refute his assertions, and it's something else entirely to dismiss them as "troll" or "butthurt".

It looks like that comment is from the author of a few popular-press PLs books (most recently Real World Haskell), so probably knowledgeable, though not Harper-level accomplished.

That comment was posted by Bryan O'Sullivan; equivalent to Ted T'so getting involved in a discussion on Linux filesystems.

It looks like most of the folks in the Haskell reddit community are taking it with good humor; I read that comment as a wry tweaking rather than as outright dismissal. Language nerds at play, fun to watch.

He should at least preface these kinds of posts with, or add something to the sidebar, that reveals that he is positively and absolutely biased toward SML: http://en.wikipedia.org/wiki/Robert_Harper_(computer_scienti...

I get an odd taste in my mouth seeing a core language contributor bashing other languages for being "inferior," whilst attempting to appear neutral.

Does that affect the validity of his arguments?

I would be more sympathetic except that I am constantly seeing a certain subset of Haskell programmers engaged in the same kind of advocacy. Should they all disclose a conflict of interest because they like Haskell?

If they contributed to the Haskell type system and they are commenting on the inferiority of the type systems of other languages, absolutely yes.

This is far from his first Haskell-bashing exercise. Take a look at the Wikipedia page for Haskell: "Robert Harper, using Standard ML to teach introductory programming, has given his reasons for not using Haskell. Among these are the difficulty of reasoning about resource usage with non-strict evaluation, that laziness complicates the definition of data types and inductive reasoning,[49]and the "inferiority" of Haskell's class system compared to ML's module system.[50]"

I'm not saying his arguments aren't valid. It's just curious that he's not attacking SML with the same vitriol, and perhaps people would like to know why.

I don't see how he is obligated to attack anything else with the same vitriol, if he doesn't see the same problems with it. It seems that we might just as well try to declare a moratorium on Haskell programmers' bashing of other languages on the basis that those other languages are not type-safe enough.

Any time someone bashes $FAVORITE, I can just disclose to everyone that they are a ${FAVORITE}-basher and therefore aren't speaking credibly. Hooray!

Surely you don't believe that SML doesn't have its own set of issues? My point is he doesn't criticize SML in the same manner on any issue, for a very good reason: he helped design the language.

I believe SML doesn't have any issue that Robert Harper cares about. It is nearly perfect in all things Robert Harper cares about. Are you suggesting that Robert Harper should care about more things than what he currently cares about?

I disagree with your opinion that he doesn't criticize SML because he was involved in the design. SML is not perfect, but Robert Harper does not criticize SML because SML is Robert-Harper-perfect. Or nearly so.

What's your point?

My point is that you are seeing an ulterior motive where I don't see any.

I think in Harper's case he really does believe SML does it The Right Way, rather than promoting SML for ulterior/career reasons. His opinion on that subject isn't shared by many, but I think it's a genuinely held opinion. He just has very particular views on how type systems should be, and tends to overstate his views (e.g. treating questions reasonable people can disagree over as if he were stating unarguable facts).

> Does that affect the validity of his arguments?

His argument can be valid and still be pointless for 99% of people. Granted we all must make these decisions for ourselves, but if someone smirks and says "screw Haskell" because the exception system is unsound and then goes back to using Perl or Java, they have missed the point.

> I would be more sympathetic except that I am constantly seeing a certain subset of Haskell programmers engaged in the same kind of advocacy. Should they all disclose a conflict of interest because they like Haskell?

If you see someone engage in misleading advocacy you should call them out for it. A big problem with Haskell is that it is so weird and different that new users are always blogging about how great it is. When they make a small realization they blog it, and their misconceptions come along with it. I've been using Haskell for a while, and I find it very hard to stomach it when this happens, so I don't usually follow the comments closely when I see it happen. I doubt I'm alone in that. But there's a world of difference between newbie love babble and a calculated PR stunt by a PL expert.

One can craft an entire argument that's valid and still complete BS. Politicians do it every day. You should be asking if his arguments are sound given adequate context and background information. Harper is most definitely biased against Haskell as evidenced by criticisms of his examples and how he plugs SML. Given this, the facts and examples he provides on Haskell shouldn't be taken at face value. Valid arguments are easy to spot. Sound ones are not.

I never heard of the guy, and I could tell he liked ML. He wasn't really hiding it, IMO.

To be fair, he did write a book on programming languages and he knows a lot about the subject. He might troll a little but IMO it's always enlightened trolling.

In this case, he points out a corner case that the Haskell community already knew about. But I, a beginner haskeller, didn't.

It's a much higher level of discourse than the typical "Haskell is {only for academics, not suitable for applications that need to handle mutable state, right-wing}" that people like to throw around.

Eh, I think people reading Robert Harper's blog can be expected to know that Robert Harper wrote The Definition of Standard ML.

Like everyone who is clicking the link on the front page of Hacker News right now?

Well, you can't expect that, but what I am saying is that it is a blog, and I think a blog author should be free to write for his audience. Parent comment seems to say that you should write every blog post as if it is intended for the general public, which I disagree.

No, that's not even remotely close to what I said.

I'm saying it wouldn't hurt his case to write a small blurb about him being one of the designers of SML in the sidebar or to use language like "when we designed SML" or "the choices we took in SML," so it doesn't appear as if it's a wholly objective critique or even subject line.

Well, he does disclose his SML relation at http://existentialtype.wordpress.com/about/

I think that is enough for a blog. In my opinion he is not trying to mislead the public. He is simply not writing for the public.

Hm, I was expecting this to at least mention that exceptions in Haskell pure code is imprecise, and you can only guarantee the exception you desire by throwing it in the IO monad.

http://research.microsoft.com/en-us/um/people/simonpj/papers...

Although I'm not sure what the point is in the article: yes, if you write a purposefully flawed instance of Typeable, you will get errors when you try to use it. I'm not convinced that this is a demonstration that it is "unsafe", since the flawed Typeable instance seems to cause errors in the code that uses the flawed Typeable instance, and not in other parts of the code.

I don't disagree. But -

> yes, if you write a purposefully flawed instance of Typeable, you will get errors when you try to use it.

And if you write flawed C, you will also get errors when you try to use it... but I don't think that will get many heads nodding in the camp of static typing zealots.

> zealots

That word has no place in technical discussions.

The idea that static typing is better than any other tool for preventing bugs is a contentious dogma, not essentially different from iPhone vs. Android flame wars - just more intellectualized.

Don't flatter yourself that your position on a matter of hotly-argued opinion is technical and that other positions are not technical.

> And if you write flawed C, you will also get errors when you try to use it..

Errors potentially in completely unrelated parts of the code. Or worse, no detectible errors at all, just silent corruption of data. You parent comment was trying to make this distinction I think, note the emphasis on "code that uses it" in the comment you're replying to.

It's quite a lot easier to mess up C memory management than to somehow accidentally manually specify a ridiculous Typeable instance.

When he says "Exceptionally" does he mean "very much" or "relating to exceptions"? Or is it a pun and he means both?

The latter.

I think he means "relating to exceptions", but it's meant to at first make you think "very much".

"relating to exceptions" provides the justification, and the other meaning is a pun, not an intellectually-defended usage.

http://research.microsoft.com/en-us/um/people/simonpj/papers...

Is this a troll? I can't tell...

The title is linkbait if not trollish. However the article is just a technical discussion about the best way to implement exceptions in pure functional code. He prefers the way it is done in ML.

NECK BEARD VS NECK BEARD

(this article appears to have no practical implications)

Suddenly it's clear to me.

Haskell itself may be the greatest troll of all time. I'm dense, and it takes me a while to "get it". But Haskell may be such an awesome troll that even the people who implemented the language may not be in on the joke yet either.

Normally we look down on trolls. But just maybe, a troll can be so perfect that it can be admired as a work of art. Haskell may well be that instance of trolling elevated to an art.

Reply on news.ycombinator.com