関数型プログラミング言語Haskell Part30 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/01/15(日) 23:43:54.28

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

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

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

**デフォルトの名無しさん** · 2017/06/12(月) 20:01:13.71

GHCi で ["aa", "bb", ["cc", "dd"]] を評価してみれば一発だろうに

• Couldn't match expected type ‘Char’ with actual type ‘[Char]’
• In the expression: "cc"
In the expression: ["cc", "dd"]
In the expression: ["aa", "bb", ["cc", "dd"]]

**デフォルトの名無しさん** · 2017/06/12(月) 21:30:08.56

>>647
> ["a","b",["c","d"]]
> = "a":"b":["c","d"]:[] --["c","d"]が一つの値なので、文字列じゃない！！とエラーになる。

文字列または文字列のリストからなるリストというのはあり得るでしょう？
その場合ならエラーではないはず

>>649
> どうしてもできないときは、それはする価値がないのだ

いまの場合、どうしてもできない証明はどうするんだろう？

>>650
> GHCi で ["aa", "bb", ["cc", "dd"]] を評価してみれば一発だろうに

それだけではその評価が本当に正しいかどうかが分からない

**デフォルトの名無しさん** · 2017/06/12(月) 22:36:06.43

>>651
> 文字列または文字列のリストからなるリストというのはあり得るでしょう？

文字列というのが String 型を指していて、文字列のリストというのが [String] 型を指しているのであれば、
文字列または文字列のリストからなるリストという型は「あり得ません」。

なぜなら、Haskell には「型A または型B」という型は存在しないからです。
(data T = D String | E [String] の型は T であって、D や E ではない)

> いまの場合、どうしてもできない証明はどうするんだろう？

なぜ「証明」を求めるのでしょうか。
Haskell だとこれはできないよと言われ、簡単な理由を説明された時、
あなたはいつもその証明を求めるのですか。
今回の問題に限って求めているのであれば、その理由を説明してください。
理由によっては、あなたが納得できる証明以外の説明ができるかもしれません。
というのも、できないことの証明を本当にしようとすると、かなり難しいからです。
きっと構文規則や意味論にまで話が及びます。
そんな証明できる人は稀ですし、できる能力があっても、したくないでしょう。

> それだけではその評価が本当に正しいかどうかが分からない

あなたの場合、「正しい」とは何を意味するのでしょうか。

>>650 が言っているのはきっと、GHCi で試してみれば「構文エラーであることが分かる」、
ということだと思いますよ。
それが正しいのか分からないというのは、GHC は信用できないということですか。

**デフォルトの名無しさん** · 2017/06/12(月) 22:39:18.30

>>651

https://paiza.io/projects/TpKm5_4fBEc7_YoKQIeKJQ

こういうのがお望み？
いずれにせよ List のデータコンストラクタ(:)を持ち出した >>633 は救済できんが。

**デフォルトの名無しさん** · 2017/06/12(月) 22:48:23.36

もしかして本当に欲しかったもの：
[["aa"], ["bb"], ["cc", "dd"]]

**デフォルトの名無しさん** · 2017/06/12(月) 22:49:39.74

https://paiza.io/projects/4geVOsfwAnMedzLfkbEDpw

こっちのほうがパラメータ多相でいいか。

**デフォルトの名無しさん** · 2017/06/12(月) 22:58:41.14

ちなみに、自分自身を要素の型とするかのような「ネストしたリスト」のようなデータ構造（というかinfnite typeのまがいもの）自体はときどき使いたくなるので簡単なライブラリを書いたことはある。そういやOCamlはオプショナルだが infnite type 扱えるんだったっけ？？

**デフォルトの名無しさん** · 2017/06/12(月) 23:23:51.05

>>652
> なぜなら、Haskell には「型A または型B」という型は存在しないからです。

「今のHaskell」には存在しないということね？
こっちは今のではなく本来のに興味があるので。

> Haskell だとこれはできないよと言われ、簡単な理由を説明された時、
> あなたはいつもその証明を求めるのですか。

簡単な理由でよいのだが、「今そうなってるから」は興味がない

> あなたの場合、「正しい」とは何を意味するのでしょうか。
> >>650 が言っているのはきっと、GHCi で試してみれば「構文エラーであることが分かる」、
> ということだと思いますよ。

さっきも言ったが、「今そうなってる」というのは「正しい」とは異なる

**デフォルトの名無しさん** · 2017/06/12(月) 23:32:25.99

方法が存在しないことの証明って悪魔の証明でないの？
できると主張する側ができることを証明しないとダメだよ

痴漢の言いがかりをつけられて、『痴漢していないことを証明しない限り有罪な』って裁判官に言われて納得できる？

**デフォルトの名無しさん** · 2017/06/12(月) 23:39:48.75

>>657はできるという根拠をコードで示せばいい。

Haskell 2010 に従ったコードで、しかしGHCが不当にも
型検査で排除するというような、そういうコードを示せば
話はたちまちに解決する

**デフォルトの名無しさん** · 2017/06/12(月) 23:42:32.96

[“aa”, [“bb”,”cc”]]

について　Haskell2010　の構文規則をを充足するような
Haskellの型をつけてくれればいい

**デフォルトの名無しさん** · 2017/06/12(月) 23:43:46.21

>>657
みんな、特に断りがなければ今のHaskellについて質問したり語ったりしています。

なので、そうでなければ、初めにちゃんと断っておかないと、話が合わなくなります。

また、本来のHaskellとは何かも説明しておかないと、これまた話が合いません。

私は今のところ、今のHaskellでアプリを作ることに興味が向いているので、
そうではない議論からは抜けさせてもらいます。

>>658
方法の存在を仮定した場合に矛盾がおきることを示すことで、方法の非存在を示すやり方もあります。
数学(厳密な論理)の舞台に上げられるテーマであれば友好的な手です。
(面倒かどうかは別にして)

**デフォルトの名無しさん** · 2017/06/12(月) 23:48:33.05

>>661
うぁ、恥ずかしい、友好的な手って何だよ。

有効な手、ね。

>>659
彼、今のHaskellには興味ないそうですよ。

**デフォルトの名無しさん** · 2017/06/12(月) 23:48:35.55

定義の証明をしろってことか
1の次の数は2であることを証明しろ的な
つまり1=2は間違いとは言えないのだ

**デフォルトの名無しさん** · 2017/06/12(月) 23:59:06.10

>>663
>1の次の数は2であることを証明しろ的な
>つまり1=2は間違いとは言えないのだ

Succ 1 = 2 とか普通にPAで証明できるけど……

**デフォルトの名無しさん** · 2017/06/13(火) 00:09:20.22

本来のHaskellってなんですか

**デフォルトの名無しさん** · 2017/06/13(火) 00:57:22.00

ＬＩＳＰベースのリスト

**デフォルトの名無しさん** · 2017/06/13(火) 11:30:18.72

>>651
それぞれのリストはあるけど、両方の型を持ったリストはない。
リストがいっぺんに受け取れる型は一つだけ。

ghciで拒否られたらそれまでじゃね？
何か作りたいわけじゃないって事？
下で将来のHaskellとか語ってるっぽいけど、今作れないでいつ作るの。

>>645見るに最終的に欲しいのは

["a","b","c","d"]

だろ？

f ["a","b"] ["c","d"]
= ["a","b"] ++ ["c","d"]
= ["a"] ++ "b":["c","d"]
= [] ++ "a":"b":["c","d"]
= ["a","b","c","d"]

じゃあダメなのか？
手段にこだわるより、目的果たす事考えようぜ。

**デフォルトの名無しさん** · 2017/06/13(火) 12:23:55.30

>>658
> 方法が存在しないことの証明って悪魔の証明でないの？

そんなことないよ。不可能性の証明なんて数学では普通にあるでしょ

>>661
> 特に断りがなければ今のHaskellについて質問したり語ったりしています。

スレタイは「今の」とはなっていない。「今の」「Haskell」に限るとつまらない
「関数型プログラミング言語」の方がおもしろい。ここは「関数型プログラミング言語」がテーマと認識している。（俺はね）
「今の」「Haskell」は単にその一つ

> また、本来のHaskellとは何かも説明しておかないと、これまた話が合いません。

本来の関数型プログラミング言語程度の意味。それはみんな意識してるでしょ？

>>667
> それぞれのリストはあるけど、両方の型を持ったリストはない。

それは今のHaskellについた制限のようなものでしょ？

> f ["a","b"] ["c","d"]
> = ["a","b"] ++ ["c","d"]
> = ["a"] ++ "b":["c","d"]
> = [] ++ "a":"b":["c","d"]
> = ["a","b","c","d"]
>
> じゃあダメなのか？

それではもとの問題と違うし、スマンが興味わかんわ

**デフォルトの名無しさん** · 2017/06/13(火) 13:10:39.07

>>668
将来も今も["a","b","c","d"]は[String]って型で表現できるけど、
["a","b",f ["c","d"]]はどういう型で表現するのさ？
こう表現出来るってのが無いと、ただ単に型に対する意識が低いだけのお馬鹿さんだよ？

**デフォルトの名無しさん** · 2017/06/13(火) 13:17:22.94

大体、複数に型を纏めるんならタプル使えよ。
(["a","b"], f ["c","d"])
fが部分適用してない、値を返す関数なら結果の型が入るし、部分適用で関数としてタプルに入ってるなら何か受け取って何か返す関数の型がタプルにに入る。

**デフォルトの名無しさん** · 2017/06/13(火) 14:08:02.45

nilわすれてるってのはさ、
[a, b, c, d] と a : b : c : d : [] が等価ってことでさ、
この末尾の:[]を忘れたらあかんってことじゃないの？

**デフォルトの名無しさん** · 2017/06/13(火) 14:26:42.82

>>669
そこのfはどういう関数型という想定？

**デフォルトの名無しさん** · 2017/06/13(火) 15:33:15.95

自分の間違いを認められず引くに引けなくなってるだけなんじゃないの

**デフォルトの名無しさん** · 2017/06/13(火) 18:11:35.28

>>672
>>668に聞いてくれ。
そもそもどんな型でも文字列が返ってくる以外は入れられない。

f = concat

["a","b",f ["c","d"]]
=["a","b","cd"] --これは>>668のやりたいことでは無い。

こう言うの以外は現行で受付られないが、それ打破するリストの型表現が存在出来るなら、将来実装されるかもな。

**デフォルトの名無しさん** · 2017/06/13(火) 18:19:50.97

fは引数でもない外側のリストを無理やり拡張するのか……おぞましいな
そんな実装されたらHaskell見限るわ

**デフォルトの名無しさん** · 2017/06/13(火) 18:35:46.29

だよな。
だからこそmapとかの関数作りやすいのに、そんな変な機能将来に渡って欲しいとは思わん。
入力->出力が素直だからこその関数プログラミングだってのに。
欲しい最終データが手に入れば良いのに、>>668は手段と目的が逆転してんだよ。

**デフォルトの名無しさん** · 2017/06/13(火) 19:30:15.82

どうしてもそれができないときは、本当にそれが必要不可欠なのか、もう一度よく考えてみよう

**デフォルトの名無しさん** · 2017/06/13(火) 21:22:18.24

>>669
> ["a","b",f ["c","d"]]はどういう型で表現するのさ？
関数fの型によるけどその出力がStringなら["a","b",f ["c","d"]]　の型はもちろん[String]だね。

>>674
> そもそもどんな型でも文字列が返ってくる以外は入れられない。
結局、今のHaskellでは、["a", "b", ["c", "d"]]　のような表現はできないと言ってるだけね？
関数型言語としてなぜそんな表現力を制限するのか分からん。どういう場合に使いたくなるかは知らんが。

>>676
> 入力->出力が素直だからこその関数プログラミングだってのに。
入力->出力が素直ってどういうこと？　自然変換のことじゃないよね？ｗｗｗ
関数プログラミングは入力->出力になってればそれで十分だと思うが

>>68
> ["aa", "bb", f ["cc", "dd"] ] =
> ["aa", "bb", "cc", "dd"]
> となるような関数fはどのように書けるでしょうか

結局もとのこの問題について、“一般の関数型言語”でのfの不可能性をだれも論証できないのかな？
（要点さえ分かれば簡略でよいが）

**デフォルトの名無しさん** · 2017/06/13(火) 21:34:21.04

型は単に「欲しい最終データが手に入ればよい」っていうよりは
ある種の性質がコンパイル時に保証されてるってのがありがたい
エンバグも検出しやすい

他の言語だと[Any] なListがあったりするけど(例えばScala)
よくあんなの使うなーって思う

>>678
> ["aa", "bb", f ["cc", "dd"] ] =
> ["aa", "bb", "cc", "dd"]
これはリテラルでこう書いてる以上、 fがどんな値を返そうと
左辺は要素が3のリストで右辺は要素が4のリストだから
パターンマッチに成功するわけない

**デフォルトの名無しさん** · 2017/06/13(火) 21:39:23.64

>>678
ここにいる人たちは俺もあんたも含めて誰も証明できないことは、
いままでの一連のレスですでに分かっているはず。

あんたの投げかけた議論に誰もあんたの望むようには応えられないことも分かっただろ。

あんたの話はhaskellという小さな枠組みを遥かに越えてるんだよ。
いい加減スレチだってことに気づこうよ。

頼むから、一般の関数型言語における可能性や証明の議論は大学でもっと頭のいいヤツらとしてくれ。

**デフォルトの名無しさん** · 2017/06/13(火) 21:43:22.47

中途半端な数学屋なんて全然怖くないのに
数学系と聞いて逃げるHaskellプログラマ大杉

**デフォルトの名無しさん** · 2017/06/13(火) 23:14:18.88

とりあえずこんなもんでどう？
https://ideone.com/wMOghJ

**デフォルトの名無しさん** · 2017/06/13(火) 23:32:43.89

どうせならFoldableにすりゃよかったな
ま、いっか

**デフォルトの名無しさん** · 2017/06/13(火) 23:59:28.85

Haskell の枠組みにとらわれないなら、自分専用関数型言語の
文字列リテラルを 682 が示した Nest みたいに自由に定義すればいいもんな

これで解決だ

**デフォルトの名無しさん** · 2017/06/14(水) 00:01:03.56

ideoneやpaiza.ioのようにhaskellコードのコンパイルと実行を同時にしてくれるようなローカルアプリはありますか？
補完とかはなくてもいいですし、exeも生成しなくていいのですが

**デフォルトの名無しさん** · 2017/06/14(水) 00:24:00.03

["aa","bb",f["cc","dd"]]=["aa","bb","cc","dd"]なるfが存在しないことは、
チャーチ・ロッサー性で説明できる。

チャーチ・ロッサー性は、簡単に言うと、計算の順番を変えても
最終的な計算結果が変わることが無いという性質。

もし上記のようなfがあるとすると、以下の2つの式の計算結果が同じでなければならない。
なぜなら、これら2つの式は、一番内側のfを先に計算するかどうかの違いしかないから。

null(tail(tail(tail ["aa","bb",f["cc","dd"]])))
null(tail(tail(tail ["aa","bb","cc","dd"])))

しかし、計算すればわかるが、上はtrueで下はfalseになるので矛盾する。
よってfは存在し得ない。

本当は、型なしラムダ計算に落としこんでからやる必要があるけど、
(型なしラムダ計算にチャーチ・ロッサー性があることは証明済み)
骨子としてはこんな感じ。

**デフォルトの名無しさん** · 2017/06/14(水) 00:35:10.46

要するにLispのマクロの ,@ みたいな展開をしたいってことか？

**デフォルトの名無しさん** · 2017/06/14(水) 02:36:17.24

>> 683

まあ、こういうデータ構造なんか既視感あるよなと思ったら、リストじゃなくてツリーだよね
つうか Data.Tree がまんまそれ

**デフォルトの名無しさん** · 2017/06/14(水) 05:34:36.84

>>681
↑
この人強そう

**デフォルトの名無しさん** · 2017/06/14(水) 09:21:04.82

>>678
＞関数fの型によるけどその出力がStringなら["a","b",f ["c","d"]]　の型はもちろん[String]だね。

そこまで分かってて、f ["c","d"]が単一のStringにならざるを得ない。
つまり

["a","b","c","d"]

ではなく、

["a","b","cd"]

の様な単一の値としてしか返りようがないって分かるだろ。
あれか、複数の値を返せってか。
従来の値が欲しい方はどうすんだよ。

**デフォルトの名無しさん** · 2017/06/14(水) 09:53:35.84

>>679
> 他の言語だと[Any] なListがあったりするけど(例えばScala)
> よくあんなの使うなーって思う
その例は極端すぎる。Anyは論外。型の否定と同じ。（Scalaも推奨はしてないと思うが）

> fがどんな値を返そうと左辺は要素が3のリストで
ふつうに考えてそうだよね。
そこを以下のように暗算して、できるかと思っちゃった。
f[x, y] = x : [y] とすると、
[a, b, f[c, d]] = a : b : (c : [d]) = a : b : (c : d : []) = a : b : c : d : [] = [a, b, c, d]

>>680
というわけで、ここは俺が暗算で頭の体操してミスってた。
優しく拒否してもらったがスマンｗ

>>686
> ["aa","bb",f["cc","dd"]]=["aa","bb","cc","dd"]なるfが存在しないことは、
> チャーチ・ロッサー性で説明できる。
折角だが今の件はチャーチ・ロッサー性（合流性）は関係ないと思う。
合流性以前の到達性が問題なので。

**デフォルトの名無しさん** · 2017/06/18(日) 12:36:58.87

配列xsとysと引数を2つ取る関数gがあって、
f g xs ys = map (\x -> map (g x) ys ) xs
となるような関数fってあったりしますか？
例えば
f (+) [1,2,3] [4,5,6] = [ [5,6,7], [6,7,8], [7,8,9]]
となるような関数です

**デフォルトの名無しさん** · 2017/06/18(日) 12:50:16.34

>>692
hoogle で調べてみても、それっぽいものが見当たりませんね。
少なくとも標準ライブラリにはありません。
なので、その定義に自分で適当に名前を付けて使ってください。

**デフォルトの名無しさん** · 2017/06/18(日) 12:56:47.67

>>693
ありがとうございます
ないならないで問題ありません
たまに使うのですが、既にあるならわざわざ定義するのも無駄だなと思っただけなので

**デフォルトの名無しさん** · 2017/06/18(日) 15:28:29.26

>>692

f g xs ys = concatMap (¥x -> map (g x) ys ) xs

でいいなら（つまりリストを1段階潰していいなら）あるよ。

g <$> xs <*> ys

がその答え。

**デフォルトの名無しさん** · 2017/06/18(日) 17:41:11.73

>>692
zipWithに配列の配列渡せば行けるか？と書いてみた。

zipWith (map.(+)) [1,2,3] $ repeat [4,5,6]

うん。
素直に関数作った方がいいね。
リスト内包表記なら分かりやすいと思う。

f g xs ys = [map (g x) ys | x <- xs]

**デフォルトの名無しさん** · 2017/06/18(日) 17:41:54.37

x配列の配列
oリストのリスト

**デフォルトの名無しさん** · 2017/06/18(日) 22:40:07.66

これで行けるよ。
f x = fmap . (. (:[])) . liftA2 x
f (+) [1,2,3] [4,5,6]
[[5,6,7],[6,7,8],[7,8,9]]

**デフォルトの名無しさん** · 2017/06/19(月) 05:32:16.99

そういう関数ってすでにある？って質問なのにオレオレ実装載せてく人たち…

**デフォルトの名無しさん** · 2017/06/19(月) 06:40:21.02

しかも、質問者の実装が一番素直で分かりやすい

**デフォルトの名無しさん** · 2017/06/19(月) 07:45:05.62

隙あらば実装

いや、プログラム板ではそれでいいんじゃないか。

**デフォルトの名無しさん** · 2017/06/19(月) 10:22:09.65

組み込みの関数でラムダ式を隠蔽してしまうことには意味があるんじゃないか

ところで質問者の例だと結果が可換なのでそうじゃない例の方が良かったのでは
f (+) [1, 2, 3] [1, 3, 5] -> [[2,4,6],[3,5,7],[4,6,8]]
f (+) [1, 3, 5] [1, 2, 3] -> [[2,3,4],[4,5,6],[6,7,8]]
とか

**デフォルトの名無しさん** · 2017/06/19(月) 10:46:07.27

>>702
それならば、あなたはどのような意味を見いだしたのかまでちゃんと言わないと。
何にどのような意味を見いだすかは人それぞれですし。

私は、ソースは人間が読みやすい事に最大の意味を見いだします。
なので、計算結果を容易に想像できるという点で、
>>692 や >> 696 の下の定義は好きですね。

**デフォルトの名無しさん** · 2017/07/01(土) 02:37:46.49

IOモナドは命令書という喩えが一番しっくり来た

**デフォルトの名無しさん** · 2017/07/01(土) 08:12:10.07

IOモナドっつーか、モナドは難しく考えんで良いだろと。
IO String >>= String
IO String >> は結果を捨てる。>>= ¥_ -> の略記。
return String ってしたらIOなString返るから、return使えばモナドの途中で純粋な関数で加工出来る。

それがIOモナドにも具体的な型にも依存しない汎用的な表現が

m a >>= a

ってだけ。

これだけ覚えれば使うにゃ十分だし、使ってるうちにただの型クラスやってわかる。
結局型クラスも型を受け取れる型ってだけで、ただの型でもあるから、純粋関数の結果としてString返すと、IO StringとStringは型が違うよって怒られる。

だからIO Stringにする為にIO Stringな関数か、return使いましょうってだけ。

具体的な型を考えれば何のことはない。
returnはそう考えればまあ自然なんだが、リターンってよりレシーブって印象。

**デフォルトの名無しさん** · 2017/07/01(土) 09:35:49.67

main = getLine >>= return.tail >>= putStrLn

getLine
一行入力でIO String生成。

>>=
getLineに生成されたIO StringをStringとして右辺に渡す。

return.tail
tailは受け取ったStringの先頭を省く。
そのままだとStringのままで、IO Stringを受け取る次の>>=に渡せないので、returnでStringをIO Stringにして返す。

>>=(2番目)
最終出力のputStrLnに向けてIO StringをStringにして渡す。

putStrLn
受け取ったStringを改行付き出力。

説明のために長く書いたけど、型を揃えれば良いって分かればこうも書ける。

main = getLine >>= putStrLn.tail

何もないところからIOを生成するmain = 直後の関数以降は基本的に純粋な型を受け取ってIOな型を返せばコンパイラ通るので、何の役にも立たないけどこれもコンパイル通る。

main = getLine >>= return.tail

putStrLnも関数である以上、何らかの値を返してるので見ようと思えば見れる。

main >>= putStrLn.tail >>= print

()にIOを付けたIO ()が返ってると分かる。

**デフォルトの名無しさん** · 2017/07/01(土) 10:27:56.55

IOと純粋関数の関係がどうしても理解できなかったけどwiki読んだらやっとわかったからオススメ
https://wiki.haskell.org/IO_inside

**デフォルトの名無しさん** · 2017/07/03(月) 20:20:17.13

stack使ってるのですが、openFileでカレントディレクトリ以外のファイルを指定って出来ないんですかね？

**デフォルトの名無しさん** · 2017/07/03(月) 20:31:50.76

stack関係あったっけ？
何となく¥を¥¥ってしてないだけじゃないかと予想。

**デフォルトの名無しさん** · 2017/07/08(土) 21:56:26.43

タプル作ろうと思ってHoogleで
f :: a -> b -> (a, b)
f a b = (a, b)
となるような関数探したら見つからないんだけどもしかしてない？
割と使いそうなイメージなんだけど

**デフォルトの名無しさん** · 2017/07/08(土) 22:11:48.22

どういうときに使いたいのさ
curry/uncurry ならたまに使うけど

**デフォルトの名無しさん** · 2017/07/08(土) 22:18:49.21

これで
https://wandbox.org/permlink/bSFTBbmr9cQGguSw

**デフォルトの名無しさん** · 2017/07/08(土) 22:48:00.26

>>710
タプルコンストラクタ

$ ghci
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Prelude> :t ((,))
((,)) :: a -> b -> (a, b)

**デフォルトの名無しさん** · 2017/07/08(土) 22:53:26.22

>>713
おお、まさにこれです
ありがとうございます

**デフォルトの名無しさん** · 2017/07/10(月) 01:15:03.97

すみません traceデバッグについてですが
ある変数に色とかで印を付けて
IOとは別の専用簡易コンソールに出力表示とか
簡単に出来ない物でしょうか。

**デフォルトの名無しさん** · 2017/07/15(土) 19:13:14.12

GHC 8.2 で実装予定の backpack なるものが一体
現在のどのような問題をどのように解決することを目指したものか、
分かる方いますか？

どうも、モジュールシステムの拡張みたいですが...

**デフォルトの名無しさん** · 2017/07/17(月) 23:01:46.61

ご冥福

**デフォルトの名無しさん** · 2017/07/18(火) 03:45:58.72

すぐりって読むのだと思ってました

**デフォルトの名無しさん** · 2017/07/19(水) 22:41:31.74

https://twitter.com/tanakh/status/886624071005294592

これ？

**デフォルトの名無しさん** · 2017/07/21(金) 21:39:30.54

文字列のリストがあって、それぞれの要素を順番にputStrLnするだけならmapM_よりtraverse_の方がいいですか？

**デフォルトの名無しさん** · 2017/07/22(土) 10:13:22.40

Haskellerなんですぐ死んでしまうん

**デフォルトの名無しさん** · 2017/07/22(土) 11:57:08.36

えぇ・・・

**デフォルトの名無しさん** · 2017/07/22(土) 14:53:16.39

必要以上に多相にしたり制約を弱めるのは典型的な bad practice
concat のかわりに join 使ったりしないでしょ

**デフォルトの名無しさん** · 2017/07/22(土) 14:54:33.27

ライブラリコード書くときには可能な限り型クラス制約を弱めて多相に
利用するコードではむしろ反対に

**デフォルトの名無しさん** · 2017/07/22(土) 17:58:06.65

>>723
つまりtraverse_の方がいいって認識でいいですか？

**デフォルトの名無しさん** · 2017/07/22(土) 19:58:53.32

Haskellerはマジでメンヘラが多い

**デフォルトの名無しさん** · 2017/07/22(土) 22:29:16.45

パフォーマンスモニターを提供する ekg というライブラリがあるんだが、
これ、なかなか凄いな。

統計情報がHTTPプロトコルでリアルタイムに提供されるから、
モニタリング専用のアプリを使わずとも普通のブラウザで見れる。
カウントするものをプログラムの中で定義することもできるみたいだし、
けっこう本格的だ。
パフォーマンスチューニングが捗りそう。

ちなみに、俺はこのライブラリの存在をここで知った。
http://www.stephendiehl.com/posts/production.html
このブログポストに商業アプリ制作にHaskellを使う際の心得みたいなことが書かれていて、
Performance and Monitoring の項で ekg が紹介されている。
このブログの他のポストもなかなか面白いから暇人は読んでみるといいよ。

**デフォルトの名無しさん** · 2017/07/23(日) 00:17:34.21

>>725
ちょい待ち　>>723 や >>724 のアドバイスに従うなら、そこは mapM_ でしょ

**デフォルトの名無しさん** · 2017/07/24(月) 20:13:14.08

他の言語の書き方が良くなると聞いて始めてみたが、難しい・・・
というか今のとこ恩恵が分かんない^^;

**デフォルトの名無しさん** · 2017/07/24(月) 20:20:07.13

他言語の書き方は俺は良くなったな

**デフォルトの名無しさん** · 2017/07/24(月) 21:03:53.98

過去何度か似たような質問や意見が出てるが、
今までこういう書き方だったのがHaskellのお陰でこう改善された、
という具体例が挙がった試しがない。
改善例が載っているブログなどの紹介すらない。

俺の中では、前後の違いを明確に説明できないものは改善とは認められない。
原因がはっきりしない事はあるだろうが、改善したと言うからには
少なくとも違いははっきりと説明してほしい。

それができないと言う事は、きっと違いが説明できないほど微妙で曖昧な変化を
改善と言っているのだろう。

**デフォルトの名無しさん** · 2017/07/24(月) 21:22:17.61

いやそんなの最初からちゃんとやれよと思うかもしれんが非関数型の言語を触っているときに比べて入出力をはっきりと意識するようにはなった
特に動的型付けだと何も考えなくても動くだけのものは作れてしまうからな

**デフォルトの名無しさん** · 2017/07/24(月) 21:27:21.43

大リーグ養成ギブスはめられてるような気持ち

**デフォルトの名無しさん** · 2017/07/24(月) 21:56:08.66

>>731
　　　　 /: : : : : __: :/: : ::/: : :／/: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ　　　　＿＿＿
　　　 /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::､　／　　　　ヽ
　　　 /ヽヽ: ://: :!:,X~::|: /;,,;,/: :／　ﾘ!: ::/ﾉ　 l｀ヽl !: : |: : : :l: :l: ﾘ /　そ　そ　お　＼
　　　/: : ヽヾ/: : l/::l |／|||llllヾ,､　　/ |: :/ , -==､　l＼:::|: : : :|i: |　/ 　う　う　前　　|
.　　 /: : : //ヾ ; :|!: ｲ､||ll|||||::||　　　ﾉノ　ｲ|||||||ヾ､ |: ::|!: : ｲ: ::|/　　な　思　が
　　 /: : ://: : :ヽｿ::ヽl |{ i||ll"ﾝ　　　 ´　　　i| l|||l"l　｀|: /|: : /'!/l 　　ん　う
　∠: : : ~: : : : : : : :丶ゝ-―-　　　　　 , 　ｰ=z_ｿ　　 |/ ﾊﾒ;, :: ::|.　　　だ　ん
　　 i|::ﾊ: : : : : : : : : : : ､ﾍﾍﾍﾍ　　　　､　　ﾍﾍﾍﾍﾍ /: : : : : ＼,|.　　　ろ　な
　　 |!l　|: : : : : : : : :､: ::＼　　　　､-―-,　　　　　　/ : : :丶;,,;,:ミヽ　　う　ら
　　　　　丶: :ﾊ､lヽ: :ヽ: : ::＼__　　｀~　"　　　　　 /: : ﾄ; lヽ）　　　ゝ
　　　　　　ﾚ　｀|　｀､l｀､＞=ﾆ´　　　　　　　 ,　　_´ : :}　｀　　　／
　　　　　　　　 ,,､r"^~´"''''"t-｀r､ _　　-､　´ヽノ　＼ﾉ　　　／　　　　お・
　　　　　　　,;'~　　_r-- ､__　　　　　~f､_>'､_　　　　　　　　 |　　で　　前・
　　　　　　f~　　,;"　　　　　~"t___　　　　ﾐ､ ^'t　　　　　|　　は　　ん・
　　　　　 ,"　　,~　　　　　　　　　ヾ~'-､__　ﾐ_ξ丶　　　　　|　　な　　中・
　　　　　;'　　,ｲ　.. 　　　　　　　　　ヽ_　　ヾ､0ヽ丶　　　　l　　　　　　　　　/
　　　　（　;":: |:　:: ..　　　　　　　　　 .｀,　　ヾ　丶 !　　　　＼＿＿＿＿／
　　　　　;;;; :: 入:: :: :: 　　　　l｀ｰ-､　　）l　　ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　ヾ　丶

**デフォルトの名無しさん** · 2017/07/24(月) 22:18:09.60

俺は大幅に改善されたので満足です

**デフォルトの名無しさん** · 2017/07/24(月) 22:30:09.86

はすける始めたら彼女とセフレが出来ました！

**デフォルトの名無しさん** · 2017/07/25(火) 00:51:32.66

デザインパターンのようなものが自然に学べる(要出典)

>>732
IOモナドを学んでしまうとvoidとかなんやねん！て気持ちになる

**デフォルトの名無しさん** · 2017/07/25(火) 02:18:19.45

IO () ← なんやねん！

**デフォルトの名無しさん** · 2017/07/25(火) 11:48:16.84

空のタプルやね
引数にタプル使わないけど戻り値には使う
他の言語では最も書きにくいパターンを敢えて書く

**デフォルトの名無しさん** · 2017/07/27(木) 03:54:31.04

空のタポゥってvoidに相当するんでないのって訊いてんの！

**デフォルトの名無しさん** · 2017/07/27(木) 07:51:05.82

例えばIO ()なら空のタプル自体は要らなくとも「IOという文脈に包まれている」という情報は欲しい
遅延評価がデフォのHaskellで実行順序
を保証するためにはそれらのIOを繋げる必要がある
voidは何も返さないからそれができない
こんな感じで値そのものに意味はなくとも「それとセットになっている何か」が欲しいとき空のタプルを使うことが多い

**デフォルトの名無しさん** · 2017/07/27(木) 08:18:47.17

空タプルはvoidなんじゃないかっていってるの！
voidが無いなんて嘘っぱちだろっていってるの！

実質 IO void やろってゆってんの！

**デフォルトの名無しさん** · 2017/07/27(木) 08:24:32.65

物狂いか

**デフォルトの名無しさん** · 2017/07/27(木) 11:08:02.42

IO () はIOモナドの中にしか現れられないが
他言語のvoidはその辺の関数に普通に紛れ込めてしまう
もちろん通常は規約とかデザインパターンなどで読みやすく気をつけるわけだけど
IOモナドならそういう意図しない副作用が無いことを
型レベルで保証してくれてありがたい

**デフォルトの名無しさん** · 2017/07/27(木) 11:45:48.74

集合論でいうと()型の値の集合は空集合ではない
デザインパターンでいうとSingleton

だがvoidはSingletonではない
そもそもvoidはオブジェクトか？

**デフォルトの名無しさん** · 2017/07/27(木) 13:52:35.44

Haskellにおいてユニット型の値は () とボトムの2つ。

**デフォルトの名無しさん** · 2017/07/27(木) 15:38:01.66

ボトムは正規形になっていない式ではないのか
途中の式のことを値といっていいのか

**デフォルトの名無しさん** · 2017/07/27(木) 16:36:16.86

>>747
https://wiki.haskell.org/Bottom

> Bottom is a member of any type, even the trivial type () or the equivalent simple type:
>
> data Unary = Unary

**デフォルトの名無しさん** · 2017/07/27(木) 18:13:58.43

value of any typeとは言っていない