関数型プログラミング言語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/11/02(月) 00:43:43.72

---- エラーメッセージ
Haskell Online Compiler [ghc-8.4.4]
Copyright (c) The University of Glasgow

Compiling your program...

[1 of 1] Compiling Main ( prog.hs, prog.o )

prog.hs:6:47: error:
• No instance for (Num (Parser Int))
arising from the 'deriving' clause of a data type declaration
Possible fix:
use a standalone 'deriving instance' declaration,
so you can specify the instance context yourself
• When deriving the instance for (Num ParserInt)
|
6 | newtype ParserInt = PI (Parser Int) deriving (Num)
| ^^^

**デフォルトの名無しさん** · 2020/11/02(月) 21:44:04.17

こうすりゃ無理やり通すことはできるけど、
そもそもパーサ同士の足し算等々でどう動いて欲しいのか分からんから
まともなインスタンス宣言が書けん

{-# LANGUAGE FlexibleInstances #-}
instance Num (Parser Int) where
　x + y = x
　x * y = x
　abs x = x
　signum x = x
　negate x = x
　fromInteger n = return 0

**デフォルトの名無しさん** · 2020/11/02(月) 23:56:16.57

>>552
元は別スレに出てた問題で
「与えられた文字列の中で“trickと"treat”どっちが先に出てくるか判定せよ」
なんです
とりあえずparserを与える関数として
makeP = mconcat . map ( manyTill anyChar . char )
でできました
コレを例えば"abc"にapplyするとmtl = manyTill、ac=anyCharとして
(mtl ac $ char 'a') <> (mtl ac $ char 'b') <> (mtl ac $ char 'c'>
というparserになりコレにhiajklbcnという文字列をparseするとhijklとabcが出現するするまでに読み飛ばした文字列を返してくれます
それでお題の答えとしてparseの結果を
lastInd x s = case ( runParser ( makeP x ) () "" s ) of
Left _ -> ( [ 2, 0 ] , x )
Right y -> ( [ 0, length $ x ++ y ], x )
のようにしてlengthで数えたんです
しかしちょっと冗長なかんじがします
そもそも読み飛ばした文字列なんか欲しいわけではなく読み飛ばした文字数が欲しいだけだからほんとは
Parser String 型ではなく例えば
length <$> ( manyTill anyChar ( char 'x')
とかのParser Intで十分です
問題はコレをどうやって繋げて総和を返すコンビネータを作ろうかというところなんです
Parser Stringはmonoid型を持ってるのでmconcat一発で繋げられるんですがParser IntはNum持ってないのでsum一発で繋げるというわけにはいかないんです
なんとかできないかと探してみるとなんか「Numをderivingする」という記事を見つけて、お、コレでいけないかと色々やってみたんですがやはりParser Intにderiving一髪でNum入れる方法見つからなくてなんとかならんもんかと

**デフォルトの名無しさん** · 2020/11/03(火) 01:59:40.73

わざわざNumのインスタンスにしなくても、これでいいのでは
makeP = fmap sum . mapM ( fmap length . manyTill anyChar . char )

**デフォルトの名無しさん** · 2020/11/03(火) 10:26:04.44

>>554
うん、まぁ別にNumのインスタンス入れなくてもこの問題の話だけならいくらでも方法はあると思うんだけど、そもそもモナドってもこういう時のためにあるんじゃないのかなと思って
例えば(+)なら Num a,Functor f のとき Num (f a)は自然には導出できない、なぜなら fmap (+) は f a -> f ( a - > a ) になってしまう
しかし Applicative f なら lifaA2 (+) がピッタリ f a -> f a -> f a になって自然にキレイに Num (f a) が導出できる
だからすごく理論的には自然なのに方法がないのは何故なんだろうと
というかderiving (...) の (...) にかけるやつとダメなやつの基準がわからない
実用本位でよく使うやつだけ用意されてるに過ぎないのかな？

**デフォルトの名無しさん** · 2020/11/03(火) 11:32:34.46

一応、Num (f a)は導出できるけど、それで定義した(+)だと
交換則(x + y = y + x)が成り立つ保証がないからじゃないかねぇ
(パーサの順番を入れ替えた場合を考えるとわかりやすい)

{-# LANGUAGE FlexibleInstances #-}
instance (Num a, Applicative f) => Num (f a) where
　x + y = (+) <$> x <*> y
　x * y = (*) <$> x <*> y
　abs x = abs <$> x
　signum x = signum <$> x
　negate x = negate <$> x
　fromInteger n = pure $ fromInteger n

**デフォルトの名無しさん** · 2020/11/03(火) 11:50:57.17

>>556
なるほど、文法的に通っても意味的に文法には出てこない"Num rule"が補償されないからダメって事なのかな？
まぁ今はclassのメンバ関数の自分が利用するやつだけ定義する必要無くなったみたいだから手で書いてもいいんだけど、>>550の例だと

newtype Eval a = Eval (ReaderT Env (ExceptT String Identity) a)
deriving (Functor, Applicative, Monad, MonadReader Env, MonadError String)

とかはmonad translater越しにできるし

newtype Quantity = Quantity Int
deriving (Eq, Ord, Num, Show)

もできるのになんで Parser (Int) はあかんねんと
なんかプラクマつけたらいけんもんかと
Num くらいならいいけど Floating とかだと惨劇になってしまう

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

この話の面白いところは
Parser Intという型を宣言する言語と
そもそも型を宣言しない言語
どっちが生産性高いかってことだよ

**!id:ignore** · 2020/11/06(金) 20:16:57.19

stackくんさぁ、コンパイラのダウンロードが200MB強あるんだから、低速回線は途中で切断されるとかよくありそうなことじゃん
サスペンド・レジューム機能搭載は必須じゃないのかね
きょうびyoutube-dlでさえ向こうに切断Forbiddenされても今までダウンロードした分は残ってて、再度ダウンロードを開始した際には途中から残りの部分をダウンロードすように始まるってのにさ
仮に205.86 MiB / 205.87 MiBまで来て切断された場合
リトライすると0 MiB / 205.87 MiB からだなんてお互い不幸になると思わないのか？
こっちは成功するまで永遠に繰り返すんだぞ？　むしろそっちの方がそちらにとっても迷惑じゃん
それとも低速回線は死ねっていう差別的思想を持っているのかね？

**デフォルトの名無しさん** · 2020/11/08(日) 11:31:57.94

一方TeXはisoイメージを使った

**デフォルトの名無しさん** · 2020/11/08(日) 13:05:47.79

パターンガードの変数の束縛は局所的なのですが、全ての場合で共通して使用してほしい束縛はどうやりますか？

**デフォルトの名無しさん** · 2020/11/09(月) 01:15:49.21

>>561
質問の意味がよく分からないのだが、コード例を出せる？
こんな風に書けたらいいのに、みたいな。

**デフォルトの名無しさん** · 2020/11/09(月) 19:55:38.03

rootsInternal :: Quadratic -> Double -> Roots

rootsInternal q d

　= let

　　　　two_a　　　= 2.0 * (a q)

　　　　realpart　　= - (b q) / two_a

　　　　dside d　　= (sqrt d) / two_a

　　　　dpart　　　= dside d

　　　　complexpart = dside (-d)

　　in if d==0

　　　　then　　　-- Discriminant is zero, (single) root is real

　　　　　　Root $ realpart :+ 0

　　　　else

　　　　if d<0

　　　　then　　　-- Discriminant is negative, roots are complex

　　　　　　Roots (realpart :+ complexpart) (realpart :+ (-complexpart))

　　　　else　　　-- Discriminant is positive, all roots are real

　　　　　　Roots ((realpart + dpart) :+ 0) ((realpart - dpart) :+ 0)

のlet ～ in みたいなのを

rootsInternal q d
　|　d==0　　　= ...
　|　d<0　　　　= ...
　|　otherwise　= ...

みたいな書き方の時にもやりたいんです

**デフォルトの名無しさん** · 2020/11/09(月) 19:58:42.43

おっと無用な改行が一々入っちゃった。。。

**デフォルトの名無しさん** · 2020/11/09(月) 20:20:48.18

>>563-564
where で出来なかったっけ？だめだったかな？

**デフォルトの名無しさん** · 2020/11/09(月) 21:00:20.89

あ、できました。
お騒がせしました（////)

**デフォルトの名無しさん** · 2020/11/11(水) 19:20:13.76

正格評価について質問です

ひとつの引数しかない関数 f を正格評価するときには

f $! x

でよいようですが2引数の場合はどうするんですか？

( f $! x ) $! y

で x, y を先に展開してくれますか？
良さげなんですがどう確かめたものやら
なんか正格評価と遅延評価で格段に計算量が変わる f の例ってありますか？

**デフォルトの名無しさん** · 2020/11/11(水) 21:38:04.29

遅延評価がなくてもGCはメモリ解放を遅らせている
GCをいじるにはIOが必要

$!を使うのにも少なくともモナドが必要と考えるのが自然なのでは？
x' <- return $! x
y' <- return $! y
return $! (f x' y')

**デフォルトの名無しさん** · 2020/11/11(水) 22:07:05.86

>>568
そうなんですか？
とりあえずモナドで試してみます
兎にも角にも正格評価と遅延評価でこんなに計算の回数が違ってくるってのなんかご存知ないですか？
例えばdpの例でFibonacciを

f 0 = 0
f 1 = 1
f n = (f $ n-1) + (f $ n-2)

と

f' 0 = (0,1)
f' n = (a+b,a) where (a,b) = f' (n-1)
f = fst . f'

で比べると目に見えて計算量が違うみたいな奴で「正格評価が効いてる」って目に見えてわかるような例があるとありがたいんですが

**デフォルトの名無しさん** · 2020/11/12(木) 14:57:12.09

正格評価と遅延評価で計算量が変わるといえばtaraiじゃね？

**デフォルトの名無しさん** · 2020/11/12(木) 23:16:18.57

⊥になるものでいいじゃん

**デフォルトの名無しさん** · 2020/11/13(金) 06:27:56.29

trace や unsafePerformIO で評価順を調べられないかな

**デフォルトの名無しさん** · 2020/11/13(金) 12:04:46.50

みなさん情報ありがとうございます
今んとこヒマな時にやってみた実現は

cube x = x*x*x

a x = case x of
0 -> 0
1 -> 1
_ -> ( a $ x -1 ) + ( a $ x - 2 )

main = do
tA <- getCPUTime
print $ cube $ a 38
tB <- getCPUTime
print $ tB - tA

と

print $ cube $ a 38 → print $ a 38

の比較
結果
----
59722225363795389930809
3801127096000
----
39088169
3514055718000

この程度だとコンパイラが勝手にメモ化してくれるようで差がでないorz
まだタライとかは試して見てません
取り急ぎご報告まで

**デフォルトの名無しさん** · 2020/11/16(月) 23:33:39.07

>>567
もうとっくに解決したかもしれませんが、評価の順は trace 関数でも確認できます。

import Debug.Trace

g :: Int -> Int -> Int
g x y = trace ("g") (x + y)

main :: IO ()
main = do
let a = trace ("a") 1
let b = trace ("b") 2
let c = (g $! a) $! b
putStrLn $ show c

これを実行すれば、b a g 3 の順に出力されます。
正格評価されていると言えます。

ちなみに、($!) を ($) に変えれば、g a b 3 の順に出力されます。

**デフォルトの名無しさん** · 2020/11/18(水) 01:05:30.21

>>574
イヤ、まだ奮闘中です
おぉ、そんな便利なものが
使ってみます

**デフォルトの名無しさん** · 2020/11/21(土) 23:31:14.57

Haskellはライブラリの中身を覗くと
Template Haskellを駆使した
グッチャグチャの実質別言語みたいなコードがザラなのがなぁ・・・
水面下の白鳥状態じゃねーか

**デフォルトの名無しさん** · 2020/11/22(日) 16:59:26.57

ゴミライブラリ使うのやめて良いやつ作って公開してくれ

**デフォルトの名無しさん** · 2020/11/22(日) 17:19:45.03

在学中か学校出たての経験浅い奴しか担い手がいないのだろうからそんなもんなんだろう

純粋関数型言語は学生がかかるはしかみたいなもので
やがて計算機科学の現状に絶望し去ってゆく
現在のコンピューターは手続き型に最適化されているのだ

**デフォルトの名無しさん** · 2020/11/22(日) 18:37:00.71

単純に関数型言語がわかる人が少なすぎるからじゃないの？

**デフォルトの名無しさん** · 2020/11/22(日) 20:14:41.06

居飛車党と振り飛車党の闘いは続く

**デフォルトの名無しさん** · 2020/11/23(月) 02:58:53.25

イヤ、まぁ純粋に速度とか効率とか考えたら手続き型言語の方が優位なのはその通りでしょ？
だって現在の計算機がノイマン型の手続き型の処理をするために設計されてるんだから
そりゃバリバリにチューニングしたら手続き型言語には絶対勝てない
その時代時代の最新の計算機の性能をフル活用しないとできないような処理は当面関数型言語の出番は回ってこない
しかしそこまでの処理でないならやはり関数型言語の活躍できる場面も出てはくるだろうけど、しかし例えそうなったとしても手続き型言語も関数型言語も両方臨機応変に使いこなせるようになるとなると中々難しいから、結局どちらか選ぶなら手続き型言語という事になってしまう
しばらくは関数型言語が実務の場面でバリバリ使われるようになるのは中々難しい
当面研究者とか、サンデープログラマーの趣味の世界でしか出番ないかもしれない

**デフォルトの名無しさん** · 2020/11/23(月) 03:10:25.23

並列並行処理を型で表せる辺り、強力なんだけどなぁ

**デフォルトの名無しさん** · 2020/11/23(月) 03:19:37.79

Reditを見てると、Haskellerの求人も結構あるんだが

**デフォルトの名無しさん** · 2020/11/23(月) 12:02:25.91

居飛車と振り飛車というのは危機感が足りない
ガソリン車と電気自動車だ
個人の就職じゃなくて会社が丸ごと潰れるリスクを想定するための研究だよ

**デフォルトの名無しさん** · 2020/11/23(月) 13:19:57.85

一句できた！

『次に来る』
言われ続けて
数十年
（来ない）

**デフォルトの名無しさん** · 2020/11/23(月) 13:27:42.48

近未来
今となっては
古臭い

**デフォルトの名無しさん** · 2020/11/23(月) 13:29:17.88

>>586
いいね！

**デフォルトの名無しさん** · 2020/11/23(月) 14:40:17.74

新しいなんて嘘つくより古いものは古いものとして扱う歴史や古文の方が正しい

**デフォルトの名無しさん** · 2020/11/23(月) 20:51:18.66

関数型言語を処理するために設計されたコンピュータってどんな構造なんだろ

**デフォルトの名無しさん** · 2020/11/23(月) 21:33:53.00

みんなが数学好きで自己啓発嫌いなのは処理速度じゃなくて
嘘をつかないかどうかの問題

**デフォルトの名無しさん** · 2020/11/24(火) 01:11:11.02

>>589
LISPマシンというものがかつてありましたなあ

**デフォルトの名無しさん** · 2020/11/24(火) 03:49:22.53

JAVAチップが実現されてればスタックマシンだからFORTH最強だったのでは

**デフォルトの名無しさん** · 2020/11/24(火) 21:00:48.17

速度は実はそこまで重要じゃない
飛行機からメンテナンスハッチ取り除いて何kg軽量化しましたって言ったところで、仕事好き定量評価好きなにわかが、わかりやすい数字見て喜ぶだけで、実際はそんな嬉しい話じゃない
というかそもそももっと遅いスクリプト言語は流行ってるし

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

Haskell でゲーム開発したいんですが
FRP は死滅しちゃったの？

**デフォルトの名無しさん** · 2020/11/24(火) 21:44:37.33

>>594
死滅の意味がよく分からんが、問題なく使える。
stackageにもあるでしょ。

それはそうと、なんで初めから難しいFRPを使おうとするの？
普通に素直に設計して作ってみればいいのに。

**デフォルトの名無しさん** · 2020/11/30(月) 15:39:12.43

bind演算子の名前の由来ってなに？
なにも束縛してなくね？

**デフォルトの名無しさん** · 2020/11/30(月) 17:26:29.13

a >>= b
がdo記法で
do
x <- a
b x
みたいになるからじゃね？

**デフォルトの名無しさん** · 2020/11/30(月) 21:06:13.38

(>>) これも bind と言うよ

**デフォルトの名無しさん** · 2020/12/02(水) 00:25:53.39

ここで聞いていいのかわからないけど…
Nixのいいチュートリアルとかってある？

**デフォルトの名無しさん** · 2020/12/04(金) 21:16:59.61

これとかどう？

https://github.com/Gabriel439/haskell-nix

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

ブログ書いてたら彼女と無料で海外留学という名のデートに行けた話【影響力やばい】
https://www.youtube.com/watch?v=Y8Q1z3Mi7BQ
若いうちから人を雇ったり、任せるクセをつけるべき理由とは？
https://www.youtube.com/watch?v=6yAvDQxhldI
【対談】インフルエンサーマーケティングに300万円突っ込んでみた結果...
https://www.youtube.com/watch?v=AMjWD0F8PLQ
収入を上げたければ、自分の影分身を作るべし
https://www.youtube.com/watch?v=V3Kc-lUxH88
勉強のために10日間で21個のアプリを作った話【初心者時のプログラミング学習】
https://www.youtube.com/watch?v=JkN5kmR9dgk
学校では教えてくれないことの中にはお宝が眠っている
https://www.youtube.com/watch?v=oq92u9nJ7FY
ブロガーからステップアップしていくために必要なスキル
https://www.youtube.com/watch?v=F6qsOyRIaQE

**デフォルトの名無しさん** · 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 ってどういう意味？