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

**デフォルトの名無しさん** · 2020/02/10(月) 18:17:36.49

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

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

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

**デフォルトの名無しさん** · 2020/12/05(土) 23:01:31.80

>>600
すごい良さげ。ありがとう

**デフォルトの名無しさん** · 2020/12/05(土) 23:45:36.72

>>601
すごい良さげ。ありがとう

**デフォルトの名無しさん** · 2020/12/06(日) 02:18:39.34

>>601
グロ

**デフォルトの名無しさん** · 2020/12/08(火) 09:15:41.98

実際にちょっとしたプログラム書いてみると
メモリ周りの最適化が困難なんだよなこの言語。

しかも最適化の方向性がアルゴリズムの改良ではなく
言語特有のボトルネックの回避がメインになるから
コードを見ても最適化の意図が分かりにくくて
一見無駄に冗長に記述してるだけに見えるコードが出来上がる。

**デフォルトの名無しさん** · 2020/12/08(火) 11:08:46.52

最適化の意図なんてPythonと同じでいい
ライブラリは全部Cで書いてmainだけHaskellで書け

**デフォルトの名無しさん** · 2020/12/08(火) 12:02:52.73

一時期あんなにモナドの記事とか書かれまくったのに、最近盛り上がりに欠ける
Haskell製アプリも企業が採用したって話もほとんど聞かないけど、気のせい？
尖ったところで使われてるんかな

**デフォルトの名無しさん** · 2020/12/08(火) 13:07:23.14

言語関係なく企業が作ったアプリを買ったことがほとんどない
個人が書いた本を買うことはある

**デフォルトの名無しさん** · 2020/12/08(火) 13:30:45.48

まぁなんだかんだHaskellは実用性というより、やはり数学研究の一貫の色合いが強いからなぁ

**デフォルトの名無しさん** · 2020/12/08(火) 13:52:48.29

一環では？
数学の前に国語の研究をしたほうがよいのでは？

**デフォルトの名無しさん** · 2020/12/08(火) 15:02:11.16

お前はまず自分の人間性を見直せ
煽りじゃなくマジで

**デフォルトの名無しさん** · 2020/12/09(水) 01:52:25.38

Haskell自体は面白くて本や記事も読むけど、なんか書く気起きないんだよな
でも他の言語で関数型由来の機能が追加されたときに「あ、これHaskellでやったところだ！」ってなれる

**デフォルトの名無しさん** · 2020/12/17(木) 17:53:27.84

Haskellでx = x + 1をIORef使わず擬似的に再現。
(実際には代入では無く、結果をラムダ式の同名の変数に渡してるだけ)

main = do let x = 0
print x
x <- inc x
print x
x <- inc x
print x

inc n = return (n + 1)

モナド式の書き方だとこうなる。

main = do let x = 0 in print x >> inc x >>= \x -> print x >> inc x >>= \x -> print x

inc n = return (n + 1)

さらに>>=演算子を()で囲んで関数にするとこうなる。

main = (>>=) ((>>=) (do let x = 0 in print x >> inc x) (\x -> print x >> inc x)) (\x -> print x)

inc n = return (n + 1)

**デフォルトの名無しさん** · 2020/12/17(木) 17:53:45.49

モナド無しだけど、Cで再現するとこんな感じ。(スタック消費するけど)

#include <stdio.h>

int inc(const int);
int f(const int);

int main(void)
{
const int x = 0;
printf("%d\n",f(f(x)));
return 0;
}

int inc(const int x)
{
return (x + 1);
}

int f(const int x)
{
printf("%d\n",x);
return inc(x);
}

**デフォルトの名無しさん** · 2020/12/18(金) 19:59:30.35

目的が実用だろうが研究だろうがIORefは使っていいぞ
IORefは手段なので、具体的な目的に依存しない

**デフォルトの名無しさん** · 2020/12/19(土) 08:53:57.33

気持ちはよくわかる。自分も初めてdo式の定義を見た時、おぉぉぉとなった。
というわけで、いつdo式パラダイスが登場したのかアヒル体験してみた。
[When was do-notation introduced?](https://www.reddit.com/r/haskell/comments/8rkrgq/)

> Haskell 1.3 adopted Jones’s “do-notation,” which was itself derived
from John Launchbury’s paper on lazy imperative programming (Launchbury, 1993).

自分の場合、Haskellを知る前に、Moggi大先生の論文体験を一撃で敗退した時に
おぉぉぉした覚えがある。

* Notions of computation and monads
in [Eugenio Moggi Publications](https://person.dibris.unige.it/moggi-eugenio/publications.html)

宗教上の理由で、シーケント図が書かれた書物体験はできないが、幸いなことに、
最初のシーケント図にdo式らしきものが書いてある。ナウなヤングの言葉では
次のようになると思う。

``` haskell
kleisli_extension :: (Monad t) => (a -> t b) -> (t a -> t b)
kleisli_extension f c = do
x <- c
f x
```

今も論文に何が書かれているかわからないが、その時は、<em>おぉぉぉ、
プログラミング言語って数学的に捉えられるんだ</em>体験をした記憶がある。
一般に、紙上のプログラミング言語と実働するものとの間には万物の長城が
あるので、Haskellのdo式もすごい発明と思うが、その技法の骨子は、既に
[同時多発的](https://www.youtube.com/watch?v=FMmCJ6-uu3M)に発見されて
いたのかもしれない。歴史絵巻体験では、
[A History of Haskell](https://misreading.chat/2020/10/27/)も面白かった。

**デフォルトの名無しさん** · 2020/12/20(日) 18:18:16.88

ネタを拝借して、次のコードを考える。

``` haskell
inc :: (Applicative f) => Int -> f Int
inc n = pure (n + 1)

lhs :: (Int -> () -> String) -> Int -> IO String
lhs dump x = do
y <- inc x
z <- print y
pure $ dump y z

rhs :: (Int -> () -> String) -> Int -> IO String
rhs dump x = inc x >>= \y -> dump y <$> print y

lhs ((.) show . (,)) 123 >>= print
rhs ((.) show . (,)) 123 >>= print

lhs (const . const "hello") 123 >>= print
rhs (const . const "hello") 123 >>= print
```

**デフォルトの名無しさん** · 2020/12/20(日) 18:18:58.94

IOモナドを恒等モナドに差し替えて、Rに移植する。

``` {r raskell}
do = pure = id = function (a) a;
const = function (a) function (ab) a;
`%.%` = function (bc, ab) function (a) bc (ab (a));
`%$%` = function (ab, a) ab (a);
`%>>%` = function (a, ab) ab (a);

inc = function (n) n + 1;
caty = function (a) cat (a, "\n", sep = "");

lhs = function (dump) function (x) do ({
y <- inc (x);
z <- caty (y);
pure %$% dump (y) (z);
});

rhs = function (dump) function (x) {
inc (x) %>>% (function (y) dump (y) %$% caty (y));
};

lhs (function (y) function (z) list (y, z)) (123) %>>% print
rhs (function (y) function (z) list (y, z)) (123) %>>% print

lhs (const %.% const ("hello")) (123) %>>% print;
rhs (const %.% const ("hello")) (123) %>>% print;
```

Rは関数の引数を問答無用に遅延評価するので、最後の`rhs`だけがHaskellと
異なる動作をする。Rの遅延評価の例としては煩雑過ぎるが、HaskellのIOモナド
とサイドバイサイドに比較できる例になっている。

**デフォルトの名無しさん** · 2021/01/05(火) 09:39:14.86

ふと思った。

a型の2次元配列が必要になった時、
[[a]] や Array (Int, Int) a ではなく、
(Int, Int) -> a が真っ先に思い浮かぶなら、
そいつは関数型にどっぷりハマってるな、と。

**デフォルトの名無しさん** · 2021/01/08(金) 14:54:16.81

関数型は並列処理に強いという話を聞くけど
fpgaの高位合成がC言語で行われている理由は何ですか？

haskellでの高位合成やgpgpuはどうなっていますか？
実用されていますか？

**デフォルトの名無しさん** · 2021/01/08(金) 15:09:45.01

Haskellの人気は横ばいまたは下降気味。
なぜ未来であるはずのHaskellは勢いを持たない？
実際使ってる人達の印象はどうなの？

https://www.reddit.com/r/haskell/comments/iaxx7x/thoughts_on_how_to_measure_haskells_popularity/
https://trends.google.com/trends/explore?q=%2Fm%2F03j_q&;date=all#TIMESERIES
https://insights.stackoverflow.com/trends?tags=haskell

**デフォルトの名無しさん** · 2021/01/08(金) 15:22:31.00

Haskellはアカデミックな言語だっていうけど
アカデミックな人がやることが多い機械学習でPythonが伸びた
並列処理に強いなら機械学習の行列処理がHaskellで行われても良かったんじゃないの？

**デフォルトの名無しさん** · 2021/01/08(金) 18:33:26.91

Haskellは並行並列を楽に書けるのであって速く書くのに向いているわけではない（滅茶苦茶向いていない訳でもないがハードウェアに近い組には速度で勝つのは大変）
そしてDNNは内部処理がテンソル演算でこそあるけどインターフェイスでそこまでむき出しのテンソル演算をするのは多くない

なによりアカデミックは一枚岩ではなく当然色々幅が広くて
Haskellがアカデミックと呼ばれる所以は言語処理系や型理論、その実装の分野
並行並列が楽に書けるってのはその流れからくる、関数の純粋性とソフトウェアトランザクショナルメモリの成果
機械学習系の源流になる内の画像処理系ではC++やmatlabが、統計系はRやmatlabが使われててnumpyと共に徐々にPythonに移行してきた
ちょっと下のレイヤーのBLASやシミュレーションではC++とFortran、後にGPGPUの独擅場で今ではPythonから呼ばれる形で使われてる訳だ

**デフォルトの名無しさん** · 2021/01/09(土) 00:06:52.64

機械学習はどっぷり工学分野だからアカデミックという印象は少ないイメージあるが

**デフォルトの名無しさん** · 2021/01/09(土) 16:47:47.44

haskellについて調べてるんだけど
関数の合成は関数Aの返値と関数Bの引数の型が一致するとかの条件が必要？
解説記事に「関数はファンクタです」とか書かれてるんだけど
任意の関数を合成できるわけじゃないよね？

**デフォルトの名無しさん** · 2021/01/09(土) 17:24:37.63

>>625
関数合成のシグネチャを見れば分かる
(.) :: (b -> c) -> (a -> b) -> a -> c
"bからcへの関数"と"aからbへの関数"を受け取り、"aからcへの関数"を返す関数が関数合成

**デフォルトの名無しさん** · 2021/01/10(日) 13:23:32.27

・Functorは高階カインドのクラスです
・二変数の型構築子(->)を部分適用したものがFunctorのインスタンスになります
この説明を省略したら意味がわからないよね

**デフォルトの名無しさん** · 2021/01/11(月) 01:34:20.58

超大作過ぎるけど

[Entropy and Diversity](https://golem.ph.utexas.edu/category/2020/12/entropy_and_diversity_on_the_a.html)

**デフォルトの名無しさん** · 2021/01/11(月) 11:54:49.85

>>625
関数合成可能性の話と関数が関手であることは全く関係ないぞ

**デフォルトの名無しさん** · 2021/01/11(月) 13:43:32.73

Haskell　　　　圏論
=====================
関数　　　　　　射
Functor　　　　関手
Reader r 　　　Hom関手

**デフォルトの名無しさん** · 2021/01/11(月) 16:14:02.10

H本終えたくらいの初心者が、中級上級それ以上を目指すためのロードマップって大体こんな感じ？
わたしは全部マスターしたわけじゃなくて、界隈でよく聞くのでなんか重要そうくらいのノリw

中級
・Freeモナド
・Profunctor optics
・コモナド
・Custom Prelude

上級
・型レベルプログラミング
・Extensible Effects
・Indexed Monads
・Template Haskell

**デフォルトの名無しさん** · 2021/01/11(月) 23:19:18.98

まず何より先にアプリ作ろうよ。
先人たちはアプリを作りまくる過程で、
役立つテクニックや概念を編み出してきたのだから。

**デフォルトの名無しさん** · 2021/01/12(火) 00:18:20.62

Haskelｌは哲学であり、哲学からは何も生まれない

**デフォルトの名無しさん** · 2021/01/12(火) 01:04:23.78

>>632
ここでの問題はHaskellの鉄人になるためのロードマップであって、
Haskellでアプリを作れるようになるためのロードマップではない

**デフォルトの名無しさん** · 2021/01/12(火) 01:51:40.85

>>634
そうか、余計な事だった、すまない

**デフォルトの名無しさん** · 2021/01/12(火) 09:05:11.74

哲学からは法が生まれますが…

**デフォルトの名無しさん** · 2021/01/12(火) 10:08:30.41

何かを生まなければならないというのは道徳か？
その道徳から全てが始まるのか

**デフォルトの名無しさん** · 2021/01/13(水) 04:05:16.97

オタクのこういう会話クソキモい

**デフォルトの名無しさん** · 2021/01/13(水) 10:09:05.37

キモいという感情から
感情と知性の分断が生まれる

**デフォルトの名無しさん** · 2021/01/13(水) 10:21:18.95

Haskell でカッコよく速いプログラム書きたいんですが、どう言う分野が向いてますか？

**デフォルトの名無しさん** · 2021/01/13(水) 21:12:21.98

>>640
パズルソルバー

**デフォルトの名無しさん** · 2021/01/13(水) 22:41:38.73

感情は先入観から生じ
先入観を克服することで知性に至る

**デフォルトの名無しさん** · 2021/01/14(木) 00:13:44.79

でも先入観のメリットはスピードだから
速度の最適化みたいな建前を用意すれば知性と知性の対等な関係にはなる

建前はキモいとか本音がカッコイイとか言い出さない限り

**デフォルトの名無しさん** · 2021/01/14(木) 07:11:45.05

感情のための知性が工学
知性のための知性が理学

**デフォルトの名無しさん** · 2021/01/14(木) 08:24:32.45

なんかやたらポエムを書きたがるレスが増えたな

**デフォルトの名無しさん** · 2021/01/14(木) 10:42:33.32

音やリズムをデザインしてるのか
音読できない言文不一致言語があれば、デザインと論理的構造を分離できそう

**デフォルトの名無しさん** · 2021/01/15(金) 04:12:13.96

これ意見割れてるけどどっちが正しいの？
有識者諸君のご意見を伺いたい
https://www.quora.com/Is-functional-programming-most-likely-to-survive-transitions-to-different-CPU-architectures-like-post-von-neumann-ones

**デフォルトの名無しさん** · 2021/01/15(金) 10:43:33.32

関数型を信じるというよりオブジェクト指向を疑うべき
オブジェクト間の通信がただの関数呼び出しから軽量スレッドに変わったらどうなるか等

**デフォルトの名無しさん** · 2021/01/15(金) 20:09:59.52

>>648
重たくなる。

**デフォルトの名無しさん** · 2021/01/16(土) 10:01:48.97

fix関数は least-defined な不動点を見つけるそうだけど、
この least-defined ってどういう意味？

**デフォルトの名無しさん** · 2021/01/16(土) 10:43:22.09

おれの先入観によるとポインタの循環の周期が最小

**デフォルトの名無しさん** · 2021/01/20(水) 07:45:01.78

多分できないんだろうなと思いつつ質問です
あるページで乱数をいっぱい調達する方法でこんなのありました

randIntsList = let
getOne rec = ( return . ( : rec ) )
=<< ( randomIO :: IO Int )
in iterate ( >>= getOne ) ( return [ ] )

main = do
a <- ( return . head ) =<< randIntsList !! 100
print a

コレはもちろんうまく行きました
でもコレちょっと不愉快です
IO [ Int ] とかで例えば

randInts :: IO [ Int ]
randInts = do
hd <- ( randomIO :: IO Int )
tl <- randInts
return $ hd : tl

main = do
a <- ( return . head ) =<< randInts
print a

とかであらかじめ使う数を指定しないで好きなだけとってくるとかできないもんでしょうか？
上のはGHCで参照すると実行時エラー出ます

**デフォルトの名無しさん** · 2021/01/20(水) 14:24:39.71

ついさっき関数的プログラミングの話題してたが
やっぱり通じないな

関数？そりゃ関数くらい普通に書くよねw
副作用？必要なら出ないように書けばいいんじゃないの？どうでもよくない？
純粋関数の考え方？そんなのいらないよねw
部分適用？今までそんなの必要になったことないなあw そんなの何に使うんだ？

まあ言われてみれば誰にでもわかるような利点を提示できないってのは確かにあるが・・
利点がないなら好みの範囲で片付けられちゃったな

**デフォルトの名無しさん** · 2021/01/20(水) 15:57:32.54

いらないと思う人は使わなければいいし気にしなければいいってだけだよね

**デフォルトの名無しさん** · 2021/01/20(水) 16:39:30.61

>>652
これでどうかな？
randInts2 :: [IO Int]
randInts2 =
iterate ( >>= const (randomIO :: IO Int) ) (randomIO :: IO Int)
main :: IO ()
main = do
a <- head randInts2
print a

**デフォルトの名無しさん** · 2021/01/20(水) 17:07:44.96

>>653
いわれてみればhaskell触るまでこういう特徴が泣くほどうれしいなんて思ってなかったなぁ……

**デフォルトの名無しさん** · 2021/01/20(水) 17:39:40.94

>>653
利点を提示っていうかLispとHaskellの違いを提示する必要がある
Lispの利点を再現するだけならPythonで十分な気がする

しかしHaskellを再現できるものがまだ出てこない
それは関数型じゃなくて静的型の説明をしないと意味が分からないと思うけど

**デフォルトの名無しさん** · 2021/01/20(水) 18:38:17.88

>>655
ありがとうございます
そうなんです
今のところそれしか解決策ないんです
しかし希望では IO [ Int ] であって欲しいんです
イメージとしてはこうです
ある関数 f があって乱数で挙動が変わって欲しい
もちろん最終的にはIOモナドを使わないとしょうがない
しかし色々いじってる段階ではモナド被せないで代わりに擬似乱数無限配列 psuedRand :: [ Int ] みたいなのを食わせて

f a b c psuedRand

みたいに呼び出して色々頑張って、最後の最後にIOモナドで実地に

　( return . f a b c ) =<< realRand

に切り替えるみたいな事ができないかなと思ったんです
f が使用する乱数がある程度わかるので別に無限列でなくてもいいっちゃいいんですけど
今一歩モナドに包まれてる関数いっぱい出てくるの好きじゃないんですよ
通のホムペとか見てるとむしろバンバンモナドでくるんどいた方がいいみたいなのもみるんですけどねぇ

**デフォルトの名無しさん** · 2021/01/20(水) 18:57:39.14

>>658
そうなのかあ。
すまない、俺では力不足のようだ。

**デフォルトの名無しさん** · 2021/01/20(水) 19:04:15.17

>>659
いえいえ、ありがとうございます
考えていただいて感謝です🙏

**デフォルトの名無しさん** · 2021/01/20(水) 20:02:19.54

headやtailの戻り値の型はIOではないって宣言してるから
リスト処理中にrandomIOができなかったとしても不思議ではない
型を宣言するってそういうことよ

**デフォルトの名無しさん** · 2021/01/20(水) 21:15:09.40

>>658
やりたい事の本質がいまいち分かりません。
2点確認します。

ひとつめ。
結局のところ今は [a] 型の乱数を返す関数を作りたいのでしょうか。
それとも、IO [a] 型の乱数を返す関数を作りたいのでしょうか。
はたまた、両方でしょうか。

ふたつめ。
開発環境では
> f a b c psuedRand

本番環境では
> 　( return . f a b c ) =<< realRand

という事でしょうか。
前者は純粋関数の式、後者は IO モナドを伴う式です。
これは、本番環境で IO モナドな関数を、開発環境では純粋関数で開発するという事ですよね。
開発環境を本番環境にする際には、後者の式を呼び出している外側の関数も、
純粋関数から IO モナドに書き換えるのでしょうか。
あまりお勧めしません。
本番環境で IO モナドな関数は、開発時も IO モナドで開発&テストした方が良いと思います。
環境が違ってもインターフェース(型シグネチャ)はそろえた方が良いです。
事情がおありなので、あくまで私は勧めないというだけですけど。

**デフォルトの名無しさん** · 2021/01/20(水) 21:21:29.93

>>661
まぁそうですね
できんもんはできんのでしょうね
ただ出来るか出来ないかの判定がまだまだ自分の実力不足でできないのか、実際禁止されててできないかのか判断がつかないんです

>>662
やはりそうなんでしょうね
まだまだ初心者でいまひとつモナドで包まれてるの馴染みがないので避けれるなら避けたいと思ってしまいます
この場合はモナドで最終的にくるむなら避けられても避けるべきではないのでしょうね

**デフォルトの名無しさん** · 2021/01/20(水) 21:52:28.04

>>663
型を書かない言語も普通に存在するので、型を無視する方法があってもそれも不思議ではない

**デフォルトの名無しさん** · 2021/01/20(水) 23:15:01.74

>>664
まぁ今回のは諦めます
出来るのなら見つけたホムペの人が紹介してくれてただろうし

**デフォルトの名無しさん** · 2021/01/21(木) 00:38:31.39

>>653
副作用とか純粋関数の話は単体テストの話題と絡めたいね
それが通じなかったら知らん
部分適用というか高階関数の話は
コールバックとかイテレータのような「処理の抽象化」が
極めて書きやすくなるというような話でどうか

**デフォルトの名無しさん** · 2021/01/21(木) 06:01:52.78

Haskellで厳しく性能を最適化しようとすると
抽象的なところで実装を意識したコードを書くことになって苦労する
みたいなレビューがあった

Haskellはベンチ結果良いように見えて
その手の「実装を意識したコード」がベンチ用に書かれるからで
実際は割と遅めなんだな

**デフォルトの名無しさん** · 2021/01/21(木) 06:07:07.88

>>667
そのレビューのURLを貼っていただけないでしょうか

**デフォルトの名無しさん** · 2021/01/21(木) 06:30:57.22

https://stackoverflow.com/questions/35027952/why-is-haskell-ghc-so-darn-fast
この辺
> thanks for the link.
80 lines is what I called "low-level style of programming not much different than
programming in C itself." . "the higher level code",
that would be the "stupid" fmap (length &&& length .
words &&& length . lines) readFile.
If that was faster than (or even comparable to) C,
the hype here would be totally justified then.
We still need to work hard for speed in Haskell as in C, is the point.

>>605もそんなことをかいてる

**デフォルトの名無しさん** · 2021/01/21(木) 06:38:11.58

以下の厳密というのは遅延評価じゃなくするという事だろう？
しかも「プロファイルを作成して改善」は一度アプリを書いてから実行の様子を観察して最適化していくという事だろう。
抽象的にHaskellらしく書いていきなり速いというわけではないという事だ。
プロファイラーでボトルネックを特定して特殊なコードに変えていけば速くなる、と。

＞はい、怠惰はおそらくナイーブなHaskellが遅い最大の理由であり、
最適化されたHaskellでさえ速度の点で信頼できない可能性があります。
そのため、パフォーマンスが重要なアプリケーションにはお勧めしません。
OCamlの方が適しています。繰り返しになりますが、
HaskellをBangPatternsなどで厳密にすることはそれほど難しくありません。
また、コードの読み取りや保守が難しくなることもありません。
したがって、パフォーマンスが望ましいが、遅いプロトタイプでも問題がない場合は、
Haskellが非常に良い選択です。うまく機能するものを一緒にハックしてから、
プロファイルを作成して改善します。

**デフォルトの名無しさん** · 2021/01/21(木) 08:18:51.22

こういう認識
・Haskellはコードだけでは最適化ポイントを見つけれない
・最適化したら変なコードになる
・普通のHaskellコードはベンチで他言語に惨敗する

**デフォルトの名無しさん** · 2021/01/21(木) 09:21:08.07

これも
・最適化の方法が処理系（GHC)次第で決まり、プログラマーの認識内に無い。
GHCに対してひたすらトライアンドエラー

**デフォルトの名無しさん** · 2021/01/21(木) 21:44:08.46

・Haskellが欲しかったポジションはなんかPythonにとられてしまった

**デフォルトの名無しさん** · 2021/01/22(金) 00:20:12.86

HaskellとPythonは似ていないから両方使ってもDRYに違反しない

似たもの同士で馴れ合い、異質なもの同士を分断するやつは信用できないが
Pythonは似たもの同士でしっかり競争して生き残ったやつだから信用できる

**デフォルトの名無しさん** · 2021/01/22(金) 01:34:45.31

pythonがなかったとしてもhaskellがそのポジションになることはなかっただろう

**デフォルトの名無しさん** · 2021/01/22(金) 02:27:11.57

欲しかったHaskell
・型を最大限に活用、バグが無いことを保証しつつ自然にC言語並みの性能も出る

**デフォルトの名無しさん** · 2021/01/22(金) 08:04:15.32

Haskellerのキモオタ「ｼｸﾞﾈﾁｬｧ」

**デフォルトの名無しさん** · 2021/01/22(金) 12:35:37.28

醜悪な表現が得意な奴って、綺麗な表現だとポエムとか言われる恐怖を煽られた結果なのかなと
ふと思った

**デフォルトの名無しさん** · 2021/01/23(土) 13:17:02.46

>>665
ListT を使えばと思ったけどだめだった。
・参考
https://blog.mudatobunka.org/entry/2018/01/03/233314
・残骸
module Rand2 where

-- stack install list-t
-- stack exec ghci

import Control.Monad.IO.Class ( liftIO )
import ListT ( ListT, toList )
import System.Random ( Random(randomIO, randomRIO) )

t1 :: ListT IO Int
t1 = return 3

t2 :: ListT IO Int
t2 = liftIO (randomIO :: IO Int)

t3 :: ListT IO [Int]
t3 = repeat <$> t2

output :: ListT IO [Int] -> IO ()
output t3 = do
li0 <- toList t3
print $ take 10 $ head li0

**デフォルトの名無しさん** · 2021/01/23(土) 22:12:27.68

>>679
できたー！
module Rand2 where

-- stack install list-t
-- stack exec ghci

import Control.Monad.IO.Class ( liftIO )
import ListT ( ListT, toList, cons, take )
import System.Random ( Random(randomIO) )

t2 :: ListT IO Int
t2 = liftIO (randomIO :: IO Int)

t3 :: ListT IO Int
t3 = do
x <- t2
cons x t3

output :: IO ()
output = do
li <- toList $ ListT.take 10 t3
print li

{-
*Rand2> output
[7616927328998369033,6970782903781268443,-1509938769401207081,-2789264750098693865,-6524417077297424569,8403979199680420436,-3097298192134792937,-2736699795503652525,-4754186463647322678,5658901448509988002]
-}

**デフォルトの名無しさん** · 2021/01/24(日) 10:57:12.77

自分の理解が根本的に間違ってるかもしれんけど
haskellは宣言型で実効順序が定まっていないみたいな話を聞いたんだけど
do記法は普通に上から下に実行されるというイメージになるの？

main = do
x <- readLn
x2 <- readLn

こういう風に書いた場合、最初に入力したものがxに入り、その順番は入れ替えれないはず
do記法はほとんど命令型じゃないの？

IOモナドとかに入力されていくアクション列はその順番を入れ替えれないよね？
どんな感じでコーディングされてるか知らないけど
副作用があるところでは順番を入れ替えれないはず、即ち命令型と大差ないはず

**デフォルトの名無しさん** · 2021/01/24(日) 12:14:30.84

>>680
おお、できるんですか！？
すげー
残念ながらいまListT使えないので環境整理してやってみます

**デフォルトの名無しさん** · 2021/01/24(日) 13:21:27.07

>>681
do記法という言語機能は、上から下への命令の実行を記述するものではない
モナドの組み合わせ方を宣言しているだけ
IOのようなモナドの定義に対してはたまたま命令型言語のようになるだけ
言語レベルで命令を上から下へ実行しているわけではない

**デフォルトの名無しさん** · 2021/01/24(日) 15:49:32.04

じゃあ標準入力から来た文字列の1行目と2行目を分けて扱うにはどう書くの？

**デフォルトの名無しさん** · 2021/01/24(日) 16:19:42.60

ListT.toListの引数には有限のリストしか渡せないんだろう多分
現に
li <- toList t3
print (take 10 li)
ではなく
li <- toList $ ListT.take 10 t3
print li
と書いてある

**デフォルトの名無しさん** · 2021/01/24(日) 16:51:40.79

>>685
> ListT.toListの引数には有限のリストしか渡せないんだろう多分
> 現に
> li <- toList t3
> print (take 10 li)
> ではなく
> li <- toList $ ListT.take 10 t3
> print li
> と書いてある

確認したところ、おっしゃる通り、
前者では応答が返ってきませんでした。
（ListT.repeat でも同じ結果だったので、t3 が悪いのではないです）

> ListT.toListの引数には有限のリストしか渡せないんだろう多分
これで合っていると思います。

**デフォルトの名無しさん** · 2021/01/24(日) 23:50:31.64

やっぱり無理なんですかねぇ？
例えば以下は通るので ”IO 無限リスト” が原理的に無理なわけではないとは思うんですけど

list = return $ repeat '3'

main = do
x <- list
print $ take 10 x

何がどう違うもんなんでしょう？

**デフォルトの名無しさん** · 2021/01/25(月) 09:17:23.58

すいません
無限ランダム整数列の件ですが方法がありました
というかSystem.Randomの中に最初から用意されてました
自作でランダム有限列作っておられた方のブログ見つけたので無限列なんて用意されてないとすっかり思い込んでました
以下の方法で1～10の長さ100の乱数列が簡単に作れるようです
第一引数に値の範囲、第二引数に乱数の種を仕込みます
乱数の種は
mkStdGen :: Int -> StdGen
や
getStdGen :: IO StdGen
newStdGen :: IO StdGenSource
で作成すれば良いようです
乱数の型はIntだけでなくDoubleなどでも作れるようです

----
import System.Random

randomInts :: StdGen -> [ Int ]
randomInts = randomRs (1,10)

main = do
ris <- ( return . randomInts ) =<< getStdGen
print $ take 100 ris

**デフォルトの名無しさん** · 2021/01/25(月) 09:36:17.94

種が IO だから、
randomRs の戻りは [a] なんだね

**デフォルトの名無しさん** · 2021/01/25(月) 11:51:44.88

ライブラリは暗記ですが、数学は暗記ですか？っていう定番のあれだな

**デフォルトの名無しさん** · 2021/01/25(月) 13:32:32.62

>>684
newStdGen :: IO StdGenSource
↑ワロタw
コピペするとよくあるわw

**デフォルトの名無しさん** · 2021/01/25(月) 13:33:07.46

安価ミス>>688

**デフォルトの名無しさん** · 2021/01/27(水) 00:16:50.20

dp の質問です
haskell でdynamic programing する方法の例でFibonacci数列の計算を

fib = 0:1:( zipWith ( + ) ( drop 0 fib ) ( drop 1 fib ) )

で計算させるというテクニックを紹介しているページがあってなるほどなぁと感心しました
で同じテクニック使ってcomb6 !!i !! jが二項係数C[i, j]になる配列

comb6 = ( ( 1 : ( repeat 0 ) ) : )
$ zipWith ( zipWith ( + ) ) comb6 ( map ( 0 : ) comb6 )

を作ってみました
コレはうまくいきます
comb6 !! 2000 !! 1000
とかも一瞬で計算してくれます
でcomb7 !! i !! j が二項係数C[ i+ j, i ]となる配列comb7を

comb7 = ( ( repeat 1 ) : )
$ zipWith ( zipWith ( + ) )
( comb7 )
( tail $ map ( 1 : ) $ comb7 )

と定義してやってみると、compileまでは通るのですが実行comb!!1!!0すると<<loop>>と言われて止まってしまいます
しかし手計算で展開してみてもloopしてないと思うんですけどどこがおかしいのかわかりません
どなたかわかりませんでしょうか？

**デフォルトの名無しさん** · 2021/01/27(水) 11:32:01.04

comb7 = x : xs
xs = zipWith f comb7 ys
ys = tail zs
zs = map g comb7
zs = map g (x : xs)
= g x : map g xs
ys = tail (g x : map g xs)
= map g xs
xs = zipWith f comb7 (map g xs) -- ここで(map g xs)のパターンマッチができない

**デフォルトの名無しさん** · 2021/01/27(水) 12:36:29.90

>>694
ありがとうございます
しかしどうもパターンマッチに失敗してるようではないようです
実際コンパイラは型推論に成功してるように見えますし、明示的に
comb7 :: [[ Int ]]
を入れてもダメです
実行時のエラーメッセージも
Non-exhaustive patterns
ではなく
prog : << loop >>
が表示されています

**デフォルトの名無しさん** · 2021/01/27(水) 13:52:31.92

こういう時は自分の考えに自信を持つことも必要
誰かがエラーメッセージを見ている（または見ていない）のを見たからといって簡単に考えを変えない方がいい

**デフォルトの名無しさん** · 2021/02/02(火) 01:48:19.32

fixの定義は fix f = let x = f x in x となっていますが、
この x 自体は再帰的に定義されていると言えますか？

**デフォルトの名無しさん** · 2021/02/02(火) 16:19:31.38

>>693
xs0 = repeat 1
xs1 = zipWith (+) xs0 (0:xs1)
xs2 = zipWith (+) xs1 (0:xs2)
xs3 = zipWith (+) xs2 (0:xs3)

こんな感じに個別に定義すれば確かに計算できるので、
comb7 !! 1 を計算するのにcomb7 !! 1 が必要だぞという点を
怒っているような気がするのだが確かなことは言えない、すまぬ

comb6 !! n は計算するのに comb !! (n-1) の情報だけで十分なところが違うので

**デフォルトの名無しさん** · 2021/02/02(火) 17:58:42.89

>>697
再帰的と言うのは木構造を想定している気がする
そのコードはグラフ簡約のためにそうなったので木構造でも再帰的でもないと思う

**デフォルトの名無しさん** · 2021/02/02(火) 22:40:39.64

>>698
ありがとうございます
私も多分それが原因かなと思い始めてます
一回目のcomb7 !! 1 と二回目では続く添字が! !!2 から !!1 に減ってるのですがHaskellはそんな事は勘案せずに「comb7 !! 1の展開の中にcomb7 !! 1が出てきたからアウト」と言ってるのかなと
つまりはこの手の二重漸化式はHaskellはそのままズバリでは読んでくれないんでしょうね

**デフォルトの名無しさん** · 2021/02/03(水) 00:23:45.54

comb7 !! 1 を計算するには length comb7 >= 2 のようなものが必要だぞ
でも長さは1かもしれないからアウトという判断は正しい
オーバーランするよりよっぽどいい