関数型プログラミング言語Haskell Part31©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2017/09/27(水) 02:33:08.70

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

haskell.org (公式サイト)
https://www.haskell.org/

前スレ
関数型プログラミング言語Haskell Part30
http://mevius.2ch.net/test/read.cgi/tech/1484491434/

**デフォルトの名無しさん** · 2018/05/24(木) 10:55:19.93

567

**デフォルトの名無しさん** · 2018/05/25(金) 21:11:33.96

エスパー来る

ところで、関数型言語のこの世の春は来ますか？

**デフォルトの名無しさん** · 2018/05/26(土) 04:33:44.12

GHCのインストール先の変え方教えて
ちなWindows
Cドライブに入れたくない

**デフォルトの名無しさん** · 2018/05/26(土) 04:40:40.86

Stackのコンフィグをイジる？

**デフォルトの名無しさん** · 2018/05/31(木) 00:34:57.11

haskellの練習してる初心者なんですが２進数の文字列表現を１０進数の整数に変換する処理ってこんな感じで大丈夫でしょうか？ https://csacademy.com/code/CsGalG5X/

**デフォルトの名無しさん** · 2018/05/31(木) 01:09:51.63

単に数値にしてるだけであって、10進数に変換して表示してるのはprintさんでしょ？

**デフォルトの名無しさん** · 2018/05/31(木) 08:07:17.08

Showが忖度したのであってInteger大臣が文字列化を指示したわけではない

**デフォルトの名無しさん** · 2018/06/01(金) 00:33:16.96

10進数への変換も自前で実装しろって話の流れ？

**デフォルトの名無しさん** · 2018/06/01(金) 01:50:05.31

>>571が何を目指すのかによる。

**デフォルトの名無しさん** · 2018/06/05(火) 20:09:41.67

どうでもいいけど、それぞれのGHC言語拡張の名前で単数形と複数形の違いがいまいち分からん。
うろ覚えで複数形で書いてコンパイルエラーになったり。

命名規則とかあるんかな？

**デフォルトの名無しさん** · 2018/06/06(水) 07:44:03.32

使った中じゃ英語で説明するのに複数形が使われるであろうものなら
大体複数形だったと思うけど
カタカナ語のノリでやってるから割と間違う

**デフォルトの名無しさん** · 2018/06/13(水) 21:49:00.45

すごいH本に煽られるとまじでムカつくんだけど

**デフォルトの名無しさん** · 2018/06/17(日) 22:53:19.15

すごいHだから勃起botをリツイートしてるのか

**デフォルトの名無しさん** · 2018/06/18(月) 09:11:06.80

おい！あの岡部健（毛の壁）がgithubで活動を再開してるぞ！

**デフォルトの名無しさん** · 2018/06/18(月) 18:39:20.54

IT芸人が新作コンテンツ提供開始か

◆QZaw55cn4c · 2018/06/18(月) 20:51:53.97

>>580
本当ですか！ぜひお会いしたい！

**デフォルトの名無しさん** · 2018/06/27(水) 12:31:39.52

今時コンパイルとか流行らないよ
サクッと書けても実行までが面倒だと普及しない
もっと標準ライブラリをヘビィにしてPython化するしか生き残りの道はない

**デフォルトの名無しさん** · 2018/06/27(水) 14:44:28.75

同意だ。Turtle使ってシェバンにstackコマンドライン書いて、
Haskellでシェルスクリプトするというのがあったが正気の沙汰とは思えない。

**デフォルトの名無しさん** · 2018/06/27(水) 19:48:00.92

むしろ今はコンパイル全盛期でしょ
rubyとか下火だし

**デフォルトの名無しさん** · 2018/06/27(水) 22:56:56.37

どれだけ簡潔に記述出来ても
短いプログラムでは実行するまでの手間の割合が大きくなるから
pythonでいいやってなる

**デフォルトの名無しさん** · 2018/06/28(木) 05:41:11.51

対話環境使わんの？短いプログラムてのがどんな状況か知らんからなんとも。

**デフォルトの名無しさん** · 2018/06/28(木) 07:28:52.90

Haskellで簡潔に書けるという特殊能力を持っておきながら
破壊的で動的型付けな言語を選ばなければいけないという悲劇

**デフォルトの名無しさん** · 2018/06/28(木) 15:27:57.03

なんで宗教みたいに二者択一になるの
要所要所で使い分ければいいだけでしょ

**デフォルトの名無しさん** · 2018/06/28(木) 16:47:06.64

たかだか数秒のことで簡潔さを失いたいとは思わないね

**デフォルトの名無しさん** · 2018/06/28(木) 16:57:33.76

バンパターンとかseqとか使いまくるからあんま簡潔に書けないわ

**デフォルトの名無しさん** · 2018/06/28(木) 17:36:24.62

簡単なプログラムだと
このifでこれとこれ書き換えてさらにネストしたifでこれとこれを書き換えて
とかやっちゃうな
haskellでもStateモナドとか使えばいいんだろうけど

**デフォルトの名無しさん** · 2018/06/28(木) 18:02:30.70

文字列を直接操作したければ動的型でいい
直接操作することなくShowとReadで処理できるならHaskellの型は無駄ではない

**デフォルトの名無しさん** · 2018/06/28(木) 20:20:52.20

より真理に近い言語以外使いたくないのだ

**デフォルトの名無しさん** · 2018/06/28(木) 20:47:06.63

込み入った評価戦略で脳ミソ使わされるのが真理とも思えんがw

**デフォルトの名無しさん** · 2018/06/28(木) 20:59:45.19

量子コンピュータが実用化されればへーきへーき

**デフォルトの名無しさん** · 2018/06/28(木) 22:01:03.00

文字列入力を要求してその文字列を含むファイルを検索して見つかったらエディタで開く、
的な、コマンドラインからさっと使いたいので実行までが重いと困るけど、
cabalプロジェクトにする程のもんでもない規模のやつ

**デフォルトの名無しさん** · 2018/06/28(木) 22:04:23.65

if ってあんま使ったことない。関数のガードとcase、あとData.Bool.bool

**デフォルトの名無しさん** · 2018/06/29(金) 18:53:31.79

Yesodって失敗したの？

**デフォルトの名無しさん** · 2018/07/02(月) 22:40:55.64

Haskellは"関数型だから"コードが短く生産性が高いと聞いたのに
関数型ではないPythonの方がコードが短く書けると知った時の絶望感

**デフォルトの名無しさん** · 2018/07/02(月) 22:42:40.97

そうなのか？

**デフォルトの名無しさん** · 2018/07/03(火) 12:03:15.48

関数型ではないHaskellがあるってことだろ
男の娘みたいなやつが

**デフォルトの名無しさん** · 2018/07/03(火) 12:11:44.26

関数型こそ邪悪なシンタックスに頼らない無敵の流派なのだ
ただし両方使う方が強い

**デフォルトの名無しさん** · 2018/07/03(火) 12:22:05.97

最強はＦ＃で決まりがこのスレの結論です

**デフォルトの名無しさん** · 2018/07/03(火) 15:28:26.92

バグバグしてていいならpythonの方が手っ取り早いでしょ

**デフォルトの名無しさん** · 2018/07/03(火) 19:37:38.72

そのバグが出ない haskell で、まともなグラフ描けるライブラリ作ってくれよ

**デフォルトの名無しさん** · 2018/07/03(火) 20:25:29.91

そういう考え方の人はpythonの方がいいでしょ
住み分け住み分け

**デフォルトの名無しさん** · 2018/07/03(火) 20:42:26.69

>>606
hackage にアップされているグラフ描画ライブラリの
まともではない点とその理由を列挙していただけないでしょうか。

来月ちょっと暇ができるので、ここで議論が深まれば、
列挙されたものの幾つかを改善してみようかと思います。

**デフォルトの名無しさん** · 2018/07/03(火) 22:20:48.11

>>608
Haskell は調べかかってあきらめたからよく知らないんだが、Python ユーザの視点で書かせてくれ。

Python だとグラフ描くライブラリは、単純な(と言っても強力な)matplotlib って Matlab のパクリの他、
よりハイレベルなグラフが簡単に描けるライブラリとか、インタラクティブなグラフが描けるライブラリとかがある。
どれも、Jupyter ってWeb環境から普通に使えるし、データフレームって表みたいなデータ構造を入力に出来る。
データフレームはつまらないけど実用的には必須で、
カンマ区切りのテキストファイルとかエクセルとかデータベースを読み取れる。

Haskell ってそもそも標準的なデータフレームが無い気がするんだ。間違ってたらぜひ教えて欲しい。

あとオレが調べた時は単純にHaskell のグラフライブラリは見た目が古臭かった。gnuplot 並み。
最近だとPythonでもRでも、カッコいい色のセットとかを選べるし、複数のグラフを簡単にレイアウトできる。
頑張ればカッコよく描けるのかもしれないけど、そんなところに頑張りたくないんだ。

**デフォルトの名無しさん** · 2018/07/04(水) 03:12:38.67

じゃあグラフ描くならPythonってことでいいんじゃないですかね

**デフォルトの名無しさん** · 2018/07/04(水) 03:48:39.08

すいません。ハマってしまってます。助けてください。
GHC 7.8.3です。
有理数係数の複素数の計算をしようとして
import Data.Ratio
import Data.Complex
として
Prelude Data.Ratio Data.Complex> ((0%1):+(1%1))^2
としたら

<interactive>:5:1:
No instance for (RealFloat (Ratio a0)) arising from a use of ‘it’
In a stmt of an interactive GHCi command: print it

と駄目みたいです。
何がだめなのかさっぱりわかりません。
どなたか解決策わかりますか？

**デフォルトの名無しさん** · 2018/07/04(水) 06:46:15.75

>>609
matplotlibやpandasあたりは、
そのためだけに、Python使うくらいのライブラリだから、
他の言語に使いたいライブラリがあれば、
その言語を使うで使い分けで良いんじゃない。
Excelの読み書きもなんかもPython使ってるよ。

**デフォルトの名無しさん** · 2018/07/04(水) 07:58:03.61

HaskellのシンタックスのPythonが欲しい

**デフォルトの名無しさん** · 2018/07/04(水) 09:21:13.05

>>611
HaskellのComplexで四則演算などをしようとすると
各要素はRealFloatクラスのインスタンス (いわゆる浮動小数点数)である必要がある
Ratio a はRealFloatのインスタンスになれないので計算できない
こうなってる理由はざっくり言えばHaskellのNumが悪い
(参考： https://blog.miz-ar.info/2016/06/haskell-num-class/#abs_signum )

**デフォルトの名無しさん** · 2018/07/04(水) 11:08:34.25

>>614
ありがとうございます。
Ratio a 割り算できるのに駄目なんですね。
別法考えます。

**デフォルトの名無しさん** · 2018/07/04(水) 11:21:15.35

>>609
例えば QuickPlot　(https://github.com/sheegl/QuickPlot)
そこそこモダンな描画を行うライブラリでしたが、
README.md にあるとおり、もうメンテナンスは行われていません。
ビジュアライゼーションサーバーのクライアントを作る方がより効率的だから、だそうです。

私もそう思います。
haskell でグラフ描画ライブラリを作るなら、
・データの作成 (取得や加工、整形など)
・サーバーへアクセスするためのインターフェース
この2点の実装に絞りたいですね。

データの作成は、python では Pandas のデータフレームを挙げていますが、
haskell ではこんなのはどうでしょうか。
https://github.com/chrisdone/labels/tree/master/labels-explore

あと、gnuplot を卑下してるようですが、そんなにダメですか？
私には視認性の良いグラフに見えますけど。
Wikipedia のグラフにも使われていますし。

**デフォルトの名無しさん** · 2018/07/04(水) 14:52:23.98

gnuplot も悪いとまでは言わないが、昔の解像度が低く色数もあまりなかった時代に最適化されてる気がするんだよ
Python のグラフと、微妙に用途が違うのかもしれないが

Python のグラフ
ttps://seaborn.pydata.org/examples/index.html

**デフォルトの名無しさん** · 2018/07/04(水) 16:23:51.06

>>617
すいません、違いがよくまかりません。

gnuplot デモ
http://gnuplot.info/demos/

私には低解像度&少色数時代の環境に最適化されているようにはどうしても見えないです。

**デフォルトの名無しさん** · 2018/07/04(水) 19:14:51.99

会社のプレゼンに使うならPythonの例の方がオシャレに見える
しかしオシャレなグラフというのは見栄え以外の面では役に立たない

**デフォルトの名無しさん** · 2018/07/04(水) 21:47:59.97

MY6

**デフォルトの名無しさん** · 2018/07/05(木) 02:06:23.28

その無駄に思えるオシャレが大事なんだぜ

**デフォルトの名無しさん** · 2018/07/05(木) 06:27:20.02

Pythonの例として上げられてるのは、seabornという
1. Rからデザインと
2. 人気のあるデータ表示方法
をパクって、同じことをmatplotlib.pyplotを裏で使ってお手軽にできるようにしたパッケージであって、
素のmatplotlib.pyplotのグラフはgnuplotのデフォルトと変わりのない見た目ですよ

gnuplotだって、山ほど表示用オプションがあって綺麗に表示できます

**デフォルトの名無しさん** · 2018/07/05(木) 09:04:27.74

>>622
gnuplot でお手軽に綺麗に表示できるようになってるの？

話が逸れたが、ある程度データ構造が共通に使えて
目的に応じて使えるかなり機能も見た目も
良くできたグラフライブラリが幾つかある、ってのが Python の状況だよ
個人的にはHaskell でそれが出来りゃ嬉しいが、、
Python は実行しないとエラーが出ないから、げんなりする時もある

教えてもらった labels- explorer は面白そうなんで見てみるよ

**デフォルトの名無しさん** · 2018/07/05(木) 12:35:27.07

>>623
綺麗にできるかどうかは使用者のセンスに依ると思います。
python の方のサンプルは、単に淡い色を使い、
線を太めに表示しているだけに見えますが、違いますか？
他に python のグラフならではの特徴があれば言ってください。

下記のような設計のライブラリがあればあなたの要望は満たされますか？

1. 見た目が python のサンプルの様になる「デザインのプリセット」がある。

2. pandas のデータフレームに似た使い勝手の「2次元の表」からグラフを生成できる。

3. 上記1. 2. を満たせば、グラフの生成自体は gnuplot に任せても良い。

**デフォルトの名無しさん** · 2018/07/05(木) 18:25:11.62

一見丁寧に見えてなかなかに辛辣でワロた。

**デフォルトの名無しさん** · 2018/07/05(木) 18:32:51.78

そんなところ頑張りたくないからデフォルトで一般受けする図を出せる奴が欲しいってだけの議論でなんでこんな白熱するんだ

**デフォルトの名無しさん** · 2018/07/05(木) 18:54:20.69

>>626
Pythonユーザーの視点、て一言がたぶん余計だったと見受けられる。

Haskellな人、でググると逆の気持ちが分かるかと。

**デフォルトの名無しさん** · 2018/07/05(木) 21:16:31.45

勘違いしているようですが、python 視点とかはどうでもいいです。
要は、希望されている機能がどれだけ楽に実装できるかが問題なんです。

その「頑張りたくないからデフォルトで」がプリセットの提供で満たせ、
かつ gnuplot を使ってもいいのなら、
見た目の部分は頭をそれほど使わず実装できそうです。

また、データフレーム的なデータ構造も、
もうメンテされてなさそうですが、labels-explore で賄えます。

となれば、ライブラリの形はインターフェースを簡易化したラッパー的なもので十分。

一から作るより遙かに楽です。

でも、私の指摘の他に python のグラフならではの特徴があり、
それを求められているのであれば、実装が難しくなり、
正直腰が引けます。
そのための確認です。

**デフォルトの名無しさん** · 2018/07/05(木) 21:59:46.30

普通にいける範囲なら実装してくれるってこと……？
神かよ

**デフォルトの名無しさん** · 2018/07/05(木) 22:39:32.46

Pythonならでは、って訳じゃないが(むしろ Rのパクリだと思うが)
facet とかいうグラフを二次元の表に並べたオシャレなグラフは欲しい
軸はグラフ毎に共通にできたりバラバラにできたりする
seaborn の facetgrid ってクラス見てくれ、map でグラフ書いたりしてて、ちょっと関数型言語の影響がありそうだから

あとは逆にHaskell ならではの良さが出るかどうかだな

**デフォルトの名無しさん** · 2018/07/05(木) 23:17:35.48

> Haskellならではの良さ
フーム

**デフォルトの名無しさん** · 2018/07/05(木) 23:22:55.84

>>630
複数のグラフを並べるのは、gnuplot では、このサンプルの一番下のものですね。
http://gnuplot.sourceforge.net/demo_5.0/layout.html

すみませんが、python 自体は昔に少し触ったくらいで殆ど門外漢です。
不慣れなものを調べるのは面倒で、そこまで労力や時間をかけたくないです。
あくまで、暇ができるのでやってみましょうか、という話です。

なので、実装してほしい事は自分の口で、
python を知らない者にも分かるように説明してください。
それでも、あまりに大変そうならお断りするかも知れませんが。

あと何度も言いますが、オシャレなグラフになるかどうかは個人のセンスですので、
そんなものはライブラリに期待しないでください。
ある程度のプリセットは用意しようと思いますが、あくまで私のセンスです。
普通は利用者がパラメーターを調整して自分でオシャレに仕上げるものです。

**デフォルトの名無しさん** · 2018/07/06(金) 00:29:48.55

それはいけない。
現にSeaborneはおしゃれに仕上げて来ているので、Pythonならライブラリに期待できるのにHaskellでは期待出来ないということになってしまう

**デフォルトの名無しさん** · 2018/07/06(金) 01:50:57.76

>>633
プログラミング言語を用いてグラフを作る目的は、
データの取得、加工、整形までをサクッとプログラムしたのだから、
そのデータの全体像を捉えるための可視化も「ついでに」してしまおうというもの。

つまり、プロセッシングしたデータの特徴を「すぐに見たい」という要求に応えるもの。

その様な目的のグラフに求めるのは、データの様相を正しく映すこと。
オシャレなんて入る余地は微塵もありません。
(例えば haskell には使用メモリ量をプロファイルしたデータのグラフ化ツールがありますが、
そのグラフにオシャレさは必要でしょうか)

もし、人にカッコイい思われるグラフを作りたいとか、
人にインパクトを与えるグラフを作りたいという目的ならば、
なにもプログラミング言語を使わなくてもいい。

というのが、古臭いかもしれませんが、私の考えです。

なので、あくまでオシャレなグラフを作るライブラリを求めているのでしたら、
私のモチベーションは大きく下がるので、
この件から降ります。

**デフォルトの名無しさん** · 2018/07/06(金) 02:04:10.34

>>634
そういう考えなら降りた方が良いと思うよ

**デフォルトの名無しさん** · 2018/07/06(金) 05:21:13.62

なんでオシャレにしないといけないんですか（正論）

**デフォルトの名無しさん** · 2018/07/06(金) 06:38:28.09

自己肯定感かな
論理に自信があるなら論理だけでいいがそうでなければオシャレが必要なような気がする

**デフォルトの名無しさん** · 2018/07/06(金) 06:41:34.00

何がオシャレなのかを定義して
正確に人に伝えるところからじゃないの？

**デフォルトの名無しさん** · 2018/07/06(金) 07:12:51.82

もし定義できないならできないと伝えるのが正しい言葉なんです

**デフォルトの名無しさん** · 2018/07/06(金) 07:46:50.10

ユーザーは最初から見た目を重視してんのに、ここにきていきなりオシャレは必要ないって突っ返すのは、
さすがにPythonがどうとかHaskellがどう以前にコミュニケーション不全

**デフォルトの名無しさん** · 2018/07/06(金) 08:37:44.78

万能なプリセットなんておれは期待してないから、
適当なのを真似るだけで全然問題ないよ
ただ別に金出してるわけでもないから、おれは好き勝手書いてるけど別に従う必要はないよ

あとちょっとグラフに対するおれの感覚と違っているようだから書いておく

少なくとも今は、一種類のデータだけじゃなく、沢山の種類のデータを見たい人がいるんだよ。
そういう人にとっては、情報は圧縮されていて欲しい。忙しいから、全体を見たいんだ。
例えば一台の使用メモリ量じゃなく50台のを見たい、とかだよ。
そんな時に、５０枚のグラフを渡されて一個一個が完璧に可視化しているでしょ、とか言われたら困る。

画面に収まるようにするには、削ってもいい情報を削り、例えばfacetみたいな方法でまとめるしかない。
かといって圧縮しすぎても分からなくなるし難しいけどね。

**デフォルトの名無しさん** · 2018/07/06(金) 10:10:20.21

>>641
> 画面に収まるようにするには、削ってもいい情報を削り、例えばfacetみたいな方法でまとめるしかない。
> かといって圧縮しすぎても分からなくなるし難しいけどね。

私は「全体像」を捉えるための可視化と言っています。
細部を見るための可視化とは言っていません。
（50個分のグラフで表されるデータの全体像を捕らえたいという要望に、
50枚のグラフを作るなど愚の骨頂）

そして、それはあなたがオシャレではないと感じている gnuplot でできますよね。
gnuplot のサンプル見ましたか？

gnuplot でもできることは理解したけど、
オシャレではないので却下という事ですか？

**デフォルトの名無しさん** · 2018/07/06(金) 11:23:26.70

長い棒グラフを端折る為に、下端を0以外の数値にしちゃうとか、マナー違反しない限りもう好きにやってくれ

**デフォルトの名無しさん** · 2018/07/06(金) 11:46:42.42

オシャレって結局UXだからね
手軽に良いUXが得られる方を使うのは自然っちゃ自然なわけで

**デフォルトの名無しさん** · 2018/07/06(金) 14:15:19.37

UXを定義できないなら予測もできない
予測できると思ってるならやっぱり定義するべき

**デフォルトの名無しさん** · 2018/07/06(金) 18:44:45.57

UX自体の定義は単純だよね
プロダクトによってユーザーが得る経験
良し悪しになると一意には定まらないけど良い悪いのアンケでも取って統計的有意差を得られれば良い悪いとしていいと思う

もし客観主義として定義可能なものしか定義と認めないと言うならお手上げだ
良いUXが得られるとされるプロセスには既にアンケなどによるユーザ要求の明確化が含まれてしまうからね

**デフォルトの名無しさん** · 2018/07/07(土) 09:26:18.48

アンケ取って結果を発表するところまで全部がUXになるからお手上げだな
放○線を測定して数値を報道するみたいなUXだ

**デフォルトの名無しさん** · 2018/07/07(土) 11:29:34.03

出来ない出来ないと言い訳ばかりして実際出来ているPythonから目をそらす

**デフォルトの名無しさん** · 2018/07/07(土) 11:58:08.73

プロシュー○「出来る…そんな言葉は使う必要がねーんだ。」

**デフォルトの名無しさん** · 2018/07/07(土) 12:00:36.05

たかがグラフ一つでいつまでもスレを汚さないで
もっと本格的な話をして

**デフォルトの名無しさん** · 2018/07/07(土) 21:46:46.78

質問

let a = takeWhile p $ sort xs
これって、どこまでソート処理されるかは、
xs の並び方と条件 p によるよね
(厳密にはaの評価方法によるけど)

今のsortの実装は確かマージソートだったはずだから、
極端な話、条件に合う要素がただ一つだけ先頭にあれば、
ソート処理はすぐに終わると思っていい？

**デフォルトの名無しさん** · 2018/07/07(土) 23:14:16.03

>>651
そういう意図なら
sort $ takeWhile p xs
じゃないかな
最初に書いてある式だと、takeWhile p が引数のリストを評価しようとしたときに
sort xsの第一要素を見る必要があるのでxsをソートし終わらないと評価が進まないはず

**デフォルトの名無しさん** · 2018/07/08(日) 00:09:13.07

マージソートでマージが遅延されるならhead $ sort xsはO(n)だと思う
いい感じの説明用コードが思いつかないけど
あとたぶん例のクイックソートも

**デフォルトの名無しさん** · 2018/07/08(日) 00:15:59.84

あークイックソートは先頭だけでも最悪O(n^2)になったりするか

**デフォルトの名無しさん** · 2018/07/08(日) 01:32:29.33

>>652
オレ >>651

つまりはn要素のリストのsort後の先頭m要素 (m<n) を評価するのは、
n要素を評価するより少ない計算量で済むんじゃないか、という質問なんだ

だから sort と takeWhile を入れ替えたら意味ない

**デフォルトの名無しさん** · 2018/07/08(日) 01:40:40.69

ふと思いついたが、比較関数に unsafePerformIO を入れて比較回数をカウントすれば分かるかも

今は実験環境が無いから、起きたら試してみる
お騒がせしてごめん、という結果になるかも

お休み、お前ら

**デフォルトの名無しさん** · 2018/07/08(日) 09:12:56.04

実験したら、やっぱり評価に必要な部分しかソートされなかったよ
実験は takeWhile じゃなく take でやった

[実験コード]
ucomp :: IORef Int -> Int -> Int -> Ordering
ucomp ref x y = unsafePerformIO $ do
modifyIORef ref (+1)
return $ compare x y

main = do
let g = mkStdGen 1
let xs = shuffle' [1..8] 8 g
rc <- newIORef 0
let ys = take 8 $ sortBy (ucomp rc) xs
putStrLn $ show $ maximum ys
c <- readIORef rc
putStrLn $ show c

take で取り出す要素数を8個と3個で実験し、show c の結果を比較
　　8個　c=19
3個　c=14

やっぱ遅延評価ってイイね
ベスト3を決めるのに他言語みたいに全部を評価する必要がない

ちなみに、100万個の要素でもやってみた
　　all　c=19237801
　　3個　c=1413225

質問したけど、ひとりで納得してしまった、すまん

**デフォルトの名無しさん** · 2018/07/08(日) 09:49:58.54

>>657
>ベスト3を決めるのに他言語みたいに全部を評価する必要がない
別に他言語でも全部を評価する必要はない。
https://ja.wikipedia.org/wiki/%E9%81%B8%E6%8A%9E%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0

**デフォルトの名無しさん** · 2018/07/08(日) 10:45:22.88

どんな言語だろうが全部ソートすれば O(n*log(n)) で最小値や最大値を探すのは O(n)

この n と n*log(n) の差を無視できないなら
そもそも n と 100*n の差を無視するのもダメじゃないかと思う

**デフォルトの名無しさん** · 2018/07/08(日) 11:20:47.41

>>658
いや、そうじゃなくてさ

上位m個の選択処理とソート処理とをソース上ではきっちり分けてるじゃん
ソースを読む人間にとってはすげー読みやすいわけよ

なのに内部処理的には2つが連携して、
必要なところまでしかソートされないだろ
選択処理のためにワザワザ特殊なソート処理をしなくてもさ

そこがすげーって感動してるんだよ

**デフォルトの名無しさん** · 2018/07/08(日) 11:30:44.71

まあソートなんて如何にもキャッシュ次第なアルゴリズムで
連結リストと遅延評価のO(N)が配列と正格評価のO(NlogN)に
現実的なNの範囲で勝てるのかものかどうか・・・

**デフォルトの名無しさん** · 2018/07/08(日) 13:00:05.06

まるで永久機関の話を見ているようだ

**デフォルトの名無しさん** · 2018/07/08(日) 22:57:14.98

具体例や比喩で抽象度を下げるのは良い
だが「永久機関っぽいもの」の集合を作ったらむしろ抽象度が上がり収拾がつかなくなる

**デフォルトの名無しさん** · 2018/07/09(月) 10:04:31.05

arrayパッケージのData.Array.(!)はO(1)ですか。

**デフォルトの名無しさん** · 2018/07/11(水) 00:08:42.37

Haskellの採用とユーザ満足度が向上
https://www.infoq.com/jp/news/2018/07/haskell-user-survey-2018

**デフォルトの名無しさん** · 2018/07/13(金) 00:35:06.69

発展編！ Haskellで「型」のポテンシャルを最大限に引き出すには？【第二言語としてのHaskell】
https://employment.en-japan.com/engineerhub/entry/2017/10/03/110000