4 ms·

The conclusions of http://fregepl.blogspot.jp/2013/03/adding-concurrency-to-frege-part-iii.html http://fregepl.blogspot.jp/2013/03/adding-concurrency-to-fre...

by stuhood 13y ago

The conclusions of http://fregepl.blogspot.jp/2013/03/adding-concurrency-to-frege-part-iii.html http://fregepl.blogspot.jp/2013/03/adding-concurrency-to-fre... lead me to believe that the author knows significantly more about Haskell than about either the JVM or concurrency. I hope that the language is able to attract a healthy number of contributors in those areas before it begins to accrete it's own idiomatic concurrency patterns.

noelwelsh 13y ago
Your comment would be more useful if you elaborated on these claims.
- stuhood 13y ago
  The section on forkIO vs forkOS is interesting because the author does not mention implementing green threads atop the JVM. It would be feasible for Frege and its core libraries to use an implementation of "green threads" based on Promises or CPS under the covers in order to implement a concurrency model indistinguishable from Haskell's. While it is true that the vast majority of JVM code you interact with is blocking and expects to own whatever OS thread it is running on, that could be treated as a concern of FFI, where untrusted/blocking code in Java land gets dedicated OS threads (similar to FuturePools/execution-contexts for scala Futures, or how you would manually isolate blocking code for Erlang or Go FFI.) Additionally, the comment dismissing STM seems like an afterthought, because there are at least three JVM implementations (Clojure's, Scala's, and Multiverse) But the main comment I was referring to was: To do serious concurrent work in an JVM environment is different and it will thus require different knowledge ... which suggests that the author isn't interested in supporting Haskell's idiomatic concurrency model atop the JVM, and is instead fine with the status quo of blocking code.
  - pron 13y ago
    There are at least two JVM lightweight thread libraries. Kilim [1] and Quasar[2] (written mostly by me). [1]: http://www.malhar.net/sriram/kilim/ http://www.malhar.net/sriram/kilim/ [2]: http://puniverse.github.io/quasar/ http://puniverse.github.io/quasar/
  - voxfrege 13y ago
    > which suggests that the author isn't interested in supporting Haskell's idiomatic concurrency model atop the JVM This is not quite true (I am the author). Yet I know my limits. Every contribution from the community is welcome, OTOH. The point of the blog posts was only to explore how far one can get with what Java has.
GertrudeCruz 13y ago
my best friend's step-mother makes $81 an hour on the laptop. She has been unemployed for six months but last month her income was $18340 just working on the laptop for a few hours. why not find out more... www.Buzz19.com

by stuhood 13y ago

noelwelsh 13y ago

Your comment would be more useful if you elaborated on these claims.

stuhood 13y ago
The section on forkIO vs forkOS is interesting because the author does not mention implementing green threads atop the JVM. It would be feasible for Frege and its core libraries to use an implementation of "green threads" based on Promises or CPS under the covers in order to implement a concurrency model indistinguishable from Haskell's. While it is true that the vast majority of JVM code you interact with is blocking and expects to own whatever OS thread it is running on, that could be treated as a concern of FFI, where untrusted/blocking code in Java land gets dedicated OS threads (similar to FuturePools/execution-contexts for scala Futures, or how you would manually isolate blocking code for Erlang or Go FFI.) Additionally, the comment dismissing STM seems like an afterthought, because there are at least three JVM implementations (Clojure's, Scala's, and Multiverse) But the main comment I was referring to was: To do serious concurrent work in an JVM environment is different and it will thus require different knowledge ... which suggests that the author isn't interested in supporting Haskell's idiomatic concurrency model atop the JVM, and is instead fine with the status quo of blocking code.
- pron 13y ago
  There are at least two JVM lightweight thread libraries. Kilim [1] and Quasar[2] (written mostly by me). [1]: http://www.malhar.net/sriram/kilim/ http://www.malhar.net/sriram/kilim/ [2]: http://puniverse.github.io/quasar/ http://puniverse.github.io/quasar/
- voxfrege 13y ago
  > which suggests that the author isn't interested in supporting Haskell's idiomatic concurrency model atop the JVM This is not quite true (I am the author). Yet I know my limits. Every contribution from the community is welcome, OTOH. The point of the blog posts was only to explore how far one can get with what Java has.

GertrudeCruz 13y ago

my best friend's step-mother makes $81 an hour on the laptop. She has been unemployed for six months but last month her income was $18340 just working on the laptop for a few hours. why not find out more... www.Buzz19.com