This document is about Task
, an alternative for Scalaz's Task
or Scala's Future
.
Note this is work in progress and this document suffered multiple modifications already:
I'm going to start off by motivating what I'm doing here. And I want to be clear that I'm not "dissing" the existing collections implementation or anything as unproductively negative as that. It was a really good experiment, it was a huge step forward given what we knew back in 2.8, but now it's time to learn from that experiment and do better. This proposal uses what I believe are the lessons we can learn about what worked, what didn't work, and what is and isn't important about collections in Scala.
This is going to start out sounding really negative and pervasively dismissive, but bear with me! There's a point to all my ranting. I want to be really clear about my motivations for the proposal being the way that it is.
Every application ever written can be viewed as some sort of transformation on data. Data can come from different sources, such as a network or a file or user input or the Large Hadron Collider. It can come from many sources all at once to be merged and aggregated in interesting ways, and it can be produced into many different output sinks, such as a network or files or graphical user interfaces. You might produce your output all at once, as a big data dump at the end of the world (right before your program shuts down), or you might produce it more incrementally. Every application fits into this model.
The scalaz-stream project is an attempt to make it easy to construct, test and scale programs that fit within this model (which is to say, everything). It does this by providing an abstraction around a "stream" of data, which is really just this notion of some number of data being sequentially pulled out of some unspecified data source. On top of this abstraction, sca
package bar.foo.lenses; | |
import java.util.function.BiFunction; | |
import java.util.function.Function; | |
public class Lens<A, B> { | |
private final Function<A, B> getter; | |
private final BiFunction<A, B, A> setter; |
; Inspired by https://twitter.com/gigasquid/status/530699466891067392 ... | |
; An implementation of the Fizz Buzz Kata with no conditionals. | |
(defn fb-gen | |
[step value] | |
(into (sorted-map) (zipmap (range step 101 step) (repeat value)))) | |
(def nums (into (sorted-map) (zipmap (range 1 101) (range 1 101)))) | |
(def threes (fb-gen 3 "fizz")) | |
(def fives (fb-gen 5 "buzz")) | |
(def fifteens (fb-gen 15 "fizzbuzz")) |
(defn fizzbuzz [n] | |
(let [all-nums (range 0 n) | |
folder (fn [fb-str p-num fb-coll] | |
(mapcat (fn [x] (cons fb-str (rest x))) | |
(partition-all p-num fb-coll))) | |
fizz (folder "fizz" 3 all-nums) | |
buzz (folder "buzz" 5 fizz) | |
fizzbuzz (folder "fizzbuzz" 15 buzz)] | |
fizzbuzz)) |
You have a 16x16 grid of which the 4 centermost cells are always 100 degrees and the cornermost cells are always 0 degrees. All other cells start at 50 degrees.
For example, a 6x6 grid would look like this:
| 0 | 50 | 50 | 50 | 50 | 0 |
| 50 | 50 | 50 | 50 | 50 | 50 |
| 50 | 50 | 100 | 100 | 50 | 50 |