1. 19
  1.  

  2. 4

    Monads are not some mystical, otherwordly concept. Using them is actually pretty mundane. If you approach them as if you need to have your mind blown, you’re going to miss the point.

    One of the least pretentious things I’ve read about monads and I wholeheartedly agree.

    1. 3

      Lazy evaluation is about composability and refactoring, not performance. Occasionally getting better asymptotics is more a happy coincidence than something to rely on.

      Good that this misunderstanding was cleared up!

      1. 2

        Unfortunately, you can’t really have unit tests in the same file with your source code.

        I don’t see why not. I do. I use Haskell Test Framework (HTF), which wraps both hUnit and a QuickCheck implementation. Any function named with a prefix test_ is treated as a hUnit-style test (prop_ for quickcheck properties).

        Here’s an example https://github.com/jmtd/liquorice/blob/master/Liquorice/Pure.hs#L193

        You can also collect all such in line tests together into a separate test binary so cabal test and similar run them and report on them all together

        https://github.com/striot/striot/blob/master/src/TestMain.hs

        1. 2

          The main argument against is probably having the tests sneak into your module exports.

          I see that HTF deals with most of this. (Does the prune haddock option cause the exported test name to not show up in the liquorice haddocks on hackage?) Though you still end up pulling in HTF and a whole lot of dependencies for non-test builds.

          1. 2

            Does the prune haddock option cause the exported test name to not show up in the liquorice haddocks on hackage?

            Yes that’s right

            Though you still end up pulling in HTF and a whole lot of dependencies for non-test builds.

            That’s true and perhaps the most significant drawback

            1. 1

              Since HTF is preprocessing already, I wonder whether it could strip the test code from non-test builds.

        2. 2

          True and False are uppercase. Pythonistas rejoice.

          Yes! Unlike other languages, True and False are defined as type constructors from the standard library (Prelude), rather than language keywords:

          data Bool = True | False
          

          And

          if <bool> then <e1> else <e2>
          

          expressions are actually sugar for case <bool> of { True -> e1; False -> e2 }.

          1. 1

            Yes! Unlike other languages, True and False are defined as type constructors from the standard library (Prelude), rather than language keywords

            Not all languages. In C, booleans are (typically) defined like

            #define true	1
            #define false	0
            

            no keywords here :P