関数型プログラミング言語Haskell Part32

**デフォルトの名無しさん** · 2019/01/29(火) 09:05:47.90

関数型プログラミング言語 Haskell について語るスレです。

haskell.org (公式サイト)
https://www.haskell.org/
日本Haskellユーザーグループ
https://haskell.jp/

前スレ
関数型プログラミング言語Haskell Part31
https://mevius.5ch.net/test/read.cgi/tech/1506447188/

**デフォルトの名無しさん** · 2019/10/23(水) 02:29:17.74

>>609は書いてる途中で間違って送信してしまった

>>608
ああ、ちょっと筆（じゃなくてキーボード）が滑って簡単に書きすぎたね
確かに関手とか自然変換といった概念も圏論にはあるが、これらもある圏から見れば射や対象に過ぎない

いずれにしても圏論には値や関数や変数といった概念はない

**デフォルトの名無しさん** · 2019/10/23(水) 03:34:04.69

では何らかの制限がないと取り扱いが難しいよね
例えば英語と日本語の翻訳で使われる意味を咀嚼変換するロジックを圏論だと言われたら
なんか凄く難しそうだなとか

**デフォルトの名無しさん** · 2019/10/23(水) 07:48:02.01

別に集合論だって写像の集合を考えればいいわけでそんなのは圏論を持ち出さなくても十分
重要なのは圏論は写像の合成(関数合成)を抽象化して扱う理論だということで
だからこそa -> IO bを射とする圏を作れればそこでの射の合成方法は普通の関数合成と同じように扱える
で実際にIOはクライスリトリプル(Monadのインスタンス)を定義できるからa -> IO bを射とするクライスリ圏が定義できる

**デフォルトの名無しさん** · 2019/10/23(水) 15:46:04.24

質問です。
当方数学科卒で学生時代圏論は死ぬほど使ってました。
しかしアーベル圏という純数学的なお話知ってるだけで、計算論に応用する話は全く勉強した事ない状態です。
そういう人間が圏論の計算論への応用を勉強したいときオススメの教科書、参考書は何かご存知ですか？
抽象圏論や数学基礎論も少しかじった事があるのでその手の話が出てきてもあまり困る事はないと思ってます。

**デフォルトの名無しさん** · 2019/10/23(水) 18:37:44.76

そこまで圏論に詳しいなら逆に世の中の有象無象の情報処理の実態を
見て新しい提案ができるんじゃないかと思うけどどう？

**デフォルトの名無しさん** · 2019/10/23(水) 18:48:53.05

型推論とモナドがわかったら解散でいいじゃん
だらだら続けるとサンクコストが増える

**デフォルトの名無しさん** · 2019/10/23(水) 20:01:33.78

浮動小数演算みたいなある種のモナド則が成り立たんものを考えると、
逆にモナド則のありがたさがわかる。
そんな程度で十分だよ。

**デフォルトの名無しさん** · 2019/10/23(水) 22:29:52.97

どちらかと言えば、モノイドの方が役に立つ

**デフォルトの名無しさん** · 2019/10/23(水) 22:51:28.42

浮動小数点のモナド？
モナド則の結合律っぽい奴は普通の関数で言うなら
f (g x) == (f . g y) x を要請してるのであって
f,gの計算には依存しないから浮動小数点が破壊することはないよ

**デフォルトの名無しさん** · 2019/10/23(水) 22:55:47.94

ミス f (g x) == (f . g) x だった

**デフォルトの名無しさん** · 2019/10/24(木) 01:14:02.96

f x = x / 0.3
g x = x * 0.3

**デフォルトの名無しさん** · 2019/10/24(木) 01:19:57.43

ghci でやってみたら循環小数にならなかった。macOSの電卓でも。
へぇ～。

**デフォルトの名無しさん** · 2019/10/24(木) 01:57:21.20

>>613
> そういう人間が圏論の計算論への応用を勉強したいときオススメの教科書、参考書は何かご存知ですか？
> 抽象圏論や数学基礎論も少しかじった事があるのでその手の話が出てきてもあまり困る事はないと思ってます。

理論計算機科学（以下、TCSと略）への圏論の応用を勉強したいのならば、最もベーシックなテキストとしては

1. Andrea Asperti & Giuseppe Longo: Categories, Types, and Structures, 306+xii pp., MIT Press (1991)
型理論として単純型付きλ計算と２階の型付きλ計算それぞれに対する圏論的意味論を議論している他、
型無しλ計算の意味論を展開する上で不可欠な再帰的領域方程式とその解に対する圏論的な見方も解説している。
更にHaskellなどで喧しいモナドやKreisel圏についても解説している。（関数プログラミング言語へのモナドの応用は
本書の著者の１人であるLongoの論文から全てが始まった）
この本の最大の欠点は誤植がとても多いことと昔のMacで書かれていてテキスト中の数式も図も美しくないことだ。
なお、現在は書籍としては品切れになっていたと思うが、著者のHPから電子的に無料で入手可能になっていたはずなのでネットで探して下さい。

2. Roy L. Crole: Categories for Types, 335+xvii pp., Cambridge University Press (1993)
様々な型理論（型理論は(関数)プログラミング言語とその型システムを形式的体系としたものと考えて良い）に対する圏論的意味論を議論している。

3. 横内寛文：プログラム意味論，261+vi pp.，共立出版 (1994)
久しく品切れになっていたが少し前に増刷されたので現在はジュンク堂などの大型書店などの店頭で買えるはず。
表示的意味論、型無し・型付きλ計算、領域理論、関数型言語の意味論について１つずつ章を設けて解説した後、この本で必要とする圏論の解説がされ、
プログラミング言語の表示的意味論で必須の再帰的領域方程式とその解法に対する圏論からのアプローチと
λ計算の意味論としてλモデル・λ代数・圏論的モデルとしてのCCC（デカルト閉圏あるいは積閉包圏）について解説している。

この他にもTCSへの圏論の応用としてはオートマトン理論への応用や代数的仕様記述言語の意味論への圏論の応用
（こちらの意味論ではデカルト閉圏は使われない）などがある。

**デフォルトの名無しさん** · 2019/10/24(木) 02:41:27.79

>>622訂正と補足

まず1に関する説明中の次の箇所を訂正します。つい筆が滑ってKleisliをKreiselと書いてしまった。

誤> 更にHaskellなどで喧しいモナドやKreisel圏についても解説している。（関数プログラミング言語へのモナドの応用は
正> 更にHaskellなどで喧しいモナドやKleisli圏についても解説している。（関数プログラミング言語へのモナドの応用は

それから、

> なお、現在は書籍としては品切れになっていたと思うが、著者のHPから電子的に無料で入手可能になっていたはずなのでネットで探して下さい。

と書いたが、無料の電子版は著者の一人であるLongoの次のURLよりPDFファイルの形で配布されている。

https://www.di.ens.fr/users/longo/files/CategTypesStructures/book.pdf

**デフォルトの名無しさん** · 2019/10/24(木) 09:09:56.34

>>618
浮動小数においては
(a+b)+c != a+(b+c)
なんだよ。

**デフォルトの名無しさん** · 2019/10/24(木) 19:35:38.99

>>624
だからこそ「モナド則の結合律のこと言ってるの？あれは関数合成的な話だから関係ないよ」
って言ってるんだけど
ああもしかして>>616は結合律一般について言ってるのか？
それならアスペみたいなこと言って悪かった
いやまさか四則演算の結合律の便利さから
printFile file = readFile file >>= putStrLn
printFile == readFile file >>= putStrLn
になることの利点を理解しろという主張だとは思わなかったからさ・・・

**デフォルトの名無しさん** · 2019/10/24(木) 19:42:56.62

いやモナド則で語ることなんて結合律以外ないだろ。。
結合律を無条件で仮定できる状況がどれほど負担を減らすかって話なんだが
ここまでバカな絡まれ方するとは思わなかった。

**デフォルトの名無しさん** · 2019/10/24(木) 19:50:34.49

ああ、printFile file == readFile file >>= putStrLn だった
しかもそれも誤解しか生まない表現で
要はreadFile file >>= putStrLnをprintFileで置き換えても問題ないってことを言いたかったんだけど
いやほんと5ch向いてないね

**デフォルトの名無しさん** · 2019/10/24(木) 20:08:28.59

>>627
なんか、あんたは気持ち悪いね

**デフォルトの名無しさん** · 2019/10/24(木) 20:16:05.76

>>626
いやほんと頭が悪くて申し訳ない
「足し算の結合律って便利でしょ？モナド則も結合律だから便利なんだよ」
こんな糞みたいな主張をする人間が世の中にいることぐらいは分かっておくべきだった

**デフォルトの名無しさん** · 2019/10/24(木) 20:22:28.52

単位元を語ってもええんやで

**デフォルトの名無しさん** · 2019/10/25(金) 04:29:07.52

>>629
前提として「足し算の結合律って便利だね」
じゃ足りないの
何が不足なのかな
副作用をモナドの結合連鎖外に及ぼさない事による恩恵が主目的じゃないの？
とくにマルチスレッドコア環境だと色々有難いよね
モナド連鎖の組み合わせとか組み替えとかがスカッとできてイイ！とか
連鎖の中で起きたエラーのリカバリーとかはよくわからん

**デフォルトの名無しさん** · 2019/10/25(金) 08:07:43.53

>>631
モナドが実際の所どれぐらい便利なのかは分からないけど
(m >>= f) >>= g == m >>= (\x -> f x >>= g)
が言ってることは単純なんだよ
>>=が普通の関数呼び出しのように使えるというだけ
$(普通の関数呼び出しを演算子化したもの)の場合を考えれば分かりやすいかな
g $ (f $ x) == (\y -> g $ (f $ y)) $ x
関数と値の引数が$と>>=では逆だから両辺が逆向きになってるけど
要するに二つの関数を一つの関数まとめても構わないという
誰もが当たり前にやってることの理論的基盤を>>=にも要請してるというだけなんだよ
だから getLine >>= printFile と getLine >>= readFile >>= putStrLn
が同じだと言うためにはこの結合律を満たさなきゃならない
ちなみに二個以上の関数をまとめ上げる場合や多引数の場合もこれで証明できる

**デフォルトの名無しさん** · 2019/10/25(金) 08:33:13.53

>>632
モナドの条件が成立すると色々便利な事は認識している
端緒の認識はそれで問題ないと思ったけど
便利だよねって見解が
>こんな糞みたいな主張をする人間が世の中にいることぐらいは分かっておくべきだった
って言われて、え？え？何かマズイ理解なり認識があるのか??
何がマズいのかワカラン??って感想
単純に罵倒してマウント取りたかっただけなら問題ない

**デフォルトの名無しさん** · 2019/10/25(金) 09:19:09.32

>>624見たとき何言ってんだコイツと思ったが案の定ボコされてて安心した
論理的な思考ができない人間って怖いわ

**デフォルトの名無しさん** · 2019/10/25(金) 11:27:36.73

>>624
>浮動小数においては
>(a+b)+c != a+(b+c)
>なんだよ。
まるめ誤差を考慮すればだけど
浮動小数点を引き合いにだして!=だってやった事か

**デフォルトの名無しさん** · 2019/10/25(金) 18:07:06.47

>>633
そこは売り言葉に買い言葉だったんじゃねーの。
俺は雑な主張はアリだと思うし、それに対する善意の解説もいいと思うぞ

**デフォルトの名無しさん** · 2019/10/25(金) 18:15:13.95

>>633
三段論法的なのが糞だって言ってるだけでその部分は別に間違ってないよ
まあマウンティングするつもりはないんだが
曖昧なこと言っといてそれについて意見したら「バカに絡まれた」なんて
そりゃ感情的にもなるよ確かに大人げないけどさ

**デフォルトの名無しさん** · 2019/10/25(金) 18:32:47.40

>>636
そう言ってくれるなら嬉しい限りだけど
最初のレスから反省する点が多すぎるのでもう消えます
スレのみなさんご迷惑をおかけしました😿

**デフォルトの名無しさん** · 2019/10/25(金) 19:57:54.15

まあかなり意地の悪い例を出したつもりではあったけどね。
「論理的思考」とか言い出す輩が引っかかりそうな例を。

**デフォルトの名無しさん** · 2019/10/25(金) 20:50:12.32

どうでもいいけど「論理的アルゴリズム」だったら簡単にコピーできそう
アルゴリズムとパラダイムの違いの一つは、コピーする自由

**デフォルトの名無しさん** · 2019/10/26(土) 00:21:14.14

モナドの話してる中で一人結合則全般についての話始めて浮動小数点数に関する当たり前の説明せっせとしてんのは草
小学校で習う掛け算も足し算もモナドみたいに便利だけど浮動小数点数はモナドと違って不便だねえ

**デフォルトの名無しさん** · 2019/10/26(土) 10:10:55.84

最近近隣スレで浮動小数点数で恥ずかしい書き込みを繰り返してる香具師を観かけたが
きっとCS知らない浮動小数点数覚えたての厨房が暴れてるんだろう

**デフォルトの名無しさん** · 2019/10/26(土) 10:22:10.08

素人なので確認したい
浮動小数点演算は計算式の組み替えによって生じる
計算ごとの丸め誤差とその蓄積が一意ではない
そこが問題。でいいですか？

**デフォルトの名無しさん** · 2019/10/26(土) 12:52:46.96

例えば、3桁の有限桁数で、

123,000 + 987 は、どうなると思う？w

**デフォルトの名無しさん** · 2019/10/26(土) 13:03:31.77

>>644
浮動小数点は実装の有効桁数とか精度誤差の複合なんですね
やっと理解できたとかも

**デフォルトの名無しさん** · 2019/10/27(日) 09:39:17.43

>>644
>123,000 + 987 は、どうなると思う？

合成や結合則との関係は？

**デフォルトの名無しさん** · 2019/10/27(日) 12:11:44.86

ヒント
(123000 + 987) + 456
123000 + (987 + 456)

**デフォルトの名無しさん** · 2019/10/27(日) 12:20:50.14

>647
有効桁数３の条件下では
443
443
で結合則？を満たしている

**デフォルトの名無しさん** · 2019/10/27(日) 14:13:05.51

>>647
ヒントなどと気取らず最初からその例を出せばいいのに…

>>648
整数計算で有効桁数という考え方はあまりしないとおもうし
計算途中の有効桁数範囲外の取り扱いを決めておかないと
なんとでも言えるような。JISにあったかな？

**デフォルトの名無しさん** · 2019/10/27(日) 20:56:25.06

>>649
最初からも何も最初言ったの俺じゃないし誰でも気づくだろ

**デフォルトの名無しさん** · 2019/10/28(月) 15:11:56.47

恥の上塗り

**デフォルトの名無しさん** · 2019/10/31(木) 16:11:16.19

最近のHaskellは末尾再帰形は当たり前として、余再帰形まで最適化するってマジ？

**デフォルトの名無しさん** · 2019/10/31(木) 19:47:56.88

モナドの話すると怒る人が一定数いるのに
最適化の話は難解でもすんなり受け入れられるのなんでだろう

**デフォルトの名無しさん** · 2019/10/31(木) 19:53:32.58

>>653
モナドとか関係なくあまりに馬鹿っぽいレスが怒られるだけ
例えば>>653もそう

**デフォルトの名無しさん** · 2019/10/31(木) 20:01:53.96

年寄りが自分の理解できないことをしゃべるなって
いっているだけでしょ。最適化はなんだかんだいっ
て実践もしくはなんとか理解できる範疇とかでは。

**デフォルトの名無しさん** · 2019/10/31(木) 20:08:46.83

例えば「馬鹿っぽい」の定義はモナドの定義よりもずっと複雑なんだよ
そのわりに「馬鹿っぽい」は難解すぎるという認識はほとんどない

**デフォルトの名無しさん** · 2019/10/31(木) 21:33:19.89

Haskellや圏論のモナドってライプニッツ由来？ギリシャ哲学由来？

**デフォルトの名無しさん** · 2019/10/31(木) 22:15:10.01

モナドの場合、「俺の理解は正しくて、お前の理解は間違ってる」てな話になりがちだから。

**デフォルトの名無しさん** · 2019/11/02(土) 11:54:49.10

>>622
お返事おくれて申し訳ありません。
時間作って是非挑戦みたいと思います。
ありがとうございました。

**デフォルトの名無しさん** · 2019/11/02(土) 21:23:26.95

【ぼくようメモ】

Haskellはマルチディスパッチをネイティブサポートしているので、
デザインパターンの一つ、Visitorパターンを気づかない内に使っている。

**デフォルトの名無しさん** · 2019/11/02(土) 22:57:22.40

Haskellを勉強するとどんなメリットが有りますか？

① Haskellを使って仕事する開発プロジェクトなんてものは世の中に有るのですか？
② ①が無いなら開発プロジェクトが無くても仕事の効率化などで、役立てる方法は有るのですか？
③ ②も無いなら、勉強して得た知識を日々のJava等の開発プロジェクトで役立てる方法は有るのですか？

**デフォルトの名無しさん** · 2019/11/02(土) 23:45:55.62

3かな。
コード書く際に
入出力部分と、ディターミニスティックな部分を選り分けるような書き方するようになった。

**デフォルトの名無しさん** · 2019/11/03(日) 00:23:07.97

>>661
世界に目を向ければ、Reddit でよく求人されてる

**デフォルトの名無しさん** · 2019/11/03(日) 07:05:59.77

>>662
>ディターミニスティック
？？
基本遅延評価なので即時評価とのより分？

**デフォルトの名無しさん** · 2019/11/03(日) 07:44:37.10

>>664
ディターミニスティック
決定論的な

IOが絡む非決定論的なコードと、引数と戻り値の関係が決まっている決定論的なコードとを、
しっかり分けて書けるようになったと言いたいのだろう。

要するに、副作用のあるコードと純粋なコードを分けるということだ。

**デフォルトの名無しさん** · 2019/11/03(日) 10:14:27.60

女心と秋の空はデバッグするのが難しいってことだ

**661** · 2019/11/03(日) 12:44:26.49

皆さんありがとうございます。

どうやら、あまり勉強する意味がなさそうに感じました。
なぜみなさんはこの言語をおやりになっているのでしょうか？
趣味でしょうか？

**デフォルトの名無しさん** · 2019/11/03(日) 12:48:35.08

まあ勉強する意味はないといえばないかな。
その当時盛り上がったってのが理由だったりするから趣味といえば趣味。
でもまあその言語がどういうところを気にして作られたかってのを
触って実感するってのはプログラム全般で役に立つと俺は思うけどね。

**デフォルトの名無しさん** · 2019/11/03(日) 13:13:12.24

Javaから初めて、Javaしか書いたことが無い人というのは再帰メソッドとして実装した方が良いものも、慣れていないし面倒くさいからという理由で再帰にしたがらない傾向が有ります。
Hakellを勉強した人間なら、そういうことが起こらないという利点が有るといいうことでしょうか？

**デフォルトの名無しさん** · 2019/11/03(日) 14:27:23.33

将棋の居飛車党と振り飛車党みたいなもん

**デフォルトの名無しさん** · 2019/11/03(日) 14:42:14.64

ループより再帰がいつも正しいわけではないでしょ
Javaなんだし
おれが仕事でやってるプロジェクトでは再帰は基本NGだよ

**デフォルトの名無しさん** · 2019/11/03(日) 15:00:10.66

ループと末尾再帰は等価(キリっω

**デフォルトの名無しさん** · 2019/11/03(日) 15:01:32.59

haskell学んでも、stack safeな再帰を書けるようになるわけでもないから、
haskellを学ぶ利点だとは思わない

理由を探さなきゃ学ぶ気になれないものには手を出さなければいいんだよ
CSの世界に限っても死ぬまでに学びきれないだけのネタがあるんだし

**デフォルトの名無しさん** · 2019/11/03(日) 16:32:47.09

『達人プログラマー』でも「毎年1つ新しい言語を学べ」と言っている
まあ凡人にそこまでは厳しくとも
たまに新しいプログラミング・パラダイムに触れることは
プログラマーにとって有益であると思うよ
それは知識として即効性のあるものというよりは(そういうのもあるかもしれないが)
1年2年経って効いてくるタイプのものかなと

**デフォルトの名無しさん** · 2019/11/03(日) 18:49:00.94

>>661
②かな
宣言的プログラミングの作法が身につく

普段Javaを使っているのなら、
最近のJavaは関数型プログラミングのシンタックスがかなり増えてきているので
Haskellで高階関数の使い方を理解しておくと、Javaプログラミングに直接的に役立つ

**デフォルトの名無しさん** · 2019/11/03(日) 19:10:14.85

宣言的プログラミングとは何ですか

**デフォルトの名無しさん** · 2019/11/03(日) 20:02:00.41

横レスだけど、そんなに役に立たないものなのか．．．
入門本買おうか悩んでたのに

**デフォルトの名無しさん** · 2019/11/03(日) 20:22:26.22

>>665
副作用ですか
Cのポインター辺りは副作用上等でトリッキーな事をしつつ記述してあるわけで
副作用と脆弱性に苦しんだ結果、RUST

Haskellの恐ろしい所はプログラムが何らかの高度な数学的アルゴリズムな場合があって
別途資料がないと全く理解できない
あっても以下略

**デフォルトの名無しさん** · 2019/11/03(日) 20:59:17.59

>>670

プロの世界では振り飛車は居飛車より勝ちにくいと言われますが、久保九段や菅井七段のようにそれを使って実践で勝つプロもいます。
アマの世界では振り飛車か居飛車かが直接勝敗に結びつくような高度な戦いができないので好きな方を選べばいいです。

ところが、ビジネスプログラミングの世界ではどうでしょうか？
残念ながら、手続き型プログラミング言語の開発プロジェクトしか存在しません。
関数型は使おうにも使う場所が無いのです。

**デフォルトの名無しさん** · 2019/11/03(日) 21:02:48.17

ないことはない
たとえIT土方業界であっても

**デフォルトの名無しさん** · 2019/11/03(日) 21:12:52.97

>>679
Javaだって宣言型にシフトしつつあるし、
最近のJavaScript(ECMAScript)は基本的に宣言型プログラミングだよ

宣言型プログラミング＝関数型プログラミングではない

**デフォルトの名無しさん** · 2019/11/03(日) 21:23:44.54

宣言型を変にもてはやす記事とかあるけどさ、
あれバグがあるときに凄まじくデバッグしにくいってことはちゃんと知っておいた方がいいぞ。

**デフォルトの名無しさん** · 2019/11/03(日) 21:26:11.59

>>682
それはいくらなんでもド素人すぎるだろう

**デフォルトの名無しさん** · 2019/11/03(日) 21:44:19.05

>>683
多分、君は論理プログラミングとか制約プログラミングについて理解してないんだろう。

**デフォルトの名無しさん** · 2019/11/03(日) 21:49:28.47

>>684
むしろそちらの方が専門に近いのですが、
どういうことか教えていただけますか？

◆QZaw55cn4c · 2019/11/03(日) 21:49:45.89

>>674
＞『達人プログラマー』でも「毎年1つ新しい言語を学べ」と言っている
新しい言語を一年に一つ、とは、これは厳しい縛りですね…

◆QZaw55cn4c · 2019/11/03(日) 21:51:15.76

>>679
＞久保九段
地元の棋士なので光速谷川氏とともに密かに応援してたりします

**デフォルトの名無しさん** · 2019/11/03(日) 21:59:29.92

>>685
横からだけど
凡人にとっては数学的な静的な関係を見つけ出すのはしんどいことが多い
副作用あろうが、ソースコードをステップ実行でトレースできる手続き型の方が
問題解析が楽ってことは往々にしてある

**デフォルトの名無しさん** · 2019/11/03(日) 22:04:59.57

>>686
ジャンプ漫画みたいな台詞すこ

「三つか四つはないと、暇を持て余してしまいます……」的な

**デフォルトの名無しさん** · 2019/11/03(日) 22:44:06.12

モナドって結局、計算効果Tをもたらすプログラム(T-プログラム)は
クライスリ圏をなすからクライスリトリプル(モナド)がT-プログラムの
合成規則として必要だから出てくる

**デフォルトの名無しさん** · 2019/11/03(日) 22:45:11.48

駄目な理系君の典型

**デフォルトの名無しさん** · 2019/11/03(日) 22:56:40.83

>>691
否定しないが結論としてはそうだぞ
モナドを利用したテクニックと登場する理由は違って当然じゃね？

**デフォルトの名無しさん** · 2019/11/03(日) 23:34:12.73

>>681

>Javaだって宣言型にシフトしつつあるし

どのような店を持ってシフトしているとおっしゃっているのか、例を教えていただけると嬉しいです。

**デフォルトの名無しさん** · 2019/11/04(月) 05:48:03.18

モナドの副作用云々は
Scala Monix の並列プログラミングも面白い

**デフォルトの名無しさん** · 2019/11/04(月) 06:29:33.14

>>678
恐ろしさというよりも
Haskellの仕様その他聞くと全く関係ない数学の話をしだす奴ばかりでカンファレンス途中で抜けてきたことがある
数学には全く興味ないんだがね
言っても聞きやしないこいつらとは合わないわと思った

**デフォルトの名無しさん** · 2019/11/04(月) 07:07:21.47

>>695
マジでHaskellは数学者が数学者の為にデザインしたみたいなものなので
ネット上のコードも数学的専門性に全振りしたものが普通にある
そんなのは数学の専門課程と無関係な人間には理解できない

だけど、英文の赤黒木を扱うHaskellのコードは恐ろしくスッキリ短くて
余分なノイズが少ない
全体の把握が楽だった、恐ろしく高密度かも
コメントで書く詳細説明≒Haskellのコード

**デフォルトの名無しさん** · 2019/11/04(月) 12:15:05.55

型の宣言だけならコードの中に埋め込むことはできた
だが数学の知識をすべて宣言するのは無理
だからコードを読みながら数学勉強しようと思ったら、わかることは静的型ばっかりだぞ

そもそも数学は広大過ぎてどこから手をつけるか迷うから静的型から始めるのは合理的

**デフォルトの名無しさん** · 2019/11/04(月) 20:52:45.92

数学の後ろ盾があるとよくわからない安心・万能感を錯覚し
これがよくわからない人を呼び寄せてしまう
この魅力はオカルトめいている
謎多き異性に惹かれてしまうのと似ている

**デフォルトの名無しさん** · 2019/11/04(月) 21:01:45.20

キモすぎてわろた

◆QZaw55cn4c · 2019/11/04(月) 21:05:02.30

>>696
＞赤黒木を扱うHaskellのコードは恐ろしくスッキリ短くて
＞余分なノイズが少ない

赤黒木がそんなに短くなるのですか？！
やっぱり haskell をがんがらなくては

**デフォルトの名無しさん** · 2019/11/04(月) 21:24:51.70

オカルトめいているのは数学でも言語でもない
人間の感情がオカルトめいているのだ

**デフォルトの名無しさん** · 2019/11/04(月) 21:59:28.69

>>700
英語の参考資料(ブラウザで翻訳しつつ
Red-Black Trees in a Functional Setting
ttps://pdfs.semanticscholar.org/7756/16cf29e9c4e6d06e5999116f777e431cafa3.pdf

◆QZaw55cn4c · 2019/11/04(月) 22:04:39.09

>>702
thx a lot !
英語は読めないのですが、想像していなかったくらいに簡潔ですね…

**デフォルトの名無しさん** · 2019/11/05(火) 17:15:35.86

PostgREST は Haskell のキラーコンテンツになれるか

**デフォルトの名無しさん** · 2019/11/05(火) 20:00:05.59

Haskellの代数的データ構造は、速度が低い方に引かれるけど、恐ろしく合理的な手法かも知れない
中身は基本Lispの構文糖衣相当だからLIST処理のコストがそのまま処理速度に反映される

ただ、数学者が数学者の為にデザインした分だけ優れた表現力をもっている

C++で
class TEST {int a, b, c}; が
Haskellでは
Test Int Int Int になって
関数の定義時に
add (Test x y z) =
z + y + z
関数定義で型指定と値を変数名に拘束して計算する

test = Test 1 2 3
add test
なんか凄い気がする

**デフォルトの名無しさん** · 2019/11/05(火) 20:14:52.01

Simon Peyton Jonesもなんかよくわからんけど関数型言語カッケーと思ったからやった
って言ってるくらいだからそういうのでいいんかもなとは思う。

**デフォルトの名無しさん** · 2019/11/05(火) 20:40:52.74

>>705
C++17なら、そこそこそれっぽく書けないか?
struct Test { int a, b, c; };
auto add(Test t) {
auto [x, y, z] = t;
return x + y + z;
}
auto test = Test{ 1, 2, 3 };
add(test);

**デフォルトの名無しさん** · 2019/11/05(火) 20:47:05.49

おっと、型定義はこっちのほうがそれっぽいか
#include <tuple>
using Test = std::tuple<int, int, int>;

**デフォルトの名無しさん** · 2019/11/05(火) 20:58:36.52

ええやん