5 ms·

*** Exception: Prelude.head: empty list

giornogiovanna 7y ago
Yeah, I don't know why Prelude.head doesn't return a Maybe. Anyway, the point stands. • In Java forgetting to check for null will crash your program. • In C, forgetting to check for NULL will lead to undefined behavior. • In Haskell, you either have to (a) check for Nothing, or (b) explicitly say "crash the program if this is Nothing" by using a function like fromJust or head, which internally does (a). This is always an improvement over C, and often an improvement over Java. Side note: I like Rust's convention of consistently naming these might-crash-your-program methods "unwrap" and "expect".
- pdexter 7y ago
  Yeah I think rust has better defaults here.
  - crimsonalucard 7y ago
    I get the choice. It's unintuitive for basic types to be wrapped in a maybe mondad. People expect addition, subtraction and division to return numbers. To have division be the only operation to return an optional is a bit off. I get the choice of why it wasn't done with haskell even though I disagree with it.
crimsonalucard 7y ago
You cannot have a null exception in haskell. Yes, I'm aware of that 1/0 returns an exception. I'm saying that it makes sense to use nulls because 1/0 is an undefined operation. Therefore to represent the output of 1/0 with a null makes sense. So the existence of nulls makes sense. That is not haskell code I'm typing up there. "1/0 = undefined" is not code. If you read my reply you will see that my statement isn't referring to an exception caused by 1/0. It's actually referring to a null exception which is completely different. I am explicitly saying that the "null" in haskell is part of a sum type (the maybe monad) and in that case the "null" or nothing will be handled with no run time errors. You cannot have a null exception in haskell. Never did I say Haskell has no runtime errors, and 1/0 is not an exception caused by a null. Please analyze and reread my statement.
hopia 7y ago
Isn't that just due to `head` being a non-total function? Nothing to do with null per se.
- giornogiovanna 7y ago
  Well, Haskell calls the empty list the "null" list (see List.null), so I could say that List.head crashes when it encounters a null. :P Anyway, the real lesson is that even if your language has sane defaults that force you to check that your list isn't empty, or that your pointers aren't null, a bad library function like List.head can hide that check away from you and crash anyway, bringing you back to square one in terms of the type system preventing unexpected crashes.
  - crimsonalucard 7y ago
    The null works with cons. So it's not a proper null. A proper null should throw an exception if you try to do any operation on it.

Yeah, I don't know why Prelude.head doesn't return a Maybe. Anyway, the point stands. • In Java forgetting to check for null will crash your program. • In C, forgetting to check for NULL will lead to undefined behavior. • In Haskell, you either have to (a) check for Nothing, or (b) explicitly say "crash the program if this is Nothing" by using a function like fromJust or head, which internally does (a). This is always an improvement over C, and often an improvement over Java. Side note: I like Rust's convention of consistently naming these might-crash-your-program methods "unwrap" and "expect".

pdexter 7y ago
Yeah I think rust has better defaults here.
- crimsonalucard 7y ago
  I get the choice. It's unintuitive for basic types to be wrapped in a maybe mondad. People expect addition, subtraction and division to return numbers. To have division be the only operation to return an optional is a bit off. I get the choice of why it wasn't done with haskell even though I disagree with it.

crimsonalucard 7y ago

You cannot have a null exception in haskell. Yes, I'm aware of that 1/0 returns an exception. I'm saying that it makes sense to use nulls because 1/0 is an undefined operation. Therefore to represent the output of 1/0 with a null makes sense. So the existence of nulls makes sense. That is not haskell code I'm typing up there. "1/0 = undefined" is not code. If you read my reply you will see that my statement isn't referring to an exception caused by 1/0. It's actually referring to a null exception which is completely different. I am explicitly saying that the "null" in haskell is part of a sum type (the maybe monad) and in that case the "null" or nothing will be handled with no run time errors. You cannot have a null exception in haskell. Never did I say Haskell has no runtime errors, and 1/0 is not an exception caused by a null. Please analyze and reread my statement.

hopia 7y ago

Isn't that just due to `head` being a non-total function? Nothing to do with null per se.

giornogiovanna 7y ago
Well, Haskell calls the empty list the "null" list (see List.null), so I could say that List.head crashes when it encounters a null. :P Anyway, the real lesson is that even if your language has sane defaults that force you to check that your list isn't empty, or that your pointers aren't null, a bad library function like List.head can hide that check away from you and crash anyway, bringing you back to square one in terms of the type system preventing unexpected crashes.
- crimsonalucard 7y ago
  The null works with cons. So it's not a proper null. A proper null should throw an exception if you try to do any operation on it.