These are chat archives for ramda/ramda

12th
May 2015
Jethro Larson
@jethrolarson
May 12 2015 01:41 UTC
oh wait, is "map" short for "monoid-apply"
maybe brain still fried. I'm going to go lay down now
Raine Virta
@raine
May 12 2015 07:47 UTC
what do you think about Ramda having a complemental version of R.isNil built in?
or am I missing something if I do R.complement(R.isNil) a lot?
Michael Hurley
@buzzdecafe
May 12 2015 10:48 UTC
notNil? could be tasty sugar
mac10688
@mac10688
May 12 2015 12:50 UTC
I emailed the javascript jabber host, hopefully I'll get to hear someone knowledgeable on a podcast in the future :) I think there's a lot going on here that could easily fill up a show and enlighten a lot of people.
Michael Hurley
@buzzdecafe
May 12 2015 14:16 UTC
@mac10688 cool, thanks
Raine Virta
@raine
May 12 2015 14:44 UTC
is there an upgrade guide yet?
Michael Hurley
@buzzdecafe
May 12 2015 15:19 UTC
I think @crosseye is assembling it today
Raine Virta
@raine
May 12 2015 15:47 UTC
ok, nice
Simon Friis Vindum
@paldepind
May 12 2015 16:27 UTC

It just occurred to me. A deep merge could be used as a side effect free way of updating objects:

var house = {color: 'red', windows: {frameColor: 'white', amount: 3}};
var changedHouse = _.mergeDeep(house, {windows: {amount: 4}});

But if that is how people would like to use the function then mergeDeep is probably a bad name. And the implementation should differ as well. Then is would make sense to do as little deep copying as possible.

I think that use case is much more interesting for a functional library than merging objects.
Hardy Jones
@joneshf
May 12 2015 16:53 UTC
I thought that was the point
Simon Friis Vindum
@paldepind
May 12 2015 16:57 UTC
Then I'm just really slow :)
But I'm used to merge from non-functional libraries where the point is certainly just to merge objects.
Hardy Jones
@joneshf
May 12 2015 17:09 UTC
Maybe I'm the slow one :). I don't understand the difference you're pointing out.
Jethro Larson
@jethrolarson
May 12 2015 17:14 UTC
nil? does javascript need yet another word for a null value?
Simon Friis Vindum
@paldepind
May 12 2015 17:17 UTC

@joneshf Just merging two objects could be like this:

var oneHalf = {name: 'Niels Bohr', nationality: 'Danish'};
var otherHalf = {field: 'Physics', married: true};
var niels = merge(oneHalf, otherHalf);

But using merge as a setter would look like this:

var niels = {name: 'Niels Buhr', nationality: 'Danish', field: 'Physics', married: true};
var correctNiels = merge(niels, {name: 'Niels Burh'};

In the first example the two arguments passed to merge are "equal" but the information should really be in the same object. In the second example the purpose is to update the first object passed to merge with the values in the second.
I.e. the second example is just a mutation free alternative to: niels.name = 'Niels Bohr'.

Jethro Larson
@jethrolarson
May 12 2015 17:20 UTC
@raine That article's future has an orElse() you know what would be the equivalent method in ramda-fantasy future?
Hardy Jones
@joneshf
May 12 2015 17:21 UTC
@paldepind what do you mean by "equal"?
@jethrolarson there isn't
Scott Sauyet
@CrossEye
May 12 2015 17:24 UTC
@paldepind are you suggesting something like assoc?
Simon Friis Vindum
@paldepind
May 12 2015 17:24 UTC
@raine They represent the same thing and the order in which they're passed to merge has no meaning. In the second example the first object is the one to update and the second contains changes.
@CrossEye Yes. Like a more powerful version of assoc.
It occurred to me while reading some Elm code. In Elm you can update a record with the following syntax:
{ point3D | x <- 0, y <- 0 }
Which would be the same as merge(point3D, {x: 0, y: 0})
Jethro Larson
@jethrolarson
May 12 2015 17:29 UTC
@joneshf would the equivalent be .bimap(errorfn, R.I) ?
Scott Sauyet
@CrossEye
May 12 2015 17:30 UTC
This does strike me as the best way to think of merge, much better than a cloning operation.
Simon Friis Vindum
@paldepind
May 12 2015 17:38 UTC
But with that mindset it suddenly makes sense to deep copy as little as possible (like assocPath). Then you could effectively use use objects and nested objects as a immutable data structure where the common parts could be shared between different versions to reduce memory usage.
Hardy Jones
@joneshf
May 12 2015 17:49 UTC
@paldepind oh, I see what you mean.
@jethrolarson Oh, I didn't see bimap, yes that looks about right.
Jethro Larson
@jethrolarson
May 12 2015 18:53 UTC
Actually I was thinking about it and the signature is different. I created a chainReject to get the effect.
Hardy Jones
@joneshf
May 12 2015 18:58 UTC
I thought orElse :: Future a b => (a -> c) -. Future c b ?
Jethro Larson
@jethrolarson
May 12 2015 18:59 UTC
or Else is (a -> Future b) -> Future b
just like chain
He has rejectedMap for the ( a -> b) -> Future
Oh crap I'm starting to understand this shit
Scott Sauyet
@CrossEye
May 12 2015 19:38 UTC
@jethrolarson. I've thought that once or twice too. Don't worry. The feeling goes away quickly.
Jethro Larson
@jethrolarson
May 12 2015 19:55 UTC
Yeah, it's deja vu for me too
But I actually wrote some code using futures in a non-tutorial usecase and it functioned.
:cake:
Hardy Jones
@joneshf
May 12 2015 20:30 UTC

@jethrolarson that is missing some type variables.

You mean orElse :: Future a b => (a -> Future c b) -> Future c b, it's the opposite of chain in that case.

Guess there's nothing in rf for it though.

the type variables are important