関数型プログラミング言語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/03/09(土) 09:51:28.74

haskell入門ほぼ読んだけどちょっと物足りなくてもうすこしhaskell勉強したい欲がある(目的は競プロとか月並みにaiとか)
なんかええ本ある？数学の高速なライブラリとか圏論、モナドの解説あるやつで(数学は拒絶反応しない)
get programming with haskellとか並行並列とか多少気になってるけどどう？

**デフォルトの名無しさん** · 2019/03/09(土) 10:30:48.34

初心者を抜けた後、実践へ進みたいのなら幾つか勧められる本はある。

しかし、更なる勉強がしたいのなら、勧められる本はない。
初心者用か、初心者を抜けたばかりの者にはまだ難しい本しかない。
特に君の目的(競プロやAI)に叶う本は今のところ皆無だ。

なので、ネットを漁れ。

あと質問がやや曖昧で、何を求めているのか分からん。
数学の高速なライブラリの何を求めてる？
それを自作できる知識なのか？
活用する知識なのか？
もしくは、仕組みが知りたい具体的なライブラリでもあるのか？

圏論やモナドにしても然り。
それらの何が知りたいのか具体的に言ってみ。

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

>>220
具体的には数学書のような理論本ですね今のところ全然数学臭さがないので(コンピュータとは乖離してるかもしれないけど)
速度に関しては、命令型の書き方でないのでどうすれば速度が出る書き方が出来るかが一番興味あります
ai,競プロはやるとしたときの足掛かりが気になりました
このみっつのどれかが掘り下げられれば幸いです。

**デフォルトの名無しさん** · 2019/03/09(土) 11:19:03.37

THUNKとかWHNFとかだろうけど
俺もここら辺の本とかあるなら読んでみたい

**デフォルトの名無しさん** · 2019/03/09(土) 11:28:44.92

>>221
「数学書のような理論本」悪いが意味が分からん。
具体的に「何が知りたいのか」を言ってくれ。
理論と言うのが大雑派すぎる。

速度を上げる方法を学びたいのなら、
・Haskell High Performance Programming
・関数プログラミング珠玉のアルゴリズムデザイン
この2つが正にうってつけだが、
「Haskell入門をほぼ読んだ」段階では挫折しそう。

AI や競プロは前レスでも言ったが本は無い。
AI は reinforcement leaning や deep leaning など技術範囲を絞ったワードと
haskell を組み合わせたキーワードでネット検索。

競プロは実際の競技で提出されたソースをたくさん読んで真似しろ。

**デフォルトの名無しさん** · 2019/03/09(土) 11:50:40.66

>>223
どうもありがとうございます。図書館で覗いてみます
具体的には、数学との関わりを体系だって書いてる書籍を探してましたが、そりゃ個々のキーワードで探す方が手っ取り早くて色々漁れますわな

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

競プロにHaskellはどうなんだ…？
良くわからんけどSTモナド使いまくる感じになるのかな
あるいは珠玉のアルゴリズムを理解仕切った超人達の集まりなのか

**デフォルトの名無しさん** · 2019/03/09(土) 13:43:47.24

>>221,223
珠玉のアルゴリズムデザインへの入門としては同じ著者の
『Haskellによる関数プログラミングの思考法』
(旧版名は『関数プログラミング入門 ―Haskellで学ぶ原理と技法―』)
がいいと思う
他の入門書よりは数学色が強いし
等式変形によって効率を改善していく運算も割と丁寧に扱っていると思う

あとは『純粋関数型データ構造』とかも参考になるかも？
ただ競プロならSTRefとかSTUArrayとかに習熟するほうが
手っ取り早いし有力かも

**デフォルトの名無しさん** · 2019/03/09(土) 13:49:45.09

>>225 >>226
例えば AtCoder の参加者のコードを見てみると分かるが、
STモナドなんて使ってるヤツはいない。
そもそも、haskell に慣れたら、STモナドなんて使いにくいだけだろ。
競プロみたいな短く速いコードを書く必要があるなら尚更。

珠玉本を理解しきった者かどうかは知らんが、
極端に短いコードで解いてくるヤツは、
どちらかといえば数学の知識が豊富なんじゃないかな。
問題文を数学の世界に落とし込む事に長けているように見える。

コンテストにもよるが、競技プログラミングは
個人的にはアルゴリズム力よりも数学力がより大事だと思ってる。
例えば Project Euler の高番号問題をシンプルに解けるヤツは競技も強そう。

**デフォルトの名無しさん** · 2019/03/09(土) 15:47:05.82

>>226 >>227
どうもありがとうございます。StateとかSTは内部処理はよくわからないけど便利なので使い方おぼえておきたいとこですね

**デフォルトの名無しさん** · 2019/03/09(土) 20:50:02.63

珠玉本難解すぎる
登場する学生達が天才過ぎる

**デフォルトの名無しさん** · 2019/03/10(日) 04:06:11.50

>>229
それでも理解したいのなら質問すればいい

**デフォルトの名無しさん** · 2019/03/14(木) 01:49:52.87

instance head ってよく聞くけど、
これは instance 宣言のどの部分のこと？

例えば次の宣言の場合
instance (Foo a) => Bar (Baz a b) | a -> b where

・(Foo a)
・Bar (Baz a b)
・Bar (Baz a b) | a -> b
・instance キーワードと where キーワードの間の全部
・その他

どれ？

**デフォルトの名無しさん** · 2019/03/14(木) 02:00:29.34

>>231
すまん、instance 宣言に関数従属は無いよな。

改めて、

instance (Foo a) => Bar (Baz a) where

この例だとどこが instance head なんだ？

**デフォルトの名無しさん** · 2019/03/14(木) 08:32:21.91

>>231
自己解決した。

instance head は => より右側かつ where より左側の部分だった。

スレ汚してすまない。

**デフォルトの名無しさん** · 2019/03/20(水) 22:23:43.02

HaskellのGUI(Gtk2hs)でカウンター作ってみた。

import Graphics.UI.Gtk

main = do
initGUI
window <- windowNew
set window [windowTitle := "counter", containerBorderWidth := 10]
mainbox <- vBoxNew True 5
containerAdd window mainbox
label <- labelNewWithMnemonic "0"
boxPackStart mainbox label PackNatural 0
countbtn <- buttonNewWithLabel "Count"
clrbtn <- buttonNewWithLabel "Clear"
boxPackStart mainbox countbtn PackNatural 0
boxPackEnd mainbox clrbtn PackNatural 0

widgetShowAll window
onClicked countbtn (labelGetLabel label >>= \n -> labelSetText label (show (1 + (read n))))
onClicked clrbtn (labelSetText label "0")
onDestroy window mainQuit
mainGUI

**デフォルトの名無しさん** · 2019/03/20(水) 22:24:12.70

label <- labelNewWithMnemonic "0"
boxPackStart mainbox label PackNatural 0
countbtn <- buttonNewWithLabel "Count"
clrbtn <- buttonNewWithLabel "Clear"
boxPackStart mainbox countbtn PackNatural 0
boxPackEnd mainbox clrbtn PackNatural 0

widgetShowAll window
onClicked countbtn (labelGetLabel label >>= \n -> labelSetText label (show (1 + (read n))))
onClicked clrbtn (labelSetText label "0")
onDestroy window mainQuit
mainGUI

**デフォルトの名無しさん** · 2019/03/20(水) 22:24:33.45

boxPackStart mainbox countbtn PackNatural 0
boxPackEnd mainbox clrbtn PackNatural 0

widgetShowAll window
onClicked countbtn (labelGetLabel label >>= \n -> labelSetText label (show (1 + (read n))))
onClicked clrbtn (labelSetText label "0")
onDestroy window mainQuit
mainGUI

**デフォルトの名無しさん** · 2019/03/21(木) 05:11:02.25

コマンドラインでエンターを押すごとに数字が増えていく(Ctrl+C押すまで止まらない)
Haskellコード

main = mapM_ (\n -> print n >> getLine) [0..]

out:
0
1
2
3
4

**デフォルトの名無しさん** · 2019/03/21(木) 22:17:24.35

急にどしたんww

gtk2hsのドキュメントがHackageから消えてるのは気のせい？

**デフォルトの名無しさん** · 2019/03/21(木) 22:23:19.66

なかなかGHC8.8出ないね

**デフォルトの名無しさん** · 2019/03/21(木) 23:42:33.25

無限ポップアップ上げるやつ現れないとは高尚なスレ
リストで遅延評価使うのがなかなかハスケルっぽい

**デフォルトの名無しさん** · 2019/03/22(金) 06:11:43.80

一応、カウンターみたいなのは純粋関数型言語には作れない言われてたから、作ってみた。
確かにi++みたいな事は出来ないが、違う方法で参照透明性を確保しつつ実現出来ると実感。
(個人的にHaskellには副作用はあると考えているが、参照透明性は崩れないとも考えている)

**デフォルトの名無しさん** · 2019/03/22(金) 07:23:09.19

そりゃ副作用はあるよ。
じゃなきゃIO処理できない。

haskell の特徴は純粋な関数から副作用のある関数を呼べないこと。

**デフォルトの名無しさん** · 2019/03/22(金) 07:32:41.43

うい。
そう言う仕組みになってるくせに、IOな関数も扱いとしては純粋な関数と同じ扱いなのが気に入ってます。
(型に気をつけていれば自然とそうなるし、普通にprint関数と純粋関数を関数合成出来るのが好き)

**デフォルトの名無しさん** · 2019/03/22(金) 07:54:45.66

純粋関数型言語でカウンタが作れないというのは、
同じ関数を呼び出した結果がカウントアップされるような関数のこと。
pythonで書くとこんな感じ。
>>> def create_counter():
　　n = 0
　　def counter():
　　　　nonlocal n
　　　　n += 1
　　　　return n
　　return counter

>>> counter = create_counter()
>>> counter()
1
>>> counter()
2

**デフォルトの名無しさん** · 2019/03/22(金) 08:09:16.10

>>244
そうなんですが、純粋関数型言語の場合、その関数を何回呼び出したのかカウントする関数を作るみたいな視点の切り替えで対処するのではと。
つまり自身のファイルを読み込んで自身(counter関数)を

a = counter
b = counter

a = 1
b = 2

に置き換える関数なら作れます。

欲しいのは結果であり、動作ではなく結果が同じなら良いと言う解釈です。

**デフォルトの名無しさん** · 2019/03/22(金) 10:06:06.24

終了やカウントクリアに対応してみた。

import System.Exit

main = do putStrLn "quit code is 'q', count clear code 'c'"
mapM_ (\n -> print n >> getLine >>= f) [0..]

f "quit" = exitWith ExitSuccess
f "clear" = main
f _ = return ()

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

副作用もカウンタもGUIもHaskellでできる (Haskellで作れるとは言っていない)

**デフォルトの名無しさん** · 2019/03/22(金) 14:11:11.50

まあ要はcounter関数はswap関数と同じですよ。
手続き型言語ではソートや繰り返しに必須ですが、関数型言語で各種ソート作る時にswap関数は使った事がない。
木を見て森を見ずというか、counter関数を何に使うの？って話で、カウンターとしての用途なら再帰関数の引数でf (x + 1)とか渡せば良いだけですし。

loop10 n | n > 10 = return ()
loop10 n = print n >> getLine >> loop10 (n + 1)

**デフォルトの名無しさん** · 2019/03/22(金) 14:35:43.76

つまりHaskell(というかElm？)で無限アラート書いとけば捕まらなかった？

**デフォルトの名無しさん** · 2019/03/22(金) 15:17:19.58

Haskellの再帰は場合によってはヒープを使うから
10^9回ぐらい閉じる奴がいたらサイバーテロとして扱われてたかもしれない

**デフォルトの名無しさん** · 2019/03/22(金) 15:36:25.55

そこは気を付けなきゃだけど(と言うか、スタックは兎も角ヒープ使うってreverseみたいにリスト溜め込むとかだけで、手続き型言語でもあり得る場面に限られそうだが)、
むしろモナドな再帰(IOはもちろん、リスト->リストな再帰も)がループになると言うのは、
手続き型言語よりも再帰でスタック使うケースが少ないと言う魅力もある。
(ここは手続き型言語が末尾再帰最適化に対応しても追いつけない所)

>>246 の通り、mainを再帰的に呼び出してもループになると言うのは知る限り手続き型言語では見たことない。

main変数が他の言語で言うmain関数的な動きをしているのも、圏論的には変数は引数無しの関数と見做せるから。
main変数を評価しようとすると束縛されたプログラムが動き出す。

n = 1 ― 変数であり、常に1を返す引数無しの関数

**デフォルトの名無しさん** · 2019/03/22(金) 17:16:42.19

いやGHCが与えるスタックはヒープなんだよ
Cのコールスタックみたいな固定領域じゃなくてね
それもデフォルトで最大メモリの8割というデカさだから
うっかり非末尾再帰を放っておこうものならスワップ地獄に陥る

**デフォルトの名無しさん** · 2019/03/22(金) 18:49:40.42

非末尾再帰を末尾再帰に自動変換するのって技術的に不可能？
末尾再帰ってなんか無理やり感あるよね

**デフォルトの名無しさん** · 2019/03/22(金) 19:00:24.32

フィボナッチを再帰で書くと定義がそのまま動く感動が味わえるのに末尾再帰に書き直すととたんに台無しになるよねｗ

**デフォルトの名無しさん** · 2019/03/22(金) 22:26:05.94

ヒープにあろうがスタックにあろうが末尾再帰に意識して書けばまず解決する問題だね。
ghciやrunghcみたいなスクリプト形式だと最適化(部分的な正格評価)が不十分で

sum’ n [] = n
sum’ n (x:xs) = sum’ (n + x) xs

という末尾再帰があった場合、

sum’ 0 [1,2,3]
= sum’ (0 + 1) [2,3]
= sum’ ((0 + 1)+ 2) [3]
= sum’ (((0 + 1)+ 2)+ 3) []

みたいに(遅延評価のせいで)結果を入れる変数の方でスタック消費するけども、コンパイラ(ghc)の方はこの問題は無い。

**デフォルトの名無しさん** · 2019/03/22(金) 22:43:20.21

>>254
別に数列(リスト)から取り出す形にすれば末尾再帰にする必要ないでしょ。

main = print $ fibs!!3 ― 0から数えて3番目
where fibs = 0:1:zipWith (+) fibs (tail fibs)

foldlの正格評価版 foldl’みたいにzipWithの正格評価版作って差し替えると高速化する。
(このネタ書いてたブログの人はzipWith’を標準で入れてて欲しいって書いてた)

zipWith’ f (x:xs) (y:ys) = seq a $ a:zipWith f xs ys
where a = f x y
zipWith’ _ _ _ = []

**デフォルトの名無しさん** · 2019/03/22(金) 23:37:15.19

>>256
定義そのままで書きたいって話であって末尾再帰だからダメとは言ってないでござるよ

**デフォルトの名無しさん** · 2019/03/23(土) 11:46:10.06

「感動」はダメとは言わないが意味がわからないと言いたい

**デフォルトの名無しさん** · 2019/03/23(土) 11:57:03.27

自然に書くなら数学の定義通り書くよね
でも今のコンピュータの制約上仕方なく末尾再帰にしないといけないよね
自然に書ける日は来ないのかなあってある種当たり前の感覚だと思うけど

**デフォルトの名無しさん** · 2019/03/23(土) 11:59:26.53

コンピューターの制約で変えねばならないならば定義に問題がある
定義は可能な限り一般に適用可能でなければならない
よって定義を変えればよい

**デフォルトの名無しさん** · 2019/03/23(土) 12:03:29.66

感情をそのまま言語化できるなら犬や猫も言葉を話せることになる
実際には感情と言語は一致しないので感情をそのまま言語化することはない

**デフォルトの名無しさん** · 2019/03/23(土) 12:16:16.80

何か噛み合ってないな
自然な感覚に近い表現ができるほうが可読性高いよねくらいの話でしかないはずなのに
今何の話になってるんだ？？

**デフォルトの名無しさん** · 2019/03/23(土) 12:18:39.39

言葉を話さない動物やAIには言語の制約がない
ゆえに動物やAIは人間を超える可能性がある
壮大な詭弁だ

**デフォルトの名無しさん** · 2019/03/23(土) 12:22:19.42

末尾再帰＝ループ

分岐が発生するとこの関係が崩れる

**デフォルトの名無しさん** · 2019/03/23(土) 12:26:33.46

何か変なとこに手出しちゃったみたいですね
もうやめときます
スレ汚し失礼しました

**デフォルトの名無しさん** · 2019/03/23(土) 13:28:21.51

可読性で思い出したが
ソースを読まなくても使ってみればわかることは読まない方がいい
読んだときの自然な感覚なんかよりも、そもそも読まないのが最も自然

**デフォルトの名無しさん** · 2019/03/23(土) 16:34:59.79

可読性をあげるためだけに型に別名つけるのってどうなの

type Description = Text

みたいなやつ

**デフォルトの名無しさん** · 2019/03/23(土) 17:38:52.05

まあ読みやすさっていうか書きやすさだよなそれ

**デフォルトの名無しさん** · 2019/03/23(土) 18:36:54.54

読むコストを下げるためだけにギャンブル
○○のコストは安いというのが本当か嘘かを賭ける

賭けないのが最も安いと思わないか

**デフォルトの名無しさん** · 2019/03/23(土) 19:48:40.97

>>259

https://i.imgur.com/816HQOu.jpg

https://i.imgur.com/wTI8fNg.jpg

一応、末尾再帰も式変形した定義通りなんだけどね。

fib3 0 a _ = a
fib3 n a b = fib3 (n - 1) b (b + a)

n = フィボナッチ数のn番目(fib n)

a = fib nの時のフィボナッチ数

b = fib (n + 1) の時のフィボナッチ数

fib3 nはfib3 (n - 1)のbがaになり、b(fib3 (n + 1))はfib3 (n - 1)のb(fib3 n) と a(fib3 (n - 1))を足したものである。

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

>>269 賭けない、は具体的には何？型シノニムを使わないということ？

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

>>271
使うのは自由だが可読性の勉強等はしないということ

**デフォルトの名無しさん** · 2019/03/24(日) 00:47:12.07

>>272
悩んでないでスタイルを決め打ちして自分が自然だと思える書き方で行く、みたいな感じですか

**デフォルトの名無しさん** · 2019/03/24(日) 09:54:41.46

そんな言葉は使う必要がねーんだ
書き方は決まってないのにもうすでに書き終わってるからだ

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

やっぱりHaskellは常人向けではないんですね
Ocamlやります

**デフォルトの名無しさん** · 2019/03/24(日) 12:49:13.41

そういえば言語も決まってなかったな
常人は言語を決めないとプログラムを書けないってマジ？

**デフォルトの名無しさん** · 2019/03/24(日) 15:26:29.39

>>275
Windowsでは、昔のrubyみたいな状況なので、
それ以外のプラットフォームでやるのがいいよー

**273** · 2019/03/24(日) 16:35:05.61

よく判らないアドバイスだったな…
勉強・研究しないで突っ込むのはそっちの方が賭けてる感あるし、
すぐに書き終えるなら確かにそういう難しさはないが、
ソフトウェアのプロジェクトって面白いものは大抵長くなると思う。

>>277
Windows環境はWSLではダメなん？

**デフォルトの名無しさん** · 2019/03/25(月) 18:54:20.99

>>261
感情表現と言うように感情はあくまでイメージ想起性のもので
文法を持ってないものだと思う。
感情をそのまま言語化なんて人間でもしてないだろ。
あくまで論理的内容の会話文章の表現に感情を想起させる表現を
選んで論理としては同じだけれど得られるイメージが異なる文を
作っているだけだと思う。
そこで文を構成するために選ぶ表現がやたら極端なときに、感情的と評されているだけで。

ていうかおじさんになったしもう無理

**デフォルトの名無しさん** · 2019/03/25(月) 20:49:31.29

>>279
得られるイメージが変わってしまうのはコンピュータの制約のせいだよ
fibのイメージをそのまま表現できたら感動するのになあ

この状況ではコンピュータの制約は変えたいがイメージは変えたくない
「論理としては同じだけれど得られるイメージが異なる」という想定は大外れ

**デフォルトの名無しさん** · 2019/03/25(月) 21:05:17.06

イメージw
お前らあほだろ

**デフォルトの名無しさん** · 2019/03/25(月) 21:17:58.51

コンピュータの制約が悪夢のようだから消去法でイメージ
あほなことしてるだろ
俺達なんだぜこれ

**デフォルトの名無しさん** · 2019/03/25(月) 21:19:23.78

イメージないと妥当性の判断もできんぞ。
これだって
書き込み内容を読んで
内容から推測される人物像をいままでの記憶から割り出して
そういう人物に対してかつてもった心象(イメージ)を
この場合の想定(先入観)として設定して
否定的判断をするという内容を伝達しているだろ

大体こういうプロセスじゃね？

**デフォルトの名無しさん** · 2019/03/25(月) 21:58:18.36

数学の世界で効率を全く重視してないわけじゃないからな。無限の速度のCPU上なら同じと見なせるってだけで。

末尾再帰のfibとか数学的だからアーキテクチャ関係なく元の定義より速い。
行列苦手だから書けないが、もっと速い行列バージョンも存在する。

**デフォルトの名無しさん** · 2019/03/25(月) 22:00:17.95

これなんか深かった。結局愚直なコードのままで良かったみたいな
https://haskell-jp.slack.com/archives/C5666B6BB/p1551956556140300

**デフォルトの名無しさん** · 2019/03/25(月) 22:05:21.04

あとこれ。今はコンパイラが賢くなったのでfoldlが遅くなくなったよって話
https://qiita.com/autotaker1984/items/09c5ceaa13e9077f5359

**デフォルトの名無しさん** · 2019/03/25(月) 22:10:40.54

これはPrologについて書かれているが、ここで話題にしてるのはこの記事と同じ議論だろう？

宣言型プログラミングの可能性と限界
https://thinkit.co.jp/article/157/3

**デフォルトの名無しさん** · 2019/03/25(月) 22:23:26.20

全く読んでないがパラダイムと論理は同じではない
パラダイムの限界と論理の限界は同じではない

◆QZaw55cn4c · 2019/03/25(月) 22:53:06.90

>>284
＞末尾再帰のfib
fib が末尾再帰でかけますか？

**デフォルトの名無しさん** · 2019/03/25(月) 23:23:28.81

>>289

つ >>270

**デフォルトの名無しさん** · 2019/03/25(月) 23:29:06.55

sum x:xs = x + sum(xs)
は数学っぽく見えるけどアキュムレータ噛ますと途端にループに見える不思議

**デフォルトの名無しさん** · 2019/03/26(火) 02:32:22.40

アキュムレータは余再帰っぽく見える
数学っぽいの反対は余再帰っぽい説

**デフォルトの名無しさん** · 2019/03/26(火) 19:05:26.53

Haskell知らんでも無意識に >>270 みたいな式を思い描いて
for文とかに落とし込んでる感じじゃね？
n回繰り返すのが昇順か降順かの違いだけで。

Python

def fib(n):
temp = 0
a = 0
b = 1
for i in range(n):
temp = a
a = b
b = b + temp
return a

for i in range(10 + 1):
print(fib(i))

Haskell

main = mapM_ (print.fib) [0..10]

fib n = fib' n 0 1
where
fib' 0 a _ = a
fib' n a b = fib' (n - 1) b (b + a)

**デフォルトの名無しさん** · 2019/03/26(火) 19:25:31.93

誰でも頭が良くなる、プログラムが書けるようになる方法が発見される 42162
https://you-can-program.hatenablog.jp

**デフォルトの名無しさん** · 2019/03/31(日) 07:28:40.29

プログラマーのための圏論と言うPDFで公開されてるのが分かりやすい。（上・中・下の三冊)
http://bitterharvest.hatenablog.com/entry/2016/11/24/203021

**デフォルトの名無しさん** · 2019/04/04(木) 13:40:08.49

自然数が射(関数)になっていると言う感覚が分かった気がする。

Haskellで書けないけど、書けるとするなら

1 = 1

1という名前の1を返す引数無しの関数。

**デフォルトの名無しさん** · 2019/04/04(木) 13:43:46.44

記号的な1を1と書き、概念的な1をチャーチ数で表現するなら

1 = succ zero

**デフォルトの名無しさん** · 2019/04/04(木) 21:34:52.78

トートロジーではないのかね？

**デフォルトの名無しさん** · 2019/04/05(金) 00:53:58.06

トートロジーとかチンプンカンプンな高卒なんで。。。
補足説明や訂正があったら勉強になります(￣^￣)ゞ

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

ラムダ的な自然数は高階関数を使うけど、圏論は冪を使わないことが多い

**デフォルトの名無しさん** · 2019/04/05(金) 08:37:08.96

Haskell でもsuccって関数ありましたね。。。
私が

1 = succ zeroで表現したかったのは、どんな数体系でも1と表現される何かという意味での1です。

例えば16進数の10はAと表現されますのですが、

A = 10

とすると10が16進数では10進数の16になるので10進数でも16進数でも10として扱われる概念としてチャーチ数にしたかったのですが、
チャーチ数も含めた全ての数体系で10として扱われる何かを表現したいみたいな。

うーん。。。表現力が乏しくてすみません。

**デフォルトの名無しさん** · 2019/04/05(金) 18:59:26.73

本当の所は
Int $ succ Zero
というような頭部正規形で表される関数のシンタックスシュガーだと思う

**デフォルトの名無しさん** · 2019/04/05(金) 21:40:52.25

HNFは射ではない
そもそも圏論にHNFはない

**デフォルトの名無しさん** · 2019/04/06(土) 02:09:18.76

・チャーチ数はペアノシステムの1つの実装である
・任意のペアノシステムは(適当な公理のもとで)互いに同型である
みたいな話？

**デフォルトの名無しさん** · 2019/04/06(土) 03:06:25.41

>>303
> HNFは射ではない
> そもそも圏論にHNFはない

こういう表現は間違い
何が射かであり何が圏でないかは、どんな圏を考えているかに依存する

例えばだが、単純な型付λ計算（型の集まりが直積型の構成と関数型の構成について閉じている）に対応する圏、つまり単純な型とそれで型付けされるλ項の成す圏を考えることができる
そこでは、対象は個々の型で、射はλ項だ
そして個々のλ項は、そのλ項の中に現れる自由変数の各々の型の積対象からλ項全体への型という対象への射と考えるというものだ
この場合、λ抽象があるので冪対象が必要になり、従って、この単純な型付λ計算に対応する圏は必然的に積閉包圏というタイプの圏になる
これはいわゆる“categorical type theory”（圏論的型理論）の最も簡単な具体例だ

この圏の場合は単純な型付けに関してwell-typedなλ項は全て射として認められるのでもちろんhead normal formになっているλ項もwell-typedである限りは射だ

**デフォルトの名無しさん** · 2019/04/07(日) 09:14:23.15

Haskellの開発環境で、ブレークポイント張って評価中の変数の値を見る、みたいなのって出来ますかね？
Visual Studioのローカルウィンドウ的なの。
普段はSpacemacs使っててREPLで評価しては進め、評価しては進め、みたいな感じでやってます。

**デフォルトの名無しさん** · 2019/04/18(木) 13:41:44.67

並行並列言語Haskellの基本と特徴
https://logmi.jp/tech/articles/321095

2018年11月10日、Haskell-jpが主催するイベント「Haskell Day 2018」が開催されました。
純粋関数型プログラミング言語Haskellをテーマに、Haskellに興味のある人から入門者、
ちょっとできる人まで、様々な層に向けたプレゼンテーションを行った本イベント。実務
から研究まで、幅広いHaskellの事例を共有します。プレゼンテーション「並列並行言語
Haskell 」に登壇したのは、syocy氏。講演資料はこちら (↓)(後略)

https://speakerdeck.com/syocy/bing-lie-bing-xing-yan-yu-haskell
https://speakerd.s3.amazonaws.com/presentations/07d92af9d7aa40bca6cc3959d3f56b28/parallel-and-concurrent.pdf

**デフォルトの名無しさん** · 2019/04/18(木) 23:50:53.53

オライリー本の要約だけ？みたいな

**デフォルトの名無しさん** · 2019/04/25(木) 08:46:13.49

cabalのnew-から始まるnixスタイルコマンドが出来たからtackつかう意味あまりないですよね

**デフォルトの名無しさん** · 2019/04/25(木) 09:33:12.75

>>309
v2-build だっけ？よく知らないが stack いらなくなるやつなんだ？

**デフォルトの名無しさん** · 2019/04/25(木) 23:59:42.81

stackageが変わるんですねぇ。stack2も間もなくとか。
https://www.fpcomplete.com/blog/2019/04/stackage-changes-and-stack-2

**デフォルトの名無しさん** · 2019/04/29(月) 10:21:15.20

stack or cabal どっちを使えばいいんだ

**デフォルトの名無しさん** · 2019/04/30(火) 07:55:22.06

stack!

**デフォルトの名無しさん** · 2019/04/30(火) 15:29:26.12

>>312
迷う理由がわからない
現時点で好きな方を使えばいいのでは？

どっちを使っても、後で後悔することなんてないと思うが

**デフォルトの名無しさん** · 2019/04/30(火) 18:00:12.30

>>314
もはや同等とみていいの？
一長一短がイマイチ見えないので比較できない。

**デフォルトの名無しさん** · 2019/04/30(火) 18:03:11.15

入門者に紹介するときはどうすれば？

**デフォルトの名無しさん** · 2019/05/01(水) 13:06:07.04

>>315
自分で情報を得られず、比較できなくて選べないくらいなら、
一長一短なんか考えずに、今好きな方や気になる方を使えば良いんだよ。

stackを長い間使ってきたから今後も使い続ける、でもいいし、
新しいcabalに興味が沸いたからcabal使ってみる、でもいい。

例えばパーサーライブラリ、Webライブラリ、FRPライブラリなどは色々あるけど、
いちいち「一長一短を比較した上で」選ぶ人はそんなに多くないでしょう。
みんな取りあえず何か一つ使ってみて、他に興味が湧いたら浮気してみて、
それからでしょ、比較するのは。

**デフォルトの名無しさん** · 2019/05/01(水) 13:20:11.30

>>316
両方の一長一短をちゃんと比較して紹介するのは、
記事や本を書くプロや、意欲のある人に任せればいいと思う。

紹介のプロじゃないのなら、自分が好きな方を精一杯アピールすればいい。

それもできずに、初心者にどちらを紹介しようか悩むのなら、順番が違う。

どちらか一方でもアピールできるくらい使い込むのが何よりも先でしょ。

**デフォルトの名無しさん** · 2019/05/01(水) 13:42:48.29

まぁこの手の選択にある程度以上責任持って助言するのは難しいんだよな。
少なくとも両方使ってないとどっちがいいとか言えないし。
ほとんどの人が最初に使った方をそのまま使い続けるもんじゃね。
私もcabalしかつかったことないし。