These are chat archives for ramda/ramda
compose(map(f), chain(g)) == chain(compose(map(f), g))
@joneshf parsing/manipulation mainly, but maybe formatting too. i have string input that should be interpreted using some heuristics where it prefers some way to parse it. stuff that momentjs is supposed to do out of the box. but i struggle to make it behave the way i want, since the control you have over a "valid" parse is really limited.
but it's not the first time momentjs bit me. it's timezone support is sketchy at best. the site i work on is swedish. when my laptop happens to be in europe and i interpret user input such as "2015-06-01 10:00" it correctly identifies that june is "CEST", daylight saving and december "2015-12-01 10:00" as "CET" (no daylight). however. if my laptop is in india, where i spend my winters, this automatic recognition for cutoff dates for daylight savings can't be had. you can't tell it "interpret this string as if my laptop is somewhere in europe", even though it clearly does that under the hood.
and do i even need to mention the mutability of it?
m = moment(); m.add(2, 'days'); m is ... ?
m = moment(); tomorrow = m.add(1, 'days'); yesterday = m.sub(1, 'days'); // oh no it isn't!
(as...) -> as
R.applytransforms a function which accepts positional arguments into a function which accepts a list.
R.unapplytransforms a function which accepts a list into a function which accepts positional arguments.
R.apply. i've stared myself too blind at fn.apply to think beyond that.
R.chain, for example, transforms a function which takes an unwrapped value into a function which takes a wrapped value.
FutureT (Cofree Identity) ClickEventis better descriptive?
> null >= 0; true > undefined >= 0; false
> null > 0 false > null == 0 false > null < 0 false
> null < 0 false > null <= 0 true > null == 0 false > null >= 0 true > null > 0 false
> 42 == ['42'] true >  ==  false
['42'], which are of different types,
==coerces both values to strings. Both have the same
==uses identity so the fact that both arrays have the same
.toString()representation is ignored.
const toList = (...args) => args
@raine: I haven't seen rtype before, didn't make much sense from the README, and am not motivated by it to investigate any further.
I have played around with stampit a bit. I've seen half-a-dozen similar libraries for pure prototypal inheritance, and many more for pseudo-classical inheritance. None have ever done that much for me. I'm especially turned off by Eric Elliott's aggressive insistence that his is the only reasonable way to do inheritance in JS -- not the library per se, but the general approach. While I happen to share his preference, I don't think the choice is so stark, and this attitude really bothers me: "Well, I'm an O'Reilly published author, so my point of view is so much more valuable than yours." I've been approached about writing a book, and responding to that gave me more impetus to consider doing it than any actual good reasons.