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/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' だけを型パラメータにしていることを問題視している

**デフォルトの名無しさん** · 2025/02/22(土) 00:16:39.92

>>194
>一般的に型は静的に扱えるなら静的に扱える方が有利
コンパイル時に検査できるものはすればいい

>コンテナも制約を受けるとわかっているならなぜそちらも型パラメータにしないのか？
>フィールド 't' だけを型パラメータにしていることを問題視している
コンテナが制約を受けるのか値が制約を受けるのかは、単に構文と処理系の実装の問題。意味的にはどちらも制約を受ける
変数aの型によって動作が変わる関数を、a.foo()と書く仕様にしようがfoo(a)にしようがどちらでもいいのと同じ

というか「必要性がわからない」なら、首を突っ込まなきゃいいのでは

**デフォルトの名無しさん** · 2025/02/22(土) 00:26:40.81

>コンテナも制約を受けるとわかっているならなぜそちらも型パラメータにしないのか？

あなたがそうしたけりゃそうすりゃいいだけの話
「集合Gは群であるとする」といっている人に対して、
「群構造は二項演算*、単位元e、逆演算・^(-1)にも依存するのに、なぜ(G, *, e, ・^(-1))と書かないのか」とか言っているようなもん
そう書きたきゃそう書けばいい
俺はめんどくさいからそうしないだけ

**デフォルトの名無しさん** · 2025/02/22(土) 00:28:08.00

バカだから不利となる動的生成しようとしてるのだろう
そのケースは静的で済む

**デフォルトの名無しさん** · 2025/02/22(土) 00:31:03.33

>>197
静的で済むならそれでいいじゃん
型なんだから

**デフォルトの名無しさん** · 2025/02/22(土) 00:34:02.62

型を動的に生成する、つまり実行時に決まる値に型が依存していても、コンパイル時に検査できる場合はある

ということが分かっていない？

**デフォルトの名無しさん** · 2025/02/22(土) 00:36:50.14

>>195
収容するコンテナ型Cと一意となるフィールドの型Fの二つの型パラメータを持つ型となるため、
CとFの両方が必要ですね。
CもFも様々な型を取り得るため、
二つとも必須となります。

**デフォルトの名無しさん** · 2025/02/22(土) 00:37:58.92

たとえばList nで長さnのリストを表すとする
nが実行時に決まる値だったとしても、関数
concat: List n -> List m -> List (n + m)
の型はコンパイル時にチェックできる

**デフォルトの名無しさん** · 2025/02/22(土) 00:39:25.47

>>200
うん
だから、そう書きたきゃそう書けばいいじゃん

**デフォルトの名無しさん** · 2025/02/22(土) 00:42:20.87

>>201
いずれもList型なので、
そのケースは静的に型が定まっていますね。

**デフォルトの名無しさん** · 2025/02/22(土) 00:45:02.92

正直、あなたの意図がよくわからない
こちらの言っていることが理解できないのか、わざわざこんな辺鄙なスレでよく分からん難癖をつけるのが楽しいのか

**デフォルトの名無しさん** · 2025/02/22(土) 13:49:24.39

型を動的に作るなんて、RailsのActiveRecordとかごく一般的に行われていることだと思うが

**デフォルトの名無しさん** · 2025/02/22(土) 14:03:06.41

>>205
それはRubyがスクリプト言語に過ぎなくて動的型付け言語だからだよ
まともな普通の言語は静的型付け言語なのでActiveRecordのようなO/Rマッピングも静的型付け

**デフォルトの名無しさん** · 2025/02/22(土) 14:54:10.02

>>206
そもそも動的型付け言語・静的型付け言語なんてものはない。
型検査をコンパイル時に行うかどうかは、処理系の実装方法に過ぎない。
また、型が実行時の値に依存していても、コンパイル時に検査することは可能（>>201）

あなたは前提知識が足りてなさすぎる

**デフォルトの名無しさん** · 2025/02/22(土) 15:46:05.77

言語のセマンティクスと実装は分けて考えるべき

**デフォルトの名無しさん** · 2025/02/22(土) 15:57:38.39

>>207
あなたが混同してる
型検査をコンパイル時に行うかどうかは規格、セマンティクスの領分で
実行時の値とされているものを静的にチェックできる範囲でチェックして警告を出したりするのは実装の領分だろう

**デフォルトの名無しさん** · 2025/02/22(土) 16:05:21.30

>>207
その両者は明確に分かれてる
動的型付け言語は実行の途中で初めて型が確定しうる
静的型付け言語は必ず実行前に全ての型が定まる
これらは言語仕様で定まる

静的型付け言語は型の安全性やパフォーマンスに優れている
C/C++, Fortran, Go, Haskell, Java, OCaml, Pascal, Rust, Scala, Swiftなど
スクリプト言語以外は静的型付け言語が多数派

**デフォルトの名無しさん** · 2025/02/22(土) 16:35:21.85

>>209
>型検査をコンパイル時に行うかどうかは規格、セマンティクスの領分で
>実行時の値とされているものを静的にチェックできる範囲でチェックして警告を出したりするのは実装の領分だろう
>>207はまさにそう言っているのだが

**デフォルトの名無しさん** · 2025/02/22(土) 16:51:46.18

もうブログかなんかに書いててくれないか

**デフォルトの名無しさん** · 2025/02/22(土) 16:53:22.31

静的型付け言語はその言語仕様により
常に全ての型を静的に(＝実行前に)確定できる
これは言語仕様により定まることであり実装とは関係ない

**デフォルトの名無しさん** · 2025/02/22(土) 16:54:54.90

妄想乙

**デフォルトの名無しさん** · 2025/02/22(土) 17:46:21.34

実行速度の速い言語がすべて静的型付けな点が答えだろうね
素人向けのスクリプト言語は動的型付けで遅い

**デフォルトの名無しさん** · 2025/02/22(土) 18:03:51.25

>>210
しれっとHaskell混ぜるなってのw

**デフォルトの名無しさん** · 2025/02/22(土) 19:31:02.81

馬鹿が常駐して終わったスレ
さよなら

**デフォルトの名無しさん** · 2025/02/22(土) 20:19:25.50

無意味な動的型付けにこだわってるのは一人だけだから無視すればよいだけかと
型推論の進歩により静的型付けの唯一の弱点も消えた
型指定を省略できるクロージャなどその典型例

**デフォルトの名無しさん** · 2025/02/22(土) 22:50:21.56

>>218
> 動的型付けに拘ってる
書かれていることを正しく読もう

**デフォルトの名無しさん** · 2025/02/22(土) 22:56:32.72

>>187は動的型付けとは何ら関係がない
むしろ、直後に指摘されているようにほとんどのケースでコンパイル前に検査できる

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

型が第一級オブジェクトの言語は、論理学でいえば命題を量化できる二階述語論理に相当するわけだ

**デフォルトの名無しさん** · 2025/02/23(日) 03:10:06.06

f x = 10
g y = 20
h z = 30
h . g . f 10 -- 30

**デフォルトの名無しさん** · 2025/02/23(日) 03:10:58.23

hの定義内で途中の計算結果10, 10, 20を参照するにはどうするか

**デフォルトの名無しさん** · 2025/02/23(日) 04:40:15.50

トランポリン

**デフォルトの名無しさん** · 2025/02/23(日) 06:54:06.73

h z x y = 30にする

**デフォルトの名無しさん** · 2025/03/09(日) 23:01:10.03

>>223
途中を参照したいなら関数の返り値を複数にして返していく
途中を表示したいなら関数を副作用アリにする

**デフォルトの名無しさん** · 2025/03/14(金) 17:25:51.81

S式
(+ 1 (* 2 3))

RPN
1 2 3 * +

CPS
1 >> (x ->
2 >> (y ->
3 >> (z ->
(y * z) >> (m ->
(x + m))))))

Do記法
x <- 1
y <- 2
z <- 3
m <- y * z
x + m

**デフォルトの名無しさん** · 2025/06/17(火) 21:17:24.66

はぁ？　クロージャって何すか？
クローゼットのことですか？

プログラマ「もういい」