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/03/05(火) 22:53:42.99

Erlang OTPみたいなアプローチが良いと思う

**デフォルトの名無しさん** · 2024/03/08(金) 23:46:15.42

重要なのはプロトコル
定められた型のメソッドを持つことが重要

**デフォルトの名無しさん** · 2024/03/11(月) 12:27:38.30

実装の継承は悪手

**デフォルトの名無しさん** · 2024/03/13(水) 21:40:17.77

関数とオブジェクトなんて、要はどっちも値を入れたら何かを返す箱なのだから、内部構造を考えなければ共通化できるはず
配列も、機能だけ見れば、キーが数値なだけのただのオブジェクト
リストやジェネレータなどをイテレートするのも、関数を引数なしで呼び出すようなもの

**デフォルトの名無しさん** · 2024/03/13(水) 23:38:55.71

Pythonは__call__()メソッドを実装することでオブジェクトも関数のように振る舞える
これは小規模なプログラムでは関数として実装しておき、大規模になったらシームレスに移行できるように

**デフォルトの名無しさん** · 2024/03/14(木) 18:36:51.37

Iterable⊂Callable⊃Associative

だが、Iterableとしての呼び出し方とAssociativeとしての呼び出し方が異なる

**デフォルトの名無しさん** · 2024/03/14(木) 18:40:46.10

x = [1, 2, 3]をIterableとしてCallableだと思う場合、x() = next(x)
AssociativeとしてCallableだと思う場合、x(n) = x[n]
になる

**デフォルトの名無しさん** · 2024/03/14(木) 21:09:23.66

マシン語を知らないと妙なこだわりを言い出すからおもしろいよなw

**デフォルトの名無しさん** · 2024/03/14(木) 23:24:02.50

異なる層の話を出すのもどうかと思うがね

**デフォルトの名無しさん** · 2024/03/15(金) 08:26:32.50

>>101
コンピュータサイエンスにおいて低レイヤーが上位という価値観があるのって、おそらく日本だけだと思うんだけど、どうしてこういう逆行現象が起こるんだろう？

**デフォルトの名無しさん** · 2024/03/15(金) 08:47:50.82

数学だと基礎論は馬鹿にされてるよね
通常の数学やるときに選択公理だとか不完全性定理だとかいってるのは素人だけ
そりゃ形式的に「基礎論のほうが原理に近い」というだけならべつに数学を知らなくても分かるからね

**デフォルトの名無しさん** · 2024/03/15(金) 08:56:58.18

>>103
マシン語わかる
でもコンピューターサイエンスの素養なし
って感じのロートルが必至にマウントとろうとしてるだけだろな

**デフォルトの名無しさん** · 2024/03/15(金) 09:01:28.78

ふつうは情報学科でも昔ならSICPでやったようなプログラミングの概念や機能に関する講義があるはずで、
ちゃんと勉強している人で実装と機能を分けて考えるということができない人はいないよ

日本で低レイヤーが偉そうな顔してるのは単に、大学等で体系的に学ばずに昔からパソコンに触ってただけのおじさんが言ってるだけ
日本ではプログラマが高等教育が必要な専門技術職として見なされておらず、パソコンしか取り柄のない社会不適合者を低賃金でこきつかう職種だと見なされていたのが原因

**デフォルトの名無しさん** · 2024/03/15(金) 09:10:45.64

>>104
物理学科の自称秀才がやたらと素粒子論専攻したがるのもこれだよなぁ……
実際に勉強して内容に興味を持てたかどうかではなくて、ラベルで判断してる
20過ぎた大人が将来の進路に関わる選択でそういうことするのは、病的としか言いようがない

**デフォルトの名無しさん** · 2024/03/15(金) 12:38:47.19

>>99
ってことは>>31の方法でも菱形継承問題ふつうに発生するやん

Iterable < Callable
__call__ = __next__

Associative < Callable
__call__ = __getattr__

Array < Iterable, Associative
__next__ = piyopiyo
__getattr__ = hogehoge

arr = Array(blahblahblah)
arr() はどっちになるべき？

**デフォルトの名無しさん** · 2024/03/15(金) 14:11:38.88

a) 実装継承
b) 多重継承
c) 多段階継承

ができる時点で菱形継承問題は避けられない
Rubyは、クラスは(b)を、モジュールは(c)を諦めることでこの問題を回避している

**デフォルトの名無しさん** · 2024/03/15(金) 14:37:43.94

>>108
pythonはそうだよ

**デフォルトの名無しさん** · 2024/03/15(金) 16:37:06.04

Rubyのrefinementsみたいに、このスコープでは型定義を変えるみたいなのがあればまだマシになんのかな
たとえば、あるブロック内でだけ(Int, Int)をPoint2Dとみなすとか

**デフォルトの名無しさん** · 2024/03/15(金) 17:16:49.88

>>108
・具象型とインタフェースを分ける
　具象型→Int, Str, List<T>など
　インタフェース→Comparable, Iterableなど
・多重継承したインタフェースで仮想でないメソッドに名前の重複があったらエラーにする

とするしかないのでは

**デフォルトの名無しさん** · 2024/03/15(金) 17:20:27.60

型とインタフェースは分けないと、たとえば

equal(x: Eq, y: Eq) -> bool

とか無意味になる
xとyには具体的な型が同じものが入ってほしいのに、Eqインタフェースを持っている型すべてを許容してしまう
ほんとうにやりたいのは

equal(x: T, y: T) -> bool where T: Eq

ということ

**デフォルトの名無しさん** · 2024/03/15(金) 17:33:55.76

型システムと並行性はむずかしいな
でも、言語がプログラマに好まれるかどうかってそんなとこにないと思うよ
一時期、高機能なタスクランナーやら単体テストフレームワークやらがたくさん出てきたけど、結局はnpm-scriptsとか言語標準のunittestライブラリに収束した

**デフォルトの名無しさん** · 2024/03/15(金) 17:40:58.53

powershellはプログラミング言語としてはbashよりもはるかに高機能だが、誰もあれで書きたいとは思わない

**デフォルトの名無しさん** · 2024/03/15(金) 18:11:48.66

>>108
inheritanceを型に対して行うのが間違いな気がする
Int x Intを、Point2DとRationalのサブクラスとしたとする
Point2DとRationalの両方に + を実装（前者にはベクトルとして、後者には有理数として）したとして、

(1, 2) + (3, 4)

はどうなるか？
それは結局、今(1, 2), (3, 4)をどの型だとみなしているかによるのであって、型Int x Intの与り知らぬところだ

**デフォルトの名無しさん** · 2024/03/15(金) 18:25:53.61

>>109
Mixinで多重継承問題回避できる理屈がよくわからんかったけど、今ようやっと理解できたわ

**デフォルトの名無しさん** · 2024/03/15(金) 18:31:58.44

>>113
結局Rustのトレイト境界が正解ということか

**デフォルトの名無しさん** · 2024/03/15(金) 19:43:07.16

>>109
Javaの場合は、クラスは(b)を、インタフェースは(a)を諦めている

**デフォルトの名無しさん** · 2024/03/15(金) 21:35:17.15

ダイヤモンド継承は、コンパイラが検出するのが正しい気がする
構文で回避するには、>>109みたく機能を制限するしかない
RustとHaskellはしてくれる

**デフォルトの名無しさん** · 2024/03/15(金) 21:53:50.95

まあ、でもプログラミング言語が人気になるかどうかは
>>114の言うように、処理系の完璧さではなく、実用のニーズに耐え得ることなんだろうな

**デフォルトの名無しさん** · 2024/03/15(金) 22:34:31.87

クロージャとオブジェクトが同等なのはわかったが、それよりもさらに強力な言語機能はないのか？

**デフォルトの名無しさん** · 2024/03/15(金) 23:30:35.88

継続

プログラマが直接触らないものとしては、ガベージコレクションとかレキシカルクロージャとかもそうかもね

**デフォルトの名無しさん** · 2024/03/16(土) 20:49:53.31

Eiffel、Delphi、C#なんかは菱形継承してもそれぞれに別名を与えて捌ける機能を持ってるが
オブジェクト指向自体が下火なのもあって、最近のやつはそこまで作り込まれてない感

**デフォルトの名無しさん** · 2024/03/16(土) 21:44:17.40

多重継承は名前がぶつかろうがそれ自体に問題は一切ない
抽象型から具象型への継承で実装継承でないならば区別できる限り問題は生じない

本質的な問題は実装継承であること
特にに具象型から具象型への継承が問題
これは多重かどうかに関係なく問題となる

**デフォルトの名無しさん** · 2024/03/16(土) 22:15:39.23

そもそもOOPにおける継承ってのは、数学的に破綻してるんだよ
>>116で述べているとおり
型定義にサブタイピングの実装方法が入るわけがない

**デフォルトの名無しさん** · 2024/03/16(土) 22:18:29.76

自然数 is a モノイド

と自然にみなす方法は2通りある
その方法は自然数の定義とは関係ない

**デフォルトの名無しさん** · 2024/03/16(土) 22:28:23.06

クラスが欠陥品なのは同意だが
クラスを捨てて型クラスを使えばよい

**デフォルトの名無しさん** · 2024/03/16(土) 22:30:52.34

行列式=1の2次正方行列が、
自分の型はM(2)なのか、GL(2)なのか、SL(2)なのかなんて知らんがな

**デフォルトの名無しさん** · 2024/03/16(土) 22:35:57.52

>>127の問題は型クラスやtraitでも発生するしなあ
C++で没になったconcept_mapのようなものを複数切り替えられる機能が求められる

**デフォルトの名無しさん** · 2024/03/19(火) 03:55:14.66

x: T where T: K where K: L where ...

のように高階の型や

fn(x: T) -> Type

のようにパラメータに依存する型などがいくらでも作れたらどんなことができるのだろうか

**デフォルトの名無しさん** · 2024/03/19(火) 22:24:36.99

>>131
具象型Tに対して抽象型Kの制約を課すところまでは普通として
抽象型Kに対して高階抽象型Lの制約を課すメリットが見つからなかった

代替の方法として高階とせずに
抽象型Kに対して同じレベルの抽象型Lの制約を常に課す宣言ができれば十分にみえる

**デフォルトの名無しさん** · 2024/03/20(水) 17:07:37.10

>>60
これを一般化したのが依存型やね
これが扱えると数学の証明を型で書ける

**デフォルトの名無しさん** · 2024/04/06(土) 13:15:05.66

なんでもラムダ
→なんでもオブジェクト
→なんでも型

**デフォルトの名無しさん** · 2024/04/07(日) 01:46:27.75

全称量化子は関数で
存在量化子はパターンマッチングで
表せるので、一階述語論理もラムダ式で書けそう

**デフォルトの名無しさん** · 2024/04/07(日) 05:29:44.44

書けるの意味がわからんな
書いてどうする？
カリー・ハワード対応とかチューリング完全と関係ある話か？

**デフォルトの名無しさん** · 2024/04/07(日) 06:21:18.75

存在命題とか背理法とか、仮定を仮引数にしたラムダ式を使えば、具体的に証明や値を構成しなくても所望のものを取ってこられるんだな

**デフォルトの名無しさん** · 2024/04/07(日) 07:33:56.22

それは理論的に不可能

**デフォルトの名無しさん** · 2024/04/07(日) 09:52:53.31

res = hoge()みたいにただ結果返すのと、
hoge((res) => doSomething())みたいに引数に結果入ってくるのと、何が違うんや

**デフォルトの名無しさん** · 2024/04/07(日) 10:45:31.26

まず、hogeが同期的でない場合は

res = hoge()

とは書けない
async/awaitのような機構が必要になる

またたとえば、エラーの場合は処理を分岐させたいような場合、

hoge(
(res) => doSomething(),
(err) => handleError())

のように拡張できる
ただし、内部でさらに同じようなことをやっているとコールバック地獄になる

**デフォルトの名無しさん** · 2024/04/07(日) 11:19:43.04

>>134
依存型のあるHaskellやLean4はとくにオブジェクト指向という感じはしない

**デフォルトの名無しさん** · 2024/04/07(日) 13:08:22.06

>>141
純粋関数型で、（クラスベースの）オブジェクト指向をやる意味は皆無だからな

**デフォルトの名無しさん** · 2024/04/07(日) 19:27:40.79

純関数型言語でなくても
モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない

それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている

**デフォルトの名無しさん** · 2024/04/07(日) 20:16:17.84

だからってduck typingはクラスよりさらに悪いと思うんだ

**デフォルトの名無しさん** · 2024/04/07(日) 20:37:39.53

>>144
だからクラスとダックタイピングを採用しない言語が増えているね

**デフォルトの名無しさん** · 2024/04/07(日) 21:18:11.49

ポエムはよそでやれ

**デフォルトの名無しさん** · 2024/04/08(月) 14:29:36.32

P∧Qの導入則は、P -> Q -> P∧Q
これは(P, Q)ならばP∧Qとも読めるし
Pを仮定したとき、QならばP∧Qとも読める

**デフォルトの名無しさん** · 2024/04/09(火) 18:44:27.40

限定継続（reset/shift）の動きが意味わかんない
resetで範囲絞ってる分call/ccより実用的には扱いやすいというのは分かるが、ローカルで見たらcall/ccのほうが直感的に思える

**デフォルトの名無しさん** · 2024/04/09(火) 23:18:54.13

実装の都合では？
フル機能の継続はそこまでのスタック全部を生かし続けないといけないし分岐できないといけないしで
スタック自体をOSの用意してくれるものとは別に自前で構成しないといけないしそうするとABIからなにからつらい

**デフォルトの名無しさん** · 2024/04/10(水) 01:07:10.63

内部で継続渡しに変換してるなら、フルの継続のほうが実装しやすいと思うけど
Schemeの場合、dynamic-windとかも実装しなきゃいかんからより複雑だろうけど

**デフォルトの名無しさん** · 2024/04/10(水) 03:30:06.71

継続渡しはスタック消費をクロージャで置き換えてるわけで、スタックを自前で用意してるのと同じようなもんでは

**デフォルトの名無しさん** · 2024/04/10(水) 04:04:38.17

会話が噛み合ってない

**デフォルトの名無しさん** · 2024/04/10(水) 09:16:26.52

いや割と噛み合ってる

**デフォルトの名無しさん** · 2024/04/10(水) 11:55:16.47

処理が

A → B → C → ...

とあって

A → ... → shift(fn k -> hoge) → B → ... → C → reset

とすると

k に処理 _ → B → ... → Cが束縛される
hogeを実行するとresetまでジャンプする
resetの値はhogeの値になる

なので、たとえばバックトラックがしたいなら、
戻ってきたい場所にshiftを設置して、
fn () -> k next_valueをスタックに積んで、
クロージャの内部でk current_valueを実行すればいい

**デフォルトの名無しさん** · 2024/04/10(水) 11:57:37.66

で、スタックから継続をpopして実行する関数を別に作って
選択肢がなくなったときはそれを呼べばいい

**デフォルトの名無しさん** · 2024/04/10(水) 16:24:50.24

カプセル化を破壊するのが前提なので、ものすごく気を遣う

**デフォルトの名無しさん** · 2024/04/10(水) 17:47:04.13

call/ccやreset/shiftの型はどうなるの？

**デフォルトの名無しさん** · 2024/11/11(月) 12:09:40.22

call/ccの型は

((T -> ⊥) -> T) -> T

これは、￢Tを仮定してTが導けるならTということ
つまり、直観主義論理に排中律を追加することに相当する

**デフォルトの名無しさん** · 2024/11/28(木) 14:50:39.31

first-class typeがあると、どのような抽象化が可能になるのか

**デフォルトの名無しさん** · 2024/11/28(木) 21:23:23.02

output_integer = input_string.filter(is_number).map(char_to_integer).sum()

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

何かしらんけどHaskell版

import Data.Char

outputInteger = getLine >>= return.sum.map digitToInt.filter isDigit

f = outputInteger >>= putStrLn.("sum = " ++).show -- IOな値は必ず >>= 経由で渡される。
>f
1a2b3
>sum = 6

do表記

f = do x <- outputInteger -- IOな値は必ず <- で束縛された変数経由で渡される。
　　　 putStrLn $ "sum = " ++ show x

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

代入をなくそう

n = 1ではなく

n: 1 (nは1である)
n: Nat (nは自然数である)

これを基礎とする

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

こうすればパターンマッチなどに統一性がとれるだろう

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

map digitToInt だと"1 2 3" = [1, 2, 3] は良いとして、"123" = [1, 2, 3] と１桁ずつになるので改良した

outputInteger = getLine >>= return.sum.map (read.filter isDigit).words

> f
11 22 33 -- Input
sum = 66
> f
1a1 22b k33 -- Input
sum = 66

**デフォルトの名無しさん** · 2024/11/29(金) 08:50:35.19

よそでやれ

**デフォルトの名無しさん** · 2024/11/29(金) 18:22:51.77

>>162
n: 1は、nを1で置き換えられるが
n: Natは、n≠Natなので
何か本質的に異なるものに思える

**デフォルトの名無しさん** · 2024/11/29(金) 18:26:10.93

具体的なデータ（1とか"Hello"とか）があれば、型が決まるわけでもない
たとえば、、1 + 1は加法モノイドとみれば2だけど、乗法モノイドとみれば1
ただ、前者とみなす慣習が圧倒的に多いに過ぎない

**デフォルトの名無しさん** · 2024/11/29(金) 19:14:30.73

具体型をなくして抽象型だけにするのは？

**デフォルトの名無しさん** · 2024/12/12(木) 18:30:39.23

Leanでは、Exists(fun x: A => p x)は長いから∃x: A, p xと書くらしいので、ラムダ式のシンタックスはさらに短くなる

**デフォルトの名無しさん** · 2024/12/12(木) 20:50:14.10

命題は型

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

>>144
duck typingもクラスも使わずにinterfaceを使うのが正解

**デフォルトの名無しさん** · 2024/12/13(金) 13:33:11.56

クラスのフィールドは全く不要な概念

**デフォルトの名無しさん** · 2024/12/13(金) 21:23:08.37

クラス自体が不要
クラスを排除したモダンなプログラミング言語が多数あることが何よりの証拠

**デフォルトの名無しさん** · 2024/12/19(木) 16:09:31.78

クロージャ指向から述語指向へ

**デフォルトの名無しさん** · 2024/12/25(水) 16:41:01.48

継続指向プログラミング

**デフォルトの名無しさん** · 2024/12/28(土) 22:32:57.19

T :: ((α -> β) -> α -> (_ -> (_, β)), _ -> _)
T = (S, R)

f :: α -> β
S f :: α -> (_ -> (_, β))
S f a = fn x: (R x, f a)

f :: α -> β, g :: β -> γ
S f :: α -> (_ -> (_, β))
S g :: β -> (_ -> (_, γ))
S g >>= S f a = fn x:
let
(x', b) = S f a x
in
(R x', g b)

**デフォルトの名無しさん** · 2024/12/29(日) 01:19:32.44

Category theory for programmers読む

**デフォルトの名無しさん** · 2025/02/04(火) 01:03:51.46

プログラムのすべての箇所で値が(val: a, cont: a -> r)みたいになってたら、
独立したコンテキスト間で状態を受け渡ししなきゃいけないような仕様変更があっても、

その状態を参照できる所の(state, cont1)をセーブポイントとして保存
で、その状態を共有したい所の(val, cont2)を保存してcont1を呼び出す
stateとvalから新しいvalを作ってcont2を呼び出す

とやればいいのか

**デフォルトの名無しさん** · 2025/02/04(火) 01:47:21.80

絶対にやめろ

**デフォルトの名無しさん** · 2025/02/04(火) 22:33:26.11

>>178
それクロージャと言う

**デフォルトの名無しさん** · 2025/02/05(水) 00:00:43.61

違うが

**デフォルトの名無しさん** · 2025/02/05(水) 18:33:33.62

継続は米田埋込み
C^op → (Set)^C

型は層
C^op→(Set)

任意の圏は米田埋込みで前層の圏に埋め込める
C→(Set)^(C^op)

**デフォルトの名無しさん** · 2025/02/05(水) 18:46:54.22

継続渡しへの変換は米田埋込み、な。
a: Aの代わりに、ka: (A -> R) -> Rを考える。

**デフォルトの名無しさん** · 2025/02/05(水) 18:51:06.97

継続渡しやコールバックは
全て高位関数としてクロージャを渡すことで統一化されている
クロージャだけを考えればよくなっている

**デフォルトの名無しさん** · 2025/02/05(水) 19:16:41.69

まあ、型Aのオブジェクトaを考える代わりに、A上の関数にaを適用する関数を考えるわけだから、そりゃたしかにそうだな

**デフォルトの名無しさん** · 2025/02/05(水) 22:52:10.46

```
callcc: ((α -> β**) -> α**) -> α**
callcc f = fun (k: α*) => f (fun (x: α) => (fun (_: β) => k x)) k
```

**デフォルトの名無しさん** · 2025/02/07(金) 22:18:25.29

動的に生成される型として、たとえば型 `t`をパラメータにとって、あるコンテナ内 `t` 型のフィールドの一意性を保証する型 `Unique t ` とかを考えてみる

**デフォルトの名無しさん** · 2025/02/07(金) 22:49:12.48

依存型なら、それもできる

**デフォルトの名無しさん** · 2025/02/20(木) 01:49:56.71

[0 1]
|> iterate ([a b] -> [b (a + b)])
|> map first
|> head 20

**デフォルトの名無しさん** · 2025/02/20(木) 23:57:19.54

>>187
その型を動的生成する必要性が全く感じられない
そして制約を受けるのはコンテナ側
例えば代入やプッシュが一意性を満たしているかどうかで成功と失敗に分かれるインターフェースとなる
つまりコンテナ側の制約導入拡張型となるのではないか

**デフォルトの名無しさん** · 2025/02/21(金) 09:55:06.25

>>190
> 必要性が全く感じられない
データベースのフィールドの一意性制約、ハッシュテーブルのキーの一意性など、いくらでもあると思うが

> 制約を受けるのはコンテナ側
意味的には当然、コンテナも値もともに制約を受けている
メソッドが名前空間に属しているのか、オブジェクトに属しているのかと変わらない
それをどう管理するのかは処理系の実装の問題

**デフォルトの名無しさん** · 2025/02/21(金) 19:25:08.97

「クロージャを引数にとってクロージャを返すクロージャ」を引数にとって「クロージャを引数にとってクロージャを返すクロージャ」を返すクロージャ

**デフォルトの名無しさん** · 2025/02/21(金) 20:11:13.15

make-stream head thunk := [cont] -> cont head thunk
head stream := stream ([head _] -> head)
rest stream := stream ([_ thunk] -> thunk [])

nat-from n := make-stream n ([] -> nat-from (n+1))

take 0 stream := []
take _ [] := []
take n stream := cons (head stream) (take (n-1) (rest stream))

**デフォルトの名無しさん** · 2025/02/21(金) 23:53:10.97

>>191
必要性は当然わかってる
しかし動的生成する必要性が全く感じられない
一般的に型は静的に扱えるなら静的に扱える方が有利

もう一つ
コンテナも制約を受けるとわかっているならなぜそちらも型パラメータにしないのか？
フィールド 't' だけを型パラメータにしていることを問題視している