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

**デフォルトの名無しさん** · 2019/01/29(火) 09:05:47.90

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

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

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

**デフォルトの名無しさん** · 2019/08/19(月) 17:27:44.29

束縛あり
(m >>= \ x -> return x) = m

束縛なし
(>>= return) = id

**デフォルトの名無しさん** · 2019/08/21(水) 02:19:03.88

関数抽象とかλ抽象とか内容にたいして意味がない説明が長々と続いてると思ったら
単なる無名関数のことだった
最初からそう書けばいいのにわざと理解が遠くなる書き方するのは何だろうね

**デフォルトの名無しさん** · 2019/08/21(水) 03:03:56.38

>>438
それはラムダ抽象などに興味がある読者を対象にしているからかもしれない。

単に説明が下手なだけかもしれないが。

ちなみに私は前者に当たるので、そういう単語が出てくるとワクワクし、理解がはかどる。

**デフォルトの名無しさん** · 2019/08/21(水) 08:26:50.91

>>438
循環論法避けるため
数学だからね

**デフォルトの名無しさん** · 2019/08/21(水) 08:59:06.15

会話成り立ってるのか？

**デフォルトの名無しさん** · 2019/08/21(水) 09:50:43.38

具体例を書けないやつは説明が下手なだけだし
具体例が長々と書かれていたら読み飛ばすようなやつは誤読するだけ

少なくとも動的スコープと静的スコープを間違えた例を書くべきだ
これに関しては数学よりも歴史が役に立つ

**デフォルトの名無しさん** · 2019/08/21(水) 14:58:21.32

今日の流行りはこれ
https://withnews.jp/article/f0190820002qq000000000000000W00o10101qq000019512A

**デフォルトの名無しさん** · 2019/08/21(水) 20:13:20.77

>>442
> 具体例を書けないやつは説明が下手なだけだし

具体例を書けない人間は説明下手以前にそもそも十分に正しく理解していないからこそ具体例を書けないんだよ
中途半端な理解しかしていない人間が上手に説明できるはずがないだろうが

> 具体例が長々と書かれていたら読み飛ばすようなやつは誤読するだけ

具体例として長々としか書けないのも困り者だけれどね
説明する側が本当に良く理解できているならば、よほど高度にテクニカルで微妙な概念や定義でない限り
具体例としては簡潔で短い例や反例を挙げられるはずだ

> 少なくとも動的スコープと静的スコープを間違えた例を書くべきだ
> これに関しては数学よりも歴史が役に立つ

Lispの歴史が正にそれを物語っている
当時MITのAI Lab.のJohn McCarthyらによってLispがλ計算に基づいて初めて産み出された時、λ計算の変数のスコープを間違って
（というよりはLispが実装された1960年代前半のコンピュータのメモリ量と処理能力の極めて厳しい制限から）
動的スコープを採用して久しくその間違いを改めなかったのから、Guy Steele, Jr.らによるScheme言語の提案と同処理系の開発および
Lisp諸方言の統一化としてCommon Lispの言語仕様を策定する際に、変数のスコープとしてはSchemeの静的スコープを標準として採用することで
漸くLispプログラミング界で動的スコープでなく静的スコープが当たり前になったという歴史がね

ついでに言っておくと、かつてのLisp界隈での混乱として、言語仕様上の問題としての動的スコープ-vs-静的スコープの問題と
類似の（だが異なる）問題であるshallow_binding-vs-deep_bindingの問題（こちらは言語仕様でなく実装上の問題）とが混同されていて
混乱を招いていた（かなりしっかりしたLispの教科書でも後者を前者と混同して説明していたり、そもそもこれらの問題があることを理解せずに
書かれていたりした

shallow-vs-deepの問題が言語仕様でなく実装上の問題だと正しく且つ明快に言い切った（私の知る限り）最初のLispのテキストは
Lisp実装者だけでなく（当時の）Lispの上級プログラマにとってもバイブルとでも呼ぶべきJohn Allenの“Anatomy of Lisp”

と、まあ長々とした例を批判しながら、長々と書いてしまって申し訳ない

**デフォルトの名無しさん** · 2019/08/22(木) 09:46:16.96

説得力皆無の文章になったな

**デフォルトの名無しさん** · 2019/08/22(木) 18:48:22.95

力が無いなら金で買えばいい
問題は、相手を説得したい者に課金するか自分を説得してほしい者に課金するか

**デフォルトの名無しさん** · 2019/08/26(月) 15:26:16.91

モナドから得た値ででかいレコード初期化したいときってなんかいい書き方ない？
do記法で左矢印で一々変数に束縛してからフィールドに代入とかするのめんどい
レコードワイルドカード使うのもアプリカティブスタイルで書くのもなんかいまいちだし

**デフォルトの名無しさん** · 2019/08/26(月) 16:58:37.95

>>447
理想はどういう書き方をしたい？

**デフォルトの名無しさん** · 2019/08/26(月) 17:56:50.34

>>448
Hoge { fuga =<< piyo }
こんな感じがいいなあ
レコードワイルドカードだと何してんのかぱっと見よくわからなくなるし
アプリカティブスタイルで書くとフィールドの順番変わったりしたときそれに合わせなきゃいけないのがちょっとだけ嫌

**デフォルトの名無しさん** · 2019/08/26(月) 17:57:34.01

まちがえた=<<じゃなくて<-

**デフォルトの名無しさん** · 2019/08/26(月) 18:35:14.67

そもそも
b <- m
if b then ~
と書かなきゃいけない言語に贅沢言っちゃいかん

**デフォルトの名無しさん** · 2019/08/26(月) 20:58:49.90

ifはアプリカティブを使ってはいけない例か
意図的に書いてるなら頭いいな

**デフォルトの名無しさん** · 2019/08/27(火) 11:02:46.95

C++のnewも一個ずつだ
多変数関数の存在自体がバグみたいなもの

**デフォルトの名無しさん** · 2019/08/27(火) 13:49:23.94

たしかにむずかしいね。

**デフォルトの名無しさん** · 2019/08/27(火) 14:01:37.09

レコードでなくMap型ならモノイドで足して上書きしていけるのに。

**デフォルトの名無しさん** · 2019/08/29(木) 12:53:50.13

Haskellは数学者のおもちゃの域を超えてないな
実用を考えたらライブラリの豊富なPythonに勝るものはない

**デフォルトの名無しさん** · 2019/08/29(木) 13:19:40.08

python にまけるなんていわれるとは

**デフォルトの名無しさん** · 2019/08/29(木) 17:00:49.94

>>456
> Haskellは数学者のおもちゃの域を超えてないな

本当の数学者はHaskellなんて相手にしないよ
Haskellという玩具で喜んで遊ぶのは数学者じゃなくて数学者にあこがれてるだけの単なるプログラマ

**デフォルトの名無しさん** · 2019/08/29(木) 19:08:34.02

じゃあ本当の数学者が相手にしてるプログラミング言語はなんなの？

**デフォルトの名無しさん** · 2019/08/29(木) 19:11:37.53

本物の数学者はパソコン苦手な人も結構いる

**デフォルトの名無しさん** · 2019/08/29(木) 19:43:16.59

そこは計算機科学者と読み替えてさしあげろ

**デフォルトの名無しさん** · 2019/08/29(木) 21:23:41.46

数学基礎論とか論理でしょ
記号遊びに興じてる人々

**デフォルトの名無しさん** · 2019/08/30(金) 00:01:54.88

うちの大学の数学科の計算機系(論理とか統計とか確率とか)の教授はhaskellやってるらしい
あと数学科でやるプログラミングの授業はhaskellらしい

**デフォルトの名無しさん** · 2019/08/30(金) 00:34:37.35

おもちゃとは記号だったのか
記号などなくても実物だけがあればいいという
いわば実物指向

**デフォルトの名無しさん** · 2019/08/31(土) 23:29:39.55

GHC8.8.1リリースされたね。ﾅｶﾞｶｯﾀ
stackで使えるようになるのはいつ頃か

**デフォルトの名無しさん** · 2019/09/01(日) 00:15:49.52

>>418
副作用の有る関数を、副作用の無い関数と同一視する仕組み(IOモナド)の論理的背景とかは理解出来るけど、理解出来なくても使えるしなぁ。。。

>>419
プログラマーが圏論理解するには手助けになるけど、それ以外の人には返って邪魔かも。

**デフォルトの名無しさん** · 2019/09/11(水) 19:32:14.82

ああ！型システム入門─プログラミング言語と型の理論─が埃被ってる！
何年眠っていたんだ！

**デフォルトの名無しさん** · 2019/09/15(日) 12:27:59.45

日系メーカで残業続きの日々です。C++を使っています。
Haskell覚えたらスマートな職場に転職するチャンスありますか？

**デフォルトの名無しさん** · 2019/09/15(日) 13:02:40.03

Javaでないだけマシでしょう
欲張っては全てを失います
胸を張ってC++コードを書き続けましょう

**デフォルトの名無しさん** · 2019/09/15(日) 13:26:30.70

でも所詮日系メーカでプログラミングの向上心持ってるやつなんて上司含めてほとんどおらん
そういう中で品質いいコード書く努力が虚しいんや

**デフォルトの名無しさん** · 2019/09/15(日) 14:38:10.94

転職を強く推奨します

**デフォルトの名無しさん** · 2019/09/15(日) 14:45:40.26

まあたとえ誰も評価してくれなくとも
品質のいいコード書いておけばあとでデバッグやリファクタするときに自分が楽よ
Haskell覚えても転職に良いかはわかりませんが
C++の品質は多分上がる

**デフォルトの名無しさん** · 2019/09/15(日) 19:41:31.15

Haskellは一体いつになったら速くなるんだ
現状Javaにすら勝ててないじゃないか
関数型お得意の『最適化の余地』を永遠に残したままフィニッシュか！？

**デフォルトの名無しさん** · 2019/09/15(日) 20:15:28.04

こんな非効率な言語がPythonよりは速いって思われてる時点で最適化の賜物だろ

**デフォルトの名無しさん** · 2019/09/16(月) 08:42:30.15

関数型言語の最適化の話はOcamlにまかせてある

**デフォルトの名無しさん** · 2019/09/16(月) 20:50:11.40

そういうことならclaspでいいわ

**デフォルトの名無しさん** · 2019/09/16(月) 21:37:02.25

>>475
call-by-valueのOCamlとcall-by-needのHaskellとでは実装法は大きく異なるから最適化技術も両者で大きく異なる
関数的プログラミング言語でもML系諸言語（OCamlやStandard MLなど）やSchemeなどのcall-by-valueセマンティックスに基づく言語の実装は
手続き的（あるいは命令的）プログラミング言語の実装にかなり近いし、例えば命令的言語では最も重要な操作である変数への破壊的代入や
例外処理を言語仕様に追加し組み込むことも特に困難ではない（実際、ML系諸言語やSchemeなどLisp系諸言語は変数への破壊的代入の
プリミティブを有しているし、Standard MLなどは例外処理も言語仕様に最初から組み込まれている）

だが変数への破壊的代入や例外処理といった言語機能をHaskellのようなcall-by-needセマンティックスの関数的プログラミング言語に
追加しようとすると途端にセマンティックスを整合的にすることが困難になる

**デフォルトの名無しさん** · 2019/09/18(水) 22:01:35.11

既出ですかね
プログラミングHaskell第2版、いかがですか？

**デフォルトの名無しさん** · 2019/09/18(水) 22:33:30.71

>>478
買ったばかりでまだほとんど読めてないけど、教科書としてよさげ。
GHC前提になったし、古い記法は一掃されたし、分量も増えてる。
第I部はかなり平易な基礎と型クラスあたりまで。
第II部に対話系からモノイドまで持ってきて充実させてる。
ただ如何せん、出版社が弱すぎて、普通の書店になかなか並ばない。
ネット直販ならいいんだけどね。

**デフォルトの名無しさん** · 2019/09/18(水) 22:46:56.61

東京だと
ジュンク堂や紀伊国屋でさくっと手に入ったけど
まあ普通じゃないな

**デフォルトの名無しさん** · 2019/09/18(水) 23:07:44.70

>>479 >>480
ありがとうございます

第1版は持っているのですが、なかなか良いものなので、増補されたのなら是非と思いまして
当該のサイトにも、池袋のジュンク堂にはあるとあったので、寄り道して購入しようかと…

**デフォルトの名無しさん** · 2019/09/19(木) 11:55:27.58

第一版持ってて尚第二版買うとかハスケルガチ勢かよ

**デフォルトの名無しさん** · 2019/09/19(木) 21:57:13.69

>>482
ページ数は1.5倍位になってるみたいだし、かなり増補されてたからさ

**デフォルトの名無しさん** · 2019/09/20(金) 00:33:53.77

入門はすっとばしてLensとかConduitとか流行ったライブラリの実践例集みたいな本が欲しい
クックブックっていうのかね
なぜ出版社は入門書ばかり刷りたがるのか

**デフォルトの名無しさん** · 2019/09/20(金) 00:45:38.23

入門はいいから初心者を鍛えてくれよ
将棋ウォーズでいうと3～1級を初段～三段に上げてくれる本がないよなぁ

**デフォルトの名無しさん** · 2019/09/20(金) 06:27:12.22

並列並行haskellは面白かったな
英語苦手なのに無料公開されてた英語版全部読んじゃった

**デフォルトの名無しさん** · 2019/09/26(木) 05:11:57.59

結局のところ、rigid type variable ってどんな type variable のことなの？

**デフォルトの名無しさん** · 2019/09/26(木) 14:20:58.03

skolem type variable のことだよ＾＾

**デフォルトの名無しさん** · 2019/09/26(木) 15:49:58.48

>>484
取り敢えず使ってみよう勉強してみようという人間は多いので入門書にはそれなりの部数の需要があるが
実際に入門レベルをクリアしてその先に進む人数は一気に減少するから、その先の技術レベルの内容を扱う書籍は
よほどメジャーな言語でない限り商業ベースには乗らない

それも世界中がマーケットになる英語ならまだしも日本国内しかマーケットのない日本語の書籍となれば尚更ね

**デフォルトの名無しさん** · 2019/09/26(木) 18:11:59.76

入門書はどうでもいいことばかり書いてるから買わないことが多い

**デフォルトの名無しさん** · 2019/09/26(木) 19:57:03.06

>>488
じゃあ、rigid = skolem なのか？

ghc のコンパイルエラーメッセージに
rigid で skolem な型変数がどうとか言う文言があるから、
両者は別物のような気がするのだが。

で、skolem とは何なのだ？

**デフォルトの名無しさん** · 2019/09/26(木) 20:24:22.90

>>491
rigid=skolemだよ
昔skolemとだけ表示されてたんだが、それじゃ分かりにくいというissueが立ってrigidが併記されるようになったらしい

俺もあれがなんなのか知りたい
俺としてはexists a. aみたいな型のことじゃないかと思ってるんだけどよくわからん
わかったら教えて

**デフォルトの名無しさん** · 2019/09/27(金) 03:35:50.99

>>492
なるほど、そういう歴史があったのか。

こういうのこそ、入門書に書いておいて欲しいな。

**デフォルトの名無しさん** · 2019/09/27(金) 22:06:15.87

>>489
資本主義のバグじゃん
パッチ配布はよ

**デフォルトの名無しさん** · 2019/10/05(土) 11:54:01.11

型aがMonadならApplicativeでもあるわけですが、
実用的にreturnとpureが異なるというのは有り得るのでしょうか？

**デフォルトの名無しさん** · 2019/10/05(土) 14:04:06.04

>>495
Monad版とApplicative版とで効率化のため内部実装が異なるということは
もしかしたらあるかもしれない(実例は知らないけど)
Monadが自然に誘導するApplicativeなら振る舞いが異なるということはないはず
(標準的なリストモナドに対するZipListみたいな話を気にしている)

**デフォルトの名無しさん** · 2019/10/07(月) 22:45:01.48

>>496
> Monadが自然に誘導するApplicativeなら振る舞いが異なるということはないはず

ありがとうございます。
安心しました。

**デフォルトの名無しさん** · 2019/10/08(火) 09:34:32.63

モナドでアクションを繋げるってのは何がうれしいの？
参照透過のために仕方なくやってるだけ？

**デフォルトの名無しさん** · 2019/10/08(火) 10:35:16.66

みんなが使う言語の約束事が変更されるまで何年も待つか
一個人が関数を2つ定義するだけで解決するかの違い

**デフォルトの名無しさん** · 2019/10/08(火) 16:25:57.34

同じことの繰り返しを書かなくて済むのが大きいかな。

例えばEitherとIOの組み合わせのモナドでハードとの通信を
書いた時，割り込みプロセスを考えなくてもLeftで返せば
後続コードを飛ばしてエラーを返せるし，コード量が減った
だけ，ミスの発生率も低くなる。

これがモナドなしだとハードとの通信をするたびにエラー
確認コードをいれて例外処理やなんやかやをしないといけ
なくなる。

**デフォルトの名無しさん** · 2019/10/08(火) 17:47:38.95

EitherにもIOにもなるような万能のinstanceにロックイン？してよければclass不要
その気になれば任意の言語で応用可能ということ

**デフォルトの名無しさん** · 2019/10/08(火) 18:00:48.37

結果的にHaskellの生産性は高いの？
ライブラリや学習情報の充実度を無視するとして

**デフォルトの名無しさん** · 2019/10/08(火) 18:17:24.58

少なくともタイプする文字数はめっちゃ減る

**デフォルトの名無しさん** · 2019/10/08(火) 18:27:09.94

もう生産性高いとは誰も言わなくなったね

**デフォルトの名無しさん** · 2019/10/08(火) 19:31:45.70

文字数が減るのは高階関数のおかげ？

参照透過性によるバグの低減やコーディングのしやすさはどの程度あるんだろうか？

**デフォルトの名無しさん** · 2019/10/08(火) 19:37:25.99

巨大になっても線型に複雑度が増加するから他より有利とは言われるが
そこまで大きいの触ったことない

**デフォルトの名無しさん** · 2019/10/08(火) 20:09:52.92

PythonでもHaskellでも、タプルを使うなとか誰も言わなくなれば文字数は減る

**デフォルトの名無しさん** · 2019/10/08(火) 20:44:34.15

文字数減ればいいってんならシェルスクリプトかperlが最適だな。

**デフォルトの名無しさん** · 2019/10/08(火) 21:24:42.66

>> 505
モナドや高階関数のおかげもあるけど文字数が減るのは
つきつめると言語全体に貫かれた表現の簡潔さ志向の仕様によるかな

参照透過性のおかげで副作用を気にせず共通部分を
気軽に関数としてまとめられるとか

ブロック前後の括弧がいらないとか

再利用や多様な型に適合するように引数や関数の名前を短めにするとか

局所変数がないとか

簡単に二引数の演算子を記号を使って定義できるので
関数名を何度も書かなくて済むとか

いろいろ

書く部分が少なくなるとそれだけケアレスミスの入り込む余地は少なくなるね。
それとS/N比がよくなってロジックを追いやすい。

**デフォルトの名無しさん** · 2019/10/08(火) 21:32:14.39

何冊か本を読んだけど、Haskell の気持ちがなかなか分からん…

**デフォルトの名無しさん** · 2019/10/08(火) 21:39:47.76

何か書いてみた？

自分はRWHとかPCHとか読みながらオレオレプロジェクトを仕立てて
書き進めていったらある日を堺に急にこういうことかと理解が進んだ。

**デフォルトの名無しさん** · 2019/10/08(火) 22:21:53.53

やはりどんどん書かないとダメですよね…
おかげさまで、本業とする言語でのコーディングには有意義なフィードバックができてはいるのですが
そもそも GHC が吐き出すエラーメッセージがなぁ～

**デフォルトの名無しさん** · 2019/10/08(火) 23:04:55.55

自分もエラーが何を意味しているのか最初はわからなかった。

ただほとんどのエラーは型の不一致由来。

だから何行目のどこでエラーが出ているかだけわかればあとは
型を順番に調べていって解決できるようになった。

スペルを間違えたり似たような目的で使う別の型と勘違いしていたり
とかそれなりの理由でエラーが出ているはず。後者は代数データ型を
適当にその場で作ったりしてた頃によくやってた。

**デフォルトの名無しさん** · 2019/10/08(火) 23:09:06.98

LispとHaskellの間には謎の暗黒時代があるから
結果がすべての人にはそれがわからんのです

**デフォルトの名無しさん** · 2019/10/08(火) 23:13:57.88

その暗黒時代にSMLの本を店頭で見かけて気になった記憶がある。
結局買わなくていきなり普通のHaskellまでとんだ。

ソースから実行コードにどんなふうにおとしていってるのか最近
気になってきたのでそのうち古本でMLの本でも手に入れるか
GHCのが吐くコードを追っかけてみたい。

**デフォルトの名無しさん** · 2019/10/08(火) 23:33:07.01

>>513
ありがとうございます >>512 です
皆さん同じような苦労をされているのかなと、少し楽な気持ちになりました
もう少し粘り強く取り組んでみます!

**デフォルトの名無しさん** · 2019/10/08(火) 23:42:31.20

どういたしまして！

基本文法は簡単だから文法エラーはすぐにほとんど出なくなります。

そこまでいったら初級編終了。

**デフォルトの名無しさん** · 2019/10/09(水) 00:44:23.02

圏論の本を読もうと思ったら数学地獄にはまる

**デフォルトの名無しさん** · 2019/10/09(水) 22:12:42.71

VIMで関数名にカーソル合わせると自動で型シグネチャ動的推論して表示してくれる機能ありませんか？

**デフォルトの名無しさん** · 2019/10/10(木) 00:08:02.64

ダイクストラのアルゴリズム
優先度付きキューの手作りから始めて一週間かかってやっと完成した

あたまわーるわるわーるーわる～♪
sm32181836
脳裏に流れてる

**デフォルトの名無しさん** · 2019/10/10(木) 09:37:00.35

善意的に解釈してアルゴリズムの方の動画だと思ったが
案の定あたまわるい方の動画だった

**デフォルトの名無しさん** · 2019/10/10(木) 19:26:23.87

practical haskell second edition読み終わった

**デフォルトの名無しさん** · 2019/10/11(金) 18:25:28.60

Haskell Wiki
!haskellwiki
Hayoo
!hayoo
Hoogle
!h
Hackage
!hkg
Hoogle at Stackage
!stackage
https://duckduckgo.com/bang?c=Tech&;sc=Languages+(Haskell)

**デフォルトの名無しさん** · 2019/10/11(金) 20:15:13.77

アマゾン.co.jp
!ajp
https://learning.oreilly.com/home/
!orly
O'Reilly
!oreilly

**デフォルトの名無しさん** · 2019/10/12(土) 00:29:02.70

>>510

mylist 3 = [[1,2,3],[4,5,6],[7,8,9]]

みたいなリストを作る関数をHaskellで作ってみれば関数脳に目覚める。
割とマジで。

Haskell入門以前って電子書籍で書いたが、自力で目覚めるなら買わなくても良い。
(Haskell入門書読んでも宣言的とは？関数脳とは？がピンと来なかった経験から書いた)

**デフォルトの名無しさん** · 2019/10/12(土) 00:42:17.63

パッと思いついたのはこんな感じ？
添削してくれたら嬉しい
HaskellでなくPureScriptだが

mylist :: Int -> Array (Array Int)
mylist n = do
i <- 1..n
pure [i*3 + 1, i*3 + 2, i*3 + 3]

**デフォルトの名無しさん** · 2019/10/12(土) 01:48:37.28

>>525
コメントありがとうございます!
>>510です

ひねりなしですが…

mylist :: Int -> [[Int]]
mylist n = chop n [1..n^2]

chop :: Int -> [a] -> [[a]]
chop _ [] = []
chop n xs = take n xs : chop n (drop n xs)

chop は、直近に読んだ書籍からそのままアイデアを拝借しましたが、カンニングなしで書きました

[1..] のように、無限リストで書けたらと思いましたが、酒気帯びなためダメでした

IO の純粋って、のようなことがサッパリです…

**デフォルトの名無しさん** · 2019/10/12(土) 02:00:10.51

>>527
うーん・・・。
貴方はまだ手続き脳ですね。
(その手順でも関数脳を実感する人は実感するのでしょうが)
罰としてHaskell入門以前をご購入下さい。

IOの純粋は、「プログラマーのための圏論」と言うPDFがネットにあるのでググって読んでみると良いです。

**デフォルトの名無しさん** · 2019/10/12(土) 02:20:05.14

(n: number) => Array.from(Array(n).keys()).map(
　　i => Array.from(Array(n).keys()).map(
　　　　j => n * i + j + 1
　　)
)

**デフォルトの名無しさん** · 2019/10/12(土) 02:25:29.50

>>528
>>510です
では、

mylist :: Int -> [[Int]]
mylist n = take n (chop n [1..])

**デフォルトの名無しさん** · 2019/10/12(土) 02:33:17.76

>>528
>>510です
コメントをつけ忘れましたが、ご紹介いだいた圏論のレポートは、以前にちょっと目を通したことがあったと思いますが、サッパリだった記憶が…
あらためて拝見します
ありがとうございます!

**デフォルトの名無しさん** · 2019/10/12(土) 08:28:10.44

>>530
ちょっとchopと[1..]から離れましょう。
そして、[1..n]に何をすれば次のリストを得られるか考えましょう。
プレリュードの(入門以前と書かれた通り)基本関数の組み合わせだけで書けます。

IOと言うより入力ですが、関数の引数か、外部からの入力かだけで中身の処理は普通の関数と同じと捉えましょう。
そうするとreadLine関数が部分適用で見た目の引数の減った普通の関数に見えて来ませんか？

圏論で謳っているのは、どこから来たかが違っていても同じ事をするなら、同じ関数と見なそう。
そう言う、ある着目点以外の差異を無いものとするという事です。

**デフォルトの名無しさん** · 2019/10/12(土) 11:27:51.29

>>510 です

mylist n = take n $ f [[1..n]]
where
f [ns] = ns : f [g ns]
g ns = map (+3) ns

としたところで、要素に f を繰り返し適用して無限リストを作る関数があることを思い出し、思い出せずにカンニングして iterate を発見

mylist n = take n $ iterate f [1..n]
where
f ns = map (+n) ns

map (+n) 辺りがどうも…

**デフォルトの名無しさん** · 2019/10/12(土) 11:28:38.29

インデントの空白が消えるのか

**デフォルトの名無しさん** · 2019/10/12(土) 11:30:28.30

間違えた、先の関数の (+3) は (+n) でした

**デフォルトの名無しさん** · 2019/10/12(土) 14:40:27.19

文字数が減る主義を粛清した結果がこの関数脳内革命なのか？
文字数が減るでよかったのに

**デフォルトの名無しさん** · 2019/10/12(土) 19:37:37.13

>>525
あの本出版した人？
いくら稼げた？