These are chat archives for ramda/ramda

30th
Sep 2015
David Chambers
@davidchambers
Sep 30 2015 02:29 UTC
Is R.commute equivalent to FL's sequence?
Scott Christopher
@scott-christopher
Sep 30 2015 02:34 UTC
For arrays, yes.
David Chambers
@davidchambers
Sep 30 2015 02:51 UTC
How do they differ for other types?
Scott Christopher
@scott-christopher
Sep 30 2015 02:58 UTC
For Maybe, you could have something like:
Nothing.prototype.sequence = of => of(Nothing);
Just.prototype.sequence = of => this.value.map(Just);
So that will be Applicative ap => Maybe (ap a) -> ap (Maybe a)
David Chambers
@davidchambers
Sep 30 2015 03:05 UTC
Could you explain the Applicative constraint? This isn't yet making sense to me.
Scott Christopher
@scott-christopher
Sep 30 2015 03:07 UTC
The applicative constraint is there to be able to lift a value into functor type contained in the traversable.
So in the example above of(Nothing)
If we don't have a functor instance inside a Nothing, we don't have anything we can map over.
David Chambers
@davidchambers
Sep 30 2015 03:10 UTC
In the this.value.map(Just) case, isn't the only constraint that this.value must be a functor?
Scott Christopher
@scott-christopher
Sep 30 2015 03:10 UTC
In that particular case, yep
Another example is applying sequence/commute to an empty list.
Or any list for that matter, as it is typically implemented as a fold with of([]) as the initial value.
David Chambers
@davidchambers
Sep 30 2015 03:16 UTC
Oh, I see it now. Applicative requires of. I was thinking that applicative requires ap!
Thanks, @scott-christopher!
Scott Christopher
@scott-christopher
Sep 30 2015 03:16 UTC
No worries :)
David Chambers
@davidchambers
Sep 30 2015 03:17 UTC
Is it accurate to say that sequence turns a nested structure inside out?
Scott Christopher
@scott-christopher
Sep 30 2015 03:20 UTC
That's the way I typically think of it. It's essentially allowing a sequence of actions to take place in the order of the traversable and collecting the results.
And to clarify, traversables that contain more than one element (like list) will make use of ap too, in order to build up the traversable inside the applicative.
David Chambers
@davidchambers
Sep 30 2015 03:25 UTC
Is it roughly correct to say that sequence transforms a B inside an A into an A inside a B?
Scott Christopher
@scott-christopher
Sep 30 2015 03:26 UTC
Yeah, while maintaining the order of the original traversable.
David Chambers
@davidchambers
Sep 30 2015 03:28 UTC
Is it also correct to say that R.commute is a specialization of sequence, in that A is always List?
Scott Christopher
@scott-christopher
Sep 30 2015 03:28 UTC
Yep
Another opportunity to dispatch, if we feel like it. :)
David Chambers
@davidchambers
Sep 30 2015 03:30 UTC
That's what I was thinking!
Could we provide R.sequence, have it dispatch, and define R.commute as R.sequence(R.of)? Does this make sense, or have I gone off the rails?
Scott Christopher
@scott-christopher
Sep 30 2015 03:33 UTC
R.commute already takes of as its first argument
So it would be a direct alias of R.commute = R.sequence or vice versa
So if we really want to introduce sequence, we should deprecate commute
David Chambers
@davidchambers
Sep 30 2015 03:36 UTC
That's what I thought initially, but then I convinced myself we need two "of" functions.
Scott Christopher
@scott-christopher
Sep 30 2015 03:36 UTC
While we've always dispatched to methods of the same name as the function, I don't mind keeping commute as long as we document that it will dispatch to sequence for FL's sake.
David Chambers
@davidchambers
Sep 30 2015 03:37 UTC
R.commute is hard-coded to use List as one of the types, isn't it?
Scott Christopher
@scott-christopher
Sep 30 2015 03:37 UTC
At the moment, yep
David Chambers
@davidchambers
Sep 30 2015 03:38 UTC
So wouldn't it need to take an extra "of" argument to be equivalent to sequence?
Scott Christopher
@scott-christopher
Sep 30 2015 03:39 UTC
Not that I'm aware of.
David Chambers
@davidchambers
Sep 30 2015 03:40 UTC
How do you propose removing _of and [] from src/commuteMap.js?
Scott Christopher
@scott-christopher
Sep 30 2015 03:40 UTC
I don't see _of. Do you mean the of in the function params?
David Chambers
@davidchambers
Sep 30 2015 03:42 UTC
L33:
return concatF(acc, map(_of, fn(ftor)));
_of is x => [x].
Scott Christopher
@scott-christopher
Sep 30 2015 03:43 UTC
Ah, I was looking at the 0.17.1 tag.
David Chambers
@davidchambers
Sep 30 2015 03:44 UTC
Oh, right. The _of change is very recent.
Scott Christopher
@scott-christopher
Sep 30 2015 03:45 UTC
Perhaps it should use lift(append) rather than lift(concat)
The only reason _of is needed is to concat a singleton array to the end of the accumulated array (inside the functor).
David Chambers
@davidchambers
Sep 30 2015 03:53 UTC
See ramda/ramda#1409 for the reason we switched from append to concat.
David Chambers
@davidchambers
Sep 30 2015 04:02 UTC
I don't think I'm conveying my thoughts clearly. Currently we have two "of" functions: one provided by the caller, and one fixed to x => [x]. This is fine for [f a] -> f [a], but for arbitrary g (f a) -> f (g a) transformations it seems to me we would need to parameterize the second "of" function.
Scott Christopher
@scott-christopher
Sep 30 2015 04:02 UTC
The _of is specific to the [] traversable implementation.
Other traversables would handle that themselves.
e.g. commuteMap could also be implemented without _of using reduceRight and prepend instead:
function commuteMap(fn, of, list) {
  function consF(acc, ftor) {
    return ap(map(prepend, fn(ftor)), acc);
  }
  return reduceRight(consF, of([]), list);
}
Scott Christopher
@scott-christopher
Sep 30 2015 04:12 UTC
I'd be interested to see what people think in changing the type of the function in the first param of commuteMap from f a -> f b, to a -> f b
David Chambers
@davidchambers
Sep 30 2015 04:25 UTC
I'd love to continue this discussion in a GitHub issue, but I don't yet have a good enough grasp on the situation to write a description. I just have a general sense that R.commute is a special case of traverse, and Hardy Jones has taught me to love generalizations. :smile:
Raine Virta
@raine
Sep 30 2015 18:42 UTC
I've always wondered if it's semantically incorrect to use a -> b -> c notation if a function is not curried
Jethro Larson
@jethrolarson
Sep 30 2015 18:42 UTC
I wouldn't
I've switched to saying a, b -> c
Raine Virta
@raine
Sep 30 2015 18:43 UTC
that almost looks like it takes a tuple
Raine Virta
@raine
Sep 30 2015 20:26 UTC
heh, I was wondering why ramda-destruct wouldn't add equals to my required functions, thought it was bug in its code. turned out I was running v0.14 and that's why it didn't add it