1. 25
  1.  

  2. 9

    A well considered “here’s what clojure looks like from POV of Haskell types”. Was really fun to see what its types would look like in a type system I’m familiar with and prefer. 👍

    I always appreciate a disclaimer in a rant like this, to show that the author is a reasonable person and to add perspective. 👍

    1. 4

      The author did a good job of demonstrating Haskell’s facility for working with a closed set of types but EDN is actually extensible. In EDN, users can define their own tags that aren’t in the base set of tags. In addition to the richer set of base types in EDN, the ability to add your own is the big advantage over JSON and the author doesn’t address that in this article.

      1. 1

        Is there some form of ‘extensible types’ in Haskell, potentially as part of a language extension?

      2. 1

        What about typed Racket? :P

        1. 1

          What about it? It’s real, and it’s spectacular!

        2. 0

          That was even rougher than the last time. That function fails in way more cases than it succeeds. So maybe, just maybe, Maybe isn’t that bad.

          The unstated assumption seems to be that it’s bad for a program to error out when it receives invalid input, which I don’t think is uncontroversial. IMO the thing that’s rough here is that the type system mandates we write out twelve degenerate error cases to compile.

          1. 2

            I think the point was to demonstrate that there are a lot of implicit failure cases. Haskell doesn’t require you to provide a match clause for every data constructor. The author could have written the following with a wild-card pattern to error for all unsupported types:

            `clmap :: (EDN -> EDN) -> EDN -> EDN
             clmap f edn =
               case edn of
                 Nil -> Nil
                 List xs -> List $ map f xs
                 EdnVector xs -> List . map f $ toList xs
                 EdnSet xs -> List . map f $ toList xs
                 _ -> error "unsupported operation"`
            

            But a reason to avoid wild card patterns is that if you’re explicit about how you handle each pattern then the compiler can automatically check that you’ve covered all possible cases and let you know if you’ve forgotten one (like if you were to update the definition of EDN with a new constructor).