##Composing Composition.
When using curried binary operators like +
and -
we can't compose with (.)
because (.)
has the wrong signature:
(.) :: (b -> c) -> (a -> b) -> a -> c
as such the expression
##Composing Composition.
When using curried binary operators like +
and -
we can't compose with (.)
because (.)
has the wrong signature:
(.) :: (b -> c) -> (a -> b) -> a -> c
as such the expression
IO = (doFirst) -> | |
io = () -> doFirst() | |
io.bind = (f) -> IO(-> f(doFirst())()) | |
io | |
ioAlert = (x) -> IO(-> alert(x)) | |
ioConfirm = (x) -> IO(-> confirm(x)) | |
ioPrompt = (x) -> IO(-> prompt(x)) | |
main = -> |
Been really loving flatMap lately. I used to mostly regard it for its usefulness in its relationship to scala's for comprehensions but I'm now kind of loving it for its use as a "subtractive" and "additive" map. What I mean is that when working with Sequences you can flatMap to Seq() to get rid of something or to a Seq( ... ) if you want to split something into multiple things. Basically flatten its inherent composition. Here's a lil gist illustrating the idiom. The idea is you have a sequence of Good ('G), Neutral ('N), and Bad ('B) vibes. After the party the bad vibes are gone and the good vibes have doubled, leaving the neutral vibes unchanged. The party1 function illustrates a more linear way of thinking about the party and party2 represents some flatMap magic :). Personally I think party2, though more verbose, represents a clearer reflection of the process. It seems a bit more illustrative/declarative of what the point of the party is. The result of Party2 also has a nicer order to it.
scala> v
IO = (f) -> | |
ioF = -> f() | |
ioF.bind = (getsNextIoF) -> IOChain(ioF, getsNextIoF) | |
ioF | |
IOChain = (ioF, getNextIoF) -> | |
ioCF = -> | |
value = ioF() | |
nextIoF = getNextIoF(value) | |
nextIoF() |
### | |
Like java, javascript is optimized for throwing null pointer exceptions | |
coffeescript helps with its series of ? operators | |
but here is a scala option-eqsue "maybe monad" when such semantics | |
are preferred over the ? operators or when you want your data | |
to self-document its indefinite-ness (regular vars don't warn you | |
that you may get null or undefined!). | |
note that we're perfectly happy to give you a Some(null) or a Some(undefined) | |
just like scala. if you have an x that you want to fmap to None if it's |