Clojurians Log v2

http://tech.frontrowed.com/2017/11/01/rhetoric-of-clojure-and-haskell/

if types aren't sufficient, have you tried adding more types?

:simple_smile:

That Front Row article made my blood boil -- it gets the semantics of Clojure completely wrong so it's not any sort of "rewrite Clojure in Haskell". It's a ridiculous article.

And funny enough it's a perfect example of what both Rich and Eric were talking about:

1) it's a "fun" puzzle with little gained in the end

2) a whole lot of words to describe something that could be done, but no one has actually done it

And yeah, even then it misses out on runtime polymorphic extension so it's still wrong.

Because they built it all with pattern matching which is exactly what Rich pointed out as a flaw

It is not about the semantics of clojure, it is trying to show that you can also parse inputs that don’t have a strictly defined schema.

eh, but you can't really

The author probably didn’t communicate that clearly, I can see how the wrong message can be inferred from it.

What you get out is a dynamically typed structure, and then you have to somehow map that to internal static types. Which means you just build an informal, bug ridden, .... implementation of lisp, in Haskell 😛

Not to mention that that example doesn't really work either, since true EDN parsers must support data readers. So you have to handle extension at runtime, where something like #inst "2012-01-02" needs to be a physical date object (not a tagged or wrapped value). No way to type that at compile time. So you're left writing a dynamic type system for haskell.

It also ignores the transducer-returning arity of map -- which Haskellers have previously failed to write correct types for (I seem to recall Rich specifically calling out that transducers cannot be fully typed in Haskell?).

It basically ignores anything and everything that would show the (obvious) holes in his argument. Sorry, it's making me angry/frustrated again just re-reading it...

(and he doesn't even have a comment system so I can vent on his blog about how wrong he is! 🙂 )

You can vent in at least 4 places on reddit 🙂

i'd also like to read a blog that makes some examples a little more concrete if you were interested in typing some thoughts up

@seancorfield is right, the thing that I haven't seen fully explored (or solved) in Haskell is that transducers create a sort of state-machine.

Imagine if you tried:

actually I don't even know how to type that. but you can imagine a reduce over a typed map. Where some keys are known to have integer values, but others are known to have string values.

A correctly typed transducer should be able to catch errors with that at compile time.

I try not to venture into Reddit. Too many "opinions" and it's a giant ol' time sink...

that rings hollow to me

function composition is very type-able, and that is what a transducer is

or I should say building a transducer is function composition, and a transducer is just a function from a step function to a step function, and those are also known to exist in typed languages