4 ms·
It doesn't help to explain state in a very sophisticated way because eventually a memory write is what you're after. I'm programming on a real computer that ha
by yason 16y ago
It doesn't help to explain state in a very sophisticated way because eventually a memory write is what you're after.
I'm programming on a real computer that has memory and a cpu and in order for theory and practice to meet, there must be in the language a concept of variables that somehow map to the concept of reading and writing memory. Clojure doesn't have memory access either but it has mutable containers with very controlled, concurrent accessors.
Assignments and memory writes are very much problems I want to be solved and I'm just unhappy because Haskell doesn't want to help me with that except by strictly with its own doctrine.
In Clojure, I can partition the program state into mutable vars and refs at appropriate levels, depending on the problem and my architecture. Most of my code is pure and in general, I don't use many of those mutable containers, but I do.
If Clojure didn't have a solution for that it would remain an academic toy language.
- knome 16y agoHaskell has a mutable variable implementation here: http://hackage.haskell.org/packages/archive/base/4.0.0.0/doc/html/Control-Concurrent-MVar.html http://hackage.haskell.org/packages/archive/base/4.0.0.0/doc... It also has a software transactional memory implementation here: http://hackage.haskell.org/package/stm http://hackage.haskell.org/package/stm STM in particular is a neat way to do concurrency. http://www.haskell.org/haskellwiki/Software_transactional_memory http://www.haskell.org/haskellwiki/Software_transactional_me...
- applicative 16y ago> It doesn't help to explain state in a very sophisticated way because eventually a memory write is what you're after. I'm not sure about memory writes, but people who adopt this 'realistic' view that 'look it's a machine, it's not math', are often in a state of confusion about the workings of their own compilers. I saw this in action recently when I was fiddling semi-competently with the 'threadring' benchmark (http://shootout.alioth.debian.org/u64q/performance.php?test=threadring http://shootout.alioth.debian.org/u64q/performance.php?test=...). What the requisite program is actually doing is to calculate a certain pure function of input (something like `x mod 503 - 1`). This would be lightning fast as ... well: main = head <$> getArgs >>= print . f where f n = n `mod` 503 - 1 But the terms of the benchmark are that you do this in an amusing way where the steps involve passing news from one thread to another in a ring. In Haskell this is done with `forkIO` and that sort of thing. When compiled with any of GHC's normal flags, my attempts would chug along on big inputs evidently actually doing what the terms of the benchmark required: 503 threads were passing a hot potato around in my cpu. When I compiled with the 'via C' flag, by contrast, it was lightning fast, a little slower than the pure function mentioned above. The reason was plain: the C compiler recognized that I was writing a pure function and optimized away the ridiculous division of threads that was imposed by the terms of the benchmark. I'm pretty sure the 'winning' C program is employing this advantage though the program text is legit, but I don't have the C chops to prove it. (In any case the benchmark seems to have been deprecated, rightly -- wish I'd realized that before spending several hours working on it!) MORAL: if you really want forking processes, memory reads etc. -- if you really want to "get your hands on the real machine with real CPU" -- then .... use GHC, and tell it that's what you want. Otherwise, you're only imagining it -- and maybe your compiler is doing it, maybe it isn't; it's none of your business.
- igouy 16y ago> the benchmark seems to have been deprecated, rightly Well, not actually deprecated as such - but neither thread-ring nor chameneos-redux are included in the which-programming-languages-are-fastest summary. Mostly because there turned out to be naive parallel approaches for other benchmarks, for example spectral-norm http://shootout.alioth.debian.org/u32q/performance.php?test=spectralnorm http://shootout.alioth.debian.org/u32q/performance.php?test=...
- scott_s 16y agoYou're tying up the concept of computation with the implementation of computation that we commonly see (the Von Neumann architecture). Yes, whatever code you write in whatever language will eventually compile down to something that changes bytes in memory. But the way that you express that computation is not required to have such a concept.