Closures vs Objects (228ﾚｽ)
上下前次1-新
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
1: 2024/02/19(月)20:39 ID:VT95BnI9(1/2)調 AAS
It is well-known that closures and objects are equivalent. So are actors. Which one is the most fundamental?
よく知られたように、クロージャとオブジェクトは等価です。アクターも同様です。どの概念が最も基本的なのでしょうか？
129: 2024/03/16(土)22:30 ID:ajdJdfuW(3/3)調 AAS
行列式=1の2次正方行列が、
自分の型はM(2)なのか、GL(2)なのか、SL(2)なのかなんて知らんがな
130: 2024/03/16(土)22:35 ID:TBzj9DHS(2/2)調 AAS
>>127の問題は型クラスやtraitでも発生するしなあ
C++で没になったconcept_mapのようなものを複数切り替えられる機能が求められる
131(1): 2024/03/19(火)03:55 ID:5WuD+qyw(1)調 AAS
x: T where T: K where K: L where ...
のように高階の型や
fn(x: T) -> Type
のようにパラメータに依存する型などがいくらでも作れたらどんなことができるのだろうか
132: 2024/03/19(火)22:24 ID:TBPz9mXO(1)調 AAS
>>131
具象型Tに対して抽象型Kの制約を課すところまでは普通として
抽象型Kに対して高階抽象型Lの制約を課すメリットが見つからなかった
代替の方法として高階とせずに
抽象型Kに対して同じレベルの抽象型Lの制約を常に課す宣言ができれば十分にみえる
133: 2024/03/20(水)17:07 ID:yZelKyNv(1)調 AAS
>>60
これを一般化したのが依存型やね
これが扱えると数学の証明を型で書ける
134(1): 2024/04/06(土)13:15 ID:IRVxBt67(1)調 AAS
なんでもラムダ
→なんでもオブジェクト
→なんでも型
135: 2024/04/07(日)01:46 ID:HXZiHVf3(1)調 AAS
全称量化子は関数で
存在量化子はパターンマッチングで
表せるので、一階述語論理もラムダ式で書けそう
136: 2024/04/07(日)05:29 ID:FOjhJ4gr(1/2)調 AAS
書けるの意味がわからんな
書いてどうする？
カリー・ハワード対応とかチューリング完全と関係ある話か？
137: 2024/04/07(日)06:21 ID:ZeXbAXZK(1)調 AAS
存在命題とか背理法とか、仮定を仮引数にしたラムダ式を使えば、具体的に証明や値を構成しなくても所望のものを取ってこられるんだな
138: 2024/04/07(日)07:33 ID:FOjhJ4gr(2/2)調 AAS
それは理論的に不可能
139: 2024/04/07(日)09:52 ID:/E0pQilp(1)調 AAS
res = hoge()みたいにただ結果返すのと、
hoge((res) => doSomething())みたいに引数に結果入ってくるのと、何が違うんや
140: 2024/04/07(日)10:45 ID:thR/d4RZ(1)調 AAS
まず、hogeが同期的でない場合は
res = hoge()
とは書けない
async/awaitのような機構が必要になる
またたとえば、エラーの場合は処理を分岐させたいような場合、
hoge(
(res) => doSomething(),
(err) => handleError())
のように拡張できる
ただし、内部でさらに同じようなことをやっているとコールバック地獄になる
141(1): 2024/04/07(日)11:19 ID:0gYyGnNT(1)調 AAS
>>134
依存型のあるHaskellやLean4はとくにオブジェクト指向という感じはしない
142: 2024/04/07(日)13:08 ID:IfUr/96a(1)調 AAS
>>141
純粋関数型で、（クラスベースの）オブジェクト指向をやる意味は皆無だからな
143: 2024/04/07(日)19:27 ID:m+fa22Uj(1)調 AAS
純関数型言語でなくても
モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない
それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている
144(2): 2024/04/07(日)20:16 ID:mSidkHeO(1)調 AAS
だからってduck typingはクラスよりさらに悪いと思うんだ
145: 2024/04/07(日)20:37 ID:rmfTjPEc(1)調 AAS
>>144
だからクラスとダックタイピングを採用しない言語が増えているね
146: 2024/04/07(日)21:18 ID:E193nq4c(1)調 AAS
ポエムはよそでやれ
147: 2024/04/08(月)14:29 ID:LhsijIe9(1)調 AAS
P∧Qの導入則は、P -> Q -> P∧Q
これは(P, Q)ならばP∧Qとも読めるし
Pを仮定したとき、QならばP∧Qとも読める
148: 2024/04/09(火)18:44 ID:kKsSVHOb(1)調 AAS
限定継続（reset/shift）の動きが意味わかんない
resetで範囲絞ってる分call/ccより実用的には扱いやすいというのは分かるが、ローカルで見たらcall/ccのほうが直感的に思える
149: 2024/04/09(火)23:18 ID:Aro4tJCD(1)調 AAS
実装の都合では？
フル機能の継続はそこまでのスタック全部を生かし続けないといけないし分岐できないといけないしで
スタック自体をOSの用意してくれるものとは別に自前で構成しないといけないしそうするとABIからなにからつらい
150: 2024/04/10(水)01:07 ID:uPucvtCR(1)調 AAS
内部で継続渡しに変換してるなら、フルの継続のほうが実装しやすいと思うけど
Schemeの場合、dynamic-windとかも実装しなきゃいかんからより複雑だろうけど
151: 2024/04/10(水)03:30 ID:qIIVcoEj(1)調 AAS
継続渡しはスタック消費をクロージャで置き換えてるわけで、スタックを自前で用意してるのと同じようなもんでは
152: 2024/04/10(水)04:04 ID:nlTt4/RM(1)調 AAS
会話が噛み合ってない
153: 2024/04/10(水)09:16 ID:fNUeJXq8(1)調 AAS
いや割と噛み合ってる
154: 2024/04/10(水)11:55 ID:dXGnSmQj(1/2)調 AAS
処理が
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を実行すればいい
155: 2024/04/10(水)11:57 ID:dXGnSmQj(2/2)調 AAS
で、スタックから継続をpopして実行する関数を別に作って
選択肢がなくなったときはそれを呼べばいい
156: 2024/04/10(水)16:24 ID:gx493tSk(1)調 AAS
カプセル化を破壊するのが前提なので、ものすごく気を遣う
157: 2024/04/10(水)17:47 ID:uxnW16Zl(1)調 AAS
call/ccやreset/shiftの型はどうなるの？
158: 2024/11/11(月)12:09 ID:eaS0ivay(1)調 AAS
call/ccの型は
((T -> ⊥) -> T) -> T
これは、¬Tを仮定してTが導けるならTということ
つまり、直観主義論理に排中律を追加することに相当する
159: 2024/11/28(木)14:50 ID:D62ASfXP(1)調 AAS
first-class typeがあると、どのような抽象化が可能になるのか
160: 2024/11/28(木)21:23 ID:tgeVSyIQ(1)調 AAS
output_integer = input_string.filter(is_number).map(char_to_integer).sum()
161: 2024/11/28(木)22:26 ID:U97loGz8(1/2)調 AAS
何かしらんけど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
162(1): 2024/11/28(木)22:37 ID:iYyun2JN(1/2)調 AAS
代入をなくそう
n = 1ではなく
n: 1 (nは1である)
n: Nat (nは自然数である)
これを基礎とする
163: 2024/11/28(木)22:39 ID:iYyun2JN(2/2)調 AAS
こうすればパターンマッチなどに統一性がとれるだろう
164: 2024/11/28(木)22:59 ID:U97loGz8(2/2)調 AAS
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
165: 2024/11/29(金)08:50 ID:ZHbjuyaH(1)調 AAS
よそでやれ
166: 2024/11/29(金)18:22 ID:FvJq/OMC(1)調 AAS
>>162
n: 1は、nを1で置き換えられるが
n: Natは、n≠Natなので
何か本質的に異なるものに思える
167: 2024/11/29(金)18:26 ID:FXP1+9fo(1)調 AAS
具体的なデータ（1とか"Hello"とか）があれば、型が決まるわけでもない
たとえば、、1 + 1は加法モノイドとみれば2だけど、乗法モノイドとみれば1
ただ、前者とみなす慣習が圧倒的に多いに過ぎない
168: 2024/11/29(金)19:14 ID:lZOQa9Jb(1)調 AAS
具体型をなくして抽象型だけにするのは？
169: 2024/12/12(木)18:30 ID:XExKLUf8(1)調 AAS
Leanでは、Exists(fun x: A => p x)は長いから∃x: A, p xと書くらしいので、ラムダ式のシンタックスはさらに短くなる
170: 2024/12/12(木)20:50 ID:YVpGcPfJ(1)調 AAS
命題は型
171: 2024/12/12(木)22:51 ID:dX7jmuEY(1)調 AAS
>>144
duck typingもクラスも使わずにinterfaceを使うのが正解
172: 2024/12/13(金)13:33 ID:ObbUHrIh(1)調 AAS
クラスのフィールドは全く不要な概念
173: 2024/12/13(金)21:23 ID:ePsQGGMZ(1)調 AAS
クラス自体が不要
クラスを排除したモダンなプログラミング言語が多数あることが何よりの証拠
174: 2024/12/19(木)16:09 ID:RMYWDOZr(1)調 AAS
クロージャ指向から述語指向へ
175: 2024/12/25(水)16:41 ID:jsf4a+Fl(1)調 AAS
継続指向プログラミング
176: 2024/12/28(土)22:32 ID:U3Qq1irw(1)調 AAS
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)
177: 2024/12/29(日)01:19 ID:OIeguool(1)調 AAS
Category theory for programmers読む
178(1): 02/04(火)01:03 ID:63k9bOfa(1)調 AAS
プログラムのすべての箇所で値が(val: a, cont: a -> r)みたいになってたら、
独立したコンテキスト間で状態を受け渡ししなきゃいけないような仕様変更があっても、
その状態を参照できる所の(state, cont1)をセーブポイントとして保存
で、その状態を共有したい所の(val, cont2)を保存してcont1を呼び出す
stateとvalから新しいvalを作ってcont2を呼び出す
とやればいいのか
179: 02/04(火)01:47 ID:Juhgqulp(1)調 AAS
絶対にやめろ
180: 02/04(火)22:33 ID:W8jOB2Il(1)調 AAS
>>178
それクロージャと言う
181: 02/05(水)00:00 ID:ZsEHWtVQ(1)調 AAS
違うが
182: 02/05(水)18:33 ID:UzNcF0as(1)調 AAS
継続は米田埋込み
C^op → (Set)^C
型は層
C^op→(Set)
任意の圏は米田埋込みで前層の圏に埋め込める
C→(Set)^(C^op)
183: 02/05(水)18:46 ID:UvjLK8GW(1)調 AAS
継続渡しへの変換は米田埋込み、な。
a: Aの代わりに、ka: (A -> R) -> Rを考える。
184: 02/05(水)18:51 ID:2vUp1NTh(1)調 AAS
継続渡しやコールバックは
全て高位関数としてクロージャを渡すことで統一化されている
クロージャだけを考えればよくなっている
185: 02/05(水)19:16 ID:Osi5eBbZ(1)調 AAS
まあ、型Aのオブジェクトaを考える代わりに、A上の関数にaを適用する関数を考えるわけだから、そりゃたしかにそうだな
186: 02/05(水)22:52 ID:95phW+lE(1)調 AAS
```
callcc: ((α -> β**) -> α**) -> α**
callcc f = fun (k: α*) => f (fun (x: α) => (fun (_: β) => k x)) k
```
187(2): 02/07(金)22:18 ID:c5jjIiZy(1)調 AAS
動的に生成される型として、たとえば型 `t`をパラメータにとって、あるコンテナ内 `t` 型のフィールドの一意性を保証する型 `Unique t ` とかを考えてみる
188: 02/07(金)22:49 ID:OiS9SGfZ(1)調 AAS
依存型なら、それもできる
189: 02/20(木)01:49 ID:fXOi/Bb7(1)調 AAS
[0 1]
|> iterate ([a b] -> [b (a + b)])
|> map first
|> head 20
190(1): 02/20(木)23:57 ID:zXVkJcm2(1)調 AAS
>>187
その型を動的生成する必要性が全く感じられない
そして制約を受けるのはコンテナ側
例えば代入やプッシュが一意性を満たしているかどうかで成功と失敗に分かれるインターフェースとなる
つまりコンテナ側の制約導入拡張型となるのではないか
191(1): 02/21(金)09:55 ID:Ip3jb1gD(1)調 AAS
>>190
> 必要性が全く感じられない
データベースのフィールドの一意性制約、ハッシュテーブルのキーの一意性など、いくらでもあると思うが
> 制約を受けるのはコンテナ側
意味的には当然、コンテナも値もともに制約を受けている
メソッドが名前空間に属しているのか、オブジェクトに属しているのかと変わらない
それをどう管理するのかは処理系の実装の問題
192: 02/21(金)19:25 ID:NlF3aFif(1)調 AAS
「クロージャを引数にとってクロージャを返すクロージャ」を引数にとって「クロージャを引数にとってクロージャを返すクロージャ」を返すクロージャ
193: 02/21(金)20:11 ID:lKEY3ckS(1)調 AAS
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))
194(1): 02/21(金)23:53 ID:zYI+C5dr(1)調 AAS
>>191
必要性は当然わかってる
しかし動的生成する必要性が全く感じられない
一般的に型は静的に扱えるなら静的に扱える方が有利
もう一つ
コンテナも制約を受けるとわかっているならなぜそちらも型パラメータにしないのか？
フィールド 't' だけを型パラメータにしていることを問題視している
195(1): 02/22(土)00:16 ID:2igDN88l(1/7)調 AAS
>>194
>一般的に型は静的に扱えるなら静的に扱える方が有利
コンパイル時に検査できるものはすればいい
>コンテナも制約を受けるとわかっているならなぜそちらも型パラメータにしないのか？
>フィールド 't' だけを型パラメータにしていることを問題視している
コンテナが制約を受けるのか値が制約を受けるのかは、単に構文と処理系の実装の問題。意味的にはどちらも制約を受ける
変数aの型によって動作が変わる関数を、a.foo()と書く仕様にしようがfoo(a)にしようがどちらでもいいのと同じ
というか「必要性がわからない」なら、首を突っ込まなきゃいいのでは
196: 02/22(土)00:26 ID:2igDN88l(2/7)調 AAS
>コンテナも制約を受けるとわかっているならなぜそちらも型パラメータにしないのか？
あなたがそうしたけりゃそうすりゃいいだけの話
「集合Gは群であるとする」といっている人に対して、
「群構造は二項演算*、単位元e、逆演算・^(-1)にも依存するのに、なぜ(G, *, e, ・^(-1))と書かないのか」とか言っているようなもん
そう書きたきゃそう書けばいい
俺はめんどくさいからそうしないだけ
197(1): 02/22(土)00:28 ID:BHZ6xlR+(1)調 AAS
バカだから不利となる動的生成しようとしてるのだろう
そのケースは静的で済む
198: 02/22(土)00:31 ID:2igDN88l(3/7)調 AAS
>>197
静的で済むならそれでいいじゃん
型なんだから
199: 02/22(土)00:34 ID:2igDN88l(4/7)調 AAS
型を動的に生成する、つまり実行時に決まる値に型が依存していても、コンパイル時に検査できる場合はある
ということが分かっていない？
200(1): 02/22(土)00:36 ID:fju1Vmb5(1/2)調 AAS
>>195
収容するコンテナ型Cと一意となるフィールドの型Fの二つの型パラメータを持つ型となるため、
CとFの両方が必要ですね。
CもFも様々な型を取り得るため、
二つとも必須となります。
201(2): 02/22(土)00:37 ID:2igDN88l(5/7)調 AAS
たとえばList nで長さnのリストを表すとする
nが実行時に決まる値だったとしても、関数
concat: List n -> List m -> List (n + m)
の型はコンパイル時にチェックできる
202: 02/22(土)00:39 ID:2igDN88l(6/7)調 AAS
>>200
うん
だから、そう書きたきゃそう書けばいいじゃん
203: 02/22(土)00:42 ID:fju1Vmb5(2/2)調 AAS
>>201
いずれもList型なので、
そのケースは静的に型が定まっていますね。
204: 02/22(土)00:45 ID:2igDN88l(7/7)調 AAS
正直、あなたの意図がよくわからない
こちらの言っていることが理解できないのか、わざわざこんな辺鄙なスレでよく分からん難癖をつけるのが楽しいのか
205(1): 02/22(土)13:49 ID:3Aku5oEk(1)調 AAS
型を動的に作るなんて、RailsのActiveRecordとかごく一般的に行われていることだと思うが
206(1): 02/22(土)14:03 ID:o5bbno7I(1)調 AAS
>>205
それはRubyがスクリプト言語に過ぎなくて動的型付け言語だからだよ
まともな普通の言語は静的型付け言語なのでActiveRecordのようなO/Rマッピングも静的型付け
207(3): 02/22(土)14:54 ID:H7FLchaf(1)調 AAS
>>206
そもそも動的型付け言語・静的型付け言語なんてものはない。
型検査をコンパイル時に行うかどうかは、処理系の実装方法に過ぎない。
また、型が実行時の値に依存していても、コンパイル時に検査することは可能（>>201）
あなたは前提知識が足りてなさすぎる
208: 02/22(土)15:46 ID:IIYOJqnw(1)調 AAS
言語のセマンティクスと実装は分けて考えるべき
209(1): 02/22(土)15:57 ID:es3U9V0K(1)調 AAS
>>207
あなたが混同してる
型検査をコンパイル時に行うかどうかは規格、セマンティクスの領分で
実行時の値とされているものを静的にチェックできる範囲でチェックして警告を出したりするのは実装の領分だろう
210(1): 02/22(土)16:05 ID:W3fSq5/I(1/2)調 AAS
>>207
その両者は明確に分かれてる
動的型付け言語は実行の途中で初めて型が確定しうる
静的型付け言語は必ず実行前に全ての型が定まる
これらは言語仕様で定まる
静的型付け言語は型の安全性やパフォーマンスに優れている
C/C++, Fortran, Go, Haskell, Java, OCaml, Pascal, Rust, Scala, Swiftなど
スクリプト言語以外は静的型付け言語が多数派
211: 02/22(土)16:35 ID:N/T45y64(1)調 AAS
>>209
>型検査をコンパイル時に行うかどうかは規格、セマンティクスの領分で
>実行時の値とされているものを静的にチェックできる範囲でチェックして警告を出したりするのは実装の領分だろう
>>207はまさにそう言っているのだが
212: 02/22(土)16:51 ID:1JZL08Pv(1/2)調 AAS
もうブログかなんかに書いててくれないか
213: 02/22(土)16:53 ID:W3fSq5/I(2/2)調 AAS
静的型付け言語はその言語仕様により
常に全ての型を静的に(＝実行前に)確定できる
これは言語仕様により定まることであり実装とは関係ない
214: 02/22(土)16:54 ID:1JZL08Pv(2/2)調 AAS
妄想乙
215: 02/22(土)17:46 ID:GOJ2wF4D(1)調 AAS
実行速度の速い言語がすべて静的型付けな点が答えだろうね
素人向けのスクリプト言語は動的型付けで遅い
216: 02/22(土)18:03 ID:NU7N7MY+(1)調 AAS
>>210
しれっとHaskell混ぜるなってのw
217: 02/22(土)19:31 ID:wKCHVlKT(1)調 AAS
馬鹿が常駐して終わったスレ
さよなら
218(1): 02/22(土)20:19 ID:FTk8qZlg(1)調 AAS
無意味な動的型付けにこだわってるのは一人だけだから無視すればよいだけかと
型推論の進歩により静的型付けの唯一の弱点も消えた
型指定を省略できるクロージャなどその典型例
219: 02/22(土)22:50 ID:bh0ZAEWN(1/2)調 AAS
>>218
> 動的型付けに拘ってる
書かれていることを正しく読もう
220: 02/22(土)22:56 ID:bh0ZAEWN(2/2)調 AAS
>>187は動的型付けとは何ら関係がない
むしろ、直後に指摘されているようにほとんどのケースでコンパイル前に検査できる
221: 02/23(日)02:25 ID:tIjZB/Ol(1)調 AAS
型が第一級オブジェクトの言語は、論理学でいえば命題を量化できる二階述語論理に相当するわけだ
222: 02/23(日)03:10 ID:ojjdIlYs(1/2)調 AAS
f x = 10
g y = 20
h z = 30
h . g . f 10 -- 30
223(1): 02/23(日)03:10 ID:ojjdIlYs(2/2)調 AAS
hの定義内で途中の計算結果10, 10, 20を参照するにはどうするか
224: 02/23(日)04:40 ID:upqukZrZ(1)調 AAS
トランポリン
225: 02/23(日)06:54 ID:jtLYghc/(1)調 AAS
h z x y = 30にする
226: 03/09(日)23:01 ID:eGDnXODc(1)調 AAS
>>223
途中を参照したいなら関数の返り値を複数にして返していく
途中を表示したいなら関数を副作用アリにする
227: 03/14(金)17:25 ID:TOg9uiCJ(1)調 AAS
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
228: 06/17(火)21:17 ID:66zQf9l5(1)調 AAS
はぁ？ クロージャって何すか？
クローゼットのことですか？
プログラマ「もういい」
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.025s