in ap.js

[imchenglibin]

implement is like this:

var ap = _curry2(function ap(applyF, applyX) {
  return (
    
    typeof applyX['fantasy-land/ap'] === 'function' ?
      applyX['fantasy-land/ap'](applyF) :


    typeof applyF.ap === 'function' ?
      applyF.ap(applyX) :
    typeof applyF === 'function' ?
      function(x) { return applyF(x)(applyX(x)); } :
    // else
      _reduce(function(acc, f) { return _concat(acc, map(f, applyX)); }, [], applyF)
  );
});

not this:

var ap = _curry2(function ap(applyF, applyX) {
  return (

    typeof applyF['fantasy-land/ap'] === 'function' ?
      applyF['fantasy-land/ap'](applyX) :


    typeof applyF.ap === 'function' ?
      applyF.ap(applyX) :
    typeof applyF === 'function' ?
      function(x) { return applyF(x)(applyX(x)); } :
    // else
      _reduce(function(acc, f) { return _concat(acc, map(f, applyX)); }, [], applyF)
  );
});

why?

[CrossEye]

When we try to match the FantasyLand specifications, it is more consistent with Ramda that the translation of FantasyLand methods put the receiving object as the last parameter. This is the FantasyLand signature:

ap :: Apply f => f a ~> f (a -> b) -> f b

(where the squiggly array (~>) represents method application on the object to its left.)

This translates to a Ramda pure function as

ap :: Apply f => f (a -> b) -> f a -> f b

So I think this is right. Anyone disagree?

[imchenglibin]

function Container(value) {
    this.__value = value;
}

Container.of = function (value) {
    return new Container(value);
}

Container.prototype.map = function (fn) {
    return Container.of(fn(this.__value));
}

A. Implements 'fantasy-land/ap'

Container.prototype['fantasy-land/ap'] = function (otherContainer) {
    return otherContainer.map(this.__value);
}

usage:

ap(Container.of(3), map(add, Container.of(2)));  // Container(5)

B. Implements 'ap'

Container.prototype['ap'] = function (otherContainer) {
    return otherContainer.map(this.__value);
}

usage:

ap(map(add, Container.of(2)), Container.of(3));  // Container(5)

both A and B are ap functor, and actually they are the same ap functor, but usage are different(params order).

[CrossEye]

Ok, I see. The delegations to ap and fantasy-land/ap disagree on parameter order. That seems pretty bad. I think that our FantasyLand one is correct, and we should fix the plain one. Do you agree?

[imchenglibin]

Implements 'fantasy-land/ap'

function Container(value) {
    this.__value = value;
}

Container.of = function (value) {
    return new Container(value);
}

Container.prototype.map = function (fn) {
    return Container.of(fn(this.__value));
}

Container.prototype['fantasy-land/ap'] = function (applyF) {
    return this.map(applyF.__value);
}

usage:

ap(map(add, Container.of(2)), Container.of(3))

FantasyLand one is correct, and the delegation to ap is incorrect

[kedashoe]

Ok, I see. The delegations to ap and fantasy-land/ap disagree on parameter order. That seems pretty bad. I think that our FantasyLand one is correct, and we should fix the plain one. Do you agree?

This was done intentionally, see #1900, #1900 (comment)

[imchenglibin]

so i should implement ap functor as below?

Implements fantasy-land/ap

Container.prototype['fantasy-land/ap'] = function (applyF) {
    return this.map(applyF.__value);
}

implements ap

Container.prototype['ap'] = function (otherContainer) {
    return otherContainer.map(this.__value);
}

[CrossEye]

Even with @kedashoe's prompting, I still cannot remember why we didn't switch the order of ap when we added fantasy-land/ap.

This from @davidchambers:

The order in which a fantasy-land/ap method takes its arguments and the order in which R.ap takes its arguments are unrelated concerns. The change to the FL spec was made to bring ap into line with map and chain.

Doesn't seem to add anything we should care about. Even if we could keep ap separate from fantasy-land/ap, why would we do it? I think I fell down on the job there, when that PR stayed open too long, and didn't push back on this. But I'm in favor of switching ap to match.

[davidchambers]

From my perspective we only dispatch to ap for compatibility with old versions of Fantasy Land. For backwards compatibility, in other words. Changing the way in which we dispatch to ap would break backwards compatibility, at which point we could simply remove the fallback and dispatch to fantasy-land/ap exclusively.

[CrossEye]

I'm sure you know that my perspective on dispatching is a bit different. 😈. But that's right, we kept that for backward compatibility not with our internal code but an older FL version.

Hmmm.

[customcommander]

@CrossEye: if I understand this correctly I can confirm that this comment from @imchenglibin is still correct as of today:

1. The FL implementation is correct (i.e ApplyX['fantasy-land/ap'](ApplyF))
2. The delegation is incorrect (i.e. applyF.ap(applyX))

Our next v1.0 is likely to contain breaking changes anyway so we might as well address this issue? Otherwise let's close?