2 ms·

When somebody tosses around phrases like how to subvert Haskell's type system to accomplish basic shit you can do in other languages, it's a big red flag that t

• jmillikin 16y ago
  Subverting the type system is roughly equivalent to embedding assembly in C; possibly useful for very special cases, but almost never done otherwise. It's certainly not required to do anything commonplace.
  • xi 16y ago
    I disagree. For instance, debug printing is a very common pattern in many languages.
    • jmillikin 16y ago
      You don't need to subvert the type system to debug print; simply use 'print', 'printStrLn', or for something truly complex, WriterT. Debug.Trace is available as a last resort, but in roughly a year and a half of writing Haskell code, I can count how many times I've needed it on one hand.
      • xi 16y ago
        You can't inject 'print' or 'printStrLn' into a random function, which is the point of debug printing. And using 'Debug.Trace' qualifies perfectly as subverting Haskell's type system.
        • jmillikin 16y ago
          I'm not arguing that 'trace' is subversive, rather, most of the time it's simply not necessary (or useful). Haskell's not like other languages, where you have to build up massive unreadable piles of code to get anything done. It's easier to write properly, with small functions glued together; and when you've done that, debugging is a matter of either simply reading the code, or running it in GHCI (and then reading it). Import your function, pass it input, see what comes out; when it's wrong, you know what the problem is. Debugging with prints is for stuff that isn't pure, behavior that is outside the Haskell runtime system and thus can't be reasoned about. Which means you're using IO, which means you can take advantage of 'print' or whatever.
          • xi 16y ago
            I'm not arguing that there are no ways to debug Haskell programs. My point was that the OP's phrase indicates at least basic familiarity with Haskell and debug printing might be the thing he had in mind writing it. Haskell's not like other languages, where you have to build up massive unreadable piles of code to get anything done. That's fanboyism. I understand you feel offended by the OP's post, but it is not a good satire unless it offends somebody, and IMO, the article is excellent in summarizing attitudes of some members of the Haskell community. ;)
        • kwantam 16y ago
          You absolutely can, if only you're willing to break the rules. :) (Note that this does NOT break referential transparency as long as you're not dependent on the program's debug output for correctness of the rest of the program.) include System.IO.Unsafe (unsafePerformIO) include Control.DeepSeq (deepseq) (unsafePerformIO $ putStrLn "OES NOES") `deepseq` doStuff VVV EDIT: blocking would also block doStuff owing to the deepseq, which means that your program might take longer to complete but will either return a consistent result or none at all. Similarly, if it causes an exception, at least it won't have failed silently. Moreover, none of these complaints are any worse than those you'd find in another language and both cases are esily detected (i.e., you immediately know when referential transparency is broken), so it's still fundamentally safe as a debugging aid. Let me state that another way: if there is no evidence that putStrLn fails, the result of the above is identical to the result of "doStuff" alone. (Anyhow, upvoted your comment because your statement is certainly correct, even if I claim it doesn't invalidate my initial claims about debugging :) )
          • xi 16y ago
            Even assuming independence from the debug output, `putStrLn` may fail or block, which breaks referential transparency.