2 ms·

I guess I don't understand the difference between have a typed Go pointer and asking if it is null or not. Nil is nothing, a non-nil value means you can use it.

I guess I don't understand the difference between have a typed Go pointer and asking if it is null or not. Nil is nothing, a non-nil value means you can use it. I feel like I'm probably missing a piece of this and I feel dumb about it, sorr I'm not groking it.

pcwalton 14y ago
Every time you dereference a pointer in any language with a null pointer type, you're implicitly admitting the chance of a failure (panic, exception, ...). With a sum type (like Maybe or option in ML), you never have this possibility; you have to handle the two cases (null and not-null) separately, and the compiler checks to ensure that you can never use the pointer unless you're in the not-null branch. What Bob Harper is talking about is that, in for example Go, you can write this: if x == nil { ... use x ... } Which is of course a bug. What you meant to write is: if x != nil { ... use x ... } But the Go compiler cannot check this in the general case. However, in ML or Haskell, it's easy. This does not compile, because the type of x will be option<T> instead of T: match x with | None -> ... (* use x *) | Some _ -> () (* do nothing *) But this does compile: match x with | None -> () (* do nothing *) | Some y -> ... (* use y *) Because the type of y will be T instead of option<T>.
- drivebyacct2 14y ago
  I understand. I guess I don't do even FP to find that to be terribly important to me. To me, and I understand it's not, the pattern matching against None looks to me like a nil check in Go. Also, with your example, the compiler could definitely check, for thread-bound variables, that that code is "incorrect".
  - pcwalton 14y ago
    In the general case, the compiler can't check to see that that code is incorrect. Consider the case in which the boolean result "x == nil" is threaded around from function to function, aliased (you handed out a pointer to it), etc... Also consider the case in which "x" is aliased (you handed out a pointer to it) and it gets mutated to nil in the middle of the branch by calling some function. If you go down this road, you end up making the compiler perform a very difficult (probably undecidable) proof. There has been lots of research on this and it's not easy...
    - drivebyacct2 14y ago
      Sorry, this may be becoming off-topic, and to be honest, I'd considered multithreading (especially given Go's strong suite). Is that just not something Haskell or equivalent can do then?
      - Peaker 14y ago
        What do you mean? How does this relate to multithreading?

pcwalton 14y ago

Every time you dereference a pointer in any language with a null pointer type, you're implicitly admitting the chance of a failure (panic, exception, ...). With a sum type (like Maybe or option in ML), you never have this possibility; you have to handle the two cases (null and not-null) separately, and the compiler checks to ensure that you can never use the pointer unless you're in the not-null branch. What Bob Harper is talking about is that, in for example Go, you can write this: if x == nil { ... use x ... } Which is of course a bug. What you meant to write is: if x != nil { ... use x ... } But the Go compiler cannot check this in the general case. However, in ML or Haskell, it's easy. This does not compile, because the type of x will be option<T> instead of T: match x with | None -> ... (* use x *) | Some _ -> () (* do nothing *) But this does compile: match x with | None -> () (* do nothing *) | Some y -> ... (* use y *) Because the type of y will be T instead of option<T>.

drivebyacct2 14y ago
I understand. I guess I don't do even FP to find that to be terribly important to me. To me, and I understand it's not, the pattern matching against None looks to me like a nil check in Go. Also, with your example, the compiler could definitely check, for thread-bound variables, that that code is "incorrect".
- pcwalton 14y ago
  In the general case, the compiler can't check to see that that code is incorrect. Consider the case in which the boolean result "x == nil" is threaded around from function to function, aliased (you handed out a pointer to it), etc... Also consider the case in which "x" is aliased (you handed out a pointer to it) and it gets mutated to nil in the middle of the branch by calling some function. If you go down this road, you end up making the compiler perform a very difficult (probably undecidable) proof. There has been lots of research on this and it's not easy...
  - drivebyacct2 14y ago
    Sorry, this may be becoming off-topic, and to be honest, I'd considered multithreading (especially given Go's strong suite). Is that just not something Haskell or equivalent can do then?
    - Peaker 14y ago
      What do you mean? How does this relate to multithreading?