関数型プログラミング言語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/02/12(水) 08:25:26.33

昔話Project Eulerをhaskellで解くのに同じ役割の関数を自作した記憶がある

**デフォルトの名無しさん** · 2020/02/12(水) 13:37:04.81

そもそも天才じゃないとやりたいことが出来ない言語ってどうなんだ

**デフォルトの名無しさん** · 2020/02/12(水) 13:53:42.16

別に他の言語でも10倍量書けば同じことが出来るんだから使わなければいいだけ
共同作業の時は困るから天才だけでチーム組んでもらえばいい

**デフォルトの名無しさん** · 2020/02/12(水) 14:24:47.66

凡才も天才もほぼ同様に書けるpythonのような素晴らしい言語より、
凡才でも拙く書けるけど天才ならシンプルに書けるhaskellのような素人お断りな言語の方が好き。

魔法みたいで中二心をくすぐられるし、学ぶ意欲がわく。

まぁ、仕事の道具としては迷わず前者を使うけど。

**デフォルトの名無しさん** · 2020/02/12(水) 20:45:42.48

>>9
Rなら同様の関数をもっと短く分かりやすく書ける。

diagonals <- function(A) lapply(2:sum(dim(A)), function(i) A[row(A) + col(A) == i])

diagonals(matrix(1:12, 3, 4, byrow = TRUE))

これで [[1], [5,2], [9,6,3], [10,7,4], [11,8], [12]] というベクトルのリストが
生成される。

>>16
そうだな。プログラミング言語は問題を解くための道具だが、Haskellの場合、
プログラミング言語自体が解くための問題になっている感じ。

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

Haskellの書き方極めればC言語に匹敵する速度が出せるって聞いたんだけどマジ？

**デフォルトの名無しさん** · 2020/02/13(木) 00:18:51.95

>>18
嘘

**デフォルトの名無しさん** · 2020/02/13(木) 02:31:41.26

>>17
短さはともかく解りやすさは一概には言えないと思う。こんなのはどうかな
l = take 3 . unfoldr (Just . splitAt 4) $ [1..12]
diagonals l = map catMaybes . transpose $ zipWith (<>) (inits . repeat $ Nothing) (map (map Just) l)

> プログラミング言語は問題を解くための道具だが、Haskellの場合、
> プログラミング言語自体が解くための問題になっている感じ。
これは言い得ていると思う。Haskell の色んな所に入り込んだ抽象化のおかげで、
従来、アプリを作る末端のプログラマーが各々処理していた仕事が、ライブラリやコンパイラ側に吸い上げられる。
だから全体としての仕事の総量は少なくなる。でもそのかわり、ある程度書けるためにはベースの抽象に慣れる必要がある。
fmapってなに/モナドってなに/Foldableってなに/Lazyってなに... 学習コストは他の言語に比べてずっと高い。

>19
> Haskellの書き方極めればC言語に匹敵する速度が出せる
可能だよ
https://chrispenner.ca/posts/wc

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

>>20
それ前にも紹介されてて俺もすげーなと思ったが、よく考えると、
じゃあ今wcやlsのようなLinuxコマンドをhaskellで書きたいかと聞かれれば、
べつにいいやと応える。

もっとこう、せめてSwichやPS4のインディーズゲームや、
窓の杜の人気編集ソフトレベルのアプリで、
Cと張り合う猛者は居ないのかな。

Darcsだって肝心の速度ではgitに敵わなかったわけだし。

前に、ブロック崩しでCと比較した人が居たような気がしたが、
どこのページだったかな。

**デフォルトの名無しさん** · 2020/02/13(木) 16:46:02.30

>>21
俺はコマンドラインユーティリティを Haskell で作るのイイナって思ってる。
型の恩恵でヘルプとか書き漏らさないし、単純な計算なら自動でコマンド化できるっぽい。

Haskell 製のゲームは何故かとても少ない。こちらとか
https://store.steampowered.com/app/591640/Light_It/?l=japanese

beatmaniaのような音ゲーを120行で実装するって触れ込みのチュートリアル
http://fumieval.github.io/rhythm-game-tutorial/ja.html

**デフォルトの名無しさん** · 2020/02/13(木) 17:49:26.84

>>9
Rubyだと

def diagonals(a)
m = a.size
n = a[0].size
a.flatten.group_by.with_index{|v,i| i/m+i%n}.values
end

**デフォルトの名無しさん** · 2020/02/14(金) 14:43:09.16

Haskellで書かれた他人のコードって詠みにくいと思うのは俺だけか？
型クラスやモナドが難しいというより、何がどこで定義されてるかよくわからんし、どういう動作をする関数なのかがぱっと見でわからん。

**デフォルトの名無しさん** · 2020/02/14(金) 16:56:30.18

言語というより、可読性に対する意識の問題だと思うよ
みんな薄々読みにくいと思ってるけど、互いに頭悪いと思われてマウント取られるのが怖くて言い出せないから、読みにくいコードはいつまでも読みにくいまま
実用言語では「俺が読めないのは書いた奴が悪い」が基本なので、互いに指摘しあうことで自然と改善されていく

**デフォルトの名無しさん** · 2020/02/14(金) 16:59:16.33

>>24
千差万別としか言いようがない。
Github や hackage にあるコードを見ても、分かりやすいものもあれば、そうでないものもある。
CやJava、Python などと比べて、特に差は無いように思えるが。

何かが定義されている場所は同じモジュール内か、さもなくばインポートしているモジュール内なんだから、
検索すれば見つかるでしょ。
よくわからん、という意味がよくわからん。

動作がぱっと見でわからんというのは、それこそhaskellに限った話ではないのでは？
言語の習熟度や、そのコードで解いている問題のジャンルにもよるでしょ。

**デフォルトの名無しさん** · 2020/02/15(土) 10:44:39.37

The build process was killed (i.e. SIGKILL). The typical reason
for this is that there is not enough memory available (e.g. the OS killed a
process using lots of memory).
へんなエラーが出来て今までコンパイルできなものが急にできなくなった
Haskellは最悪
もう使いたくない

**デフォルトの名無しさん** · 2020/02/15(土) 10:58:18.94

頭が悪い奴が作るとすぐメモリ不足になると死んだじっちゃんが言っていた

**デフォルトの名無しさん** · 2020/02/15(土) 12:35:42.03

テンプレートハスケルをつかったでっかいソースだからなるのかな
一つのファイルコンパイルするのに１０分位掛かるんだけど
分割するようにすればなおる？

**デフォルトの名無しさん** · 2020/02/15(土) 14:01:44.69

>>24
問題の関数を使っているモジュールをghciにロードして:iコマンド使えば、
それがどのモジュールで定義されているのか分かるが、
そう言うことではなく？

**デフォルトの名無しさん** · 2020/02/15(土) 16:54:40.60

GHC本体も重いけどhaddockもクソ重なんだよなぁ…
Haskellで実用的なプログラムは書けないということなのか、
単にhaddockの設計がアレなのか…

**デフォルトの名無しさん** · 2020/02/15(土) 17:37:02.81

ちょいとしたwebサーバーなら良いかもと思うがそれならほかの選択肢があるんだよな。。

**デフォルトの名無しさん** · 2020/02/15(土) 17:41:30.59

cabalのbaseのバージョンって指定しないとぶっ壊れてコンパイルできなくなるんだな
ハスケルには罠が多すぎる

**デフォルトの名無しさん** · 2020/02/15(土) 18:24:38.72

お前らのマシンスペックは？

**デフォルトの名無しさん** · 2020/02/15(土) 18:44:53.36

>>33
ふーむ
cabal ファイルに書くパッケージのバージョン制限は、
その範囲ならなんでもビルドできますよ、サポートしてますよってサイン。
だから base 含め妥当なバージョンを書いておくべきってのは言えるけど…

状況はリビルドしただけで依存パッケージのバージョンが上がって壊れた、みたいな感じかな？
cabalってそんな風に動作するんだっけか

**デフォルトの名無しさん** · 2020/02/15(土) 22:05:32.62

>>31
全パッケージの情報をメモリに保持してるんじゃ重くもなるよね…
全部メモリに載ればいいけどそうでなければスラッシングの嵐…
https://github.com/haskell/haddock/issues/462#issuecomment-375822456

**デフォルトの名無しさん** · 2020/02/15(土) 22:07:07.48

苦節1ヶ月ようやく一歩前進
Haskellがどういう言語か垣間見た気がする

**デフォルトの名無しさん** · 2020/02/15(土) 23:05:59.57

>>24
「読みにくい」ではなくて「詠みにくい」かｗ

**デフォルトの名無しさん** · 2020/02/17(月) 22:23:26.89

よっしゃ～
JSONパーサーが一応完成！！
長かった…TT

**デフォルトの名無しさん** · 2020/02/18(火) 01:39:25.24

おーおめでとう～

**デフォルトの名無しさん** · 2020/02/18(火) 05:30:54.79

>>39
Githubで公開しようぜ

**デフォルトの名無しさん** · 2020/02/18(火) 19:15:31.61

>>40
あざっす
>>41
コンバーターを作る前段階としてのパーサーなのでコンバーターとして完成したら公開する予定です
今はdo、コピペ多用で見苦しいことになってますしｗｗｗ

**デフォルトの名無しさん** · 2020/02/27(木) 10:14:58.86

PowerShellのリダイレクトに悩まされた
プログラムやHaskell側のエンコーディングの問題かと思ったらPowerShellの問題だった

**デフォルトの名無しさん** · 2020/02/28(金) 00:06:13.33

ハスケルむずくて嫌い
OOPっぽく拡張可能にしようとするとつい存在量化したくなってわけわからなくなる

**デフォルトの名無しさん** · 2020/02/28(金) 01:47:53.28

>>44
目標や方針を明確にしないでなんとなくプログラムすると、
拡張可能化に限らず訳わからなくなることが多いね。
haskellは特に。

だから俺は、面倒でもごく直近のゴールとその道筋をノートに書いてから、
コーディングするように心掛けてる。
頭の中だけで出来るヤツもいるけど、俺はまだ無理。

**デフォルトの名無しさん** · 2020/02/28(金) 04:53:58.95

Writing implicit global project config file to: C:\sr\global-project\stack.yaml
Note: You can change the snapshot via the resolver field there.
Using latest snapshot resolver: lts-15.1
Stack has not been tested with GHC versions above 8.6, and using 8.8.2, this may fail
No setup information found for ghc-8.8.2 on your platform.
This probably means a GHC bindist has not yet been added for OS key 'windows32'.
Supported versions: ghc-7.8.4, ghc-7.10.1, ghc-7.10.2, ghc-7.10.3, ghc-8.0.1, ghc-8.0.2, g
hc-8.2.1, ghc-8.2.2, ghc-8.4.1, ghc-8.4.2, ghc-8.4.3, ghc-8.4.4, ghc-8.6.1, ghc-8.6.2, ghc
-8.6.3, ghc-8.6.5

32bit版のWindowsでhaskell Stackが使えない人は
C:\sr\global-project\stack.yamlファイルの
resolver:部分をlts-13.11に変更すればghcのインストールが出来るよ。

GHC8.6.4からは32bit Windowsに対応していない
https://www.haskell.org/ghc/download.html
ページの下に「LTS 13.11 for ghc-8.6.3, published 12 months ago」と書いてあるので
stack.yamlファイルを編集してこのLTSバージョンを指定した後にstack newコマンドを実行すれば
ghcのインストールが始まるよ。
https://www.stackage.org/

**デフォルトの名無しさん** · 2020/02/28(金) 05:14:00.81

>>34
OS : Windows 8.1 32bit
CPU : Atom Z3735F 1.33GHz
RAM : 2GB
eMMC : 64GB

**デフォルトの名無しさん** · 2020/03/02(月) 10:29:59.00

今までなんとなく難しそうと思って避けてたProfunctor Opticsだけど、ようやくちゃんと勉強し始めた

**デフォルトの名無しさん** · 2020/03/02(月) 19:46:53.52

自分も面白そうなので読んでみよう。

>>48
そういうのってどこで情報を仕入れてくるん？

**デフォルトの名無しさん** · 2020/03/03(火) 00:52:57.62

>>49
自分は圏論をBartosz Milewskiの動画や本で勉強してるから、
彼のブログやTwitterがメインの情報源だなあ

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

Haskell圏論で調和解析の問題解いてんのもしかして？
盛り上がりが別のところにあるとかどういう

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

俺の推測が正しければHaskellの一番高いニーズは普通のソフト書くためじゃない。研究用だろ

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

>>50
ありがとさん。
早速、本も買ったった。

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

spacemacs（intero）からvscode（hie）に移行しました。
前者だとノーマルモード時に, s bでターミナル起動+stack ghciできてたのですが、
vscodeで同じようにやるのは、どうやったら出来ますか？

**デフォルトの名無しさん** · 2020/03/09(月) 03:54:20.18

>>54
Ctrl + @　でターミナルを開く/閉じる
かな。んで
stack exec ghci
かな。

**デフォルトの名無しさん** · 2020/03/09(月) 10:30:41.72

vimでhaskellやってる人いる？
どんな環境？

**デフォルトの名無しさん** · 2020/03/09(月) 16:04:10.40

>>56
以前はhaskell用のプラグインを色々入れてIDE構築してたけど全部消した。
Alignやvim-surroundみたいな汎用的なプラグインはいくつか入れてるけど、
今はhaskellに特化したものは何もない。

結局これが一番使いやすい。
Practical Vim を実践するだけでほぼ十分にすらすらプログラミングできる。

うるさいから、ghcidも止めた。

ウィンドウは左右に分けて左にソースコード、
右にターミナルを開いてる。
左はたまに更に上下に分けて2つのソースを開くこともあるけど一時的。
タブは俺は今のところ必要ないな（使いこなせれば便利だとは思う）。

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

勉強用だけど
vim -> markdown -> pandoc -> ipynb -> ihaskell
ihaskellはdockerに隔離してる
もしjupyterを使っているなら
ihaskellのインストールは気を付けた方が良いと思う
通常のインストールをしたらjupyterが壊れた
ihaskellの問題ではなく
pythonのパッケージマネージャーの問題かもしれない

**デフォルトの名無しさん** · 2020/03/22(日) 11:54:03.39

d:\Users\dev\development\Haskell\test-project>stack setup
Stack has not been tested with GHC versions above 8.6, and using 8.8.3, this may fail
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.
Already downloaded.
Already downloaded.
Decompressing ghc-8.8.3.tar.xz...

7-Zip 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18

Processing archive: C:\Users\dev\AppData\Local\Programs\stack\x86_64-windows\ghc-8.8.3.tar.xz

Extracting ghc-8.8.3.tar

Everything is Ok

Size: 2555330560
Compressed: 204702116
Extracting ghc-8.8.3.tar...
Extracted total of 10091 files from ghc-8.8.3.tar
C:\Users\dev\AppData\Local\Programs\stack\x86_64-windows\ghc-8.8.3-tmp4384\ghc-8.8.3\:
renamePath:MoveFileEx "C:\\Users\\dev\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.8.3-tmp4384\\ghc-8.8.3\\"
"C:\\Users\\dev\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.8.3\\": permission denied (アクセスが拒否されました。)

は？２GBも展開して書き込んでSSDの素子を疲弊させておいてエラー吐いて落ちるとか許せないんだが？
7-zip使って展開してるなら一時展開フォルダの指定させてほしいんだが？
Everything is Ok <- fuck なんだが？

**デフォルトの名無しさん** · 2020/03/22(日) 12:10:51.78

スレチなので7-zipのスレへどうぞ

**デフォルトの名無しさん** · 2020/03/22(日) 12:29:04.56

>>59
C直下にフォルダー作ってそこでやった方がいいよ
たぶん

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

ghcを解凍するフォルダのセキュリティを、Everyoneに変更許可を与えると通ったわ
なんでそうなるのかは判らん。フォルダのリネーム（もしくはフォルダ間のファイル移動）に自分以外のアカウントが関わってて、
そいつが権限持ってないから拒否されたってことになるのか

それはそうと、stackの台詞眺めてると this may fail 多いな。自信ないのかよ
そんなんじゃ頼れないよ

**デフォルトの名無しさん** · 2020/03/22(日) 15:30:18.75

stackが新しいGHC(を使うStackage LTS)で警告出す件は本家にissue出とるね
Warnings about untested GHC and Cabal
https://github.com/commercialhaskell/stack/issues/5212

stackは去年の7月以来新バージョンのリリースが止まってる
(何かいざこざがあったようなことを目にしたような覚えが…)
https://github.com/commercialhaskell/stack/releases
コミットは止まってないようだけれど
https://github.com/commercialhaskell/stack/commits/master

**デフォルトの名無しさん** · 2020/03/24(火) 18:40:03.52

謎のPermission Denied 問題の解決策は chcp 65001 かよやられた

それにしてもサンプルのビルドひとつすら乗り越えられず
あまつさえググることすら向き合えず
大望を抱いたあげく最初の石ころにつまづいて数日を無為に過ごすとは… ああ、

**デフォルトの名無しさん** · 2020/03/24(火) 22:31:38.85

ドンマイ

**デフォルトの名無しさん** · 2020/03/26(木) 16:09:50.75

Haskellって勉強しておくといいことある？

**デフォルトの名無しさん** · 2020/03/26(木) 19:26:27.91

Haskell自体はクソの役にも立たないが、Haskellを勉強すると実用言語でプログラミングする際のコードが劇的に綺麗になる

**デフォルトの名無しさん** · 2020/03/26(木) 19:37:30.96

綺麗になるんじゃなくてHaskellerにとって読みやすいコードを練成できるようになるだけでは

**デフォルトの名無しさん** · 2020/03/26(木) 20:35:55.95

数年ぶりにハスケルやったらタブはやめろって明言してくるようになっててわろうたｗｗ

**デフォルトの名無しさん** · 2020/03/26(木) 20:45:53.86

Haskellerにとって読みやすいコードわかる

MonadだのApplicativeだのを無理に再現しようとして
でも型システムがへぼいから限界あって買いてる方も楽しくないし
読む方の辛さは言わずもがなだしで誰も幸せにならない

**デフォルトの名無しさん** · 2020/03/26(木) 23:26:28.22

他言語よりも深く考察され美しくまとまった言語上の概念がものすごく多数ある
抽象的な概念が他の言語より圧倒的に多くて、プログラミング言語全般についての理解を深めるのにとても役に立つ
比較的習得難易度の高いrust等の言語や、今後出てくるであろう新手の言語等も、haskellを知っていれば習得が容易になったり、深く理解して議論できるようになったりすると思う
実用アプリ作りたいだけならあんまやる必要ない

**デフォルトの名無しさん** · 2020/03/27(金) 01:37:52.01

モナドの説明見て一気に嫌になったな・・
結局書き換えをよしとするなら純粋関数型なんて言うのやめろよと
破壊操作無くしてまともにコードが書けないってことがわかってるなら最初からそのようにしておけと
どう言う目的で作った言語なのか知らないけど読めば読むほどイライラするねこれ
現実は酷いけど理想だけが飾り立てられているという印象

**デフォルトの名無しさん** · 2020/03/27(金) 06:43:54.18

その批判は勉強不足という感じ

**デフォルトの名無しさん** · 2020/03/27(金) 07:23:52.96

そんなに間違ってはないけどな。
haskellの解釈としては「命令列」を構成して返しているから副作用はない！
副作用を起こしているのは実行系だ！
みたいな屁理屈だし。

**デフォルトの名無しさん** · 2020/03/27(金) 10:39:34.20

>>74
それhaskellの説明になってなくね？

**デフォルトの名無しさん** · 2020/03/27(金) 11:19:04.85

haskellの評価順序を考えた場合、そう解釈する以外ないと思うが。
他の説明があるなら聞きたいとこだよ。

**デフォルトの名無しさん** · 2020/03/27(金) 12:07:06.57

>>76
もう少し詳しくたのむ
評価順序を考えたらどうして命令列になんの？

**デフォルトの名無しさん** · 2020/03/27(金) 12:12:13.86

評価順序ってのは遅延評価のことか
doのことかもよくわからん

**デフォルトの名無しさん** · 2020/03/27(金) 12:16:47.55

>結局書き換えをよしとするなら純粋関数型なんて言うのやめろよと
>破壊操作無くしてまともにコードが書けないってことがわかってるなら最初からそのようにしておけと

その批判はやや的外れ
誤解してる人が多いけど、Haskellは別に破壊的代入含む非純粋な計算を禁止しようとしてるのではない
Haskellのやろうとしてるのは、純粋な計算と非純粋な計算を型システムにおいてコンパイラが区別できるようにすることだけだぞ

**デフォルトの名無しさん** · 2020/03/27(金) 12:26:56.96

というか正直モナドなんかそんな何回も何回も繰り返し議論の対象にするほどのもんでもないだろ…
HaskellスレなんだからHaskellerだけでもっとHaskellらしい話題がしたいのに、
定期的にHapkeller以外がきて水差してくよな
他の手続き方言語のスレでわざわざその言語よく知らない奴が来てifとかforの話を延々されたらどんな気分よ

**デフォルトの名無しさん** · 2020/03/27(金) 13:41:08.32

>>74は正しいの？

**デフォルトの名無しさん** · 2020/03/27(金) 16:03:17.87

正しいよ

**デフォルトの名無しさん** · 2020/03/27(金) 17:41:48.21

- Haskell自体はクソの役にも立たないが、
- 実用アプリ作りたいだけならあんまやる必要ない

何故だい? プログラミング言語なんてただの道具じゃないか。Haskellで良いプログラムが書けるなら、使うべきなんだ。
『普通のやつらの上をいけ』！『普通のやつらの上をいけ』！

**デフォルトの名無しさん** · 2020/03/27(金) 17:56:54.61

>>82
説明頼む
命令列って何なの？

**デフォルトの名無しさん** · 2020/03/27(金) 18:46:42.72

IO a は State# RealWorld -> (# State# RealWorld, a #) を newtypeしたものだって話じゃないか？
命令列っていうのはState# RealWorldの列ってことだろ、多分

**デフォルトの名無しさん** · 2020/03/27(金) 18:50:49.13

言語ではState# RealWorldの列だけ作って副作用ないけど
処理系がState# RealWorldの列を一気にフラッシュしてるから
処理系レベルでは副作用が出るって事だろ

**デフォルトの名無しさん** · 2020/03/27(金) 19:23:16.95

大体そんな感じ。
IO を返す関数が「副作用をもたない」と解釈するとしたらそう考えるしかない。
とはいえ、IO が発生する関数とそうでない関数をちゃんと分けていい感じに使うって
発想は他の言語でも役に立つ考えだからそこはいいと思う。

**デフォルトの名無しさん** · 2020/03/27(金) 19:40:29.88

>>83
目的は良いプログラムを書くことではなく役に立つプログラムを書くことだろう
お前のようにそこを履き違えてる奴が多いからHaskellがいつまでもクソの役にも立たないと言われ続けるんだよ

**デフォルトの名無しさん** · 2020/03/27(金) 19:46:20.02

まともなHaskellのテキストがIO返す関数に対して副作用がないなんて書いてるの見たことないけど…

**デフォルトの名無しさん** · 2020/03/27(金) 19:49:25.94

>>84
IOアクションのことやろ

**デフォルトの名無しさん** · 2020/03/27(金) 19:58:51.05

realworld Haskellって本のrealworldってghc におけるIOモナドの実装のこと言ってて
モナドの説明で度々出てくる『文脈』っていうのもその命令列のことだと理解してるんだが
どんなもん？

**デフォルトの名無しさん** · 2020/03/27(金) 20:03:05.86

そんな難しく考えなくても計算機に与える命令のつらなりってことじゃないの？
命令には純粋っぽい命令とそうでない命令があるけど、計算(評価)前ならどんな命令だろうが単なる値だから副作用もへったくれもないって理屈じゃね
実際はメモリー上の命令は全て状態だけど、書き換えられないように管理すれば純粋とみなせるってことだろ
例えば、
1+2*2^2^-1+3*3^3^-1
という式を考えた場合、これ全体を値として捉えることもできる
実際値として使おうとすると+、*、^の部分を命令として評価しないといけないけど、使い方によっては全部評価する必要はない
これに10足したかったら
11+2*2^2^-1+3*3^3^-1
で済ますこともできる
これを小数点以下10桁まで表示したくなった時、必要な桁まで計算(評価)すれば良い
‭18.1551758356…
Haskellの基本的な考え方はこういうことでしょ

**デフォルトの名無しさん** · 2020/03/27(金) 20:16:36.86

まずはっきりさせておきたいが、Haskellのテキストで
「命令列」なるものは出てこんし誰もそんなものを使ってモナドを説明しようとしてない。
あくまで「命令列」とは、>>74が自身でモナドを理解するために有用な概念だと見出し定義した用語と考えるべきだ

だからここで有意義な議論がしたいなら、まず目的を確認する必要がある。
我々は>>74さんの頭の中を理解したいのか？
それともモナドに対してより良い理解を形成したいのか？

**デフォルトの名無しさん** · 2020/03/27(金) 20:19:07.32

遅延評価と考え方は似てると思う。状態の受け渡しとかが出てきてこんがらがる

**デフォルトの名無しさん** · 2020/03/27(金) 20:21:43.46

>>93
自分も>>74の理解で問題ないと思うんだよ

**デフォルトの名無しさん** · 2020/03/27(金) 20:47:16.26

IOモナドに副作用を追いやれることがどれくらい良いことなのかを議論するのは悪くないと思うけど、
副作用が無いなんて嘘付き！とかそもそもプログラムってのは副作用の塊だ！っていうのは誤解か誤読かフカシに騙されたかのどれかなので楽しくない話になる、と思う

**デフォルトの名無しさん** · 2020/03/27(金) 20:49:07.27

関数型と手続き型は共存するべき
関数型はマクロの性質を持っている

**デフォルトの名無しさん** · 2020/03/27(金) 21:16:36.28

>>93
別に厳密に何か言ってるわけでもないからあんたの思ってる通りでええよ。
ただの解釈だからこだわらずに勝手に理解したらいいさ。

**デフォルトの名無しさん** · 2020/03/27(金) 21:17:09.88

言語設計者じゃなければ難しいこと考える必要なんてないんだ。ただの Haskell ユーザだろ？
（Haskellの）モナドは Haskell という基盤上で動作するDSLプラットフォームだよ。
各々が Haskell 上で動作するオレオレ言語を作れるんだ。
だから一度それを走らせれば、その中に他人の言語が干渉することはできない。
C++を書いてる途中でJavaコードを直接混ぜることは許されないというトートロジー。
他のDSLとはポートを作ってそこでデータを輸出入する

（Haskellの）モナドはC++コードにJavaコードが混ざらない事を保証してくれる
そういうイメージ

（Haskellの）モナドのライブラリには、その設計者の思想によるDSLの書き方がある。
それを知らずに型とだけ睨めっこしててもIQテストだよ

**デフォルトの名無しさん** · 2020/03/27(金) 21:54:14.38

>>96
Haskellの解説本・サイトは「副作用のないプログラミング!」のように喧伝し、
副作用がまるで悪いものであるかのように誤認させているからな。

医薬品の副作用は意図しない有害な作用なので避けるべきだが、プログラム言語の
副作用は数学的な意味で関数とは言えないだけで、意図した有益な作用だから何の
問題もない。副作用があろうとなかろうと、関連が深い処理をまとめて記述する
手続き型言語の方が使いやすい。

純粋関数型なんて実用性が大きく劣る。ラムダ関数や高階関数など関数型の
おいしい所だけ手続き型に取り入れるのが賢明。

**デフォルトの名無しさん** · 2020/03/27(金) 22:59:10.30

>>100
うん。だからあなたは純粋関数型なんて実用性が大きく劣るものなんか使わず
あなたの好きな手続き型の言語で実用的なプログラム書いてればいいじゃん。
その言語のスレにいってその言語の好きなところとか新しく出てきたすごい機能とかの
話題で盛り上がったほうがよほど生産的ではなくて？
わざわざこんなスレにツバかける来る暇があったらさあ。

**デフォルトの名無しさん** · 2020/03/27(金) 23:33:11.47

>>93
おれも同意だね
ここに限らず命令列、指令書みたいなメタファーで説明しようとするやついるけど
初学者にとって全く理解の助けにならない
プログラミング言語を説明するのに命令列って説明になってない

worldの考え方とモナドによる隠蔽で説明した方が理解しやすい

**デフォルトの名無しさん** · 2020/03/27(金) 23:51:09.98

Mワードは控えようね！

**デフォルトの名無しさん** · 2020/03/28(土) 09:17:26.94

実装に依存するな、メタファーに依存しろ

こういうのって実装はコロコロ変わるがメタファーは不変という前提なんだよね
前提が崩れたらやっぱり実装に依存する方が正解だったことになる

**デフォルトの名無しさん** · 2020/03/28(土) 11:10:45.76

モナドに関しては、モナドというインターフェースを実装しとけばそのデータはdo記法という特殊構文に対応する
ぐらいの説明でいい

IOモナドに関しても、world云々とかioモナドの実装とか知らなくても問題ない
IOアクションをdo記法で組み合わせて手続型言語風の書き方を再現できることだけ知ってれば良い

**デフォルトの名無しさん** · 2020/03/28(土) 12:07:59.94

>>88
ハァ？じゃあ役に立つプログラムを書けばいい

良い／役に立つはどう違うか、説明できないだろ
雰囲気で誤魔化せると思っているお前みたいなアホが真の元凶
良いプログラムが役に立つプログラムと無関係なら、良いなんて指標は何の役にも立たん

Haskellで役に立つプログラムをお前が書け
それができないならせめて、何が足りないのか言え

**デフォルトの名無しさん** · 2020/03/28(土) 12:16:59.39

このスレだけでなくあちこちに、"悟り派"が蔓延ってるのにそろそろ一言言っておくぞ
悟り派は、Haskellで悟りを得て自分の言語に持ち帰る
そして自分の製品のなかに不完全なHaskellのサブセットを作ってブーたれる。やれ遅延評価がない、モナドがない…
そんなんするくらいなら最初からHaskellで書けや

新規の参入、それ自体はいいことだが…

**デフォルトの名無しさん** · 2020/03/28(土) 12:38:06.30

>>104
IOアクションの命令書のメタファーは登場した当初から変わってないでしょう

>>102
指令書のメタファーは初学者にとって助けにならない？
そうかな、わかりやすいと思ったけど
RealWorld の State 、って説明はこっちはこっちで腑に落ちたし

>>92
の解説は、自分はなんか違和感を持ったが… うまく反論できない

**デフォルトの名無しさん** · 2020/03/28(土) 12:40:02.34

>>107
雑種のことをハーフとか不完全とか言うやつは悟りが足りない
むしろ二倍

**デフォルトの名無しさん** · 2020/03/28(土) 12:53:14.21

>>101
「ついてこれないならついてこなくていい」スタイルもどうかと思うぞ
そんなんやってたら、いずれ砂漠になっちまう
ただでさえスレッドが一週間止まるなんてざらにある現状なのに

>>100
> 副作用があろうとなかろうと、関連が深い処理をまとめて記述する手続き型の方が使いやすい
Haskell はモナドの do 構文を通して手続きをサポートする。手続き型言語でもある
副作用の有無に関わらず処理をモジュールにまとめることはできる
むしろ入出力が型に明に表れるので通信的凝集などの高凝集なモジュール分けに自然になりやすい

ただそれと引き換えに、ラフに、スケッチ的にプログラミングするのがやりにくい
これは原理的なトレードオフではないと思うが、少なくとも現時点ではそうだ

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

>>109
(雑種って言い方がすでに汚ねぇ)
人種にするみたいに、思想に文句をつけてるわけじゃなくてだな…
プログラマー全体の仕事の総量は増えてるってことを批判してる。非効率

**デフォルトの名無しさん** · 2020/03/28(土) 13:20:53.69

>>107
悟り派はそんな面倒なことしません。
他の言語に移るだけです。

**デフォルトの名無しさん** · 2020/03/28(土) 13:39:06.65

>>112
そんな面倒なこと？
Haskell風ライブラリを作ることか？それとも最初からHaskellでやること？
後者だとすれば何がボトルネックになっているのか