3 ms·

You don't need to do head [] but nulls are unavoidable in Java.

tmptmp 10y ago
How can I be sure that some lazy code (may be from some library) may not encounter "head []" at all? Of course, I can avoid that by avoiding all such libraries. Another painful thing is the exception handling is also not as clean and clear as, say Java/Python exception handling, AFAIK. Please correct me if I am wrong here, and I will be a happy camper. In fact, I love Haskell as it has taught me how to think clearly. But I am scary to use it in production, sorry for that.
- wyager 10y ago
  It's actually quite easy. Enable the completeness checker. It won't let you use head, because it's incomplete. In other words, it will say "stop using head". What this entails practically is something like a) using safe head, which has type [a] -> Maybe a, or b) using the non-empty list type, or c) using streams, which don't have an empty constructor. There are lots of things you can do, but the general approach is "use pattern matching to cover all cases". The compiler can tell you if you've done this or not, and it you do your program will never crash. >Another painful thing is the exception handling is also not as clean and clear as, say Java/Python exception handling, AFAIK. Monadic exception handling is 100x easier than in Java or Python. Java copied Haskell/ML's use of Maybe/Optional for avoiding null pointers in Java 8, but they haven't yet figured out Haskell's use of Either and friends for exception handling. Handling true exceptions in Haskell outside of IO code is worse than in Java, which is probably what you're thinking of, but most code bases completely avoid it. It's not hard at all. Handling true exceptions in IO is often nicer than Java, because Haskell has well-thought-out primitives like bracket.
  - tome 10y ago
    > Enable the completeness checker. What's this "completeness checker"?
    - wyager 10y ago
      The -fwarn-incomplete-patterns ghc option.
      - dllthomas 10y ago
        That does not warn about using `head`. It wouldn't even warn about an attempt to define `head`, so long as you do so with a call to `undefined` or `error` (which is effectively what's done in the base libraries).
        wyager 10y ago
        >That does not warn about using `head`. You're right, I didn't realize that. Thankfully, `head` is one of the few common functions that's incomplete, and it's usually pretty obvious what they are. > It wouldn't even warn about an attempt to define `head`, so long as you do so with a call to `undefined` or `error` 1. It's syntactically quite simple to avoid these two. 2. If you're using these, you're obviously aware your program can fail. 3. fdefer-typed-holes was introduced as a better alternative to undefined that warns you when used.
        dllthomas 10y ago
        It's syntactically quite simple to avoid those two in your own code. You're not necessarily aware that a library you're using is using these. That said, the community is pretty good at nudging people toward total functions, particularly in commonly used libraries (Prelude notwithstanding). And as you say, it helps that it is generally obvious when non-totality is newly introduced - infinite loops being the biggest exception, but that's unavoidable anywhere you don't have an actual totality checker.

How can I be sure that some lazy code (may be from some library) may not encounter "head []" at all? Of course, I can avoid that by avoiding all such libraries. Another painful thing is the exception handling is also not as clean and clear as, say Java/Python exception handling, AFAIK. Please correct me if I am wrong here, and I will be a happy camper. In fact, I love Haskell as it has taught me how to think clearly. But I am scary to use it in production, sorry for that.

wyager 10y ago
It's actually quite easy. Enable the completeness checker. It won't let you use head, because it's incomplete. In other words, it will say "stop using head". What this entails practically is something like a) using safe head, which has type [a] -> Maybe a, or b) using the non-empty list type, or c) using streams, which don't have an empty constructor. There are lots of things you can do, but the general approach is "use pattern matching to cover all cases". The compiler can tell you if you've done this or not, and it you do your program will never crash. >Another painful thing is the exception handling is also not as clean and clear as, say Java/Python exception handling, AFAIK. Monadic exception handling is 100x easier than in Java or Python. Java copied Haskell/ML's use of Maybe/Optional for avoiding null pointers in Java 8, but they haven't yet figured out Haskell's use of Either and friends for exception handling. Handling true exceptions in Haskell outside of IO code is worse than in Java, which is probably what you're thinking of, but most code bases completely avoid it. It's not hard at all. Handling true exceptions in IO is often nicer than Java, because Haskell has well-thought-out primitives like bracket.
- tome 10y ago
  > Enable the completeness checker. What's this "completeness checker"?
  - wyager 10y ago
    The -fwarn-incomplete-patterns ghc option.
    - dllthomas 10y ago
      That does not warn about using `head`. It wouldn't even warn about an attempt to define `head`, so long as you do so with a call to `undefined` or `error` (which is effectively what's done in the base libraries).
      - wyager 10y ago
        >That does not warn about using `head`. You're right, I didn't realize that. Thankfully, `head` is one of the few common functions that's incomplete, and it's usually pretty obvious what they are. > It wouldn't even warn about an attempt to define `head`, so long as you do so with a call to `undefined` or `error` 1. It's syntactically quite simple to avoid these two. 2. If you're using these, you're obviously aware your program can fail. 3. fdefer-typed-holes was introduced as a better alternative to undefined that warns you when used.
        dllthomas 10y ago
        It's syntactically quite simple to avoid those two in your own code. You're not necessarily aware that a library you're using is using these. That said, the community is pretty good at nudging people toward total functions, particularly in commonly used libraries (Prelude notwithstanding). And as you say, it helps that it is generally obvious when non-totality is newly introduced - infinite loops being the biggest exception, but that's unavoidable anywhere you don't have an actual totality checker.