関数型プログラミング言語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/12/12(木) 11:38:57.75

>>840
はい。 f,g はトップレベルではなくIOアクションの中で定義しても大丈夫です。

IORefを使わなきゃ無理かな、と思ってたんだけど、これは目から鱗でした。
cached = pure
でいいんだよね？単にモナド一枚かぶせるだけで計算のキャッシュになるなんて、
今年一番のオドロキですわ

**デフォルトの名無しさん** · 2019/12/12(木) 13:37:02.84

>>841
cached = pure ではない
IORefを使うのは正しい

**デフォルトの名無しさん** · 2019/12/12(木) 15:32:55.96

>>842
うーん指摘の通りだった。
>>841 のやり方ではIOアクション cachedHeavy を簡約で実行した時点で heavy が計算される。
f や g の中でそれぞれ実行したなら都度重い計算が走ってしまう。
i <- cachedHeavy をその前に実行するなら一度で済むが、遅延の要件「f,g のどちらかが呼ばれるまではしたくない」
を満たさない。

**デフォルトの名無しさん** · 2019/12/12(木) 15:46:44.83

つまり…　こんな感じでいいのかしら

cached :: IO a -> IO (IO a)
cached f = do
　r <- newIORef Nothing
　pure $ do
　　c <- readIORef r
　　case c of
　　　Nothing -> do
　　　　ts <- f
　　　　modifyIORef r . const . Just $ ts
　　　　pure ts
　　　 Just ts -> pure ts

＞ x <- cached $ print "heavy" >> pure 42
＞ x
"heavy"
42
＞ x
42

**デフォルトの名無しさん** · 2019/12/13(金) 00:08:15.85

IORefをご存知でない？

**デフォルトの名無しさん** · 2019/12/13(金) 11:45:01.85

>>845
間違っているところがあったら、具体的に教えていただきたい。

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

cabalファイルの中でexectableで同じcabalファイルの
ライブラリー名をbuild-dependsにかいてあるのに
そのライブラリーのbuild-depensを全部書かないとコンパイルできない
のはなんで？テンプレート使ってるからとかある？

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

ソースディレクトリをexeとlibに別々にしたら直った
なんだこのバグは酷いバグだ

**デフォルトの名無しさん** · 2019/12/16(月) 18:39:37.82

岡部健 (Ken Okabe)今度はQuoraでもアカウントBANされる
https://link.medium.com/EX3Y4COIs2

**デフォルトの名無しさん** · 2019/12/16(月) 19:25:09.38

終わったコンテンツでしょ、彼はもう

**デフォルトの名無しさん** · 2019/12/17(火) 00:03:50.44

オワコン。人間もっとやることある

**デフォルトの名無しさん** · 2019/12/17(火) 08:07:51.17

キャッシュ？ https://wandbox.org/permlink/98ZKnQW0uSr5c5CV

f () = print "hoge" >> getLine >>= \x -> print "foo" >> return (\() -> x)
main = do
putStrLn "1234"
f () >>= \g -> do
let e = g ()
print e
print e

**836** · 2019/12/17(火) 15:16:27.15

>>852
たしかに f で行なった計算の結果を g で使えてるけど、俺の求めてたのは
さらに g の結果も f で使えることなんです。どっちを先に実行しても計算は一度だけ、を求めてた。

**デフォルトの名無しさん** · 2019/12/17(火) 22:59:40.32

そもそもライブラリを全てimportする奴はいないので
使わなかったライブラリのコードは最後まで実行されない
全てのライブラリについて使うか使わないか予測できないならば実行の順序は予測できない

**デフォルトの名無しさん** · 2019/12/18(水) 00:29:20.63

>>854
ここにいるぜ。まあ可能な限り、ということだけども…
多すぎでリンクできなくてGHCが落ちるのが面白かった。

**デフォルトの名無しさん** · 2019/12/18(水) 09:15:25.20

え、岡部健ってQuoraで暴れてたの？
アカウント停止はまた癇癪起こして名誉毀損してたとかが理由？？

**デフォルトの名無しさん** · 2019/12/18(水) 11:17:26.49

>>856
彼がなにかしらのコミュニティーでうまくやっていけないのは、これまでの活動からわかりきっている。
むしろ、Quoraではよく持った方だと思うよ。お薬をきちんと服用するようになってるんだろうね。

**デフォルトの名無しさん** · 2019/12/18(水) 14:06:51.57

あいつか

**デフォルトの名無しさん** · 2019/12/19(木) 00:31:57.76

haskell自体はいいんだけどstackとかhieとかいちいちでかくてめんどくさい
本当にhaskell書いてる人はいるの？

**デフォルトの名無しさん** · 2019/12/19(木) 07:07:47.77

依存関係を管理するのは理想
依存関係を消すのが現実
C++やSTLに依存することすら嫌ってCだけで書くみたいな現実

**デフォルトの名無しさん** · 2019/12/19(木) 07:48:35.49

hieはもうちょっとなんとかならんのかとは思う

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

>>860
Rubyをdisるのは止めれ

**デフォルトの名無しさん** · 2019/12/19(木) 14:13:07.54

実際にHaskellでコード書いてみると分かるけど
コンパイル通れば計算結果は確かに正しいんだけど
巨大なメモリを謎に使うようなバグが混入する事が結構あって
その種類のバグってエラー吐かないから特定がめっちゃ難しい。
巨大なプロジェクトでHaskell使うのは現実的には無理だと思う。

**デフォルトの名無しさん** · 2019/12/19(木) 14:32:39.93

それ
haskell で書かれたプログラムのパフォーマンスチューニングむずすぎる

**デフォルトの名無しさん** · 2019/12/19(木) 14:54:58.39

あればあるだけ使おうとするんでない？
足りなくなってからようやく（これからやる処理に必要最低限の）ガベコレ
この繰り返しだから永遠に自転車操業

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

この種のバグの混入原因って大抵の場合
ネットに散らばっている'Haskellらしい'記法にあったりするから
初心者の頃に読んだ書き方が
「(実はこの人全然Haskellでコード書いてないじゃんっ！！)」
と気が付くまでワンセット

ネット上だと処理が大きくなると破綻するようなサンプルコードばっかりでウンザリする
特に遅延評価を活用するような記法は
大抵メモリ関連のバグの原因になるから実際には避けなきゃダメなのばかり

**デフォルトの名無しさん** · 2019/12/19(木) 20:23:04.10

デフォルトの挙動性格評価にするやつあったよね
あれ使ってる？

**デフォルトの名無しさん** · 2019/12/19(木) 20:49:23.97

ガベコレ言語を全否定してみるのも一つの方法
たとえばスマホが壊れたら全部新品にするかそれとも壊れた部品を特定してそこだけ修理するか

**デフォルトの名無しさん** · 2019/12/19(木) 20:50:47.99

結局最適化しようとするとコンパイラのくせをしっかり理解してたり
凄まじい技術力がいるという。。

**デフォルトの名無しさん** · 2019/12/19(木) 23:44:31.80

つまり Rust の時代か

**デフォルトの名無しさん** · 2019/12/20(金) 10:00:27.91

Rustってhaskellerにも結構評判いいけどどうなの

**デフォルトの名無しさん** · 2019/12/20(金) 11:16:14.21

>>871
俺は「あぁ，Haskell でいうアレね」みたいな感じで学べた
厳密な感じが好きなら，気にいるんじゃないのかな
ドキュメントも揃っていて学びやすいと思う

ただ，俺はいまいち使い所を見いだせてない
Haskell で書ける分野なら Haskell で書いちゃうし
ちょっとしたツールとかサーバーサイドとかは Go のが楽だし

WebAssembly を生成するために使うのが
今一番，Rust の活きる分野な気がする
Rust は，クロスコンパイルが楽なので

(個人の感想です

**デフォルトの名無しさん** · 2019/12/20(金) 11:25:55.75

>>871
ただのLisp方言やML方言はもう飽きたってことだろ

**デフォルトの名無しさん** · 2019/12/20(金) 12:03:56.77

「C言語は純粋関数型」と言ってたのってQuoraの岡部健？

**デフォルトの名無しさん** · 2019/12/20(金) 21:36:07.96

フロントをrustで書くとか一番馬鹿な選択だろ。話にならん。

**デフォルトの名無しさん** · 2019/12/23(月) 17:59:43.65

もしかしてParsecってあんまり使われてない？
Parsecのドキュメントが2001年とか古いのしか無くて、最初のサンプルコードすら通らない
ライブラリの使い方が解らなくていきなり躓いてる

**デフォルトの名無しさん** · 2019/12/23(月) 18:29:48.72

ここの住民、圏論とかの話だと玄人っぽいのにプログラミングの話になると初心者っぽくて謎

**デフォルトの名無しさん** · 2019/12/23(月) 20:24:57.43

>>876
ドキュメントと言うのが何を指しているのか具体的なURLを示してくれないと、
何が原因でどう躓いているのか、助けようにも調べる取っ掛かりが無くて困る。

あと、本当にその古いドキュメントとやらしか学習資料は無いのか？
他にチュートリアルやブログなどは参考にならないのか？

**デフォルトの名無しさん** · 2019/12/23(月) 20:56:14.64

どうせ躓くなら一番最初に躓く初心者っぽい奴の方が運が良い
ビギナーズラック

巨大なメモリを使う巨大なプロジェクトの完成直前に躓くのはかなり運が悪い

**デフォルトの名無しさん** · 2019/12/23(月) 21:51:15.50

>>876
Parsec の開発は今や"メンテナンスモード"に入っていて、代わりに attoparsec や megaparsec が活発。
https://haskell.e-bigmoon.com/posts/2019/07-14-megaparsec-tutorial.html

**デフォルトの名無しさん** · 2019/12/23(月) 21:58:54.38

ここ[parsec: Monadic parser combinators](http://hackage.haskell.org/package/parsec)に載ってる
これ[Parsec, a fast combinator parser](https://web.archive.org/web/20140528151730/http://legacy.cs.uu.nl/daan/download/parsec/parsec.pdf)です
他のは、ついでにParsecに触れているという感じで、詳しそうなのはこれしか見付けられませんでした

＜続く＞

**デフォルトの名無しさん** · 2019/12/23(月) 21:59:30.49

最初のサンプルコードをGHCiで打ち込んで試そうとしてるんですが、

Prelude> module Main where
Prelude> import Parsec

<no location info>: error:
Could not find module ‘Parsec’
Perhaps you meant Parser (needs flag -package-key ghc-8.6.5)

モジュールが見つからないと言われます
最新バージョンの名前空間？と明らかに違っているので、
ここ[Text.Parsec](http://hackage.haskell.org/package/parsec-3.1.14.0/docs/Text-Parsec.html)で、この二行

import Text.Parsec.Prim
import Text.Parsec.Combinator

を見付け書いたところ

Prelude> import Text.Parsec.Prim
Prelude Text.Parsec.Prim> import Text.Parsec.Combinator

＜続く＞

**デフォルトの名無しさん** · 2019/12/23(月) 22:00:22.40

Prelude Text.Parsec.Prim Text.Parsec.Combinator> simple :: Parser Char

<interactive>:6:11: error:
Not in scope: type constructor or class ‘Parser’
Perhaps you meant one of these:
‘Parsec’ (imported from Text.Parsec.Prim),
‘ParsecT’ (imported from Text.Parsec.Prim)
Prelude Text.Parsec.Prim Text.Parsec.Combinator> simple :: Parsec Char

<interactive>:7:11: error:
? Expecting two more arguments to ‘Parsec Char’
Expected a type, but ‘Parsec Char’ has kind ‘* -> * -> *’
? In an expression type signature: Parsec Char
In the expression: simple :: Parsec Char
In an equation for ‘it’: it = simple :: Parsec Char
Prelude Text.Parsec.Prim Text.Parsec.Combinator> simple :: ParsecT Char

<interactive>:8:11: error:
? Expecting three more arguments to ‘ParsecT Char’
Expected a type, but
‘ParsecT Char’ has kind
‘* -> (* -> *) -> * -> *’
? In an expression type signature: ParsecT Char
In the expression: simple :: ParsecT Char
In an equation for ‘it’: it = simple :: ParsecT Char

引数が足りないみたいなことを言われます
英語も怪しいのに英語の解説も使えないとなるとどうして良いやら…

**デフォルトの名無しさん** · 2019/12/23(月) 22:04:05.15

haskell ide engine って今どんな使用感？
そろそろ spacemacs haskell layer (中身 intero) から乗り換えようと思ってんだけど
未だにバージョン 1 未満なのが気になった。まだ待つべきかな。

**デフォルトの名無しさん** · 2019/12/23(月) 22:05:51.18

>>880
おお、ありがとうございます
そっちでやってみます

**デフォルトの名無しさん** · 2019/12/23(月) 22:07:10.46

>>877
クヌースなんかもそんなもんだぞ。
プログラム理論と実装ガツガツやる能力は別物だから。

**デフォルトの名無しさん** · 2019/12/23(月) 22:28:25.82

>> 883
このエラーメッセージ
Not in scope: type constructor or class ‘Parser’
これは Parser が見つからないよ。みたいな意味

検索サイトのフーグルを「パッケージ指定」機能を使って探すと
https://hoogle.haskell.org/?hoogle=Parser%20package%3Aparsec
Parser は import Text.Parsec.String すれば使えるってことが解って、
同じように letter の場所も調べられる。

attoparsec や megaparsec にも似たやつあるっぽいから、何となくで読み替えていけばいいんじゃないかな。

**デフォルトの名無しさん** · 2019/12/23(月) 23:28:55.39

>>886
> クヌースなんかもそんなもんだぞ。

Knuthはそんなことはないだろ
TeXもMetafontも最初のはKnuth自身が実装したのだから

> プログラム理論と実装ガツガツやる能力は別物だから。

圏論なんかの知識は実装と全く関係ないからね、そういう方面に明るいのと実装能力とは全く無関係だ

**デフォルトの名無しさん** · 2019/12/23(月) 23:34:33.07

KnuthやLinusって
圏論どころかカプセル化・継承・ポリモーフィズムすら使ってない印象がある
実装能力とは全く無関係だし

**デフォルトの名無しさん** · 2019/12/24(火) 07:35:31.98

>>889
は？
そんなの日本の組み込み現場の奴らの大多数と同レベルじゃん

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

何をもってknuthにスキルを疑うのか分からんのだけど、彼のプログラミングスキルが
ゴミクズな世界があったとしても、scratchから書く問題ならアルゴリズムだけで
他の人より速いもの書いてそう

**デフォルトの名無しさん** · 2019/12/24(火) 16:43:33.89

>>876
すごくタイムリーに reddit に似た質問が上がってるんだが偶然？
https://www.reddit.com/r/haskell/comments/ee6lwy/resources_for_learning_parsec/

**デフォルトの名無しさん** · 2019/12/24(火) 21:34:10.54

本人がtex書くまでこれほど大変と思ってなかったいうとるやん。
そのあとの文芸プログラミングとか、cのコード見てても、これあかんなとしか思わんわ。

**デフォルトの名無しさん** · 2019/12/27(金) 22:57:25.24

**デフォルトの名無しさん** · 2019/12/28(土) 23:16:17.55

Haskellは小さいプログラムを作るには最適なんだけど
大きいプログラムになるとメモリ周りの最適化が困難なのよね
実行結果自体は正しいからテストすり抜けるだろうし
バックエンドで採用しても
本番環境で初めてメモリヤバイと気付いて死ぬ未来しか見えない

**デフォルトの名無しさん** · 2019/12/29(日) 00:21:25.50

自家用ジェット機と大型旅客機みたいなイメージかな

**デフォルトの名無しさん** · 2019/12/29(日) 11:10:02.50

死ぬことなく成功させた例
https://serokell.io/blog/top-software-written-in-haskell

**デフォルトの名無しさん** · 2019/12/29(日) 13:22:56.43

>>897
最初に上がってたsigmaの記事を発見したぞ
https://engineering.fb.com/security/fighting-spam-with-haskell/
なるほどHaskellを実運用するコツはGHCの魔改造から着手する事なのか
・・・って真似できるかーい！！

**デフォルトの名無しさん** · 2019/12/29(日) 15:18:21.26

>>898
ノリで採用したら地獄を見た感がヒシヒシと伝わってくる記事だね
その後facebookでHaskellを採用していない事実で察し
https://livedoor.blogimg.jp/sag_alt/imgs/7/e/7ece2698.png

**デフォルトの名無しさん** · 2019/12/29(日) 16:42:39.91

遅延評価を諦めて型システムとパターンマッチ系統だけを
よくわからないけどCとかC++辺りに持っていくじゃだめかな

**デフォルトの名無しさん** · 2019/12/29(日) 22:43:02.62

何を諦めたら最適解になるか？

これは愚問

**デフォルトの名無しさん** · 2019/12/30(月) 01:49:49.36

赤黒木のコード読んでいたら
関数の定義に型情報があるけど
型推論で処理されるコード部分には型情報がない
目視で定義ーコード部を交互確認すると結構きつい

抽象化には貢献してるけど、人間が読み下すのは大変、オレはコンピュータじゃない(怒
そんな感じ

**デフォルトの名無しさん** · 2019/12/30(月) 07:02:47.72

そんなのエディタにやらせればいい

**デフォルトの名無しさん** · 2019/12/30(月) 09:12:01.80

要件定義が整っている関数の書き下ろしと
プログラムで記述されたコードの読み下しは難度が異なる
Haskellのコードは情報密度が高い事と抽象度の高さが強烈に効く

**デフォルトの名無しさん** · 2019/12/30(月) 09:50:40.36

Hakellだしコード読めば分かるだろ(コメントなし）
↓数カ月後
俺の書いたコードなのに意味が分からない・・・

**デフォルトの名無しさん** · 2019/12/30(月) 10:41:43.52

工学と名のついた無根拠な宗教が蔓延ってる言語よりは科学してるだけマシ

**デフォルトの名無しさん** · 2019/12/30(月) 12:14:13.13

>>905
次の日とか
その日のうちでも
意味が分からなくなることがある

**デフォルトの名無しさん** · 2019/12/30(月) 13:26:36.21

赤黒木は左右対称のコードを2回書かされるから書きたくない
コードを読まなくても分かる
読む前から分かることをどれだけ知っているかが重要
読み始めてから努力するのは遅い

**デフォルトの名無しさん** · 2019/12/30(月) 16:27:15.32

>>899
>その後facebookでHaskellを採用していない

https://engineering.fb.com/security/simon-marlow/

**デフォルトの名無しさん** · 2019/12/30(月) 20:14:21.30

https://stackshare.io/haskell

**デフォルトの名無しさん** · 2019/12/30(月) 21:52:49.75

>>909
よく読め、受賞は2019年だが
受賞内容は2009年の功績の話だぞ
そこで語られてる内容も2014年のGHC魔改造の件の話だし
5年も経過してるのに未だにその話しか出てこないって事はそういう事よ

**デフォルトの名無しさん** · 2019/12/30(月) 22:25:35.97

よく読んだら分かること
読まなくても分かること
普遍的な方を重視するのがいいと思うよ

**デフォルトの名無しさん** · 2019/12/30(月) 23:48:10.12

>>911
枯れてきてるんじゃない？

https://github.com/facebook/Haxl

**デフォルトの名無しさん** · 2019/12/31(火) 00:12:07.17

ちなみにFacebook自身は2015年の投稿で2年かけて
Sigmaの主要技術をHaskellに移行したといっている
https://engineering.fb.com/security/fighting-spam-with-haskell/

スライドもある
http://multicore.doc.ic.ac.uk/iPr0gram/slides/2015-2016/Marlow-fighting-spam.pdf

そしてSigma の Software Engineering Manager の公募を最近LinkedInでかけていた
職位はManagerだし応募要件にはHaskellスキル必須とは記載していないようなので
Haskellが実用的に使われているっていう傍証にはならないけどプロジェクトは生きてる様子

またその後別の各技術にとってかわられたという情報もなさげ

**デフォルトの名無しさん** · 2019/12/31(火) 01:50:17.69

紹介済み？
https://serokell.io/blog/haskell-highlights-2019?

**デフォルトの名無しさん** · 2019/12/31(火) 02:29:04.76

ナイス

**デフォルトの名無しさん** · 2019/12/31(火) 23:30:17.57

>>898
haskellやってる奴が評価されるのはその手の最適化できることを見込まれてるからだぞ。

**デフォルトの名無しさん** · 2020/01/01(水) 04:13:12.99

Haskellを始めたばかりの者です
do構文は多用しても良いのですか？
手続き型を書いているような気分になります
関数型言語は初めてなので不安です

**デフォルトの名無しさん** · 2020/01/01(水) 09:08:22.50

>>918
いいよ。モナドは手続きを実現するのに役立つ抽象だよ。
でもアプリカティブで用が足りるならアプリカティブを使うべき。
IO モナドを do で合成するシーンが多いならリファクタリングの余地があるかも。
Control.Monad や Control.Applicative のユーティリティが利用できないか検討してみて

**デフォルトの名無しさん** · 2020/01/01(水) 09:16:52.80

=>= 2020年の抱負 =>=

・珠玉本を再開したい。少なくとも二度目の四天王登場回までは行きたい
・Haskell でごはん食べる

**デフォルトの名無しさん** · 2020/01/01(水) 10:49:49.64

豊富なんてかいちゃって意識高い系かよｗｗｗｗｗｗ

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

>>921 いいでしょw 新年なんだし

【最底辺】【25円】 · 2020/01/01(水) 13:25:14.55

Haskellの未来

**デフォルトの名無しさん** · 2020/01/01(水) 16:23:17.36

一般化が未来だと仮定すると未来は...

**デフォルトの名無しさん** · 2020/01/02(木) 06:03:17.61

>>920
海外にはRemote OKなところあるよ

A List of companies that use Haskell
https://github.com/erkmos/haskell-companies

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

OSS として良さげなツールを作って
Github Sponcers で支援を受ける
って方針を考えてる。どうかな

**デフォルトの名無しさん** · 2020/01/02(木) 07:26:54.44

>>925
名古屋の時計販売店BIGMOONさん
https://www.e-bigmoon.com
https://haskell.e-bigmoon.com ってお役立ちHaskell 情報がありがたいサイトやん。
中の人、時計屋さんだったのか…

**デフォルトの名無しさん** · 2020/01/03(金) 13:05:21.13

Haskellは妙にテクニカルな部分が多い気がする
2変数関数fと1変数関数gを合成するときに
g . f
ではだめで
g .: f where (.:) = (.) (.) (.)
って書くのとか良く思いつくなって感じ

**デフォルトの名無しさん** · 2020/01/03(金) 13:32:58.92

>>928
それは、ポイントフリーで書いているからテクニカルに見えるたけで、
引数を明記すればビギナーにも理解できる式になるぞ。
やってみれば分かる。

他のもそうだ。
例えばライブラリの作者がポイントフリーで書いているのは、
その方がベテランの作者やコミュニティーにとって読みやすいからだ。
彼らもビギナーを相手に解説する際は、
自分達には多少洗練されていない様に見えても、
ビギナーにとっての読みやすさを優先する。

日本語の文章における「漢字」と「かな」の関係のようなものだ。

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

>>929
(((.) (.) (.)) g f) a b
をパパっと
g (f a b)
に式変形できる自信が無い

**デフォルトの名無しさん** · 2020/01/03(金) 13:53:52.89

g . f がだめな理由は型なので
fun<A, B> g;
fun<C, fun<D, A> > f;
このような型を宣言できる任意の言語に同じ問題がある
また、他の言語で問題が解決されたらHaskellでも解決できる

**デフォルトの名無しさん** · 2020/01/03(金) 14:08:31.95

>>931
g :: b -> c
f :: a1 -> a2 -> b
に対して
(.) :: (b -> c) -> (a -> b) -> a -> c
の a を a1 -> a2 と解釈してくれれば話が速いんだけどね
a1 -> a2 -> b が実際には a1 -> (a2 -> b) で要は(->)が右結合だから駄目なのよね

**デフォルトの名無しさん** · 2020/01/03(金) 15:06:47.95

>>930
すまん、そういう話ではない。

「妙にテクニカルな部分が多い」と言うのは、
君の感じたhaskellの不満点や欠点なんだと俺は捉えたが、違うか？

2変数関数と1変数関数とを合成する関数(.:)の「型がまず先」にあって、

　　(.:) :: (c -> d) -> (a -> b -> c) -> (a -> b -> -> d)

これを実装するのに

　　(.:) = (.) (.) (.)

と書く者もいて、君に妙にテクニカルだと感じさせるのかもしれないが、

　　(.:) g f = \a b -> g (f a b)

こう書けば、ビギナーにも容易に意味が読みとれる。
テクニカルでは全然ないだろう。

君が妙にテクニカルだと感じる大部分はhaskellの生来のものではなく、
単にビギナーに読めるようにも書けるコードをたまたまテクニカルに書いただけだ。

身の丈や好みに合った書き方をすれば不満に感じることはないだろう、と言いたかった。

**デフォルトの名無しさん** · 2020/01/03(金) 15:11:49.96

>>932
随伴の事か

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

>>933
Haskellに不満を持ってるとかではなくて単に凝った式に良く出会うというだけの話よ
そして凝った式を同値変形で分かりやすい式に変形するのが難しいことも多いと思う
個人的にはどう実装するかよりもどう同一視するかの方に興味がある

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

>>935
そうだったのか、俺の完全な勘違いだった。
長文でレスの流れぶった切ってすまなかった。

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

>>936
謝ることは無いよ
自分も言葉足らずだったし
興味深い話が聞けて良かった

**デフォルトの名無しさん** · 2020/01/03(金) 18:40:52.72

凝った式を書ける俺ってイケてる！っていう中二病の文化なんでしょ

**デフォルトの名無しさん** · 2020/01/03(金) 21:30:15.19

また心理の話してる
メンタリストの文化なのかな

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

リストの1要素を書き換える関数が用意されてないのは、それが非推奨だからなの？
配列みたいな気分では使えないのかな