Hacker News Reader

Comment by dllthomas | Hacker News Reader

If something returns Maybe FileHandle, and it can't provide you a valid FileHandle, it'll provide Nothing (and if it can provide a valid FileHandle, it will provide "Just" that filehandle).

Edited to add:

Note that this can be the case in Haskell when you're relying on exceptions for error handling. That's the opposite approach from option types, though.

View on HN

In my case, I thought the laziness could be more crazy, where you created a function that would evaluate to a FileHandle, but until you actually evaluate that function, you don't have a FileHandle.

So, depending on just how "lazy" the program truly is, sure you passed it something that unwraps a Maybe, but only once you actually go to use it. That make sense?

Consider this fun bit of nonsense scala

    def foo(x:=>String): Unit = {
        println("Hello")
        println(x)
    }

If I call this as "foo(None.get)", then it will print "Hello" before barfing. In fact, if I didn't evaluate x, it wouldn't even barf. I had thought the laziness of Haskel was that ++. (Meaning I thought if I stored x off to another also lazy reference, it wouldn't barf right away.)

To make that a little more clear of what I meant, some even more amusing scala.

    class Foo(x: => String) {
        def happy = println("Doing good.")
        def sad = println(x)
    }

If I create something with "new Foo(None.get)", I can call happy on this object all day long. If I ever call sad, I get an exception.

The relevant gotcha is when doing lazy IO in Haskell. The general answer is "don't do that" - there are a number of approaches for how. (Lazy IO is fine and quite convenient for things of roughly the scale of a shell script. It's not a good fit to bigger things.)

I'm not sure I see how this changes much. My point is that with laziness, your explosion doesn't happen right where you unwrap a Maybe in the code. It happens where you evaluate the unwrapping.

Apologies for the ninja edit above, but this scala seems to show it isn't just IO that is at danger here.

     class Foo(x : =>String) {
        def happy = println("I'm good.")
        lazy val ack = x
        def sad = println(ack)
     }

Again, if I do "new Foo(None.get)", I can call happy as much as I want, but "sad" will blow up.

Now, I do not and could not claim that this sort of nonsense would have proliferated with the same abandon as null. I am claiming that this is not that unlike a null pointer exception, though.

I think the equivalent to None.get is fromJust Nothing. And yes, it's the equivalent of an unchecked nullable. The Haskell community generally frowns on fromJust (along with other unnecessarily partial functions). The better approach is to either pattern match:

    case maybe_string of
        Just string -> newFoo string
        Nothing -> defaultFoo

Or to use one of the relevant higher-order functions:

    fmap newFoo maybe_string :: Maybe Foo
    maybe defaultFoo newFoo maybe_string :: Foo

Yeah, exception resolution is pretty weird in Haskell due to laziness. In some sense, you end up thinking of exceptions as being buried in values in the language instead of exposed by computation—this is your null-value landmine problem exactly

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

This is also why the Control.Exception module exposes `evaluate`, which embeds a value in an IO computation and thus resolves this problem... If you remember to use it.

http://hackage.haskell.org/package/base-4.7.0.0/docs/Control...

Fortunately, in idiomatic Haskell exceptions are considered to be an expert feature (basically I see them in concurrent IO or resource management code only) and partial functions—usually introduced by incomplete pattern matching like `None.get` does—are veboten.

It's not perfect, but -Wall will help with that.

Reply on news.ycombinator.com