2 ms·

Yes, Clojure is full of old ideas. I've never claimed otherwise. Unfortunately, they have yet to gain significant traction as currently embodied. Clojure is jus

Yes, Clojure is full of old ideas. I've never claimed otherwise. Unfortunately, they have yet to gain significant traction as currently embodied. Clojure is just an attempt to make them palatable and practical (and fun). I would never argue against someone who preferred Haskell. As far as comonads, no - monads and comonads are essentially threaded through a single computation. The reference types I'm talking about are like, and for similar situations as, Haskell's MVars and STM TVars, which wouldn't exist if, e.g., state monads were sufficient.

jrockway 17y ago
OK, now that you mention MVar/TVar, I think I understand I understand your argument better. I think MVars and TVars are mostly a performance hack (like most other uses of state in general and ST or IO in Haskell specifically). Theoretically, many programs written in terms of MVars could be written in terms of spawning a new thread for each read/write pair. This would be easier to reason about, but probably slower. A common use of MVars: f x = pure computation g h m = forever $ hGetChar h >>= putMvar m do mvar <- newEmptyMVar forkIO $ liftM f (takeMVar m) forkIO $ g a mvar forkIO $ g b mvar <wait for exit condition> All we do is read from two handles, concurrently, and eval f for every byte on either handle. The MVar is a natural way of expressing this, but it does lead to potentially undesirable side effects. Writing it in a functional way would probably be better: f x = pure computation g h f = forever $ liftM f (hGetChar h) do forkIO $ g a f forkIO $ g b f ... There is now no shared state, since the problem doesn't actually require any. (We could use continuation passing style if we needed to keep state.) Anyway, I am still not sure how Clojure encourages the reference-less style.

jrockway 17y ago

OK, now that you mention MVar/TVar, I think I understand I understand your argument better. I think MVars and TVars are mostly a performance hack (like most other uses of state in general and ST or IO in Haskell specifically). Theoretically, many programs written in terms of MVars could be written in terms of spawning a new thread for each read/write pair. This would be easier to reason about, but probably slower. A common use of MVars: f x = pure computation g h m = forever $ hGetChar h >>= putMvar m do mvar <- newEmptyMVar forkIO $ liftM f (takeMVar m) forkIO $ g a mvar forkIO $ g b mvar <wait for exit condition> All we do is read from two handles, concurrently, and eval f for every byte on either handle. The MVar is a natural way of expressing this, but it does lead to potentially undesirable side effects. Writing it in a functional way would probably be better: f x = pure computation g h f = forever $ liftM f (hGetChar h) do forkIO $ g a f forkIO $ g b f ... There is now no shared state, since the problem doesn't actually require any. (We could use continuation passing style if we needed to keep state.) Anyway, I am still not sure how Clojure encourages the reference-less style.