関数型プログラミング言語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/03/23(土) 19:48:40.97

>>259

https://i.imgur.com/816HQOu.jpg

https://i.imgur.com/wTI8fNg.jpg

一応、末尾再帰も式変形した定義通りなんだけどね。

fib3 0 a _ = a
fib3 n a b = fib3 (n - 1) b (b + a)

n = フィボナッチ数のn番目(fib n)

a = fib nの時のフィボナッチ数

b = fib (n + 1) の時のフィボナッチ数

fib3 nはfib3 (n - 1)のbがaになり、b(fib3 (n + 1))はfib3 (n - 1)のb(fib3 n) と a(fib3 (n - 1))を足したものである。

**デフォルトの名無しさん** · 2019/03/23(土) 23:02:28.70

>>269 賭けない、は具体的には何？型シノニムを使わないということ？

**デフォルトの名無しさん** · 2019/03/24(日) 00:23:58.92

>>271
使うのは自由だが可読性の勉強等はしないということ

**デフォルトの名無しさん** · 2019/03/24(日) 00:47:12.07

>>272
悩んでないでスタイルを決め打ちして自分が自然だと思える書き方で行く、みたいな感じですか

**デフォルトの名無しさん** · 2019/03/24(日) 09:54:41.46

そんな言葉は使う必要がねーんだ
書き方は決まってないのにもうすでに書き終わってるからだ

**デフォルトの名無しさん** · 2019/03/24(日) 11:22:25.74

やっぱりHaskellは常人向けではないんですね
Ocamlやります

**デフォルトの名無しさん** · 2019/03/24(日) 12:49:13.41

そういえば言語も決まってなかったな
常人は言語を決めないとプログラムを書けないってマジ？

**デフォルトの名無しさん** · 2019/03/24(日) 15:26:29.39

>>275
Windowsでは、昔のrubyみたいな状況なので、
それ以外のプラットフォームでやるのがいいよー

**273** · 2019/03/24(日) 16:35:05.61

よく判らないアドバイスだったな…
勉強・研究しないで突っ込むのはそっちの方が賭けてる感あるし、
すぐに書き終えるなら確かにそういう難しさはないが、
ソフトウェアのプロジェクトって面白いものは大抵長くなると思う。

>>277
Windows環境はWSLではダメなん？

**デフォルトの名無しさん** · 2019/03/25(月) 18:54:20.99

>>261
感情表現と言うように感情はあくまでイメージ想起性のもので
文法を持ってないものだと思う。
感情をそのまま言語化なんて人間でもしてないだろ。
あくまで論理的内容の会話文章の表現に感情を想起させる表現を
選んで論理としては同じだけれど得られるイメージが異なる文を
作っているだけだと思う。
そこで文を構成するために選ぶ表現がやたら極端なときに、感情的と評されているだけで。

ていうかおじさんになったしもう無理

**デフォルトの名無しさん** · 2019/03/25(月) 20:49:31.29

>>279
得られるイメージが変わってしまうのはコンピュータの制約のせいだよ
fibのイメージをそのまま表現できたら感動するのになあ

この状況ではコンピュータの制約は変えたいがイメージは変えたくない
「論理としては同じだけれど得られるイメージが異なる」という想定は大外れ

**デフォルトの名無しさん** · 2019/03/25(月) 21:05:17.06

イメージw
お前らあほだろ

**デフォルトの名無しさん** · 2019/03/25(月) 21:17:58.51

コンピュータの制約が悪夢のようだから消去法でイメージ
あほなことしてるだろ
俺達なんだぜこれ

**デフォルトの名無しさん** · 2019/03/25(月) 21:19:23.78

イメージないと妥当性の判断もできんぞ。
これだって
書き込み内容を読んで
内容から推測される人物像をいままでの記憶から割り出して
そういう人物に対してかつてもった心象(イメージ)を
この場合の想定(先入観)として設定して
否定的判断をするという内容を伝達しているだろ

大体こういうプロセスじゃね？

**デフォルトの名無しさん** · 2019/03/25(月) 21:58:18.36

数学の世界で効率を全く重視してないわけじゃないからな。無限の速度のCPU上なら同じと見なせるってだけで。

末尾再帰のfibとか数学的だからアーキテクチャ関係なく元の定義より速い。
行列苦手だから書けないが、もっと速い行列バージョンも存在する。

**デフォルトの名無しさん** · 2019/03/25(月) 22:00:17.95

これなんか深かった。結局愚直なコードのままで良かったみたいな
https://haskell-jp.slack.com/archives/C5666B6BB/p1551956556140300

**デフォルトの名無しさん** · 2019/03/25(月) 22:05:21.04

あとこれ。今はコンパイラが賢くなったのでfoldlが遅くなくなったよって話
https://qiita.com/autotaker1984/items/09c5ceaa13e9077f5359

**デフォルトの名無しさん** · 2019/03/25(月) 22:10:40.54

これはPrologについて書かれているが、ここで話題にしてるのはこの記事と同じ議論だろう？

宣言型プログラミングの可能性と限界
https://thinkit.co.jp/article/157/3

**デフォルトの名無しさん** · 2019/03/25(月) 22:23:26.20

全く読んでないがパラダイムと論理は同じではない
パラダイムの限界と論理の限界は同じではない

◆QZaw55cn4c · 2019/03/25(月) 22:53:06.90

>>284
＞末尾再帰のfib
fib が末尾再帰でかけますか？

**デフォルトの名無しさん** · 2019/03/25(月) 23:23:28.81

>>289

つ >>270

**デフォルトの名無しさん** · 2019/03/25(月) 23:29:06.55

sum x:xs = x + sum(xs)
は数学っぽく見えるけどアキュムレータ噛ますと途端にループに見える不思議

**デフォルトの名無しさん** · 2019/03/26(火) 02:32:22.40

アキュムレータは余再帰っぽく見える
数学っぽいの反対は余再帰っぽい説

**デフォルトの名無しさん** · 2019/03/26(火) 19:05:26.53

Haskell知らんでも無意識に >>270 みたいな式を思い描いて
for文とかに落とし込んでる感じじゃね？
n回繰り返すのが昇順か降順かの違いだけで。

Python

def fib(n):
temp = 0
a = 0
b = 1
for i in range(n):
temp = a
a = b
b = b + temp
return a

for i in range(10 + 1):
print(fib(i))

Haskell

main = mapM_ (print.fib) [0..10]

fib n = fib' n 0 1
where
fib' 0 a _ = a
fib' n a b = fib' (n - 1) b (b + a)

**デフォルトの名無しさん** · 2019/03/26(火) 19:25:31.93

誰でも頭が良くなる、プログラムが書けるようになる方法が発見される 42162
https://you-can-program.hatenablog.jp

**デフォルトの名無しさん** · 2019/03/31(日) 07:28:40.29

プログラマーのための圏論と言うPDFで公開されてるのが分かりやすい。（上・中・下の三冊)
http://bitterharvest.hatenablog.com/entry/2016/11/24/203021

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

自然数が射(関数)になっていると言う感覚が分かった気がする。

Haskellで書けないけど、書けるとするなら

1 = 1

1という名前の1を返す引数無しの関数。

**デフォルトの名無しさん** · 2019/04/04(木) 13:43:46.44

記号的な1を1と書き、概念的な1をチャーチ数で表現するなら

1 = succ zero

**デフォルトの名無しさん** · 2019/04/04(木) 21:34:52.78

トートロジーではないのかね？

**デフォルトの名無しさん** · 2019/04/05(金) 00:53:58.06

トートロジーとかチンプンカンプンな高卒なんで。。。
補足説明や訂正があったら勉強になります(￣^￣)ゞ

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

ラムダ的な自然数は高階関数を使うけど、圏論は冪を使わないことが多い

**デフォルトの名無しさん** · 2019/04/05(金) 08:37:08.96

Haskell でもsuccって関数ありましたね。。。
私が

1 = succ zeroで表現したかったのは、どんな数体系でも1と表現される何かという意味での1です。

例えば16進数の10はAと表現されますのですが、

A = 10

とすると10が16進数では10進数の16になるので10進数でも16進数でも10として扱われる概念としてチャーチ数にしたかったのですが、
チャーチ数も含めた全ての数体系で10として扱われる何かを表現したいみたいな。

うーん。。。表現力が乏しくてすみません。

**デフォルトの名無しさん** · 2019/04/05(金) 18:59:26.73

本当の所は
Int $ succ Zero
というような頭部正規形で表される関数のシンタックスシュガーだと思う

**デフォルトの名無しさん** · 2019/04/05(金) 21:40:52.25

HNFは射ではない
そもそも圏論にHNFはない

**デフォルトの名無しさん** · 2019/04/06(土) 02:09:18.76

・チャーチ数はペアノシステムの1つの実装である
・任意のペアノシステムは(適当な公理のもとで)互いに同型である
みたいな話？

**デフォルトの名無しさん** · 2019/04/06(土) 03:06:25.41

>>303
> HNFは射ではない
> そもそも圏論にHNFはない

こういう表現は間違い
何が射かであり何が圏でないかは、どんな圏を考えているかに依存する

例えばだが、単純な型付λ計算（型の集まりが直積型の構成と関数型の構成について閉じている）に対応する圏、つまり単純な型とそれで型付けされるλ項の成す圏を考えることができる
そこでは、対象は個々の型で、射はλ項だ
そして個々のλ項は、そのλ項の中に現れる自由変数の各々の型の積対象からλ項全体への型という対象への射と考えるというものだ
この場合、λ抽象があるので冪対象が必要になり、従って、この単純な型付λ計算に対応する圏は必然的に積閉包圏というタイプの圏になる
これはいわゆる“categorical type theory”（圏論的型理論）の最も簡単な具体例だ

この圏の場合は単純な型付けに関してwell-typedなλ項は全て射として認められるのでもちろんhead normal formになっているλ項もwell-typedである限りは射だ

**デフォルトの名無しさん** · 2019/04/07(日) 09:14:23.15

Haskellの開発環境で、ブレークポイント張って評価中の変数の値を見る、みたいなのって出来ますかね？
Visual Studioのローカルウィンドウ的なの。
普段はSpacemacs使っててREPLで評価しては進め、評価しては進め、みたいな感じでやってます。

**デフォルトの名無しさん** · 2019/04/18(木) 13:41:44.67

並行並列言語Haskellの基本と特徴
https://logmi.jp/tech/articles/321095

2018年11月10日、Haskell-jpが主催するイベント「Haskell Day 2018」が開催されました。
純粋関数型プログラミング言語Haskellをテーマに、Haskellに興味のある人から入門者、
ちょっとできる人まで、様々な層に向けたプレゼンテーションを行った本イベント。実務
から研究まで、幅広いHaskellの事例を共有します。プレゼンテーション「並列並行言語
Haskell 」に登壇したのは、syocy氏。講演資料はこちら (↓)(後略)

https://speakerdeck.com/syocy/bing-lie-bing-xing-yan-yu-haskell
https://speakerd.s3.amazonaws.com/presentations/07d92af9d7aa40bca6cc3959d3f56b28/parallel-and-concurrent.pdf

**デフォルトの名無しさん** · 2019/04/18(木) 23:50:53.53

オライリー本の要約だけ？みたいな

**デフォルトの名無しさん** · 2019/04/25(木) 08:46:13.49

cabalのnew-から始まるnixスタイルコマンドが出来たからtackつかう意味あまりないですよね

**デフォルトの名無しさん** · 2019/04/25(木) 09:33:12.75

>>309
v2-build だっけ？よく知らないが stack いらなくなるやつなんだ？

**デフォルトの名無しさん** · 2019/04/25(木) 23:59:42.81

stackageが変わるんですねぇ。stack2も間もなくとか。
https://www.fpcomplete.com/blog/2019/04/stackage-changes-and-stack-2

**デフォルトの名無しさん** · 2019/04/29(月) 10:21:15.20

stack or cabal どっちを使えばいいんだ

**デフォルトの名無しさん** · 2019/04/30(火) 07:55:22.06

stack!

**デフォルトの名無しさん** · 2019/04/30(火) 15:29:26.12

>>312
迷う理由がわからない
現時点で好きな方を使えばいいのでは？

どっちを使っても、後で後悔することなんてないと思うが

**デフォルトの名無しさん** · 2019/04/30(火) 18:00:12.30

>>314
もはや同等とみていいの？
一長一短がイマイチ見えないので比較できない。

**デフォルトの名無しさん** · 2019/04/30(火) 18:03:11.15

入門者に紹介するときはどうすれば？

**デフォルトの名無しさん** · 2019/05/01(水) 13:06:07.04

>>315
自分で情報を得られず、比較できなくて選べないくらいなら、
一長一短なんか考えずに、今好きな方や気になる方を使えば良いんだよ。

stackを長い間使ってきたから今後も使い続ける、でもいいし、
新しいcabalに興味が沸いたからcabal使ってみる、でもいい。

例えばパーサーライブラリ、Webライブラリ、FRPライブラリなどは色々あるけど、
いちいち「一長一短を比較した上で」選ぶ人はそんなに多くないでしょう。
みんな取りあえず何か一つ使ってみて、他に興味が湧いたら浮気してみて、
それからでしょ、比較するのは。

**デフォルトの名無しさん** · 2019/05/01(水) 13:20:11.30

>>316
両方の一長一短をちゃんと比較して紹介するのは、
記事や本を書くプロや、意欲のある人に任せればいいと思う。

紹介のプロじゃないのなら、自分が好きな方を精一杯アピールすればいい。

それもできずに、初心者にどちらを紹介しようか悩むのなら、順番が違う。

どちらか一方でもアピールできるくらい使い込むのが何よりも先でしょ。

**デフォルトの名無しさん** · 2019/05/01(水) 13:42:48.29

まぁこの手の選択にある程度以上責任持って助言するのは難しいんだよな。
少なくとも両方使ってないとどっちがいいとか言えないし。
ほとんどの人が最初に使った方をそのまま使い続けるもんじゃね。
私もcabalしかつかったことないし。

**デフォルトの名無しさん** · 2019/05/01(水) 14:03:02.54

「みんなの見解を聞く」も自分で情報を得る過程のひとつだと思ってるんだが

記名ネットではしにくい無責任方言もここなら言えるでしょ

**デフォルトの名無しさん** · 2019/05/01(水) 14:23:04.11

まだキチンと検討していないが、自作したツールをbrewとかで公開するとき、ビルドツールを依存に含める必要が出てくると思う。予めどっちかを使うかは決めておきたい。
バージョンを重ねるなかでフラフラ変えるのは避けたい。

あとcabalだとコンパイラを替えるときはghcupなる別ツールを使うの？これだとクロスコンパイラはどうなる。
複数のアーキテクチャのための成果物をビルドするとき、ghcup set ... && cabal build && ghcup set ... && cabal build ... みたいにいちいち指定しないといけないのかしら。
コレを解決するにはghcupにパッチを当てるかcabalを改造するか、スクリプトを書くかするわけだ。その点 stack build はコマンド一発なのに。

俺は年間50時間くらいstackのパッチや関連ツールを書いてきた。このままで行けるならいいが、stack がいずれオワコンになるなら早めに見切りつけて時間節約したい。
新元号が30年続くなら令和中に1500時間も浪費することになるんだぜ。

**デフォルトの名無しさん** · 2019/05/01(水) 14:53:10.97

>>320
> 記名ネットではしにくい無責任方言もここなら言えるでしょ

そんなレスは情報ではないのでは？
ただのノイズでしょ（ノイズの全てがゴミとは言わないが）。
本当に情報を得たいのなら、時間の無駄だよ。

もし、そんなのを参考にどっちか決められるのなら、
初めからルーレットで決めるのと大して変わらないのでは？

「自分で情報を得る」の第一歩は、ビルドツールで一番何がしたいかを決めて、
それが出来るか、やりやすいかを「公式ドキュメント」を見て調べる事だよ。

stackとcabalの公式ドキュメントを見て比較して、
それでも分からない部分をピンポイントでSNSや掲示板などで質問する、
それが二歩目だと思う。

**デフォルトの名無しさん** · 2019/05/01(水) 16:46:41.64

伸びてると思ったら。。。
今の所stackかな。
cabalは依存関係で過去に評判悪かったから、新しいのの評判が固まったらかな。

**デフォルトの名無しさん** · 2019/05/02(木) 10:15:34.23

>>322
調査を並行してやっちゃいけない理由はないでしょ。聞くだけならタダやし。
スレ民の意見をノイズだなんて思ったことないよ。自分にない視点や個人的使用感、気づきにくい落とし穴を教えてもらえるかも。

俺の雑感はstackは不備だけでなくバグも多かった気がする。.stack-workを消したらビルドが直ったみたいなことが何回かあったと思う。

stackのメリットは、
(ghcupの方針が変わらないなら)コンパイラの導入まで自動でやってくれるので、例えばHaskellスクリプトを書いてシェバンにstack、
以降に依存ライブラリを書いておけばいつでもどこでも動く(HackageとStackageが活きてるかぎり)、必要なものを都度自動で用意してくれる。

stackのデメリットは、
設定ファイルが多すぎる。プロジェクトレベルでは stack.yaml, package.yaml, Hoobar.cabal
と、どれに何を書くかが判りづらい、いちいち引っかかる。

**デフォルトの名無しさん** · 2019/05/02(木) 12:34:35.03

>>324
無責任放言がノイズなんだよ。

で、その全てがゴミとは言わないとも言ってる。

**デフォルトの名無しさん** · 2019/05/02(木) 13:13:18.93

>>325 前半は反論したし、後半は批判してないですよ。

**デフォルトの名無しさん** · 2019/05/03(金) 01:40:50.69

凄いH本の中国語版見る機会があって、
漢字の用法がカタカナ語より
しっくりすると思ったんですけどどうでしょうか。

模式：　　パターン
門衛：　　ガード
類型類：　型クラス

さすがにモナドは漢字翻訳難しいみたいですが。

**デフォルトの名無しさん** · 2019/05/03(金) 06:21:38.43

その程度のカタカナがしっくり来なかった人生を反省するんだ

**デフォルトの名無しさん** · 2019/05/03(金) 09:01:46.98

慣れとしっくりくるのは別物だけどな
無意味刺激と有意味刺激、表音文字と表意文字に対する認知は先天性の個人差があるんだからあまり他人の人生なんて分かりもしないものに言及するべきではない

どちらにせよ今の中国は学術用語を積極的に訳する文化ではあるよね
Haskellに限らずclassや他の用語もそれに類した漢字が用いられてそう
ただこれも漢字の意味が時代によって変化してくると正しい用語認識を阻害しうるのは現代日本でいくらか見られているし、一長一短と個人差だね

**デフォルトの名無しさん** · 2019/05/03(金) 10:47:01.08

かつてアルゴリズムを算法とかコンパイルを翻訳とか
一部で言っていましたね。

モナドアクションを算法と訳すならモナドは法かぁ
などと連想してみました。

**デフォルトの名無しさん** · 2019/05/03(金) 11:01:45.26

漢字に訳する場合どっか権威のあるところが決める必要があるよね
そういうところがめんどくさい

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

大陸だと結構あちこちで勝手に翻訳されたり
輸入されていずれ収斂されていくっていう
感じだった。

日本でも官公庁の訳語が定着しないことも
多いよね。

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

流れも読まずminからmaxまでのランダムな数のリスト(要素数n)を得る関数作って見た。

takerand _ _ xs 0 = return xs
takerand mn mx xs n = do
x <- randomRIO (mn, mx)
takerand mn mx (x:xs) (n - 1)

使い方は

rs <- takerand 1 6 [] 10

これで1ー6までのランダムな数が10個入ったリストが手に入る。

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

流れも読まずminからmaxまでのランダムな数のリスト(要素数n)を得る関数作って見た。

takerand _ _ xs 0 = return xs
takerand mn mx xs n = do
x <- randomRIO (mn, mx)
takerand mn mx (x:xs) (n - 1)

使い方は

rs <- takerand 1 6 [] 10

これで1ー6までのランダムな数が10個入ったリストが手に入る。

**デフォルトの名無しさん** · 2019/05/03(金) 14:37:49.43

>>334
それなら、getStdGen と randomRs と take でいいのでは？

takerand mn mx n = getStdGen >>= return . take n . randomRs (mn, mx)
あるいは
takerand mn mx n = take n . randomRs (mn, mx) <$> getStdGen

**デフォルトの名無しさん** · 2019/05/03(金) 14:52:14.89

>>335
いいのでは、と言うのは失礼な言い方だった。

こういう方法もあるよ、と言うことで。

**デフォルトの名無しさん** · 2019/05/04(土) 06:36:55.99

>>335
そう言うのがあったのね。。。
thanks.

**デフォルトの名無しさん** · 2019/05/04(土) 09:34:13.31

Arrowised FRP を矢矧のFRP とかいうのは好き

**デフォルトの名無しさん** · 2019/05/04(土) 09:36:30.32

型クラスの訳語類型類は、kindの類とごっちゃになるな、と思ったけど、
kindは種が主流なのか

**デフォルトの名無しさん** · 2019/05/04(土) 17:11:10.97

>>339
主流というか、それ以外に聞いたことがない

**デフォルトの名無しさん** · 2019/05/04(土) 18:12:27.03

>>340
初期の訳語では類だったかも?
https://www.sampou.org/haskell/tutorial-j/classes.html

**デフォルトの名無しさん** · 2019/05/06(月) 16:30:54.25

すみませんHaskellでアート芸術方面のプログラミングをしたい場合
既存の表示用ライブラリは導入からして難しそうな印象があるので
表示はProcessingに任せるという方法を考えていますが、

http://hackage.haskell.org/package/processing-for-haskell

もしそういう方面に詳しい人がいましたら
それについての助言を頂きたいです。

**デフォルトの名無しさん** · 2019/05/06(月) 16:46:03.96

>>342
なにを助言してほしいのか具体的に明確に言ってくれ。

**デフォルトの名無しさん** · 2019/05/06(月) 21:07:46.31

>>343
説明が不十分ですみません。
アート芸術のプログラミングを行う場合
表示は既存ライブラリは使わずに

Haskell-Processing連携ライブラリを使って
データ処理と表示を切り分けた方が
簡単なのではないだろうかという質問でした。

https://github.com/anton-k/processing-for-haskell/blob/master/tutorial/QuickStartForProcessingers.md

表示はProcessingで行います。

**デフォルトの名無しさん** · 2019/05/06(月) 23:14:35.12

>>344
データ処理と表示処理を切り分けた方が開発が楽になるのはその通り。

でも、グラフィックスライブラリに何を使うかと、
楽に切り分けできるかどうかは、一般には関係ない。
特に haskell のグラフィックスライブラリはたいてい EDSL 形式になっているから、
どれを使おうが、切り分けの楽さは大して変わらない。

後はもうライブラリの表現力が求めるレベルにあるかどうかと、
個人の経験や慣れ、趣味の問題だ。
Processing に慣れているなら processing-for-haskell でいいだろう。
個人的には gross が好き。

ところで、既存のライブラリって何だ？
processing-for-haskell は 2016 年でアップデートが止まってるが、
これは既存ではないの？

**sage** · 2019/05/06(月) 23:44:49.55

>>345
ありがとうございます。理解しました。

参考にしたのが School of Expression だったので
情報が古くprocessing-for-haskellが
最新の物と思えて勘違いしてました。

**デフォルトの名無しさん** · 2019/05/07(火) 14:46:19.40

diagrams を使ってた。

**デフォルトの名無しさん** · 2019/05/08(水) 18:25:39.72

>>344
そういうことをしたいならProcessingだけでやった方が手間かからない
Haskellで書けば楽になるとかそんなことは一切ないので

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

>>348
「haskellで」アート芸術方面のプログラミングをするには、という質問だと思う。

ジェネラティブアートなんか haskell にもってこいじゃないかな。
もちろん、Processing の得意分野でもあるんだが、
宣言的に書ける haskell もけっこうマッチするのでは？
全て型プログラミングで生成とかもできそう。

**デフォルトの名無しさん** · 2019/05/12(日) 15:06:12.68

f xs = let g = \x -> 2 * x in map g xs

この場合、ラムダは最初に一回メモリにアロケートされて g に束縛されるよね。

でも、もしかして、

f xs = map (\x -> 2 * x) xs

これって、f が呼ばれる度に map の第一引数のコード(ラムダ)がメモリにアロケートされるの？

**デフォルトの名無しさん** · 2019/05/12(日) 21:06:22.80

クロージャにしなくてもいいラムダはただの関数として扱われるんじゃない？
というか上のコードならセーフっていうのはgを使いまわしてくれるから？
そんな気の利いた処理系なら下のラムダも使いまわしてくれそうだけど

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

その辺り、実際にどんな実行コードが生成されるかに関しては、
コンパイラ(GHC)に聞いてくれ、としか言いようがない
インライン展開とかクロージャ変換といったコンパイラ技法を学ぶことを勧める
関数型言語だからTiger本とか

**デフォルトの名無しさん** · 2019/05/13(月) 01:00:48.68

ラムダは何も簡約しなくても最初からWHNFじゃないのか
最初からWHNFならサンクとか不要だから普通の言語と同じでいい

**デフォルトの名無しさん** · 2019/05/13(月) 23:41:36.79

>>350
ラムダ式が動的に生成されるものと思っているのなら間違い
この場合は単なる関数として展開されている

**デフォルトの名無しさん** · 2019/05/14(火) 19:41:06.85

なるほど、納得できた。
これからは安心して引数にラムダを直接書ける。
ありがとう。

**デフォルトの名無しさん** · 2019/05/23(木) 06:24:49.40

mtl によるモナド合成はモナド則を保存しない

マジかよ失望しました。mtl は窓から投げ捨てます

**デフォルトの名無しさん** · 2019/05/23(木) 17:37:28.82

動的型付けに比べて静的型付けの方が優れている、は常に真？

実はHaskellで動的プログラミングをやる話を読んで、
あれっコレ意外といいじゃんと思ってしまったんだ。

**デフォルトの名無しさん** · 2019/05/23(木) 18:42:06.90

次にお前らは『優れているを定義してくれ』と言うｯ！

**デフォルトの名無しさん** · 2019/05/24(金) 01:05:05.82

任意の言語に丸投げするシェルスクリプトはズル
文字列をevalするやつもズル
ズルをする必要がない言語は優れている
どうせこんな感じだろうと思ってる

**デフォルトの名無しさん** · 2019/05/24(金) 04:51:31.33

いくつかの基準が思いつく。
速い・短い・アシストが手厚い・理解しやすい・バグが混入しにくい…

>>359
「ズル」には悪い、の意味が予め含まれていると思うので納得できない。
evalを用いた場合に比べて静的型の解決の方が優れているのを示す必要があるでしょう。

**デフォルトの名無しさん** · 2019/05/24(金) 08:28:17.80

格闘技ですら、反則には反則負けという意味が含まれている

**デフォルトの名無しさん** · 2019/05/24(金) 09:32:47.08

含まれてないと思うし、Haskellに関係ない。

**デフォルトの名無しさん** · 2019/05/24(金) 11:18:44.54

sequence_の使い所が分からん。。。
mapM_使った方が短くなるし。

うーむ。。。
渡すリストにIOな関数含められる=IOな関数を使う
リスト内包表記も使えるのは良いけど、mapM_のが簡潔。

import Data.List
import System

main = mapM_ put $ zip hellos marks
-- sequence_ [put (x,y) | (x,y) <- zip hellos marks]

hellos = (cycle.tails) "Hello World!!"

marks = cycle ["/","|","\\","--"]

put (x,y) = do putStrLn (x ++ "\n" ++ y)
mapM_ (\_ -> putStr "") [1..50000]
system "clear"

**デフォルトの名無しさん** · 2019/05/24(金) 11:19:15.22

hellos = (cycle.tails) "Hello World!!"

marks = cycle ["/","|","\\","--"]

put (x,y) = do putStrLn (x ++ "\n" ++ y)
mapM_ (\_ -> putStr "") [1..50000]
system "clear"

**デフォルトの名無しさん** · 2019/05/24(金) 14:25:55.92

>>363
モナディックアクションを構造に入れて使うとき重宝するよ。
main = sequence_ . (map (putStr "log:" >>)) $ [print "hoo",putStr "bar"]
個々のアクションを好きに調整できる(例ではそれぞれに前処理を足した)。

**デフォルトの名無しさん** · 2019/05/24(金) 18:49:41.11

>>365
ありがとう。
いつか役立てたいものです。

**デフォルトの名無しさん** · 2019/05/24(金) 18:55:43.73

別件なのですが、俺俺Eq型クラス(MyEq)を作って見ているのですが、
HugsだとNum a型のインスタンスを作れるのに、GHCだとエラーが出ます。

経験ある方、いらっしゃいますでしょうか？

main = do print $ 1 === 1
print $ 1 /== 1
print $ 1 === 2
print $ 1 /== 2

class MyEq a where
(===),(/==) :: a -> a -> Bool

x === y = not (x /== y)
x /== y = not (x === y)

instance (Num a) => MyEq a where
x === x' = isZero (x - x')
x /== x' = not (x === x')

isZero 0 = True
isZero _ = False

GHCだと全ての型をインスタンスにしろ的なエラーメッセージが出ます。。。
スマートな方法があれば。。。

**デフォルトの名無しさん** · 2019/05/24(金) 20:57:13.04

>>363
mapじゃなくunfoldrで[IO a]を作ってもいい

>>367
エラーは「インスタンスにする型はこれこれこういう形にしろ」って意味
instance (Num a) => MyEq a みたいな形を許すと
instance (MyEq a) => Num a とかもできて意味わからなくなるから
{-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
というおまじないを使って制約を取っ払う

**デフォルトの名無しさん** · 2019/05/25(土) 02:52:58.92

>>357
オブジェクトファースト動的解決脳だとHaskellはただめんどくさいだけの言語にしか見えない
利点とされていることが欠点にしか見えないもある