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/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属性つきオブジェクトへの関数、を持ち上げる関数書けばモナドになるから自動的に変換できるんだな

**デフォルトの名無しさん** · 2024/02/26(月) 22:39:42.49

そもそもオブジェクトの型を動的に判定することは不可能なのだ
ただのシンボル'0'が整数であるとは数学的に決して言えない
整数の性質を満たす集合に属しているから整数と言えるのだ
だからオブジェクトが型を授かるためにクラスは絶対に必要なのだ

**デフォルトの名無しさん** · 2024/02/26(月) 22:55:13.16

そもそもふだんそんなにポリモーフィズムしてるか？
型ヒント書いたら実行前にチェックできるとか、中間コードにコンパイルされる時高速になるとか、それでよくないか？

**デフォルトの名無しさん** · 2024/02/26(月) 22:58:38.34

モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除している
それぞれの言語は全く異なる方針を採っているがクラス排除だけは全てで一致している
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている

**デフォルトの名無しさん** · 2024/02/26(月) 23:36:19.27

xの型がT
y = Foo(x)なら
yの型はFoo(T)

というシステムでいいと思うの

Length ::= Float
Angle ::= Float
Point ::= Tuple(Float, Float)
Triangle ::=
Triangle(Length, Length, Length)
| Triangle(Length, Length, Angle)
| Triangle(Length, Angle, Angle)
| Triangle(Point, Point)

**デフォルトの名無しさん** · 2024/02/26(月) 23:50:16.48

>>57
前半はそのとおり
だがクラスは不要
変数の出自が辿れればいい

**デフォルトの名無しさん** · 2024/02/27(火) 00:02:52.99

クラスは不要で型クラスは必要

**デフォルトの名無しさん** · 2024/02/27(火) 06:56:00.52

Natural = fn
　[0] 0
　[n: n >= 0] n
end

succ = fn [Natural(n)] Natural(n + 1) end

add = fn
　[n, Natural(0)] n
　[n, succ(m)] succ(add(n, m))
end

mul = fn
　[n, Natural(0)] Natural(0)
　[n, succ(m)] add(mul(n, m), n)
end

AdditiveMonoid = Monoid()
AdditiveMonoid.implimentsIdentity(Natural, fn [] Natural(0) end)
AdditiveMonoid.implimentsAppend(Natural, add)

MultiplicativeMonoid = Monoid()
MultiplicativeMonoid.implimentsIdentity(Natural, fn [] Natural(1) end)
MultiplicativeMonoid.implimentsAppend(Natural, mul)

**デフォルトの名無しさん** · 2024/02/27(火) 11:48:35.86

たしかに「この関数から返ってたらこの型」というのはそうか
インタフェース型を返す関数から返った値は、その実体がなんであってもインタフェース型として受け取らないといけないのか

**デフォルトの名無しさん** · 2024/02/27(火) 14:07:25.42

Pythonの型ヒントも、内部的にやってることは型の階層構造を保存したオブジェクト作ったりしてるだけだし、型をクロージャで表すというのは十分に現実的

**デフォルトの名無しさん** · 2024/02/28(水) 09:15:01.79

なんでもクロージャでは構造に基づくサブタイピングができないから、ポリモーフィズムするなら必然的に名前に基づくサブタイピングをする必要がある

**デフォルトの名無しさん** · 2024/02/28(水) 18:59:36.77

型注釈はクロージャで実現できるけど、肝心の個別のオブジェクトに型を付与するには、処理系に手加えないと無理だね

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

ただのクロージャにこれはLinkedListだみたいな型情報をつけるなら

JavaScriptのようにすべてのオブジェクトがフィールドを持てるようにして、クロージャもtype属性みたいなのを持てるようにする

Pythonのように__call__()メソッドを実装すればオブジェクトも関数として呼び出せるようにして、オブジェクトにラップする

おとなしくにハッシュテーブルにラップするとかして、関数としてのインタフェースを保つのは諦める

**デフォルトの名無しさん** · 2024/02/28(水) 22:56:39.74

型定義

Counter = Type(fn [n]
　fn [i] n += i end
end)
f = Counter(0)
f is Counter # true
f(1) # 1
f(2) # 3
f(3) # 6

エイリアス

Adder = Counter
f is Adder # true

多相型

Pair = Type(fn [T, S]
　fn [t: T, s: S] (t, s)
end)

p = Pair(Int, Str)(1, 'Hello')
p is Pair(Int, Str) # true

**デフォルトの名無しさん** · 2024/02/28(水) 23:27:14.87

クロージャはその外の変数をキャプチャできてこそ本領を発揮する

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

実行のたびに無名関数を生成すると
Pair(Int, Str)の実体が毎回変わってしまう
同じ型として扱うならキャッシュしとかんといかん

Foo()の結果がFoo型になるので、自然にヒエラルキー

Pair(Int, Str) ⊂ Pair ⊂ Type

ができる

子はすべての親を知っているが、親は直接の子しか知らない

**デフォルトの名無しさん** · 2024/02/29(木) 21:57:07.71

ユニオン型

Male = Type()
Female = Type()
Sex = Male | Female

代数的データ型

Nil = Type()
Cons = Type(fn
　[T] fn [x: T, xs: List(T)] (x, xs) end
end)
List = Type(fn [T] Nil | Cons(T) end)

c = Cons(Int)(1, Nil())
c is Cons(Int) # true

nl = Nil()
nl is Nil # true
nl is List(Int) # ( = Nil | Cons(T) ) true

l = Cons(2, c)
l is List(Int) # true

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

クロージャは

(1) 評価可能な任意のコードブロックをオブジェクト化できる
(2) 新しいコンテクストを導入できる
(3) 評価を遅延可能
(4) 即時生成可能

**デフォルトの名無しさん** · 2024/03/01(金) 13:47:12.10

クロージャは、評価可能な任意のコードブロックを第一級オブジェクトとして扱える

継続は、プログラム実行時の任意の状態と処理を第一級オブジェクトとして扱える

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

欠点は何？

**デフォルトの名無しさん** · 2024/03/01(金) 16:27:28.29

>>75
汎用的な制御構造として使うには難解すぎること

**デフォルトの名無しさん** · 2024/03/01(金) 17:06:01.87

継続を入れ子にするともう予測不可能になる

**デフォルトの名無しさん** · 2024/03/02(土) 00:04:51.39

言語の高速化は処理系の仕事なのだから、特定の処理系で実行速度を最適化するために冗長な書き方を強いられるのは馬鹿げている

**デフォルトの名無しさん** · 2024/03/02(土) 00:15:28.02

型がクロージャなら例外もクロージャで表現できそう

**デフォルトの名無しさん** · 2024/03/02(土) 01:38:33.15

>>76
そこはシンタックスシュガー用意できる？

**デフォルトの名無しさん** · 2024/03/02(土) 02:47:41.13

>>80
たとえばコルーチンとか、非決定的なバックトラックとかなら

**デフォルトの名無しさん** · 2024/03/02(土) 09:23:44.53

>>79
例外処理こそ継続とパターンマッチを使うべきだよなあと思う

**デフォルトの名無しさん** · 2024/03/02(土) 11:12:48.28

決定性のバックトラックなんてあるの？

**デフォルトの名無しさん** · 2024/03/02(土) 16:06:45.66

>>81
Pythonでいうとこのジェネレータ内包表記みたいなのがあれば、多くの場面で十分なのかな

**デフォルトの名無しさん** · 2024/03/02(土) 19:52:13.99

>>84
コルーチンの中でコルーチンを呼び出したら、yieldしたら最上位の呼び出し元まで返ってくるのが望ましい

**デフォルトの名無しさん** · 2024/03/02(土) 21:01:52.57

>>85
非同期コルーチンAの中で非同期コルーチンBを呼ぼうとしたら自動的にAはyieldして戻ってからコルーチンBを呼び出し
そのBについても全て終えるか他コルーチン呼び出しで自動的にyield
それぞれyieldして待機中の非同期コルーチンは呼び出し先が解決するとyield時点から再開
というスタックレス非同期コルーチンが何万も稼働しています

**デフォルトの名無しさん** · 2024/03/03(日) 13:45:11.38

「コ」ルーチンなんだから上位という概念がそもそもない

**デフォルトの名無しさん** · 2024/03/03(日) 14:01:49.17

>>87
スタックレス非同期コルーチンは上位ランタイムがCPUコアスレッド数をフルに使って幾万個の軽い非同期コルーチンをスケジューリングすることでCPU性能を使い尽くすことができる

**デフォルトの名無しさん** · 2024/03/03(日) 14:47:38.82

的外れ

**デフォルトの名無しさん** · 2024/03/03(日) 14:53:35.32

的外れとは？
現在のネットインフラは>>88の通り動いている現実を認めたくない？

**デフォルトの名無しさん** · 2024/03/03(日) 17:03:12.55

>>87
あなたの言うコルーチンの定義は？

**デフォルトの名無しさん** · 2024/03/05(火) 13:01:59.74

スタックフルのコルーチンは、内部で呼び出したコルーチンがyieldしてるかどうか呼び出し元が知っていないといけない
つまりカプセル化を破壊する

**デフォルトの名無しさん** · 2024/03/05(火) 14:58:20.75

複数のスレッドが協調して何かするなんてのは、もはやプログラミング言語の領分じゃないんだよなぁ

**デフォルトの名無しさん** · 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

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