関数型プログラミング言語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/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しかつかったことないし。

**デフォルトの名無しさん** · 2019/05/01(水) 14:03:02.54

「みんなの見解を聞く」も自分で情報を得る過程のひとつだと思ってるんだが

記名ネットではしにくい無責任方言もここなら言えるでしょ

**デフォルトの名無しさん** · 2019/05/01(水) 14:23:04.11

まだキチンと検討していないが、自作したツールをbrewとかで公開するとき、ビルドツールを依存に含める必要が出てくると思う。予めどっちかを使うかは決めておきたい。
バージョンを重ねるなかでフラフラ変えるのは避けたい。

あとcabalだとコンパイラを替えるときはghcupなる別ツールを使うの？これだとクロスコンパイラはどうなる。
複数のアーキテクチャのための成果物をビルドするとき、ghcup set ... && cabal build && ghcup set ... && cabal build ... みたいにいちいち指定しないといけないのかしら。
コレを解決するにはghcupにパッチを当てるかcabalを改造するか、スクリプトを書くかするわけだ。その点 stack build はコマンド一発なのに。

俺は年間50時間くらいstackのパッチや関連ツールを書いてきた。このままで行けるならいいが、stack がいずれオワコンになるなら早めに見切りつけて時間節約したい。
新元号が30年続くなら令和中に1500時間も浪費することになるんだぜ。

**デフォルトの名無しさん** · 2019/05/01(水) 14:53:10.97

>>320
> 記名ネットではしにくい無責任方言もここなら言えるでしょ

そんなレスは情報ではないのでは？
ただのノイズでしょ（ノイズの全てがゴミとは言わないが）。
本当に情報を得たいのなら、時間の無駄だよ。

もし、そんなのを参考にどっちか決められるのなら、
初めからルーレットで決めるのと大して変わらないのでは？

「自分で情報を得る」の第一歩は、ビルドツールで一番何がしたいかを決めて、
それが出来るか、やりやすいかを「公式ドキュメント」を見て調べる事だよ。

stackとcabalの公式ドキュメントを見て比較して、
それでも分からない部分をピンポイントでSNSや掲示板などで質問する、
それが二歩目だと思う。

**デフォルトの名無しさん** · 2019/05/01(水) 16:46:41.64

伸びてると思ったら。。。
今の所stackかな。
cabalは依存関係で過去に評判悪かったから、新しいのの評判が固まったらかな。

**デフォルトの名無しさん** · 2019/05/02(木) 10:15:34.23

>>322
調査を並行してやっちゃいけない理由はないでしょ。聞くだけならタダやし。
スレ民の意見をノイズだなんて思ったことないよ。自分にない視点や個人的使用感、気づきにくい落とし穴を教えてもらえるかも。

俺の雑感はstackは不備だけでなくバグも多かった気がする。.stack-workを消したらビルドが直ったみたいなことが何回かあったと思う。

stackのメリットは、
(ghcupの方針が変わらないなら)コンパイラの導入まで自動でやってくれるので、例えばHaskellスクリプトを書いてシェバンにstack、
以降に依存ライブラリを書いておけばいつでもどこでも動く(HackageとStackageが活きてるかぎり)、必要なものを都度自動で用意してくれる。

stackのデメリットは、
設定ファイルが多すぎる。プロジェクトレベルでは stack.yaml, package.yaml, Hoobar.cabal
と、どれに何を書くかが判りづらい、いちいち引っかかる。

**デフォルトの名無しさん** · 2019/05/02(木) 12:34:35.03

>>324
無責任放言がノイズなんだよ。

で、その全てがゴミとは言わないとも言ってる。

**デフォルトの名無しさん** · 2019/05/02(木) 13:13:18.93

>>325 前半は反論したし、後半は批判してないですよ。

**デフォルトの名無しさん** · 2019/05/03(金) 01:40:50.69

凄いH本の中国語版見る機会があって、
漢字の用法がカタカナ語より
しっくりすると思ったんですけどどうでしょうか。

模式：　　パターン
門衛：　　ガード
類型類：　型クラス

さすがにモナドは漢字翻訳難しいみたいですが。

**デフォルトの名無しさん** · 2019/05/03(金) 06:21:38.43

その程度のカタカナがしっくり来なかった人生を反省するんだ

**デフォルトの名無しさん** · 2019/05/03(金) 09:01:46.98

慣れとしっくりくるのは別物だけどな
無意味刺激と有意味刺激、表音文字と表意文字に対する認知は先天性の個人差があるんだからあまり他人の人生なんて分かりもしないものに言及するべきではない

どちらにせよ今の中国は学術用語を積極的に訳する文化ではあるよね
Haskellに限らずclassや他の用語もそれに類した漢字が用いられてそう
ただこれも漢字の意味が時代によって変化してくると正しい用語認識を阻害しうるのは現代日本でいくらか見られているし、一長一短と個人差だね