【アンチ】関数型言語は使えない【玩具】２

**デフォルトの名無しさん** · 2012/02/28(火) 20:45:47.95

前スレ
http://toro.2ch.net/test/read.cgi/tech/1320743217/

**デフォルトの名無しさん** · 2012/03/01(木) 10:16:55.81

2chで”流れ”を感じ始めたら、少なくとも二重の意味でヤバイな。

**デフォルトの名無しさん** · 2012/03/01(木) 11:00:27.41

>>51
関数型が得意なベンチマークでなきゃヤダヤダ

ってこと。

**デフォルトの名無しさん** · 2012/03/01(木) 12:27:42.50

Rは関数型に入りますか？

**デフォルトの名無しさん** · 2012/03/01(木) 12:38:56.07

C言語プリプロセッサは関数型に入りますか？

**デフォルトの名無しさん** · 2012/03/01(木) 16:28:17.22

バナナの皮は関数型言語に入りますか？
λ
形が似てるんですが

**デフォルトの名無しさん** · 2012/03/01(木) 16:39:32.31

お前、先生が許可したら人も殺すのか
関数型言語を殺すつもりか！

**デフォルトの名無しさん** · 2012/03/01(木) 19:44:58.10

haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
（一部のみ、先行評価より速い）

そもそも、reverseが単方向リストに不利なわけだが・・・
とりあえず、main/print（ＩＯモナド使った関数）以外の関数を自作してみた

http://ideone.com/15yhM

自分がHaskellに惚れたのは、IO関連以外は言葉遊びみたいな感じで自作出来るのが楽しいから
(rangeはもうちょっと作りこめたかも・・・）
速さよりも、その構造を調べるのが楽しい

data Natural = Zero | Succ (Natural) deraiving (Eq,Ord,Show,Read)

自然数の定義と、リストの定義が似ているのが分かる。
自然数は、その長さそのものが数字としての意味を持ち、リストは長さにも長さと言う意味はあるが、自然数との決定的な違いは、要素自体も値を持っているか？だけだと言うのが分かる

遅延評価生かしたプログラムなら、ファイル処理とかだろうけど、ideoneでファイルの読み込ませ方知らん（と言うか、在るのか？）
ので、一応、こんなのも作ってみた（1から1000000までの足し算の合計のリストを作って、先頭の１０要素を表示）

http://ideone.com/insk7

簡約の様子を見てみると関数同士が絡み合って、一番外側の関数の終了条件のみで、他の関数の終了条件を満たして無くても、関数が終わるのが自然と理解できる

もちろん、最初から無駄の無い処理を書かれると負ける。foldllやmapみたいな、状態を次の再帰に引き摺らない様に書けば、スタック消費が抑えられるって言うだけで、Haskell自体の最適化は弱い

**デフォルトの名無しさん** · 2012/03/01(木) 22:13:10.07

不覚にも>>60-61の流れに

**デフォルトの名無しさん** · 2012/03/01(木) 22:56:48.12

なんで、list reverseだけでここまで引っ張ってるんだ!?
>>11を受けて関数型言語/命令型言語の適材適所の話題になると期待したのだが。

**デフォルトの名無しさん** · 2012/03/01(木) 23:19:04.92

>>64
まあここは隔離スレだし、目的が互いに異なる言語同士を単純作業で比較したがる人が集まる場所でもある。
鳥と魚を比較するのに、共通項目だからといって体重や肺活量で比較するようなもんで、最重要と言えるほどの意味は無いと思うが。

比較するなら、計算モデルからのアプローチ（CTMCPなど）も有るので、該当スレが宜しいかと。

**デフォルトの名無しさん** · 2012/03/02(金) 10:52:02.59

本スレで煽り質問しかできないバカは回線切って吊れ

**デフォルトの名無しさん** · 2012/03/02(金) 11:57:42.38

>>62
>haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
>（一部のみ、先行評価より速い）

評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ？
遅延評価を使ったプログラムの総時間と混同してないか？

**デフォルトの名無しさん** · 2012/03/02(金) 11:58:15.19

>>67
X 尊えば
O 例えば

**デフォルトの名無しさん** · 2012/03/02(金) 13:03:35.88

>>67
>評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ？

遅延評価とか先行評価とかいうのは評価『戦略』であって、『評価するかどうか』を決めるだけだ。
実際に『評価する際』には評価戦略の段階は通り過ぎてるからその問は無意味だろう。

そして遅延評価は評価するまでに猶予を置く意味合いしか無いから、
無駄な計算をしないという仮定のもとでは、遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
>>62のいう『一部』というのはたらい回し関数みたいなもののことを言ってるんだろうが、
あれはグラフ簡約がたまたまメモ化の役割を果たし無駄が省けているためであって遅延評価だからではない。

そもそも速度で評価戦略を語ることがナンセンスだよ。
あれは（たらい回しみたいな）一部の計算を無駄なく書くのを簡単にするためのものだ。
無駄なく書くのが難しくなってる計算の方が多くね、ってのが遅延評価に対して意味のある批判だろうよ。

**デフォルトの名無しさん** · 2012/03/02(金) 13:11:35.99

>>69
>そもそも速度で評価戦略を語ることがナンセンスだよ。

別にそんな話はしてなくて、「先行評価より早いものがある」について具体例が知りたいだけ。
だから、総時間と混同してないか？って書いたんだがなあ。
どっかでの、Haskell=遅いって話のことなら俺は無関係。

**デフォルトの名無しさん** · 2012/03/02(金) 13:15:22.81

だからさ、評価戦略によって『評価するかどうか』が決まってからは遅延評価も先行評価も同じ道を辿るんだから、
評価戦略に対して「aはbより早い」とかいうのは論理的に間違ってるってこと。

**デフォルトの名無しさん** · 2012/03/02(金) 13:20:50.03

>そもそも速度で評価戦略を語ることがナンセンスだよ。
これはhaskellerの負け惜しみとかそう言うんじゃなくてさ、
速度と評価戦略が別次元の問題だってことを言いたいだけ。
haskellのたらい回しとcのたらい回しは記述が似てても、
『そもそもやってることが違う』んだから。

**デフォルトの名無しさん** · 2012/03/02(金) 13:37:52.45

遅延評価は計算量を減らす目的もあるけどそれが全てじゃないよね
それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし

割と手軽に計算量を減らせる(処理系にお任せ出来る)ってくらいだろう

無限リストとかを評価しちゃうと氏ぬのは言語に関係無いから
その辺はCでも配列でなく関数とかで仮想化するし

**デフォルトの名無しさん** · 2012/03/02(金) 13:45:42.93

＞それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
いや、まったく同じ計算をするなら同じ処理時間になるよ。
ならないとしてもそれは遅延評価のせいではない。

**デフォルトの名無しさん** · 2012/03/02(金) 13:47:20.92

＞遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
よくみると俺もこんな発言をしていた。
俺も論理的に間違っているということだな（ｷﾘｯ

**デフォルトの名無しさん** · 2012/03/02(金) 13:51:12.30

>>64
ネタの投下も無しに贅沢な
それに、>>62はプリミティブな関数が自作出来るのが楽しいって言ってるだろ
python版出すなり、新しいネタ出すなりすれば良い

**デフォルトの名無しさん** · 2012/03/02(金) 13:54:12.03

＞それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
というか『適うわけない』と思った根拠はなんなのだ？
論理的に同じ計算をするならあとはなんというか、言語の基礎体力だけの問題になるはずだが。
あれか、haskellではIntがボックス化されているからとかなんかそういうのか。

**デフォルトの名無しさん** · 2012/03/02(金) 13:56:34.33

>>74
＞まったく同じ計算をするなら同じ処理時間になる
同じロジック書いても
遅延評価を実装するために発生するオーバーヘッドとかの影響で
まったく同じ計算(機械語レベルで)にはならないんじゃないの？

**デフォルトの名無しさん** · 2012/03/02(金) 14:03:36.00

>>77
＞言語の基礎体力だけの問題
そうだよ、そういう話
例え同じロジックでもインタプリタ方式の方が遅いとかそういうの

Cは安全性を犠牲にしてでも速度優先するってコンセプトがあるわけだし

**デフォルトの名無しさん** · 2012/03/02(金) 14:11:15.32

>>-79までの中に、62が居るとのお告げがあった。

**デフォルトの名無しさん** · 2012/03/02(金) 14:18:12.44

>>78
遅延させることに意味がある場合、それはオーバーヘッドとは言わないんでは？
計算結果を明示的にキャッシュするのだってもちろんスペース喰うわけで。
そういうことじゃなくてGHCの実装の深いところに基づくオーバーヘッドだというなら、
俺にもよく分からないが、お前にはそれが有意な差であると合理的に説明できるのか？

**デフォルトの名無しさん** · 2012/03/02(金) 14:20:45.94

>>80
そのレスバグだろ
開始インデックスの指定漏れてんぞ

**デフォルトの名無しさん** · 2012/03/02(金) 14:35:31.40

>>81
意味有る無しに関わらずオーバーヘッドと言うよ
機械語レベルでの違いによるものなら大小に関わらず有意だよ

**デフォルトの名無しさん** · 2012/03/02(金) 14:38:40.45

>>83
呼ぶのか。なるほど。
それは明示的に計算結果をキャッシュするコストと比べてどうなの？

**デフォルトの名無しさん** · 2012/03/02(金) 14:39:21.82

このコストっては手間的な意味じゃなくてね

**デフォルトの名無しさん** · 2012/03/02(金) 14:41:06.81

あと機械語レベルで差が出るというソースは？
簡易なものなら是非見てみたい。

**デフォルトの名無しさん** · 2012/03/02(金) 14:44:46.65

無いと思うならそれでいいよ
haskellはcと同じ速度ってことでさ

**デフォルトの名無しさん** · 2012/03/02(金) 14:45:35.68

まあ説明できないことは最初から分かってたさ

**デフォルトの名無しさん** · 2012/03/02(金) 14:49:53.34

オーバーヘッドがあったとしても遅延評価には利点があるという話だったんだけど
ここまで速度に拘るとは思わなかったからね

**デフォルトの名無しさん** · 2012/03/02(金) 14:53:17.52

あるかどうかもよく分からないオーバーヘッドの話を持ち出したのはそちらではなくって？
まあね。実際俺もあるとおもうよ。オーバーヘッド。
話として持ち出すからには根拠を持っていてほしいなと思っただけさ。

**デフォルトの名無しさん** · 2012/03/02(金) 14:56:03.90

ちなみに俺がオーバーヘッドがあると思ったのは
単にゼロオーバーヘッドでの実装は無理だろうと思ったのと
「c言語 haskell 速度比較」とかでググッた結果を見たというだけ
流石に個々の速度比較の詳細までは知らない

逆にオーバーヘッドが無いってのを示してくれたらもちろん前言撤回するよ

**デフォルトの名無しさん** · 2012/03/02(金) 14:59:04.52

こんなスレにいる駄民がそんなことを示せるわけ無いじゃないか！俺のことだよ！

ていうかよくよく読み返すと>>78は疑問文だねえ。
俺が謝ったほうがいいのかも知れない。
だがわたしは(ry

**デフォルトの名無しさん** · 2012/03/02(金) 16:34:36.45

遅延評価って、一見全部読み込んでから一部だけ出力するって処理で、必要な分しか読み込まないってので、>>62の上のmyreverseはリストを反転する必要があるから、全部読み込んでるけど、下のaddlistをmytake 10 してる方は、最初の10要素分しか読み込まない
先行評価だと、全部読み込んでから始まるか、最初の10要素だけ読み込む様に書き分ける

ファイル処理とかで、書き分ける必要が無い事になる

とは言え、最近の言語なら、オブジェクトにその辺の処理を押し込んでそうだが

**デフォルトの名無しさん** · 2012/03/02(金) 16:37:16.86

オーバーヘッドつーか、評価機構の構造自体が違うのに、
全体の処理時間が同じなわけがないだろjk

**デフォルトの名無しさん** · 2012/03/02(金) 17:43:05.82

正格評価でもありとあらゆるところにdelayとforceを忍ばせれば
遅延評価になると思うんだけど
計算量が減るところだけ遅延評価にした方がやっぱりいいと思うんだよね

**デフォルトの名無しさん** · 2012/03/02(金) 20:31:03.15

>>93
そのかわり、ファイル読み込んで同じファイルに書き出すときとか
「あー、この辺で正格評価するべ」的なこと考えんといかんけどな

**デフォルトの名無しさん** · 2012/03/02(金) 23:50:52.90

配列のreverseくらいならC++でも一行だな
std::copy(in.rbegin(), in.rend(), std::back_inserter(out));

**デフォルトの名無しさん** · 2012/03/03(土) 00:36:28.38

最近の関数型って実装まで気にするような段階なんだな
はてなあたりの選民気取りが「haskellはCより速い(ｷﾘｯ」とか言い始めたら俺もそろそろ関数型始めようかな

**デフォルトの名無しさん** · 2012/03/03(土) 05:11:01.91

速度稼ぐ必要があるコードだと結局はモナド頼りなんだろ？

関数型言語って名前捨てて”モナド型言語”とでも呼べばいいんじゃね？

**デフォルトの名無しさん** · 2012/03/03(土) 06:46:14.07

おめえらhaskell以外の話もしろよ

**デフォルトの名無しさん** · 2012/03/03(土) 06:54:33.70

遅延評価のコストについては、コンパイラの本とかに載ってることあるよ

**デフォルトの名無しさん** · 2012/03/03(土) 07:59:28.26

>>98 大学の研究のレベルから、一般はてな民が話題にするまで10年ぐらいだから、
おまえは常に10年遅れだけど、好きにすればいいと思うよwwww

**デフォルトの名無しさん** · 2012/03/03(土) 08:12:49.54

xmonadの影響で今になってX11プログラミングを始めた漏れが
8時（10分以上遅れ）をお知らせしますね

**デフォルトの名無しさん** · 2012/03/03(土) 09:12:49.53

10年遅れどころかMLなら40年遅れHaskell直系のMirandaからでも30年遅れだろ

**デフォルトの名無しさん** · 2012/03/03(土) 10:58:06.61

作ればあるもん

**デフォルトの名無しさん** · 2012/03/03(土) 13:05:49.24

>>104
登場時期が基準とかおもちゃじゃあるまいし

**デフォルトの名無しさん** · 2012/03/03(土) 13:19:05.21

ギークやらアルファブロガーやら呼ばれる人が話題する時点ではまだ玩具

それを使用する企業やそれなりの規模のオープンソースプロジェクトが
出始めるくらいから実用品だな

**デフォルトの名無しさん** · 2012/03/03(土) 14:01:18.50

Javaと心中するのは自由ですから、他人を巻き込もうと必死にならないでねw

**デフォルトの名無しさん** · 2012/03/03(土) 14:10:19.50

定番の必死認定

**デフォルトの名無しさん** · 2012/03/03(土) 14:43:35.56

このスレでの関数型言語って純粋関数型言語(Haskell,Mirandaとか)だけ？
非純粋関数型言語(Lisp,R,OCamlとか)も含むの？

Haskellはよく知らないけどCommon Lispは実用かなって思って

**デフォルトの名無しさん** · 2012/03/03(土) 15:00:07.62

アンチの脳内の都合で、その場により変わりますw

**デフォルトの名無しさん** · 2012/03/03(土) 15:05:20.65

>>111
あなたの認識ではどっちですか？

**デフォルトの名無しさん** · 2012/03/03(土) 15:07:01.59

関数型言語に定義なんてないし的当だよ

一般的な定義は

・関数を実行時に生成できる
・関数を引数として渡せる
・関数を関数の戻り値として返せる

だと思うけど、最近は勝手に

・変数に一度しか代入できない

とかルールを付け加えたり好きかっていう人が増えたから

**デフォルトの名無しさん** · 2012/03/03(土) 15:14:52.67

昔は、関数型言語と比べて手続き型言語は原始的で貧弱に思えたけど、
最近は手続き型言語もクロージャを取り込んで関数的にも書けるから、
そうなると実用上は手続き型言語で十分だと感じるけどな。

基本は手続き的に処理を書きつつ、コレクションの操作だけ map や filter,
reduce を使って関数的に書く。他人にも読みやすいコードを書こうとすれば
最終的にはそのくらいのところに落ち着くと思うけど。

>>108 みたいな「仮想ドカタ」を煽るのは現実が見えていないと思うなあ。
今時、職業プログラマだって C, Java だけじゃなくて JavaScript も Ruby も使うよ。
JavaScript で言えば、JQuery なんて発想がかなり関数的だと思うけど。
XML を対象に XPath でパターンマッチかけて filter やら map やら。
ほとんどそういう処理。

**デフォルトの名無しさん** · 2012/03/03(土) 15:19:10.49

>>113
上の３つだとJavaScriptやC++(functor)、C#(delegate)あたりも含まれるな
初代スレの1はむしろ参照透過性、変数に一度しか代入できないことの方を嫌ってるように見える

**デフォルトの名無しさん** · 2012/03/03(土) 15:19:35.75

>>113
そうなんだよね。僕もそのくらいが「関数型言語」だと思うんだけど、
逆に、そのくらいはもう、手続き型言語にも取り込まれてるんだよね。

だから、そんなのはもう関数型言語「ならでは」の長所になってない。
逆に、末尾再帰除去とかカリー化とかになってくると、まだ差がある。

とはいえ >>114 くらいのスタイルだと、
別に末尾再帰除去やカリー化がなくても、そこまで困らないけどね。

**デフォルトの名無しさん** · 2012/03/03(土) 15:27:07.99

javascriptはschemeをC言語っぽい文法に直したものだろ
昔から関数型言語と言われているよ

**デフォルトの名無しさん** · 2012/03/03(土) 15:27:17.91

Haskellなどで言う「関数」は、集合・写像ベースの概念だから、変数の書き換えに依存しないやり方のほうが関数を率直に表現出来るってだけの話だ。
Cにも同じ字面の「関数」があるが、関数型言語の関数と区別したい時は、サブルーチンと呼んだ方が実態に近い。

**デフォルトの名無しさん** · 2012/03/03(土) 15:33:16.95

良い所とか取り込んで明確な境界が無くなくなってる面があるんですね

研究目的の言語の成果が実用目的の言語に適用されたと考えたら
必ずしも実用である必要は無いのかもしれませんね

**デフォルトの名無しさん** · 2012/03/03(土) 15:33:41.38

>>117
それは違うかな。
「言われている」ではなく、
関数型言語を知っている人たちが JavaScript は関数型言語っぽいと
「言っている」が正しい表現じゃないかな。

少なくとも、
Ecma-262 の 4 Overview には
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment.

と書いてあるんだから、何言語かと一つに決めるなら、
明らかにオブジェクト指向言語でしょ。

**デフォルトの名無しさん** · 2012/03/03(土) 15:40:05.10

>>119
「何ができるか」って意味なら差はどんどん無くなってる
だが、他人のコードを読むときには「何ができないか」ってのも重要で、
そこが手続き型言語と関数型言語では違う

わざわざコードを読んで副作用が無いか目でチェックしなくても
言語仕様で保証されてるなら読むのが楽になる
OOPのアクセス修飾子なんかと同じだな

**デフォルトの名無しさん** · 2012/03/03(土) 15:42:52.61

>>120
http://www.ecmascript.org/es4/spec/overview.pdf
ここの４ページにはこうある

ECMAScript 4th Edition (ES4) is a multi-paradigm programming language that is evolved from the
3rd Edition2 (ES3), which in turn is based on JavaScript3, a programming language for the web developed at
Netscape Communications Corporation starting in 1995.

ES3 is a simple, highly dynamic, object-based language that takes its major ideas from the languages Self
and Scheme.

**デフォルトの名無しさん** · 2012/03/03(土) 15:49:23.32

http://ja.wikipedia.org/wiki/ECMAScript

ECMAScript 4 は過去2回仕様作成が挑戦されたが、仕様がまとまらず、失敗に終わっている。

**デフォルトの名無しさん** · 2012/03/03(土) 17:26:19.51

何でも関数型言語にしたがる香具師がいるな…

**デフォルトの名無しさん** · 2012/03/03(土) 20:52:56.07

関数型言語の判断基準について、整理してみた。大きく３つのグループに分類できる。
・関数型言語(誰も文句無し)
・関数型プログラミングが可能な言語
・それ以外の手続き型言語

　FP
　　---- 壁0. 変数の壁 ----
　Haskell
　　---- 壁1. 純粋性(副作用)の壁 ----
　SML/OCaml
　　---- 壁2. 型推論の壁 ----
　Scheme
　　---- 壁3. 末尾再帰最適化の壁 ----
　========<< 越えられない壁 >>========
　Smalltalk/Ruby
　　---- 壁4. 条件判定式/局所宣言式の壁 ----
　Perl/Python/JavaScript
　　---- 壁5. クロージャ/ラムダ式の壁 ----
　========<< 越えられない壁 >>========
　C/C++/Java...etc

なお、このカキコは「関数型言語Part5」スレの過去カキコ(283-335)を編集したもの
議論の参考になればと思う

**デフォルトの名無しさん** · 2012/03/03(土) 21:14:44.32

末尾再帰最適化とか、マジ関係無いだろ
実装上の話だろ

**デフォルトの名無しさん** · 2012/03/03(土) 21:47:46.75

GCC(C/C++) → 末尾再帰最適化あり

あとC++のboost::lambda(ラムダ式)とはどうなんだろうか
言語自体に直接ラムダ式があるわけじゃないけど

boost::lambdaとスマートポインタでクロージャも作れるらしい

壁4はよく分からない

**125** · 2012/03/03(土) 22:07:55.69

>>126
関数型言語にとってリストが最も基本的な複合データ型であることは、
誰もが認めることだろう
でも末尾再帰最適化が実装されていない言語の多くでは、
可変長配列(RubyであればArrayクラス)でリストを代用している
もしも、これを真面目に「ドット対の連なり」としてリストを定義して
その操作を再帰関数で定義した場合、ちょっとしたデータ量であっても
簡単にスタックオーバーフローが発生してしまう

だから、関数型言語で書かれたコードを末尾再帰最適化が実装されていない言語へ
移植しようとした場合、再帰ではなくfor/while文のような手続き型構文を使わざるをえない
これは(末尾再帰最適化という)実装がプログラミングスタイルに大きな影響を与えるという
典型的な一例であると思う

**デフォルトの名無しさん** · 2012/03/03(土) 22:11:49.10

>>128
>関数型言語にとってリストが最も基本的な複合データ型であることは、
>誰もが認めることだろう

認めねーよ。
それも実装上の話だろ。

**デフォルトの名無しさん** · 2012/03/03(土) 22:12:39.97

>>128
でも、機械を上手く動かすためのコンパイラの技術だろ
関数型言語の定義に含めることには違和感がある

**デフォルトの名無しさん** · 2012/03/03(土) 22:41:56.15

リストは副作用を嫌う関数的プログラミングがLISPから借りてきた実装上の「逃げ」。
末尾再帰最適化でループの代用にしたのと根っこは同じ。

**デフォルトの名無しさん** · 2012/03/03(土) 22:56:45.86

ま、実用を目指したコンピュータ言語なんてものは
全てが実装上の話になってしまうんだけどな。

**デフォルトの名無しさん** · 2012/03/04(日) 01:14:03.00

末尾再帰なんてC言語の教科書で知ったから
関数型言語と結びつけるイメージが全く沸かない

**デフォルトの名無しさん** · 2012/03/04(日) 03:15:06.28

128は本質をついている。
リストは再帰的データ構造を持つので、
再帰を反復の記述にとる関数型とは相性がいい。

**デフォルトの名無しさん** · 2012/03/04(日) 03:45:32.27

関数型言語にとって副作用が無いことは
本質的なことなの？
そうだと言える根拠とかあるの？

MLやHaskellが設計された頃の流行りだった
だけじゃないの？
”副作用は悪”っていう思想は、古いアルゴリズムの
教科書にはよく載ってる

**デフォルトの名無しさん** · 2012/03/04(日) 05:47:41.38

>>134
反復もリストも、圏論の抽象力の前では、単なる実装上の都合だよ

**デフォルトの名無しさん** · 2012/03/04(日) 05:50:20.88

>>125
壁３は本質的じゃないね。それよりも

--- 壁3'. 宣言性(記述順序に左右されない)の壁

を入れたほうが関数プログラミングの本質に近づくと思うのだが。

**デフォルトの名無しさん** · 2012/03/04(日) 09:08:06.01

>>137
宣言という言葉をあまり狭義に使うのはどうかな。
IBMの簡易言語RPG(現在バージョンはIVかな)は
Decision Tableを使って制御を行っているので、
昔は宣言型言語に分類されていた。同じ宣言でも
こうまで異なると問題だ。

**デフォルトの名無しさん** · 2012/03/04(日) 09:23:41.58

定義のことを宣言って言ってるだけじゃね？

英語でどうなんだか知らんけど。

**デフォルトの名無しさん** · 2012/03/04(日) 10:33:53.88

CTMCPすら知らずに妄想する隔離スレか。

**デフォルトの名無しさん** · 2012/03/04(日) 10:43:48.80

抽象度が高いことを示すコードが出てないんだが
pythonに作れなくて、Haskellに作れるものって何がある？
とりあえずHaskellでif関数自作できるとかはよく見かけるが

**デフォルトの名無しさん** · 2012/03/04(日) 11:05:05.88

if関数ったって組み込みの（型クラスを含む）条件分岐機構を使わずには書けんだろ。

**デフォルトの名無しさん** · 2012/03/04(日) 11:39:11.04

>>140知らなかったので、検索して目次を眺めてみたが、スレタイのような議論をするなら読むべきかと思った。

**デフォルトの名無しさん** · 2012/03/04(日) 11:44:07.10

>>142 ARMなら条件分岐なしのコードにコンパイルできるんでね？

**デフォルトの名無しさん** · 2012/03/04(日) 11:48:48.15

>>142
へ？
パターンマッチとガードでごく普通の関数として書けるけど
型クラスなんて大仰なもん使わんよ
と言うか、ifが普通に書けるのが遅延評価と関数もファーストクラスの値っていう特徴の賜物じゃないか

if flg t f | flg == True = t
　　　　　　| flg == False = f

関数型言語は必ず値を返すって性質上、if elseしか許されないが

先行評価のだと、両方とも関数を受け取った時点で評価前に実行されちゃうから正しく動かない
（評価前に両方実行されて、評価後にどちらかが実行される）

**デフォルトの名無しさん** · 2012/03/04(日) 12:02:53.04

つーか、関数型言語の利点と言えば、バグが無いことを保障できるって事じゃね？
数学の証明で公式が永遠に正しいことを保障するのと同じで、関数にバグが無いこと保証できれば、その関数の使い方を間違わなければ、その関数が原因のバグは無いと保証できる

**デフォルトの名無しさん** · 2012/03/04(日) 12:08:56.91

分岐を関数で表現するのは難しくない。
T（x,y）=x
F（x,y）=y
IF（c,x,y）=c（x,y）
最後のは糖衣構文で、cはTかFが入る。

問題はこれを先行評価すると、
xの評価、yの評価、どっちかの選択と
進行してしまい、無駄な評価またはやっては
ならない評価をしてしまうことになる。

遅延評価では必要になるまで引数は評価されず、
c（x,y）にはxかyの一方しか含まれないので、
上記の問題は起こらない。

**デフォルトの名無しさん** · 2012/03/04(日) 12:10:17.75

すでにコメントされていたか。

**デフォルトの名無しさん** · 2012/03/04(日) 13:14:45.06

元ネタ書いたの誰か知らんが >>125 は酷すぎる。
上下に並べている壁が、それぞれ軸が違う。
壁２は型システムの問題だろ。
壁４も意味不明。
末尾再帰最適化の有無を越えられない壁とか書いてるのもアホ丸出し。
末尾再帰になるような処理は手続き型なら最初からループで書く方が自然。
だから要らないだけ。

**デフォルトの名無しさん** · 2012/03/04(日) 13:24:51.24

型推論とオブジェクトの相性の悪さが問題だな
誤解を恐れずざっくり切るなら、
オブジェクト指向が適している分野に関数型言語は不適。

**デフォルトの名無しさん** · 2012/03/04(日) 14:09:20.29

せんせー、OCamlさんが泣いてます

**デフォルトの名無しさん** · 2012/03/04(日) 14:12:58.24

>>145
パターンマッチがすでに条件分岐機構なんだが…
条件分岐機構使って条件分岐書き換えてドヤ顔されてもな。

**デフォルトの名無しさん** · 2012/03/04(日) 15:30:46.23

>>147
Smalltalkの宣伝乙w

**デフォルトの名無しさん** · 2012/03/04(日) 16:33:15.37

一般論を書いたつもりだがどの部分がsmalltalk?

**デフォルトの名無しさん** · 2012/03/04(日) 16:34:41.05

一般論を書いたつもりだがどの部分がsmalltalk?

**デフォルトの名無しさん** · 2012/03/04(日) 17:05:02.03

T（x,y）=xがTrueクラスの定義
F（x,y）=yがTrueクラスの定義
IF（c,x,y）=c（x,y）がメソッドの動的束縛に相当した実装になっている。

具体的には、if式はifTrue:ifFalse:というメソッドで実装されている。
これがTrueクラスでは、第1引数のクロージャを評価するよう定義されていて、
Falseクラスでは、第2引数のクロージャを評価するよう定義されている。

クライアントコードでは例えば
x = y ifTrue: [do something] ifFalse: [ do something else]
というメッセージ式を評価する時に、
x=yがtrueならTrueクラスのifTrue:ifFalse:が束縛されて
第1引数の[do something]が評価される。([ ]で囲まれたものはクロージャ)
x=yがfalseならFalseクラスのifTrue:ifFalse:が束縛されて
第2引数の[do something else]が評価される。

【アンチ】関数型言語は使えない【玩具】 ２

【アンチ】関数型言語は使えない【玩具】２