These are chat archives for ramda/ramda

29th
Dec 2015
boxofrox
@boxofrox
Dec 29 2015 01:33
question about Applicative types. the identity law in fantasy-land's spec states a.of(x => x).ap(v) is equivalent to v [1]. Is this saying that a and v must be the exact same Applicative and can never differ? e.g. you can't apply a Maybe with an Either? Not that I want to, but the spec doesn't mention AFAIK that a and v must use the same container type, so it seems by omission one might theoretically find two different Applicatives to use in this manner.
boxofrox
@boxofrox
Dec 29 2015 01:46

I ask because the Id example implements ap as

// Apply
Id.prototype.ap = function(b) {
    return new Id(this.value(b.value));
};

which fails to satisfy the first law if b is not an Id type. Unless I'm a bit too pedantic about the definition of equivalence [2], and Maybe a is equivalent to Either bwhen both are Applicatives. I are so confused. :confused:

Hardy Jones
@joneshf
Dec 29 2015 02:48
taht's exactly it, they have to be the same type.
boxofrox
@boxofrox
Dec 29 2015 02:48
great. that takes a load off my mind. :smile:
Niloy Mondal
@niloy
Dec 29 2015 10:29
Hey, can someone tell me where lenses are used ?
In what situation...
jeffcato
@jeffcato
Dec 29 2015 16:23
Niloy Mondal
@niloy
Dec 29 2015 16:43
@jeffcato Umm, I read that, how is it different from assoc or assocPath
Hardy Jones
@joneshf
Dec 29 2015 16:58
@niloy how do assoc and assocPath compose?
@niloy how does lensProp or lensPath compose?
Can you use multiple assocs to get the behavior of assocPath?
Can you get the value out of an object with assoc?
Can you modify the value with an assoc?
assoc is like a simplified version of set.
prop is like a simplified version of view.
Niloy Mondal
@niloy
Dec 29 2015 17:07
Yeh, assoc doesn't compose, so lenses are composable getters_ and _setters ?
Can you modify the value with an assoc?
I think it can, in the same way lenses do, creates a new object
Can you get the value out of an object with assoc?
prop and path
David Chambers
@davidchambers
Dec 29 2015 17:10
assoc doesn't have access to the current value, so it's not possible to express increment .x.y.z in terms of assoc.
Niloy Mondal
@niloy
Dec 29 2015 17:11
evolve works in that case
David Chambers
@davidchambers
Dec 29 2015 17:11
Right. Do you see a pattern here?
Niloy Mondal
@niloy
Dec 29 2015 17:11
Lenses are unified way to achieve all?
David Chambers
@davidchambers
Dec 29 2015 17:12
Yep! Dozens of Ramda functions are (almost) made redundant by view, over, set, and a small number of helpers for creating lenses.
It's worth noting, though, that assoc can be used to add a key–value pair to an object, whereas lenses don't really handle missing properties.
Also, even if a function is just sugar, sometimes that's okay. I think some functions could be removed, though. evolve strikes me as a good candidate for deprecation.
Niloy Mondal
@niloy
Dec 29 2015 17:16
Deprecating evolve is okay as long as you provide over with the same ease of assoc and assocPath, creating lenses is too verbose :(
David Chambers
@davidchambers
Dec 29 2015 17:19
When I define a record type I like to define all the lenses up front. Then in the code I write L.name rather than R.lensProp('name').
Niloy Mondal
@niloy
Dec 29 2015 17:22
But without lenses, you can just define the paths likeL.name = ["name"] and use R.assocPath(L.name, "mickey"), seems nearly same
If you not making use of the composability, they seems equivalent
David Chambers
@davidchambers
Dec 29 2015 17:23
Yes, I see your point.
Scott Sauyet
@CrossEye
Dec 29 2015 18:39
Remember also that lenses are about any data structure, not just paths that can be delineated with named properties.
Scott Sauyet
@CrossEye
Dec 29 2015 18:45
But if you want named paths, the new lensPath should make that easier too.
var lens = R.lensPath(['foo', 'bar', 'baz']);
R.over(lens, R.inc, {foo: {bar: {baz: 10, qux: 20}}});
//=> {foo: {bar: {baz: 11, qux: 20}}})
Niloy Mondal
@niloy
Dec 29 2015 18:48
R.path actually works in a settings like this R.path(["0", "foo"], [{foo: 1}]);
although assoc doesn't
So, anything involving array will need to use lenses
And also over does not have a non-lens equivalent api
Scott Sauyet
@CrossEye
Dec 29 2015 19:28
R.path works that way not because of any deep design decisions, but merely because of the quirk of the language design that builds arrays atop objects.
Scott Christopher
@scott-christopher
Dec 29 2015 21:14
I know there has been some frustration in the past with the lack of documentation for ramda-fantasy, so I'd encourage anyone interested to peruse the new docs that have just landed and raise any issues/prs for suggestions, fixes and improvements. https://github.com/ramda/ramda-fantasy/tree/master/docs
Raine Virta
@raine
Dec 29 2015 21:16
nice job
Scott Sauyet
@CrossEye
Dec 29 2015 23:41
@scott-christopher: These are great! Sometime soon we should look at how they can integrate into http://ramdajs.com.
Scott Christopher
@scott-christopher
Dec 29 2015 23:56
I think they suffer a little from the limited markdown rendering in github, so having something styled a bit a nicer would be a win.
I have slight concerns about keeping the docs in sync by having them in separate files, but we can address that later if it becomes an issue.