Closures vs Objects

**デフォルトの名無しさん** · 2024/02/19(月) 20:39:15.91

It is well-known that closures and objects are equivalent. So are actors. Which one is the most fundamental?

よく知られたように、クロージャとオブジェクトは等価です。アクターも同様です。どの概念が最も基本的なのでしょうか？

**デフォルトの名無しさん** · 2024/02/19(月) 20:49:06.93

A closure is a function with state in the local scope.
An object also has methods and state which belong to its instance.
These are compatible with each other.

クロージャはローカル・スコープに状態をもつ関数です。
オブジェクトもまたそのインスタンスに属するメソッドと状態を持ちます。
これらは互いに互換性があります。

**デフォルトの名無しさん** · 2024/02/20(火) 09:36:12.34

オブジェクトは複数のメソッドを持てる

クロージャは関数をひとつしか返せない

オブジェクトの勝ち

**デフォルトの名無しさん** · 2024/02/20(火) 11:01:18.21

>>3
ハッシュテーブルに関数を追加して返すことで、複数のメソッドを返すことが可能
より柔軟に、オブジェクトとそれを操作する関数の組を返すこともできるし、無限個のメソッドをもったオブジェクトだって作れる
これらは書く対象によって使い分ければよいのであって、オブジェクトにメソッドが属しているのが常に最適とは限らない
たとえばイベントハンドラにコールバック関数として渡すような場合は、ひとつの関数として取得できたほうが便利

**デフォルトの名無しさん** · 2024/02/20(火) 23:29:16.13

クロージャのほうがprimitive
今時、高階関数やイテレータを書くのにわざわざデザインパターンとか使いたいかって話
クラスは、レキシカル環境つきオブジェクトだけが欲しくても必ず新しい名前空間が作られるし、単品で購入できない福袋みたいなもん

**デフォルトの名無しさん** · 2024/02/21(水) 05:55:14.17

二変数以上の関数のほとんどは、どの引数のオブジェクトに属しているともアプリオリには言えないし、オブジェクト指向は不自然
オブジェクトと引数は別物だし、もし関数を特定のオブジェクトに属するようにしたいなら、クロージャでラップすれば簡単にできる

**デフォルトの名無しさん** · 2024/02/21(水) 05:56:37.93

二変数以上の関数のほとんどは、どの引数のオブジェクトに属しているともアプリオリには言えないし、オブジェクト指向は不自然
オブジェクトと関数は別物だし、もし関数を特定のオブジェクトに属するようにしたいなら、クロージャでラップすれば簡単にできる

**デフォルトの名無しさん** · 2024/02/21(水) 10:09:33.92

2変数関数をクロージャにラップして1変数関数にしても、メソッドチェーンはできないよね

**デフォルトの名無しさん** · 2024/02/21(水) 10:29:18.43

[1, 2, 3, 4, 5]にメソッドが属してれば

[1, 2, 3, 4, 5]
.filter(hoge) # ←戻り値もオブジェクト
.map(piyo) # ←これも
.sum()

みたいにできるけど、配列がオブジェクトじゃなかったら

map([1, 2, 3, 4, 5], hoge)

の戻り値はただの配列なので、繰り返し関数適用するには、Lispみたいな醜い入れ子にするしかない

sum(
　map(
　　filter([1, 2, 3, 4, 5], hoge),
　piyo))

**デフォルトの名無しさん** · 2024/02/21(水) 12:32:59.23

>>8-9
これでどうよ

chain = (obj) => {
　return (f, ...args) => {
　　if (!f) return obj
　　return chain(f(obj, ...args))
　}
}

chain([1, 2, 3, 4, 5])(
　filter, (x) => x % 2)(
　map, (x) =>x * x)(
　sum)()
// => 35

**デフォルトの名無しさん** · 2024/02/21(水) 15:43:45.17

一時期メタプログラミングとかいって、動的にクラスやメソッドを作れるのがすごいって言われてたけど、クロージャをデータ構造として使うならそれは自明にできることでは

**デフォルトの名無しさん** · 2024/02/21(水) 16:28:56.20

やり方が複数ある場合は、一番綺麗に書けるコードを採用するのが基本

**デフォルトの名無しさん** · 2024/02/21(水) 22:54:29.50

入れ子にしなくても関数合成でいいのでは？
メソッドチェーンっぽく書くには
Reverse-application operatorってのもあるけど
個人的には関数合成のほうがスッキリしててすこ

https://ideone.com/gCWxLP
let hoge n = n mod 2 = 1
let piyo = ( * ) 2
let () = print_int (List.fold_left (+) 0 (List.map piyo (List.filter hoge [1;2;3;4;5])))

(* function composition *)
let (<<) f g x = f (g x)
let f = print_int << List.fold_left (+) 0 << List.map piyo << List.filter hoge
let () = f [1;2;3;4;5]

let (>>) f g x = g (f x)
let f = List.filter hoge >> List.map piyo >> List.fold_left (+) 0 >> print_int
let () = f [1;2;3;4;5]

(* @@ Application operator *)
let () = print_int @@ List.fold_left (+) 0 @@ List.map piyo @@ List.filter hoge [1;2;3;4;5]

(* |> Reverse-application operator *)
let () = [1;2;3;4;5] |> List.filter hoge |> List.map piyo |> List.fold_left (+) 0 |> print_int

**デフォルトの名無しさん** · 2024/02/22(木) 01:30:07.21

Forth で書いてよ

**デフォルトの名無しさん** · 2024/02/22(木) 08:01:15.94

>>13
カリー化のなせる技やね

**デフォルトの名無しさん** · 2024/02/22(木) 08:40:34.15

chainl = (obj) => {
　return (f, arg) => {
　　if (!f) return obj
　　return chainl(f(arg, obj))
　}
}

cons = (x, xs) => [x, xs]

foreach = (lst, f) => {
　if(!lst) return
　[x, xs] = lst
　f(x)
　foreach(f, xs)
}

linkedList =
　chainl(null)(
　　cons, 1)(
　　cons, 2)(
　　cons, 3)()

chainl(linkedList)(foreach, console.log)()
// 3
// 2
// 1

いろいろ書けるんだな

**デフォルトの名無しさん** · 2024/02/22(木) 10:55:42.37

カリー化もクロージャと可変長引数があればできるね

currying = (f, ...args) => (...rest) => f(...args, ...rest)

**デフォルトの名無しさん** · 2024/02/22(木) 11:04:45.60

これで、mapなどが

map(f, col)

と、関数を先にとる形でも、>>16のchainlを用いて

chainl([1, 2, 3, 4, 5])(
　currying(filter, (x) => x % 2))(
　currying(map, (x) => x * x))(
　sum)()

と書けるわけか

**デフォルトの名無しさん** · 2024/02/22(木) 11:11:29.91

いや、単にchainlを

chainl = (obj) => {
　return (f, ...arg) => {
　　if (!f) return obj
　　return chainl(f(...arg, obj))
　}
}

とすればいいのか

**デフォルトの名無しさん** · 2024/02/22(木) 12:04:47.68

クロージャの真価はコンテキストを導入できること

(let ((a 1) (b 2)) (+ a b))

((lambda (a b) (+ a b)) 1 2)

は等価
なので、上のa + bの変わりに関数を返却すれば独立したスコープの状態をもつ何かを作れる

クラスベースのオブジェクト指向でも同様だが、そのようなコンテキストのテンプレート（= class）は静的にしか作れない

**デフォルトの名無しさん** · 2024/02/22(木) 12:15:29.98

静的なほうがバグの発見は早そう

**デフォルトの名無しさん** · 2024/02/22(木) 13:03:51.54

なんでも自由を許すと無秩序になる
>>10だって、シグネチャを無視することが前提の設計になってる
（最後に結果を呼び出す時は第一引数のfを省略する）

TypeScriptが使われるのもそれが理由
今やPythonやRubyにも型がある

**デフォルトの名無しさん** · 2024/02/22(木) 13:23:57.40

くだらん
https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean

**デフォルトの名無しさん** · 2024/02/22(木) 13:24:08.05

型なんて、プログラマがちまちま書かずとも、コンパイラや型チェッカが実行前に検査してくれればいいと思う

**デフォルトの名無しさん** · 2024/02/22(木) 15:02:53.21

currying = (f) => {
　args = []
　apply = (a) => {
　　if (a === undefined) return f(...args)
　　args.push(a)
　　return apply
　}
　return apply
}

**デフォルトの名無しさん** · 2024/02/22(木) 18:39:34.82

クロージャはポリモーフィズムができない
オブジェクト指向言語ではたとえば比較演算子の動作を型によって変えられる
a.compare(b)とソースコードのどこに書いても、aの型に応じて適切にcompareの動きが選択される
変数の型によって実行する関数を変えるにはどうする？
まさか関数定義に型による条件分岐をいちいち書くわけじゃあるまいし

**デフォルトの名無しさん** · 2024/02/22(木) 19:07:57.79

class構文が入るまでどうやってJSでクラスを定義してたのか調べれば分かるよ

**デフォルトの名無しさん** · 2024/02/22(木) 19:20:20.77

>>27
a.hoge()のようにしてダックタイピングするなら当然できる
hogeがa（or a.prototype）に属さないただの関数の場合でも
hogeの中で型による条件分岐を書く以外の方法でできるか

**デフォルトの名無しさん** · 2024/02/22(木) 19:30:27.02

https://www.yunabe.jp/docs/javascript_class_in_google.html

**デフォルトの名無しさん** · 2024/02/22(木) 19:41:55.54

>>28
なんて？

**デフォルトの名無しさん** · 2024/02/22(木) 20:46:51.05

>>26,28
a, bではなくcompareのほうを、状態をもった関数オブジェクトとして生成する

一例として、

compareのクロージャには、「型名=>その型の引数を受け取った時に呼び出す関数」のテーブルを保持する
そのテーブルに関数を動的に登録するための関数を作成する

例:
IComparable = () => {
　dispatch = {}
　compare = (self, other) => { /*dispatchテーブルから関数を検索して実行*/ }
　implement = (type, fn) => { /* dispatchテーブルにfnを登録 */ }
　return [compare, implement]
}

もちろんdispatchの条件は型名じゃなくても、別の判定用関数を用意してもいい

**デフォルトの名無しさん** · 2024/02/22(木) 20:49:14.36

インタフェースの実装は、型定義に書くよりも使用時に動的にできた方が自然だ
たとえば木構造にイテレータを実装するとして、深さ優先探索にするのか幅優先探索にするのかは、その時々によって変わる。木構造の定義だけからは決まらない

**デフォルトの名無しさん** · 2024/02/22(木) 22:14:42.54

最近のフレームワークはどんどん脱オブジェクト指向・関数型化してないか？
Pythonのフレームワークは機能のMixinは継承ではなくデコレータ（ようはクロージャ）によるものが多い
Reactなんか思想は元々関数型的だったけど、ついにクラスコンポーネントやめちゃった

**デフォルトの名無しさん** · 2024/02/23(金) 00:14:17.41

cps = (f) => (...args) => args.pop()(f(...args))

eq = cps((a, b) => a === b)
sub = cps((a, b) => a - b)
mul = cps((a, b) => a * b)

fact = (n, k) => {
　eq(n, 0, (isZero) => {
　　if(isZero) {
　　　return k(1)
　　}
　　else {
　　　return sub(n, 1, (prevn) =>{
　　　　fact(prevn, (prevf) => {
　　　　　mul(n, prevf, k)
　　　　})
　　　})
　　}
　})
}

fact(5, console.log)

**デフォルトの名無しさん** · 2024/02/23(金) 13:52:03.15

Closures are functions with contexts.
Objects are structures with contexts.
A structure can have functions as its member, and vice versa.
So both are equal.

**デフォルトの名無しさん** · 2024/02/23(金) 19:20:29.47

オブジェクトよりも、クロージャよりも、第一級継続のほうが強い

**デフォルトの名無しさん** · 2024/02/24(土) 00:22:58.31

>>36
パフォーマンスは？

**デフォルトの名無しさん** · 2024/02/24(土) 06:28:09.62

>>37
1. ハードウェア/コンパイラの技術向上に期待する
2. ネックになる部分だけ最適化する
3. そもそもパフォーマンスが必要ならC++やRustなどで書く

**デフォルトの名無しさん** · 2024/02/24(土) 11:30:44.99

>>38
その回答、第一級継続関係無いやん。

**デフォルトの名無しさん** · 2024/02/24(土) 21:14:52.39

オブジェクトとクロージャが使えることは、コードブロック（+ ローカル変数）を第一級オブジェクトに持っているのだと思える
継続が第一級オブジェクトなのは、プログラム実行時の任意の状態が第一級オブジェクトということ

**デフォルトの名無しさん** · 2024/02/24(土) 21:42:30.15

>>40
継続使う場合のパフォーマンスは？

**デフォルトの名無しさん** · 2024/02/25(日) 00:23:07.77

>>41
昨日からどうした
なにか嫌なことでもあったか？

**デフォルトの名無しさん** · 2024/02/25(日) 09:10:18.70

継続はクロージャで表現されるけど、オブジェクトとクロージャが同値なら、オブジェクトによる表現もできるの？

**デフォルトの名無しさん** · 2024/02/25(日) 10:52:31.35

: fact dup
1 = if
    drop
  else
    dup 1- rot rot *
    swap recurse
  then
;

1 5 fact cr .

**デフォルトの名無しさん** · 2024/02/25(日) 11:03:04.14

インタフェースが静的に決まれば保守性はおちないと思う

**デフォルトの名無しさん** · 2024/02/25(日) 11:17:17.62

近年まれにみる良スレ

**デフォルトの名無しさん** · 2024/02/25(日) 11:28:28.39

>>31
これ継承の問題点を全部解消してる上に継承よりも強力だな

**デフォルトの名無しさん** · 2024/02/25(日) 16:27:53.33

ハァ？

**デフォルトの名無しさん** · 2024/02/25(日) 16:36:21.69

>>47
使いにくい上に動的ディスパッチとなっている
継承の問題点を解消している好例はRust
その上で使いやすく静的ディスパッチによる単相化も可能で速い

**デフォルトの名無しさん** · 2024/02/25(日) 17:38:12.08

>>49
どのへんが使いにくいのかがわからないし、動的ディスパッチだと何がよくないのかもわからない

Rustのほうが早いのはそりゃ当たり前

**デフォルトの名無しさん** · 2024/02/25(日) 17:55:13.30

>>43
できるだろうけど、継続自体が手続き/関数的な概念なので、オブジェクトによる表現をするメリットは少ないと思う

**デフォルトの名無しさん** · 2024/02/25(日) 19:51:34.20

継続とコルーチンなら、継続のほうがprimitiveなの？

**デフォルトの名無しさん** · 2024/02/25(日) 20:50:19.80

>>52
継続が第一級なら保存した継続を何度も呼び出せるが、コルーチンはyieldしたらもうその時点には戻れないので、継続のほうが根本的

**デフォルトの名無しさん** · 2024/02/26(月) 12:34:53.26

なんでもクロージャだと戻り値全部関数だけど、型情報を持つことはできる？
ディスパッチするのに必要だよね？

**デフォルトの名無しさん** · 2024/02/26(月) 15:19:09.55

>>54
type属性をもったオブジェクトとして返却すればいいんじゃないんですかね
それを毎回書きたくないなら、生成用関数を受け取って新しい生成用関数を返す関数

makeConstructor = (f) => (type, ...args) => {type: type, value: f(...args)}

みたいなのを使ってみてはどうでしょうか

**デフォルトの名無しさん** · 2024/02/26(月) 18:51:01.76

>>55
これ、オブジェクトからtype属性つきオブジェクトへの関数、を持ち上げる関数書けばモナドになるから自動的に変換できるんだな