How is composition operator

[htsign]

I saw you commit a pipeline operator implementation 5435287.
So, how about composition operator?

other implmentations

• In F#

  let f x = x * 2
  let g x = x + 3
  let h = f >> g      // ">>" is composition
  printfn "%d" (h 10) // 23
  
  let h' = f << g      // right to left
  printfn "%d" (h' 10) // 26
  
  let h'' x = x |> f |> g // it can be replaced by a pipeline operator
  printfn "%d" (h'' 10)   // 23

• In Haskell

  f :: Int -> Int
  f x = x * 2
  
  g :: Int -> Int
  g x = x + 3
  
  h :: Int -> Int
  h = f . g       -- "." is composition, right to left
  
  main :: IO ()
  main = print (h 10) -- 26

• In Scala

  object Main extends App {
    val f: Int => Int = x => x * 2
    val g: Int => Int = x => x + 3
  
    def h: Int => Int = f andThen g // "andThen" is composition
    println(h(10))                  // 23
  
    def h2: Int => Int = f compose g // right to left
    println(h2(10))                  // 26
  }

Honestry, they are simply function, not operator. but convenienced.
What do you think about?

[Kray-G]

It is a good suggestion and I also feel it useful. Anyway the operator of >>, <<, and . already has another meaning, so I need to think about the syntax. Let me know if you have any idea.

Here is an example when we try it in the current version. I guess the new operator will do the same thing, but is it correct?

function compose(...funcs) {
    return { &(a) => funcs.reduce({ &(r, f) => f(r) }, a) };
}

var f = { => _1 * 2 };
var g = { => _1 + 3 };

10 |> compose(f, g) |> System.println;  //=> 23

Best regards.

[htsign]

この場合でも、a を使わず直接 x にバインドしても良いのですが、実はそうすると、

var y = {
    name: 'y',
    methodMissing: x.methodMissing
};

y.mmm(3);

みたいに methodMissing を再利用してしまったりしたときに y.name が参照できない

なるほど…確かに言われてみればという感じですね。

最初に使用した際、実は Function.value はまだ存在していません。これは null になります。
Functional.value() とすると、その瞬間に methodMissing が発動して、いわゆる「関数を返す関数」を作って登録します。

単なるメンバ呼び出しは methodMissing 呼ばれないんですね。なるほど。
そういえば Ruby の場合はメンバ呼び出しなんて概念がなくて常にメソッド呼び出しなんですよね（アクセッサはあるとしても）
x |> f が f(x) だと考えていたので、これで十分呼び出しの要件を満たすものと思っていました。

となると、一度目は Functional.hoge() とするも二度目以降は Functional.hoge() Functional.hoge どちらでもよくなるってことですかね。
この場合はプログラムが1つであれば別のソースファイルでの処理にも引き継がれるんでしょうか？

// sample.kx
class Sample(value) {
    public foo() {
        return "foo" + value;
    }
}

Functional.foo();

// main.kx
using sample;

var sample = new Sample(10);
sample
|> Functional.foo   // be null or call function ?
|> System.println;

ひとまず、実装したので、機会を見てタグ打ちますね！

楽しみです！お待ちしています。

[Kray-G]

単なるメンバ呼び出しは methodMissing 呼ばれないんですね。なるほど。
そういえば Ruby の場合はメンバ呼び出しなんて概念がなくて常にメソッド呼び出しなんですよね（アクセッサはあるとしても）
x |> f が f(x) だと考えていたので、これで十分呼び出しの要件を満たすものと思っていました。

となると、一度目は Functional.hoge() とするも二度目以降は Functional.hoge() Functional.hoge どちらでもよくなるってことですかね。

実はこれダメなんです。。。
なぜなら、Functional.hoge 自体は「「obj を引数にもつ関数」を返す関数」なので、実行してあげないと「objを引数に持つ関数」にならないためです。

本日は時間が無いのでコメントだけ残させていただきますが、後日、もう少し説明しますね！

また、先ほどタグを打って release しておきました！
もしよろしければ、使ってみていただけると助かります。

バグを見つけたら教えていただけると。。。 😅

では、よろしくお願いいたします。

[Kray-G]

ちょっと遅くなりました。すみません。

単なるメンバ呼び出しは methodMissing 呼ばれないんですね。なるほど。
そういえば Ruby の場合はメンバ呼び出しなんて概念がなくて常にメソッド呼び出しなんですよね（アクセッサはあるとしても）
x |> f が f(x) だと考えていたので、これで十分呼び出しの要件を満たすものと思っていました。
となると、一度目は Functional.hoge() とするも二度目以降は Functional.hoge() Functional.hoge どちらでもよくなるってことですかね。

実はこれダメなんです。。。
なぜなら、Functional.hoge 自体は「「obj を引数にもつ関数」を返す関数」なので、実行してあげないと「objを引数に持つ関数」にならないためです。

Kinx の場合、メンバ呼び出し、というよりも、単純にプロパティ・アクセスとなります。Functional というオブジェクトの hoge プロパティを参照するのが Functional.hoge で、これが関数オブジェクトであれば、() で呼び出しができる、という感じです。

で、具体的には、Functional.hoge() としたときに methodMissing が呼ばれ、以下のように定義されます。

Functional.hoge = function(...args) {
    return function(obj) {
        return obj.hoge(...args);
    };
};

なので、Functional.hoge の引数は (...args) で、Functional.hoge() とすると、obj を引数に取る関数が返ってきます。順に適用すると以下のように変換されていきます。

b |> Functional.hoge()
// ↓
b |> function(obj) { return obj.hoge(); }
// ↓
(function(obj) { return obj.hoge(); })(b)
// ↓
b.hoge()

同様に map の場合、

b |> Functional.map({ => _1 * 2 })
// ↓
b |> function(obj) { return obj.map({ => _1 * 2 }); }
// ↓
(function(obj) { return obj.map({ => _1 * 2 }); })(b)
// ↓
b.map({ =>  _1 * 2 })

ですね。引数を取るかとらないかの違いがありますが、形は一緒です（あえて map にも () を付けました）。

そうすると、Functional.hoge として扱うためにはこれが「「obj を引数にもつ関数」を返す関数」ではなく、直接「obj を引数にもつ関数」であれば良いので、上記例を元に言うと、「引数を取らない場合は直接「obj を引数にもつ関数」にアサインしてしまう」ことができれば目的を達成できそうです。つまり、

Functional.hoge = function(obj) {
    return obj.hoge();
};

こうできれば良さそうです。
ただ、obj の種類によって hoge が引数を取るのか取らないのかを判断することができないので、一般化は難しいですね。。。

ということで、特定の obj に特化した Functional を作れるのはどうかな、と思い、以下のようなことを考えてみました。

var f = new Functional(); // グローバルインスタンスの Functional とは別の、新たな Functional を作成。
f.use("hoge", {argument: false}); // f では "hoge" は引数なしで使うよ、と登録。
// そうすると、f.hoge = function(obj) { return obj.hoge(); } がこの時点で登録される。

b |> f.map { => _1 * 2 }    // 他のもの、引数があるものは従来通り。
  |> f.hoge                 // f に対する hoge は () 無しで直接使える。=> b.hoge() が呼ばれる

どうでしょうか？

補足：
実際は f.use("fuga", {arugument: true}) と、引数有り（{arugument: true}）で登録することの意味はあまりない＝methodMissingで同様のことが自動的にされるので、{argument: false} は省略可能でいいかな、と思います。{argument: true} の場合は必要ですが、これを付けて登録する意味はあまりないので、普通はやらない、という感じで。

[htsign]

obj の種類によって hoge が引数を取るのか取らないのかを判断することができないので、一般化は難しいですね。。。

そうでした。関数がカリー化されているということを失念しておりました。

var f = new Functional(); // グローバルインスタンスの Functional とは別の、新たな Functional を作成。
f.use("hoge", {argument: false}); // f では "hoge" は引数なしで使うよ、と登録。

面白い考えですね。関数型とオブジェクト指向の融合みたいな。
ただ、個人的な感覚でいくと最初にインスタンス化してしまうくらいならば、上で @Kray-G 様が書かれていた通り |> Functional.hoge() としてしまった方がよさそうな気がしてしまいました。一貫性がなくなるのは非常に残念ではありますが仕様上仕方ないですよね…。
やはり世間一般的に言われる「関数型言語」はなるべくしてなったというか、関数型の思考で書きやすいように上手く設計されているんだな、と改めて感じました。

[Kray-G]

ただ、個人的な感覚でいくと最初にインスタンス化してしまうくらいならば、上で @Kray-G 様が書かれていた通り |> Functional.hoge() としてしまった方がよさそうな気がしてしまいました。一貫性がなくなるのは非常に残念ではありますが仕様上仕方ないですよね…。

了解です。
...とはいいつつ、最初の Functional.hoge() が使えなくなるわけではないので、隠し機能として実装を入れておいてみます（実装上はうまく動いているので消すのも...）。 😅

やはり世間一般的に言われる「関数型言語」はなるべくしてなったというか、関数型の思考で書きやすいように上手く設計されているんだな、と改めて感じました。

そうですね。
私は色々勉強させていただきました。ありがとうございました。

また何かアイデアがありましたら、ぜひぜひご提案ください！ 😄

[Kray-G]

Proposal

This is a current consideration about a function composition operator.

Overview

The operator +> and <+ for function composition.
This is based on the JavaScript proposal at https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition.

Implementation

Strategy

1. Introducing _functional_pipe2 and _functional_compose2. The name might be changed although.
2. The expression of a +> b basically means a syntactic sugar of _functional_pipe2(a, b).
   This will be evaluated from the left to the right.
3. The expression of a <+ b basically means a syntactic sugar of _functional_compose2(a, b).
   This will be evaluated from the right to the left.

Simple Case

_functional_pipe2

This function should be implemented as below at least.

_function _functional_pipe2(f1, f2) {
    return { &(a) => f2(f1(a)) };
}

_functional_compose2

This function should be implemented as below at least.

_function _functional_compose2(f1, f2) {
    return { &(a) => f1(f2(a)) };
}

Desugaring Example

For the pipe, here is an example.
It will be evaluated from the left to the right.

// var f = a +> b +> c +> d;
var f = _functional_pipe2(_functional_pipe2(_functional_pipe2(a, b), c), d);

For the composition, here is an example.
It will be evaluated from the right to the left.

// var f = a <+ b <+ c <+ d;
var f = _functional_compose2(a, _functional_compose2(b, _functional_compose2(c, d));

This should be actually same as below.

// var f = a <+ b <+ c <+ d;
// var f = _functional_compose2(a, _functional_compose2(b, _functional_compose2(c, d));
var f = _functional_pipe2(_functional_pipe2(_functional_pipe2(d, c), b), a);

Fiber as a Generator

When it is Fiber, I assume the pipeline will be expected to yield and pass an item one by one.
So the combination of those have to be separatedly thought.
Here is my consideration for those combinations.
By the way, this example is also including the case that the first item is not a function.

// Fiber -> Fiber
_function _functional_pipe2_ff(f1, f2) {
    return new Fiber { &(a)
        f1.reset();
        while (true) {
            var r1 = f1.resume(a);
            if (!f1.isAlive()) {
                break;
            }
            f2.reset();
            while (true) {
                // all items are passed to the next fiber one by one.
                var r = f2.resume(r1);
                if (!f2.isAlive()) {
                    break;
                }
                // passing the value to the next one by one.
                yield r;
            }
        }
    };
}
// Fiber -> function
_function _functional_pipe2_f1(f1, f2) {
    return { &(a)
        var r;
        f1.reset();
        while (true) {
            var r1 = f1.resume(a);
            if (!f1.isAlive()) {
                break;
            }
            // all items are passed to the next function.
            r = f2(r1);
        }
        return r;
    };
}
// function -> Fiber
_function _functional_pipe2_f2(f1, f2) {
    return new Fiber { &(a)
        var r1 = (!f1.isFunction && !f1.().isFunction) ? f1 : f1(a);
        f2.reset();
        while (true) {
            // the same value is passed until the end of the next fiber.
            var r = f2.resume(r1);
            if (!f2.isAlive()) {
                break;
            }
            // passing the value to the next one by one.
            yield r;
        }
    };
}
// Checking a combination.
_function _functional_pipe2(f1, f2) {
    // with Fiber
    if (f1.isFiber && f2.isFiber) {
        return _functional_pipe2_ff(f1, f2);
    }
    if (f1.isFiber) {
        return _functional_pipe2_f1(f1, f2);
    }
    if (f2.isFiber) {
        return _functional_pipe2_f2(f1, f2);
    }
    // value -> function
    if (!f1.isFunction && !f1.().isFunction) {
        return { &(a) => f2(f1) };
    }
    // function -> function
    return { &(a) => f2(f1(a)) };
}

For the composition, the order to be evaluated will be only changed.
Here is the implementation example.

_function _functional_compose2(f1, f2) {
    return _functional_pipe2(f2, f1);
}

Conclusion

According to the above scenario, the expected result in the combination of multiple generators by Fiber will be the following.
This means the last function will be assumed to be called 15 times.

var count = 0;
var range = new Fiber { &(n)
    for (var i = 0; i < n; i++) {
        yield i;
    }
};
var fbb = new Fiber { &(n)
    yield [++count, ["foo", n]];
    yield [++count, ["bar", n]];
    yield [++count, ["baz", n]];
};

// 5 |> range +> fbb +> { &(x)=>System.println(x) };
const what = _functional_pipe2(_functional_pipe2(range, fbb), { &(x)=>System.println(x) });
what(5);

Here is an actual expected result.

[1, ["foo", 0]]
[2, ["bar", 0]]
[3, ["baz", 0]]
[4, ["foo", 1]]
[5, ["bar", 1]]
[6, ["baz", 1]]
[7, ["foo", 2]]
[8, ["bar", 2]]
[9, ["baz", 2]]
[10, ["foo", 3]]
[11, ["bar", 3]]
[12, ["baz", 3]]
[13, ["foo", 4]]
[14, ["bar", 4]]
[15, ["baz", 4]]

If you have any idea or question, please let me know.
Thanks in advance.