4 ms·

but that is not the point of Haskell's type system, since it doesn't even begin to try to reach that goal. firstly, the most available `head` function crashes

by ferzul 7y ago

but that is not the point of Haskell's type system, since it doesn't even begin to try to reach that goal. firstly, the most available `head` function crashes on half the constructors. more fundamentally, just try using any file or network io method. you just won't have a clue how it can fail, because it isn't even documented. there's many methods where the best you can do is work out what exception is being used to wrap a C errno and read the appropriate Linux man page. at least C documents it's functions that can return errors, and usually encodes them in the type. in Haskell, it's just, "if you're dumb enough to use IO (and what alternative have you got), anything can crash all the time. deal with it". Haskell is great right up to that point, but that's a critical point. (I've tried to find ways to deal with this, but the most people seen to refer too something else when discussing how horrible exceptions are, so I wonder if I'm insane)

mbrock 7y ago
You might like the paper “Ghosts of Departed Proofs” which shows a great technique for dealing with preconditions in Haskell.
- ferzul 7y ago
  I'll surely read it, but based on the abstract, it's a design pattern for library writers, not a sanity pattern for library users. it won't let me know how or if the function you wrote will throw an exception, or what kind of exception it will throw, unless it's documented in the type. but my objection is that many times, the possibly of failure is only present in my generic, language/api agnostic knowledge that a file might not be readable or a ship might drop an anchor on a cable. having thought about it, I then have to read the source code to understand what exception might get thrown, so I can prevent my program from crashing. (i would prefer it to continue as best as it can in the case that some api is unavailable, which is obviously a usecase dependent decision)
  - mbrock 7y ago
    My general approach to programming is that every language at the moment is bad in serious, fatal ways, and that we are all just experimenting and practicing so that 50 years from now we might have a decent approach. Haskell is horrible in some ways, excellent in others, and this paper seems to offer a promising technique.
tome 7y ago
You're not insane at all. A substantial proportion of the Haskell community (I feel like it's a majority but it's hard to be sure) have a strong distaste for partial functions (e.g. head) and functions that throw exceptions (i.e. where you can't see from the type signature what the possible failure modes are). I'm afraid that momentum means that the base libraries change slowly, but you're a long way from alone. I suggest you come to https://www.reddit.com/r/haskell/ https://www.reddit.com/r/haskell/ if you'd like more discussion about it. We often have threads wishing for partial functions to be removed from base!

by ferzul 7y ago

mbrock 7y ago

You might like the paper “Ghosts of Departed Proofs” which shows a great technique for dealing with preconditions in Haskell.

ferzul 7y ago
I'll surely read it, but based on the abstract, it's a design pattern for library writers, not a sanity pattern for library users. it won't let me know how or if the function you wrote will throw an exception, or what kind of exception it will throw, unless it's documented in the type. but my objection is that many times, the possibly of failure is only present in my generic, language/api agnostic knowledge that a file might not be readable or a ship might drop an anchor on a cable. having thought about it, I then have to read the source code to understand what exception might get thrown, so I can prevent my program from crashing. (i would prefer it to continue as best as it can in the case that some api is unavailable, which is obviously a usecase dependent decision)
- mbrock 7y ago
  My general approach to programming is that every language at the moment is bad in serious, fatal ways, and that we are all just experimenting and practicing so that 50 years from now we might have a decent approach. Haskell is horrible in some ways, excellent in others, and this paper seems to offer a promising technique.

tome 7y ago

You're not insane at all. A substantial proportion of the Haskell community (I feel like it's a majority but it's hard to be sure) have a strong distaste for partial functions (e.g. head) and functions that throw exceptions (i.e. where you can't see from the type signature what the possible failure modes are). I'm afraid that momentum means that the base libraries change slowly, but you're a long way from alone. I suggest you come to https://www.reddit.com/r/haskell/ https://www.reddit.com/r/haskell/ if you'd like more discussion about it. We often have threads wishing for partial functions to be removed from base!