09/09/09 13:31:46
Lisp Scheme ML Haskell FP Mirranda など
関数型言語について話し合いましょう。
前スレ
関数型言語Part IV
ｽﾚﾘﾝｸ(tech板)
関連スレ
Lisp Scheme Part27
ｽﾚﾘﾝｸ(tech板)
関数型言語ML (SML, OCaml, etc.), Part 6
ｽﾚﾘﾝｸ(tech板)
関数型プログラミング言語Haskell Part11
ｽﾚﾘﾝｸ(tech板)
Emacs Lisp 3
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
09/09/09 13:50:58
テンプレ追加情報よろしく
3:デフォルトの名無しさん
09/09/09 14:12:27
【関数】Erlang【エリクソン】
ｽﾚﾘﾝｸ(tech板)
【.NET】F#について語れ【OCAML】
ｽﾚﾘﾝｸ(tech板)
4:デフォルトの名無しさん
09/09/09 19:28:02
関数型言語の定義なんて
・関数がファーストクラスオブジェクトとして扱える
・リスト操作が簡単
・ラムダが簡単
としか思っていないし、それ以上のことはどうでもいい
純粋とか非純粋とかマジどうでもいい
5:デフォルトの名無しさん
09/09/09 20:13:17
参照透明性ぢうやう
6:デフォルトの名無しさん
09/09/09 20:14:54
>>4
考えを改めると世界がよりよく見渡せるようになると思う。
今後もそんな目は要らないと言うのなら、どーでもいいが。
7:デフォルトの名無しさん
09/09/09 20:28:42
>>6
別にそんな一所懸命、何かをわかってるフリしなくていいです。
8:t ◆SQYzTdSfUA
09/09/09 20:43:05
劣化の件は私も余計だと思ってましたので取り下げます
失礼しました
ところで、前スレの990の
>ソフトウェア設計(あるいはプログラミング)という行為を、(理論を背景にして)
>より抽象的に、より形式的に実践しようとすることは大切だし、それを多くの人に広めたい。
というのは同意見です
現場でも理論的な背景を知り実践していくべきです
そういう意味ではHaskell, OCaml, Scala, haXeあたりを進んで実戦投入していけば、
いやでも広まると思います
もし現場で設計を担当していて、開発言語を決定できる権限のある方はこれらの言語を推してください
9:デフォルトの名無しさん
09/09/09 20:45:09
>>4
JavaScriptは関数型言語か否か
10:デフォルトの名無しさん
09/09/09 20:48:36
>>8
納期に間に合わなかったら誰が責任とるの？
11:デフォルトの名無しさん
09/09/09 20:56:54
>>7
分かってないけどいーじゃん、フリぐらいさせろ。
別に大きく間違った事は言ってないよな。
12:t ◆SQYzTdSfUA
09/09/09 21:04:27
>>10
Haskellじゃなくて他の"一般的な"言語を使っていたら納期遅れの責任を回避できるの？
どの言語を使おうが、責任の所在は変わらないと思う
13:デフォルトの名無しさん
09/09/09 21:04:59
>>8
末端の単純労働力のレベルを知ってて仰ってるのん？
14:t ◆SQYzTdSfUA
09/09/09 21:13:58
>>13
はい、ある程度は知っています
C++やPHPを使わせるよりは逆に安全だと思っています
実際に某関数型言語(詳しくは書けません)で協力会社さんに依頼を出したことがあります
確かに出来上がったコードは期待以下でしたが、それでもヌルポが頻発するよりましでした
15:デフォルトの名無しさん
09/09/09 22:03:58
趣味で押しつけたのが原因ならお前のせいなんじゃねーの
16:t ◆SQYzTdSfUA
09/09/09 22:49:42
当り前過ぎてためらいますが、やや気遅れしている人もいるかもしれず、関数型言語普及のために書きます
システム開発の現場の方へ：
もし趣味で学んだ関数型言語がシステム開発に有用だと思ったら、
上長やリーダー（システム設計の責任者）にその件をぜひ提言して下さい
その提言が受け入れられたからといって、万一プロジェクトが失敗した責任があなたに
降り掛かってくる事はありません
安心して提言しましょう
システム設計責任者へ：
どの言語を選ぼうが、結局のところ設計責任はあなたにあります
胸を張って自分がいいと思う言語を選択してください
たとえそれが趣味であろうとなかろうと
一般的であろうとなかろうと
17:デフォルトの名無しさん
09/09/09 23:17:30
などと供述しており動機は不明
18:デフォルトの名無しさん
09/09/09 23:48:18
当たり前過ぎるけど、
実用プログラミング言語なんて、
それをつかう一般的プログラマにとって、
言語自体が把握できる大きさと複雑さに抑えられていて、
対象とする問題記述に可能な限り簡易であればそれでいいのだと思う。
19:デフォルトの名無しさん
09/09/09 23:52:22
>>18
そうだとするとC++なんて実用言語としては論外だなｗ
C++をもちだすのはスレチだろうけど。
20:デフォルトの名無しさん
09/09/10 00:01:52
>>19
まったくその通り。
念のため>>18ではライブラリも含めての複雑さ大きさ。
21:デフォルトの名無しさん
09/09/10 00:23:47
>>20
でも複雑で巨大でも、使うプログラマからすれば必要な部分だけチョイスして
プログラムできればそれでいいんじゃないかと思うよ。
C++の全仕様を把握してるプログラマとかANSI CLの全ライブラリを熟知してるプログラマとか
存在しない（と思う）けど、別にそれは問題ないだろ。
22:デフォルトの名無しさん
09/09/10 00:28:54
K&R C が最強
はい論破
23:デフォルトの名無しさん
09/09/10 00:45:17
>>21
必要な部分だけ選択することができて、
名前などがうっかり重複してしまっても問題ないといいですね。
>>22
対象とする問題の種類と大きさによる。
24:デフォルトの名無しさん
09/09/10 01:35:18
>>23
大抵のプログラム言語は名前空間なりパッケージシステムなりで
名前の重複は実用上問題にならないか、問題が起きても発見できるんじゃねえ？
25:デフォルトの名無しさん
09/09/10 01:57:34
テンプレにScalaスレが無い……
26:デフォルトの名無しさん
09/09/10 02:11:06
Scalaスレあったのか……
27:デフォルトの名無しさん
09/09/10 15:15:17
プログラミング言語 Scala 2冊目
ｽﾚﾘﾝｸ(tech板)
28:デフォルトの名無しさん
09/09/10 15:19:10
Scalaスレも有るんでスカラね。
29:デフォルトの名無しさん
09/09/10 15:24:58
スッカラ忘れてたYo
30:ぅゅ ◆e6.oHu1j.o
09/09/19 17:32:10
Lisperってどこにいけば会えるんだ
色々と質問攻めしたいんだけど
31:デフォルトの名無しさん
09/09/19 20:07:45
ｽﾚﾘﾝｸ(prog板)
マ板の名物精神病者につき、無視推奨
32:デフォルトの名無しさん
09/09/19 21:55:50
面白そうなヤツじゃないか。
Languageもまともに綴れないようだし。
33:デフォルトの名無しさん
09/09/19 22:15:06
ここにLisperなんてロートルを超越した◆XaaQNk.がいるから、議論するといい
ｽﾚﾘﾝｸ(tech板)
34:デフォルトの名無しさん
09/09/19 23:11:29
うゆって去年まで学生だったのか
おっさんだと思ってた
おっさんは頭おかしい奴多いからな
35:デフォルトの名無しさん
09/12/27 12:28:36
なあ、Jのスレ立てたら誰か来るかい？
36:デフォルトの名無しさん
09/12/27 12:41:18
>>4
> ・関数がファーストクラスオブジェクトとして扱える
> ・ラムダが簡単
なんだこれは。ちゃんと整理しろ。
37:デフォルトの名無しさん
10/02/27 08:52:54
これほどまでに簡潔に整理された定義は無いと思うが。
38:デフォルトの名無しさん
10/02/27 13:12:56
関数型言語のより簡潔な定義：
関数の返り値を使って処理を行うスタイルが徹底されている言語
39:デフォルトの名無しさん
10/03/28 13:37:56
ｽﾚﾘﾝｸ(livebase板:94番)
94 ：どうですか解説の名無しさん：2010/03/26(金) 16:46:32.35 ID:A/YF/FyF:
40:デフォルトの名無しさん
10/03/28 16:39:34
確かに神IDだけど受ける層狭すぎだろｗ
41:デフォルトの名無しさん
10/10/19 07:36:49
まだあったのか
42:デフォルトの名無しさん
11/01/10 23:21:31
あげ
43:デフォルトの名無しさん
11/06/23 17:19:18.52
ほしゆ
44:天使 ◆KOAgYBL/Xg
11/06/30 10:07:58.49
Ｌｉｓｐｅｒに、質問攻めしたかったんだけど、
もう、それはいいや
その段階は超えた
関数型言語って、わずかにズレてんだよなぁ････
クラスなんてものを使わず、関数でかいていくのはいいんだけど、
それだけじゃダメで
根底に1つ、クラスが必要であって
そのクラスオブジェクトにlambdaやメンバ変数やメンバ関数を、 オブジェクトインスタンスごとに付け加えていく感じ
それによって、型 ＝ データとなって、
プログラム中に同じ型が存在しなくなるみたいな、そういうやつ
関数型言語は、まだそれを夢想している段階の言語で、決定的なものが抜けているからオブジェクト指向言語にすら勝てない
2011年の今現在、関数型言語で関数型プログラミングするよりも
オブジェクト指向言語にて関数型プログラミングしたほうが圧倒的に優位
45:デフォルトの名無しさん
11/06/30 14:43:26.13
そういうノリで笑ってもらえるのは高校までだなあ
46:デフォルトの名無しさん
11/06/30 20:05:47.53
>>44 OOPと関数型の関係に興味あるなら、下を読むとよい。
OOPの発想をSMLで表現する方法が載っている
URLﾘﾝｸ(mlton.org)
47:デフォルトの名無しさん
11/06/30 22:41:51.86
というか、オブジェクト指向の機能持った関数型言語がないと思ってる時点で、
不勉強な馬鹿丸出しなんだが。
同時代関数型言語でオブジェクト指向機能ないのを探す方が難しい。
48:デフォルトの名無しさん
11/07/01 02:08:14.62
>>46-47
いやいや、君ら最近覚えたような人だろうけど、
そういうことじゃないんだよね
上のコテの「OOPLで関数型」は散々議論をし尽くされた上での結論なんだよ
ひよっこには理解はできんだろうが、まあ可能性を探してくれたまえよ・・・
49:デフォルトの名無しさん
11/07/01 02:14:06.97
自演の練習をしたほうが良いかと思いました
50:デフォルトの名無しさん
11/07/01 02:18:27.97
そうそう認めたくないんだよな
判る判る・・・
51:デフォルトの名無しさん
11/07/01 02:21:16.40
おっとsage忘れた
関数型の関数は重すぎるってことだな
さよなら・・・
52:デフォルトの名無しさん
11/07/01 03:37:00.13
>>48
（注：◆KOAgYBL/Xgは うゆのトリップのひとつ）
うゆ君は英語論文も英語ブログも全然読めないですよね。
「散々議論をし尽くされた」とはどこの議論の事でしょうか？
ム板で技術に関する嘘をまき散らすのは止めてください。
53:デフォルトの名無しさん
11/07/01 03:47:33.74
副作用がないオブジェクト指向設計は
実現可能か？
俺は無理だと思う。
オブジェクト指向と関数型は
相容れない。
54:デフォルトの名無しさん
11/07/01 03:50:23.47
副作用のない実用性のあるプログラムは実現可能か？
俺は無理だと思う。
55:デフォルトの名無しさん
11/07/01 05:58:04.66
xmonadやdarcsは実用的なうちに入らないんだな
56:デフォルトの名無しさん
11/07/01 11:07:10.17
関数型言語には副作用がないというのも初級者の陥りがちな間違い。
λ計算じゃないんだから。
57:デフォルトの名無しさん
11/07/01 11:16:38.92
つまり>>53は初心者と
58:デフォルトの名無しさん
11/07/01 20:25:46.65
>>56
純度を高くすると限りなくラムダ計算に近くなって、無くなると思うぞ
59:デフォルトの名無しさん
11/07/01 20:31:36.03
Haskellには副作用がないけど破壊的更新や入出力のあるプログラム書けるよ
60:デフォルトの名無しさん
11/07/01 21:46:11.02
変数への代入も副作用なんだね。
61:デフォルトの名無しさん
11/07/01 21:52:12.08
ラムダ計算自体と副作用の有無って無関係なんじゃないの
62:デフォルトの名無しさん
11/07/01 22:23:03.86
関数型言語というのは、条件分岐（if等）と繰り返し（for等）を
変数なしに実行できるような文法を持ってる言語のことだよ。
63:デフォルトの名無しさん
11/07/01 22:59:51.50
結論としてテンプレートメタプログラミング最強と
64:デフォルトの名無しさん
11/07/01 23:28:34.24
再帰呼び出しがあれば、すべて関数型言語ということか
65:デフォルトの名無しさん
11/07/01 23:29:01.80
>>63 いや、むしろテンプレートメタプログラミングで関数型言語的なもの
に興味を持って、解読不能なコンパイルエラーでいやになって、MLに移った
のだが。まあ、gcc2.95の時代なので、もっとましになっているとは思うが。
66:デフォルトの名無しさん
11/07/02 00:04:14.43
ばかじゃん
67:デフォルトの名無しさん
11/07/02 00:50:15.76
Haskellに副作用がないなんてよく言えるなあ。
>>58
思うって言われても…
現実のプログラミング言語で極限に近づいたものは何があるの？
68:デフォルトの名無しさん
11/07/02 01:04:59.38
また具体的な話なしか
69:デフォルトの名無しさん
11/07/02 04:56:56.34
>>67
言語の問題ではなく、スタイルの問題だよ
純度の高いスタイルで書けば、副作用は限りなくゼロに近付くということ
70:デフォルトの名無しさん
11/07/02 05:27:43.51
いや言語の問題として、Haskellには(参照透明性を破るという意味での)
副作用を持つ関数がほとんど存在しない
例外はunsafePerformIOなど使って定義された関数
71:デフォルトの名無しさん
11/07/02 05:27:54.05
ああん？お客さん？ああん？
72:デフォルトの名無しさん
11/07/02 05:29:42.65
>>70
ああん？生き別れの兄弟さん？ああん？
73:デフォルトの名無しさん
11/07/02 05:50:17.81
ああんっ…
74:天使 ◆uL5esZLBSE
11/07/02 14:52:04.82
２０１１年になっても未だにJAVA使い続けてる奴ってさ
仕事で仕方なくならわかるけど
家でもJAVAやってるなら本当にバカだよね。哀れ
ゴミ
75:デフォルトの名無しさん
11/07/02 15:12:36.77
Javaバカにしてる子ってさ
変数に＄ついてる言語触ってるって事だよね
いちいちSHIFT＋４キーおして ＄ 打ちまくってる感触はどう？
76:デフォルトの名無しさん
11/07/02 15:17:21.84
Javaバカにしてるレスなんて最近ないだろ
77:デフォルトの名無しさん
11/07/02 22:39:10.62
>>70
これでもYOME
URLﾘﾝｸ(en.wikibooks.org)
78:デフォルトの名無しさん
11/07/02 23:04:55.02
え？オブジェクトって内部状態を持つものじゃないの？
副作用のないオブジェクトって何なの？
79:デフォルトの名無しさん
11/07/02 23:22:26.77
>>78
javaでいうとStringとか。
オブジェクトはメッセージに対応するメソッドを持っていればいいだけで
別に内部で状態を変化させなきゃならんとかいう決まりはないよ。
newObject = Message( oldObject, arg1, arg2 );
こういう形で十分成立する。
80:デフォルトの名無しさん
11/07/03 00:34:23.99
十分ではない
加工せず作って捨てる発想だと
効率が悪すぎるのさ
まあ幼稚園児では判らないかもしれない
つまり関数型の発想は園児レベル
その根底をぶち壊すしかない
81:デフォルトの名無しさん
11/07/03 01:00:52.02
破壊的変更を許しても意味的にimmutable、みたいな考え方をc++で見た気がするが
なんか名前がついてたと思うんだが思い出せない
82:デフォルトの名無しさん
11/07/03 01:04:41.43
もしかして： mutable
83:デフォルトの名無しさん
11/07/03 01:08:28.90
それだ。なんかﾜﾛﾀｗ
84:デフォルトの名無しさん
11/07/03 01:31:56.15
>>80 副作用を許しながら完全性・健全性を保っている言語は70年代からありますが
85:デフォルトの名無しさん
11/07/03 01:32:53.09
ループを再帰でやる、
比較をパターンマッチでやる、
辺りの概念は同意できるんだけど。
副作用そのもの扱いが確立されてない。
モナドみたいなごまかし方ってどうなのかね。
86:デフォルトの名無しさん
11/07/03 01:38:59.17
>>81
本当はCOWの事いいたかったんちゃうの？
87:デフォルトの名無しさん
11/07/03 01:41:28.12
つーか、変数に代入すること自体が
副作用なんだけどね。
副作用がだめというのなら
変数に入れてはいけない。
88:デフォルトの名無しさん
11/07/03 01:42:42.77
>>80
何が効率悪いの？
空間？速度？
89:デフォルトの名無しさん
11/07/03 01:44:25.37
>>87
イヤ。
10 = Xであるとき 11 = Xになってはいけないだけの話。
数学であるでしょ。アレがもとになってんの。
90:デフォルトの名無しさん
11/07/03 02:02:46.46
>>89
どうやったら、10=Xのとき
11=Xになるというんだ？
91:デフォルトの名無しさん
11/07/03 02:14:31.09
>>90
int X=10;
X=11;
92:デフォルトの名無しさん
11/07/03 02:16:41.03
やっぱり変数に代入することが
副作用じゃんｗ
93:デフォルトの名無しさん
11/07/03 02:21:26.16
f( x, e ) = if( x == e ) f( x + 1, e) else 0;
y = f( x );
ただし、これは副作用があるとは言わない。
94:デフォルトの名無しさん
11/07/03 02:25:11.17
f( x, e ) = if( x != e ) f( x + 1, e); else x;
y = f( 3, 5 );
間違えた、こんな感じか。意味ないけど。
95:デフォルトの名無しさん
11/07/03 02:48:39.07
もう少し具体的な説明を残しておこう。
ちょっと書きなおしたが関数の定義がこんなかんじだとする。
f( x, e ) = if( x - e ) x; else 1 + f( x + 1, e );
関数の呼び出しはこんな感じ。
y = f( 3, 5 );
で、関数というのは数だ。
数学表記で y = x + 1 なんかを関数というが正しく処理じゃなくて数なんだ。
関数定義というのは数式に名前をつけただけ。本来は関数の中には数(数式)が入る。
さっきの例で言うと
6 = ( if( 3 - 5 ) else 3; 1 + ( if( 4 - 5 ) else 4; 1 + ( if( 5 - 5 ) else 5; 1 + (・永遠に続く・) ) ) )
というひとつの式になる。
0 = ( if( 3 - 5 ) else 3; 1 + ( if( 4 - 5 ) else 4; 1 + ( if( 5 - 5 ) else 5; 1 + (・永遠に続く・) ) ) ) - 6
仮に方程式にしても通じる。もし、ここで変数への代入があった場合は？
考えてみたらわかるが5 = 4のような矛盾した数式が発生するため式として成立しなくなる。
96:デフォルトの名無しさん
11/07/03 03:01:02.73
このようになにをやっているのか
訳が分からなくなるのが関数型言語です。
97:デフォルトの名無しさん
11/07/03 03:07:45.92
うむ
>>95を1行で要約すると？
↓よろー
98:デフォルトの名無しさん
11/07/03 03:10:54.36
1+1=田
99:デフォルトの名無しさん
11/07/03 03:11:32.25
まぁ、数学が解からんヤツには、式に矛盾がないことによる見通しの良さなんて解からんだろうて。
猫に小判、豚に真珠、馬の耳に念仏、非理数系に関数型。
100:デフォルトの名無しさん
11/07/03 03:13:17.93
理系は生産性がないってことか
101:デフォルトの名無しさん
11/07/03 03:15:46.99
amazonでさえ最初はlispで書いてあったんだ。
プロトタイプ作る生産性なら関数型の方が上だろ。
ただ、バカには使えないのと、パフォーマンスの調整がメンドイってのはあるけどな。
102:デフォルトの名無しさん
11/07/03 03:18:14.92
裸の王様スレ
103:デフォルトの名無しさん
11/07/03 03:18:57.77
人間は長い文章よりも点や丸で区切られた短い文章の方が読み易く感じるのですよ。
104:デフォルトの名無しさん
11/07/03 03:21:48.06
lispで書いたのは「関数型だから」ﾅﾉｶﾅｰ?
105:デフォルトの名無しさん
11/07/03 03:22:05.34
そういや何で生産性が下がるんだ？
106:デフォルトの名無しさん
11/07/03 03:25:07.28
関数型より生産性の高い言語か。まぁ、あるかもしれん。
俺は知らんから教えてくれ。
1. 比較元の関数型言語
2. 1より生産性の高いらしい言語
107:デフォルトの名無しさん
11/07/03 03:26:18.50
1.全ての関数型言語
2.C/C++
108:デフォルトの名無しさん
11/07/03 03:26:44.69
関数型は一部の便利な概念がちょっと使われてるだけで
それ単体では生産性というか生産能力自体無いと思うの
109:デフォルトの名無しさん
11/07/03 03:28:03.30
教えてくれ(ｷﾘｯ
ｷﾀｰ
何回繰り返すんですか
110:デフォルトの名無しさん
11/07/03 03:31:50.08
予想通り関数型の定義が曖昧のまま話が進んでるな
関数型で生産性の高い言語って何だ？
ハスケル厨とかに言わせるとLISPは関数型じゃないってよ
111:デフォルトの名無しさん
11/07/03 03:33:12.03
じゃ論理的に帰納法で生産性の高さを調べようか。
解る範囲で比較できる実際のプロジェクトの工数を書いてみようや。
生産性が低い
・Concurrent Clean
・Haskell
・Miranda
・Lazy K
・F#
・ML
・OCaml
・Scala
・Erlang
・LISP
・LOGO
・Scheme
・Mathematica
・R
・Unlambda
・APL
・XSLT
生産性が高い
・C
・C++
112:デフォルトの名無しさん
11/07/03 03:50:29.84
帰納ほうで書くなら>>111じゃだめだな
命題：規模あたりの開発工数が多い言語は何か
規模あたりの開発工数が多い
・Concurrent Clean プロジェクト内容, 工数, 人数
・Haskell プロジェクト内容, 工数, 人数
・Miranda プロジェクト内容, 工数, 人数
・Lazy K プロジェクト内容, 工数, 人数
・F# プロジェクト内容, 工数, 人数
・ML プロジェクト内容, 工数, 人数
・OCaml プロジェクト内容, 工数, 人数
・Scala プロジェクト内容, 工数, 人数
・Erlang プロジェクト内容, 工数, 人数
・LISP プロジェクト内容, 工数, 人数
・LOGO プロジェクト内容, 工数, 人数
・Scheme プロジェクト内容, 工数, 人数
・Mathematica プロジェクト内容, 工数, 人数
・R プロジェクト内容, 工数, 人数
・Unlambda プロジェクト内容, 工数, 人数
・APL プロジェクト内容, 工数, 人数
・XSLT プロジェクト内容, 工数, 人数
・C プロジェクト内容, 工数, 人数
・C++ プロジェクト内容, 工数, 人数
規模あたりの開発工数が少ない
内容の規模 * 人数 / 工数 でおおよそ見積もれるはず。
113:デフォルトの名無しさん
11/07/03 03:52:03.02
宣言は書いてもデータを持ってこないのが関数型
114:デフォルトの名無しさん
11/07/03 03:58:26.06
>>111-112
何をやりたいのか知らんが
開発工数と生産性の高さってあんま関係ないでしょ
マイナーすぎたら誰もメンテできなくて却下だし
どう見ても関数型に不利な結果になる
マイコンで動かす→CASMとか
iほんで → Objc
安藤idで → java
窓で → C#VBとか
ネトで → 色々
こういう定番がある所に関数型言語が入り込む余地を考えるに、
少なくともその環境のSDKが滞りなく使えることが条件
その上で生産性を示す必要がある
115:デフォルトの名無しさん
11/07/03 04:09:09.10
haskellがCの10倍生産性が高いと仮定しても、
10倍程度ならCで書いたほうが誰でも理解できてよろしい、
という世の中です。
100倍、1000倍、彼女が出きるとかなら判りませんが。
116:デフォルトの名無しさん
11/07/03 04:16:48.92
つーか工数以前に、人数集まるのｗｗ
やる前にプロジェクト破綻するのが予測できるってどうよ
117:デフォルトの名無しさん
11/07/03 04:18:04.71
>>77
Haskell界隈でもside effectという言葉の意味が一定してない
その記事で言ってるside effectは参照透明性を壊さない
>>85
IOモナドはごまかしどころか入出力を関数的に扱う自然な方法だと思う
118:デフォルトの名無しさん
11/07/03 04:25:49.70
haskellなんか覚えなくても
東電に入れば
収入が保障されたり
芋づる式に彼女ができたり
放射能出しっぱでも賠償しなくていい
119:デフォルトの名無しさん
11/07/03 04:27:07.02
とりあえずlispのzipのコードが見つかったんで追加、工数自体は調べづらいから行数のほうがいいかもね。
>>114-115
いまさらファビョんなよ。普及なんて時間と社風の問題じゃねぇか。
amazonやら欧米企業は関数言語ユーザーが社員の半分以上いるらしい。
問題にならん。採用水準最底辺のアホの集団を基準に言うな。
規模あたりの開発工数が多い
・Concurrent Clean プロジェクト内容, 工数, 人数
・Haskell プロジェクト内容, 工数, 人数
・Miranda プロジェクト内容, 工数, 人数
・Lazy K プロジェクト内容, 工数, 人数
・F# プロジェクト内容, 工数, 人数
・ML プロジェクト内容, 工数, 人数
・OCaml プロジェクト内容, 工数, 人数
・Scala プロジェクト内容, 工数, 人数
・Erlang プロジェクト内容, 工数, 人数
・LISP zip開発,(1118行) 不明, 不明
(URLﾘﾝｸ(codepad.org))
・LOGO プロジェクト内容, 工数, 人数
・Scheme プロジェクト内容, 工数, 人数
・Mathematica プロジェクト内容, 工数, 人数
・R プロジェクト内容, 工数, 人数
・Unlambda プロジェクト内容, 工数, 人数
・APL プロジェクト内容, 工数, 人数
・XSLT プロジェクト内容, 工数, 人数
・C プロジェクト内容, 工数, 人数
・C++ プロジェクト内容, 工数, 人数
規模あたりの開発工数が少ない
120:デフォルトの名無しさん
11/07/03 04:30:10.27
ま、ユーザーになるだけなら
仕事で使わなくても、ちょっと触ればいいだけだしな。
121:デフォルトの名無しさん
11/07/03 04:33:58.50
「いるらしい」という不確かな情報でいるとカウントされちゃうわけか
話にならんのだがｗ
122:デフォルトの名無しさん
11/07/03 04:35:41.94
>>121
URLﾘﾝｸ(www.aoky.net)
amazonに関しては事実だってな。
123:デフォルトの名無しさん
11/07/03 04:36:17.87
で、なんなのzipのコードってｗ
再発明コードで比較してって生産性の比較になんの？
どんだけ行数短いですよコンテスト？
124:デフォルトの名無しさん
11/07/03 04:39:03.05
とりあえず >>114-115 みたいなヤツらは、
机上の空論じゃなく事実(実績)を出せ。
プログラマーなんだろ。
文系やら厨房みたいな、俺の想像する生産性なんていらんから。
125:デフォルトの名無しさん
11/07/03 04:40:29.16
＞俺の想像する生産性
なんか始まった？
126:デフォルトの名無しさん
11/07/03 04:40:49.50
>>123
全く違うものを比較対象にしろと？
帰納法とか演繹とかしらないの？そもそもバカなの？
127:デフォルトの名無しさん
11/07/03 04:46:07.64
>>123 は、mp3のエンコーダとイメージビューアのソースコード見比べて
どっちが効率的だなとか考えるわけか・・・。
128:デフォルトの名無しさん
11/07/03 04:48:03.38
屁理屈で結論をうやむやにし始めました
129:デフォルトの名無しさん
11/07/03 05:04:22.67
zipの中身って単なる文字列とファイル操作でしょ。
awkみたいのが生産性高いことになってしまう。
130:デフォルトの名無しさん
11/07/03 05:10:35.22
>>128 不満ならあの表埋めろよ。
>>129 それならそれでいいじゃん。実際生産性がどのくらいか調べたいだけなんだし。
事実を客観的に判断するだけだ。あと何を持って文字列と言ってんのかしらんがzipは
文字列じゃないぞ。スライド辞書とかバイナリだらけ。
131:デフォルトの名無しさん
11/07/03 05:11:57.24
>>130
>>113
132:デフォルトの名無しさん
11/07/03 08:21:58.52
>>92
代入自体は副作用じゃなく「再代入」が副作用、かな
133:デフォルトの名無しさん
11/07/03 09:21:48.00
>>86 把握した。でも俺はこのままでいいんだ
134:デフォルトの名無しさん
11/07/03 10:18:02.91
なぜ関数型言語は実用的でないのか
135:デフォルトの名無しさん
11/07/03 10:41:39.19
自分の無知を指摘されたら、ファビよって関数型言語をdisり始めたw
136:デフォルトの名無しさん
11/07/03 11:55:03.97
>>79
それって、ただの手続き型（c、basic）じゃね？
137:デフォルトの名無しさん
11/07/03 12:14:29.80
>>136
副作用の有無の話なんだからその例で充分じゃね？
OOPLのオブジェクトだって、コンストラクタの引数で状態を設定したらあとは不変、にすれば副作用は無いんだから
138:デフォルトの名無しさん
11/07/03 12:31:38.65
純粋関数型は状態の概念を拒絶しすぎて複雑にしすぎてるし
マルチパラダイムは何でもできるゆえに結局いいところも悪いところも取り込んじゃうし
まだ研究段階を出ていないと思う。
139:デフォルトの名無しさん
11/07/03 14:17:09.90
IOモナドは複雑じゃないよ
140:デフォルトの名無しさん
11/07/03 15:49:41.95
Cのlibzipが見つかったんで追加。2行以上の改行とコメントは削除してカウント。
Cはlispの4倍だってさ。
あと紛らわしいんで実例未調査の言語を外してみた。
規模あたりの開発工数が多い↑
・C zip開発,(4064行), 不明, 不明
(URLﾘﾝｸ(codepad.org))
・LISP zip開発,(1118行) 不明, 不明
(URLﾘﾝｸ(codepad.org))
規模あたりの開発工数が少ない↓
未調査言語
・Concurrent Clean プロジェクト内容, 工数, 人数
・Haskell プロジェクト内容, 工数, 人数
・Miranda プロジェクト内容, 工数, 人数
・Lazy K プロジェクト内容, 工数, 人数
・F# プロジェクト内容, 工数, 人数
・ML プロジェクト内容, 工数, 人数
・OCaml プロジェクト内容, 工数, 人数
・Scala プロジェクト内容, 工数, 人数
・Erlang プロジェクト内容, 工数, 人数
・LOGO プロジェクト内容, 工数, 人数
・Scheme プロジェクト内容, 工数, 人数
・Mathematica プロジェクト内容, 工数, 人数
・R プロジェクト内容, 工数, 人数
・Unlambda プロジェクト内容, 工数, 人数
・APL プロジェクト内容, 工数, 人数
・XSLT プロジェクト内容, 工数, 人数
・C++ プロジェクト内容, 工数, 人数
141:デフォルトの名無しさん
11/07/03 15:51:09.48
>>140
マ板でやれよ
142:デフォルトの名無しさん
11/07/03 15:55:54.00
別にいいんじゃね。言語の話だし。
これからどの言語使おうってヤツらの参考資料になるだろ。
143:デフォルトの名無しさん
11/07/03 16:04:38.64
興味は有るけど、そういうスレを作って、そっちでやって欲しいな
144:デフォルトの名無しさん
11/07/03 16:13:45.38
撮影技術を語る板で、
NHK朝ドラ、水戸黄門が視聴率があるから一番すごいドラマって力説するか?
145:デフォルトの名無しさん
11/07/03 16:53:49.73
撮影技術を語る板で、
制作期間と使用された技法数を語るようなもんだろ。
視聴者 = ユーザー数 だし。
146:デフォルトの名無しさん
11/07/03 17:16:06.02
>>144
例えが的外だなｗ
正しく対比させてやろう。
■撮影技術
○○技法を使って作られた作品（NHK朝ドラ、水戸黄門等）・・・1000作品
△△技法を使って作られた作品・・・800作品
□□技法を使って作られた作品・・・500作品
水戸黄門の視聴率・・・○％
■プログラム技術
C++を使って作られた作品（Firefox等）・・・1000作品
Javaを使って作られた作品・・・800作品
Perlを使って作られた作品・・・500作品
Firefoxのユーザー数・・・○万人
視聴率＝アプリのユーザー数。そんなのもで力説はしない。
力説するとしたら、その技法を使って作られた作品数だ。
147:デフォルトの名無しさん
11/07/03 17:38:27.10
最後がおかしい。
>力説するとしたら、その技法を使って作られた作品数だ。
それだったら普及してない言語はすべからくダメだろ。
その技法をつかって1つの作品を作るのに掛かった費用と期間だろ。
148:デフォルトの名無しさん
11/07/04 19:52:05.48
>>132
そもそも手続き言語覚え始めにx=2の次の行でx=3とか違和感ありまくりだったはずだと
149:デフォルトの名無しさん
11/07/04 20:00:26.33
>>148
俺も最初は違和感あったねえ、特に初めてBASIC触れたの小学生のときだったから
X = X + 1 が良くて X + 1 = X がダメな理由も分からなかった
左から右のほうがそれっぽいじゃん！とか思ってたw
150:デフォルトの名無しさん
11/07/04 20:46:57.44
俺、全く違和感なく受け入れてた
そもそも「言語の覚え始めの頃」という時期があったのかどうか
最初俺はベーマガとかプログラムポシェットのソースを読み上げる係だった
で、にーちゃんがそれを聞き取って、画面も見ずにひたすら打ち込む
にーちゃんが高校行ってからは、俺一人でソースを読んで打ち込んでた
そうこうしてるうちに、「こうプログラムすれば」->「こう動く」
という繋がりが頭の中にいっぱい作られた
何故それでできるのか、理由は置き去り
文法や理由を気にしだしたのは、ずーーーっと後のこと
> X = X + 1 が良くて X + 1 = X がダメな理由も分からなかった
そんな疑問、今の今まで思いつきもしなかった
お前等すげぇな
151:デフォルトの名無しさん
11/07/04 22:29:09.05
もしPCがイスラム圏で発明されていたらX+1=Xのほうが正しかったかもしれん。
152:デフォルトの名無しさん
11/07/04 23:12:55.45
アセンブラだとソースとデスティネーションの順序はどっちの流儀もあるわな
mov eax, 4
と
movl $4, %eax
とか
153:デフォルトの名無しさん
11/07/04 23:37:00.57
ASCIIは記号の数が少なすぎ
いい加減UNICODEでプログラミングしようぜ
⇒ とか ≠ とか使えるんだぞ。
154:デフォルトの名無しさん
11/07/04 23:41:40.76
問題は入力し辛いことだ
155:デフォルトの名無しさん
11/07/04 23:49:03.41
>>153
algol使え
156:デフォルトの名無しさん
11/07/04 23:51:47.87
あらこんなところに fortress が
157:デフォルトの名無しさん
11/07/04 23:59:21.29
APL再来
158:デフォルトの名無しさん
11/07/05 08:09:08.63
関数型が見直されてる理由がよくわからん。
副作用のデメリットなんて昔から言われてたし
昔と比べて関数型の生産性が上がってるとは思えないし。
159:デフォルトの名無しさん
11/07/05 08:21:27.49
>>158
マルチコアCPUの有効利用のためにマルチスレッド化が必須になって
手続型ではデバッグが難しくなったからではないでしょうか。
160:デフォルトの名無しさん
11/07/05 08:45:01.11
その割にはその方面で進展ないよね。
161:デフォルトの名無しさん
11/07/05 10:45:48.77
いや、手続き型の要素が多い言語でもSTMを採用し始めてる。
162:デフォルトの名無しさん
11/07/05 10:52:38.16
並列処理もあるかも知れんが、スクリプト言語に続いて、大手の手続き型言語も
クロージャの導入を計画したりしてるからその流れもあるんじゃね
163:デフォルトの名無しさん
11/07/05 12:34:57.46
>>158
インパクトの有るところでは、parl本家より何ヶ月も早く(当時)最新の仕様に準拠したparlインタプリタをhaskellで実装したのがきっかけだったような
164:デフォルトの名無しさん
11/07/05 22:59:41.02
JavaやC++でのクロージャの意義がわからん
165:デフォルトの名無しさん
11/07/05 23:03:38.19
C++でSTLのアルゴリズムのために関数オブジェクトを書いたことあったり
Javaでイベントハンドラ的なものを記述するためにいちいち匿名クラス書いたりしてる
んならクロージャのありがたみは分かるはず
166:デフォルトの名無しさん
11/07/05 23:03:58.99
>>164
イテレータとか書きやすくならね？
167:デフォルトの名無しさん
11/07/05 23:05:49.03
STMって関数型由来だっけ？
168:デフォルトの名無しさん
11/07/05 23:06:31.56
>>165
いや別に
169:デフォルトの名無しさん
11/07/07 11:22:58.89
>>167
元の論文"Software Transactional Memory"は言語に依存しない。
プログラミング言語で上手く扱う画期になったのが、
MSRの人たちが書いた"Composable Memory Transactions"
これはもちろんHaskellで取り扱ってる。
モナドの知識がSTMを扱う上で非常に役にたった。
170:デフォルトの名無しさん
11/07/07 21:36:13.20
Simon Peyton Jones ﾀﾝを MSR の人と呼ぶのは何か抵抗があるな...
171:デフォルトの名無しさん
11/07/07 21:49:35.63
>>170
Peyton
Pyton
Python
。。。なるほどな
172:デフォルトの名無しさん
11/07/07 23:35:48.37
ソフトウェアもアプリケーションも書かなくていいから、
楽に勤怠管理のシフトやエキスパートシステムこさえたい
173:デフォルトの名無しさん
11/07/08 00:00:24.88
>>170
けど実際そうだしなw
CLRべったりなことやっていたのは最初の一二年だけだったけど。
174:デフォルトの名無しさん
11/07/09 01:21:31.34
関数型言語もすっかり一般的になってしまったなあ
175:デフォルトの名無しさん
11/07/09 06:50:07.25
>>174
名前だけね
176:デフォルトの名無しさん
11/07/09 07:11:53.06
関数型っぽい言語なら沢山あるね
っぽい言語ならね
177:デフォルトの名無しさん
11/07/09 08:10:05.74
パソコンで使われるプログラムに限定すれば、もっともたくさんの実用的プログラムを作成してきた高級言語が関数型言語
理由は、yaccやJavaCCみたいなコンパイラコンパイラ言語は関数型言語だから
178:デフォルトの名無しさん
11/07/09 08:11:57.32
違うけど
179:デフォルトの名無しさん
11/07/09 08:39:44.87
yaccがHaskellみたいで、yacc がBNF(っぽいモノ)を採用してて、BNFのBackusが関数型言語の提唱者なのは偶然ではあるまい
180:デフォルトの名無しさん
11/07/09 08:40:40.09
宣言型と関数型の混同
181:デフォルトの名無しさん
11/07/09 09:07:39.28
yacc
・ファーストクラスの関数オブジェクトを持つ言語
・関数は副作用を持たない(持たせる方にテクニックが必要)
・参照透過性が保たれる
182:デフォルトの名無しさん
11/07/09 10:39:50.05
なんというか、関数型言語というカテゴリーが有名かどうかは
関数型プログラミングの考え方が浸透するかどうかに比べたら重要じゃないんじゃないか？
「Xは関数型言語だ」
として広く知られるよりも
「Xはプログラマがこういう性質を持つコードを書く手助けをするのでこういう風に楽ができる」
と広く知られて、それがまさに関数型プログラミングの利点なんだと広まる方が良さそうに感じるし
もっと言えば今プログラミングを学ぶ人がループや分岐を教わるときに
「構造化プログラミングだ！」と意識したりしないくらい浸透すれば言うことないと思う
183:デフォルトの名無しさん
11/07/09 11:51:43.42
「Xはプログラマがこういう性質を持つコードを書く手助けをするのでこういう風に楽ができる」
↓
「じゃあオブジェクト指向言語である○言語にもその機能を取り入れよう」
↓
「○言語に搭載されているXは関数言語由来なんだ」
↓
「だから教養知識として関数型言語を知っておくといいよ」
↓
「でも実際に使うのは○言語だけどね。使える人多いし、関数型言語と同じことできるし」
↓
「実際の開発ではフレームーワークやライブラリの数と質のほうが重要だからね」
184:デフォルトの名無しさん
11/07/09 12:04:08.69
参照透明性が必ず満たされていて、遅延評価を全く意識せず使える、
「オブジェクト指向言語である○言語」を実装したら次の書き込みをしてください。
それまで書き込み禁止ね。
185:デフォルトの名無しさん
11/07/09 12:27:40.13
>>183
もしそういう言語があるのなら、それのどこに問題があるの？
>>182の最後に書いたのはまさにそういう「関数型プログラミングとは何か？普段のやり方のこと」という状態
プログラミング言語の紹介で関数型言語だと書くのが
今「この言語にはなんと分岐とループ、そして驚くべきことにサブルーチンがあります！」と書くくらいスベる状態を「言うことない」と書いた
OOPもまだ到達してない地平だけど
186:デフォルトの名無しさん
11/07/09 12:52:56.46
> もしそういう言語があるのなら、それのどこに問題があるの？
問題はない。
ただ「実用的言語＋関数型の機能」 VS 「関数型言語 - 実用的な機能」
という比較になるのが現実だから
どうやっても関数型言語は普及しないってだけ。
関数型言語の機能が追加された実用的な言語としては
JavaやC#がある。
187:デフォルトの名無しさん
11/07/09 12:58:16.02
とりあえず
F#でOOPも使って書くコードの楽さ>>>>>>>>>>>>>>>>>>>>>>C#で関数型の機能も使って各コードの楽さ
なんだが。
より関数型的に書くならC#でかくのはCでOOPする並みに苦痛。
188:デフォルトの名無しさん
11/07/09 13:10:28.04
だから、参照透明性と遅延評価が実現できてるその「実用的言語」とやらが
どこにあるのか教えてくれよ。
189:デフォルトの名無しさん
11/07/09 13:30:36.01
オブジェクト指向と参照透過性は相性が悪い気が
190:デフォルトの名無しさん
11/07/09 13:37:17.87
>>188
Haskell
191:デフォルトの名無しさん
11/07/09 13:46:56.60
>>190
Haskellのどこがオブジェクト指向言語だ
192:デフォルトの名無しさん
11/07/09 14:16:35.16
>>188
参照透明性・・・引数の情報だけを使って処理を行えば良い。
遅延評価・・・ifを使って必要なときに処理をするロジックを書けばよい。
193:デフォルトの名無しさん
11/07/09 15:46:50.07
つまり、わかってません、ということですねわかります
194:デフォルトの名無しさん
11/07/09 15:53:23.60
int sum(int a, int b) {
return a+b;
}
と書けるからといってCの関数は参照透過性が保証されるとは言わないと思うが
>>186
「関数型言語－実用的な機能」は実用的な機能のない関数型言語だから、それだけでは関数型言語が流行らない説明にはならない
「ものが切れないステンレスのハサミより、ものが切れる鉄のハサミの方が売れるから、ステンレスのハサミは作っても売れない」と主張されたら、それはおかしいと感じるだろ？
ものが切れるステンレスと鉄のハサミで比較するか、ステンレスでは十分鋭い刃が（現時点の技術では、もしくは原理的に）製造できない根拠が必要じゃないか？
195:デフォルトの名無しさん
11/07/09 15:57:35.45
これだろ
URLﾘﾝｸ(d.hatena.ne.jp)
196:デフォルトの名無しさん
11/07/09 16:05:42.60
>>194
だから関数ごとに、参照透過性が保証されますって
ドキュメント残しておけばいいだけだって。
どうせ、参照透過性が保証された状態で、
やれることはどちらも変わらないのだから。
197:デフォルトの名無しさん
11/07/09 17:07:03.36
ドキュメントに書くだけじゃ型宣言は強制するのに型検査はしないようなもんだ
198:デフォルトの名無しさん
11/07/09 18:30:27.01
>>197
関数型言語だって、副作用をもたらす関数は作れるわけで、
参照透過性を強制してないじゃん。
結局はドキュメントでしょ？
199:デフォルトの名無しさん
11/07/09 18:45:04.60
副作用をもたらす関数は、特別な型を強制される
200:デフォルトの名無しさん
11/07/09 18:49:25.98
>>199
その関数を使う関数は、普通の関数になるから
あまり意味はない。
201:デフォルトの名無しさん
11/07/09 18:52:46.64
>>184
関数型言語である事と遅延評価を自然に使える言語である事は必ずしも一致しないんじゃないの
202:デフォルトの名無しさん
11/07/09 19:09:31.06
>>200
関数型言語では、そうはならない。
203:デフォルトの名無しさん
11/07/09 19:15:26.61
あと 参照透明性と関数型言語であることも関係ないな。
ようは副作用をもたらさない関数には
特殊なアノテーションを付けるようにして、
副作用をもたらさない関数から呼び出せる関数は
アノテーションがついている物だけとすればいいわけだし。
関数はstatic限定にする必要があるね。
204:デフォルトの名無しさん
11/07/09 19:46:50.68
>>198
作れるけど、そういう部分は他とは違って見えるし、検査も行える
Cでコメントや別のファイルに「この関数は副作用を持たない」と書いた所で、それを守らなくても何も起きない
逆に副作用を持たない関数に副作用を持たないことを書き添え忘れても何も起きない
デフォルトは「副作用を持つかもしれないし、持たないかもしれない。副作用について誰も関知しない」だから
ドキュメントを書くことが求められるけど、書いたことを守っても守らなくても（または現状を正しく書いても間違って書いても）自分がやったことに気付くマークがない
だから「型宣言は強制するけど型検査はしない」ようなものだと書いてる
>>203
それはD言語のpureキーワードそのもの
逆の方が付け忘れた時の挙動が親切だが、FFIを考えるとそうなるな
205:デフォルトの名無しさん
11/07/09 23:25:53.15
>>204
> だから「型宣言は強制するけど型検査はしない」ようなものだと書いてる
分かりにくい。
「動的言語みたい」でいいだろｗ
206:デフォルトの名無しさん
11/07/10 00:20:36.21
>>205
動的言語は実行時に型検査するけど
Cは副作用についてコンパイル時にも実行時にも検査しない
207:デフォルトの名無しさん
11/07/10 01:16:14.01
Haskellばんざーい、MLはゴミだな
208:デフォルトの名無しさん
11/07/10 01:32:58.61
Cの関数に副作用があったときコンパイル時に確認するのって簡単に仕様拡張出来るよね？
なんでやらないんだろう
209:デフォルトの名無しさん
11/07/10 01:36:46.22
C: "We trust in you, programmers."
210:デフォルトの名無しさん
11/07/10 01:49:51.83
>>208
簡単じゃない。
211:デフォルトの名無しさん
11/07/10 02:28:32.54
>>172
1.メモ帳を開き"意見書"とタイトルを打ちます
2.希望の勤怠管理シフトデザインを入力し文書化します
3.上司の高田課長に提出します
4.高田課長から、篠原部長、織田常務、杉下社長まで承認が通るのをまちます
5.承認経路から与えられた管理者、総務の小杉に勤怠管理計画を提出します
6.新規勤怠管理計画始動のメールを社内全体に送信します
7.定期的な改訂、調査を行い今後の改善をしていきます
終わり
212:デフォルトの名無しさん
11/07/10 02:37:48.29
>>208
#define int const int
#define char const char
・
・
・
略
213:デフォルトの名無しさん
11/07/10 07:02:24.30
今時の関数型と云々するやつは、どれも、真の関数型じゃない
214:デフォルトの名無しさん
11/07/10 07:12:24.94
真の関数型とかどうでもいいけど、currying がない言語は使う気がしない
215:デフォルトの名無しさん
11/07/10 07:34:02.68
>>210>>212
このレベルなのか・・・
216:デフォルトの名無しさん
11/07/10 11:09:21.56
そんなに簡単ならすぐに実装してくださいよw
217:デフォルトの名無しさん
11/07/10 12:11:08.95
curryingとpartial application(section)の混同される例は多い
カレーかや部分適用語るなら圏論におけるExponentiatioonまでは知っとけよ
218:デフォルトの名無しさん
11/07/10 12:28:20.57
>>216
>>204の最後にあるじゃん・・・
219:デフォルトの名無しさん
11/07/10 12:44:57.23
>>218
Cはconstがちょっとアレなんで、Dと違って下位互換性ある形では
少々難しいかと
例えば以下のbの値はa経由で変更できる
int a = 0;
const int *b = &a;
printf("%d\n", *b); // 0
a = 1;
printf("%d\n", *b); // 1
マルチスレッドの場合、関数に渡したbが内部処理中に
別のスレッドによって変更されない保証ができない
まあ、副作用の無い関数にはポインタ変数渡せないようにするとか
方法はありそうだが
220:デフォルトの名無しさん
11/07/10 13:13:27.27
解決できてるやん
221:デフォルトの名無しさん
11/07/10 13:34:28.07
const int const*とか無かったか
222:デフォルトの名無しさん
11/07/10 13:56:29.71
const int* const b = &a とかしても一緒
こうすると b 経由では *b も b も変更できなくなるけど
a 経由で*bを変更できるのは変わらない
223:デフォルトの名無しさん
11/07/10 14:23:47.70
Cのpointer aliasingの問題は素人が考えるよりずっと複雑。
配列や再帰データ構造が絡んだだけで、ほぼ解析不能になる。
224:デフォルトの名無しさん
11/07/10 14:42:31.15
だからポインタ使わなきゃいいって
225:デフォルトの名無しさん
11/07/10 14:46:18.09
>>224
つまり、文字列を引数に取る関数はどうすればいいのでしょうか？
226:デフォルトの名無しさん
11/07/10 14:46:38.64
そんなのCじゃねえ。
strcmpすら使えん。
227:デフォルトの名無しさん
11/07/10 14:48:38.89
restrict
228:デフォルトの名無しさん
11/07/10 14:50:30.55
関数型のスレで何いってるんだ・・・
229:デフォルトの名無しさん
11/07/10 14:51:34.61
>>225
230:デフォルトの名無しさん
11/07/10 15:02:31.12
>>227
restrictは違反したら未定義動作になるけど
エラーになるわけじゃないからなぁ
231:デフォルトの名無しさん
11/07/10 15:04:45.28
お前らC素人なんだから無理すんな
232:デフォルトの名無しさん
11/07/10 18:14:28.80
ポインタ抜きでCを使って何をしようと言うんだ
233:デフォルトの名無しさん
11/07/13 20:28:11.05
配列については、ポインタ使わず、戻り値を構造体にすれば、大体は凌げるとは思うが、
問題はループだよな。副作用抜きなら再帰しか無いわけだし、末尾最適化に祈るしか無い。
234:デフォルトの名無しさん
11/07/13 21:25:57.66
fold系を言語レベルでサポートしてやれば割と何とかなりそうじゃね？
235:デフォルトの名無しさん
11/07/14 00:52:39.96
>>233
あほだろ
236:デフォルトの名無しさん
11/07/14 07:41:51.56
>>233
配列の代わりにポインタのない構造体を使うってのはつまり型と要素数毎に
struct int3 {
int item1;
int item2;
int item3;
}
などを定義するってことか？馬鹿馬鹿しい
それで何かが良くなるとも思えないし、むしろ悪くなってるように見える
副作用を認めないと再帰しか認められないというのも正しくない
forやwhileによるループの表現力に影響するのは副作用の制限ではなく再代入の制限
237:デフォルトの名無しさん
11/07/14 07:53:13.06
アホか
構造体にくるめば、関数の引数や戻り値として、配列を、その先頭を指すポインタではなく、
中身まるごと値としてやりとりできるから、ってことだろ。わかりづらいが
238:デフォルトの名無しさん
11/07/14 07:56:49.95
いや、再代入は副作用だから正確な表現じゃないな
for (i = 0; i < len; i++) { ... }
という文はiに再代入しているが、この文が含まれる関数が外側から見て参照透過性を壊すとは限らないという意味
239:デフォルトの名無しさん
11/07/14 08:15:47.36
>>237
その方法も配列のサイズを宣言時に決めないといけないんじゃないか？
240:デフォルトの名無しさん
11/07/14 09:00:48.03
サイズ可変のベクタを渡したり返せるとか誰か言ってるか？
「だいたいは凌げる」の「だいたい」にそれは入らないってだけだろ。
241:デフォルトの名無しさん
11/07/14 09:22:15.69
内部実装くらい理解してくれ
242:デフォルトの名無しさん
11/07/14 09:23:16.36
具体的に頼む
243:デフォルトの名無しさん
11/07/14 11:12:12.70
配列を返り値でコピーするのか? ﾜﾗ
244:デフォルトの名無しさん
11/07/14 11:34:50.03
必要ならそうするさ
できるんだし
245:デフォルトの名無しさん
11/07/14 11:36:49.28
他の関数型言語のコードからCのコードへの
トランスレータ書いた方がマシなレベル
246:デフォルトの名無しさん
11/07/14 12:15:51.50
まあそういう結論になるわな
247:デフォルトの名無しさん
11/07/14 12:17:05.17
>>244
1960年代に逆戻りだな。
248:デフォルトの名無しさん
11/07/14 12:42:13.49
>>245 実際昔の GHC は（今でもターゲットによってはそうかな？）そういう実装だったし、
Stalin や Chicken という Scheme コンパイラはそれぞれの理由で C のコードを吐くけど、
基本的に人間が書くようなのとは全く別物のコードになるから、全然話が違うと思う。
>>247 どこが？
なんでも値全体をコピー、なんてのはむしろ最近の発想だと思うが。
PHP で配列を参照渡しじゃなくて普通に渡した時とか。
ていうか基本的にGCとかないCでやろうというのが無謀で、もうちょっとなんとかなる
言語でやろうよ、とは思うけど。
249:デフォルトの名無しさん
11/07/14 22:34:49.23
>>247
これははずかしい
250:デフォルトの名無しさん
11/07/14 22:36:36.23
このスレのレベルはこんなもんです
251:デフォルトの名無しさん
11/07/14 23:13:27.67
PHPとかw
252:デフォルトの名無しさん
11/07/14 23:14:16.93
な？
253:デフォルトの名無しさん
11/07/19 06:24:42.44
なんだって～
254:デフォルトの名無しさん
11/07/20 22:23:00.00
>>243
RVO効く環境なら引数で配列取るのと同等の速度が出るけどな。
255:デフォルトの名無しさん
11/07/21 12:09:25.56
ミーハーにも関数型言語に興味持ったんだが、
素人がわかりやすく勉強するには、どの言語＋ドキュメントが良いでしょうか？
Lispで階乗書いて、それから先が進まない程度のレベルなんですが。
256:デフォルトの名無しさん
11/07/21 12:25:29.76
>>255
プログラミングhaskellが入門者向けの内容で、薄くて良いよ
257:デフォルトの名無しさん
11/07/21 12:32:25.72
>>256
早速ありがとうございます。
258:デフォルトの名無しさん
11/07/21 12:50:15.23
lispはｵﾜ関
259:デフォルトの名無しさん
11/07/30 01:49:21.08
URLﾘﾝｸ(cufp.org)
こんなの見つけた
誰か行く人いる?
260:デフォルトの名無しさん
11/09/26 19:28:15.85
関数型言語のデフォルトスタンダードってなに？
261:デフォルトの名無しさん
11/09/26 19:40:51.26
>>260
> デフォルトスタンダード
【審議中】
∧,,∧ ∧,,∧
∧ (´・ω・) (・ω・｀) ∧∧
( ´・ω) Ｕ) ( つと ﾉ(ω・｀ )
｜ Ｕ ( ´・) (・｀ ) と ﾉ
ｕ-ｕ （l ) ( ﾉu-ｕ
`ｕ-ｕ'. `ｕ-u'
262:デフォルトの名無しさん
11/09/26 20:11:30.94
全く、それを言うならディフェンドスタンダードだろうが
263:デフォルトの名無しさん
11/09/26 20:18:30.76
真面目に言うとデファクトリ・スタンダード
264:デフォルトの名無しさん
11/09/26 21:03:36.71
de factoとか英語ですらないじゃないか・・
265:デフォルトの名無しさん
11/09/27 01:14:55.21
>>260
デファクトスタンダードなら、Haskellがそのために作られた。
実用的な汎用言語であるとともに、関数型言語の可能性を研究する目的で作られてる。
266:デフォルトの名無しさん
11/09/27 07:13:57.12
どのような目的で作られたかは関係なくて
どれが一番多く使われているかだろうがボケ
267:デフォルトの名無しさん
11/09/27 07:26:35.95
あなたがそう思うものがそうです。
ただし他人の同意を得られるとは限りません。
268:デフォルトの名無しさん
11/09/27 10:42:32.21
>>265
> デファクトスタンダードなら、Haskellがそのために作られた。
これはイギリス内の話です。念の為。
フランスにはOCaml派がいますし、
世界各地にSML派がいます。
269:デフォルトの名無しさん
11/09/27 11:56:45.85
schemeェ・・・
270:デフォルトの名無しさん
11/09/27 11:58:35.55
デファクトスタンダードがあるとすれば Common Lispなんじゃないの？
僕はHaskellとSchemeしかやってないけど。
271:デフォルトの名無しさん
11/09/27 12:03:42.42
ないない
272:デフォルトの名無しさん
11/09/27 17:46:25.69
Lispはもう関数型言語に数えるのなしにしようぜ
273:デフォルトの名無しさん
11/09/27 17:56:37.66
まぁ、手続き型言語にもデファクト・スタンダードなんかないしな。
かつてはCがそれに近かったが、いまは違うだろう。
274:デフォルトの名無しさん
11/09/27 18:31:15.48
でも、書籍のアルゴリズム紹介のときはCで書くのが圧倒的かな。
JAVAもかなり多いが。
洋物ならPythonとか。
まあ、Cバリアントは非常に多いから。細かい部分はおいておけば、
Cを理解できないプログラマ等はかなり少ないと思う。
研究者なんかだとMATLABしか理解できないって人は実際にいたが。
275:デフォルトの名無しさん
11/09/27 19:17:37.96
C++11 は関数型言語の要素が入ってきたから今後はこれがデファクトスタンダードになるんじゃね？
276:デフォルトの名無しさん
11/09/27 19:22:37.46
それはない。
277:デフォルトの名無しさん
11/09/27 22:09:39.28
ラムダごときで関数型なら大半が関数型だわ。
それは別として、C++のテンプレートは関数型。
あとXSLTも関数型。
278:デフォルトの名無しさん
11/09/27 23:35:24.24
なんでわざわざ「関数型の考えを取り入れた」なんて言うんだろ
単に、＊＊という新機能・新構文を加えた、だけでいいと思うが
その方が何ができて何ができないかが明確に分かる
関数型の考えが取り入れられた言語を使ってる人たちの大半は、
そもそも関数型ってどういうものか実際のところ理解していない
ならば、関数型の考えを取り入れたと言ったところで、
なんだか凄いという曖昧な印象しか持ち得ない
279:デフォルトの名無しさん
11/09/28 00:11:18.27
それお前
280:デフォルトの名無しさん
11/09/28 01:22:56.68
>>278
＞なんだか凄いという曖昧な印象しか持ち得ない
それが狙いなんじゃないの？
すごそうだから使ってみようって思ってもらうためのキャッチコピー。
281:デフォルトの名無しさん
11/09/28 04:47:41.88
手続型等に「関数型の考えを取り入れました」
なんて言われると、まるでマルチパラダイムこそ素晴らしく
「単なる関数型に勝る」という意味合いが含まれるな。
あ、でも実際そうなのか
282:デフォルトの名無しさん
11/09/28 07:12:16.38
>>280
言語開発者がそう言って宣伝するのなら分かる
が、たいていは記者がそう言っている
マルチパラダイムを大々的に宣伝してるのも、
言語開発者じゃなくてIT系の記者
283:デフォルトの名無しさん
11/09/28 10:01:26.13
ある言語が関数型であるか否かを判断できる基準はあるかな？たとえば、
(1) 条件判定式(if/case式)がある
(2) 局所宣言式(let/where式)がある
(3) 末尾再帰の最適化
これらすべてを満たせば、大半の人には関数型であると同意してもらえると思う。
ML/Haslell/Schemeはすべて満たすから文句無し。(ただしLispは(3)がNG？)
Smalltalk/Rubyは(1)のみで、Python/JavaScriptは全滅だから関数型とは認められない。
284:デフォルトの名無しさん
11/09/28 10:22:01.57
>>283
まずはクロージャーがあるかどうかだろう。
Cは関数ポインタがあるが、クロージャーはないので、関数型言語ではない(GCC拡張ならある)。
でも、JavaScriptと(2)については、スコープを任意につくるためにfunction(){ ... }();とかやる方法が定着している。
キモイけど。
285:デフォルトの名無しさん
11/09/28 10:44:11.96
funarg問題的にみて、あれ（GCC拡張）は外に持ち出せないからいかにも中途半端。
C言語の枠内で可能な限りのことをやってみました、という点では非常に面白いのだが。
286:283
11/09/28 11:28:52.95
>>284
>まずはクロージャーがあるかどうかだろう。
関数型言語を特徴付ける基準にはいくつかあって、クロージャはその一つだと思う。
でもSmalltalk/Rubyならブロックがあるから、関数型か否かを決める境界線(判断基準)としてクロージャは
弱いんじゃないかと考えて落とした。(他にラムダ式も同様の理由で判断基準から落とした。)
>でも、JavaScriptと(2)については、スコープを任意につくるためにfunction(){ ... }();とかやる方法が定着している。
これは無名関数を定義してからすぐ呼ぶことで、関数定義内の局所式(... の部分)を評価しているんだね。
確かに結果的には局所宣言式になるプログラミング技法だけど、言語要素としては実現されていないから
判断基準としてはNGになると思う。同じ事はRubyでも proc { ... }.call と書ける訳で、これをOKとは認めたくない。
287:283
11/09/28 11:37:42.50
JavaScriptについて、Firefox(JavaScript 1.7)ではlet式がサポートされたらしいから、
局所宣言式の基準(2)は限定付きでOKかも。
288:デフォルトの名無しさん
11/09/28 11:39:51.65
Smalltalk/Ruby/Python/JavaScript を関数型と認めない、という
ゴールが先にあって、そこから定義を逆算してるのか？
289:デフォルトの名無しさん
11/09/28 11:54:49.68
それもそれで一つの手ではあるな
290:283
11/09/28 12:02:01.58
>>288
そういうことになるね。
>>288の言語は(程度の差はあるけれど)どれも関数型プログラミングができる。
ここで関数型プログラミングというのは、副作用(破壊的代入や入出力)を極力抑えたプログラミング技法。
ただし、それはあくまで「関数型プログラミング技法」であって「関数型言語」ではない、という考え方。
では境界線をどこに引くべきか？と考えて残ったのが、>>283の「３項目をすべて満たす」という条件。
291:デフォルトの名無しさん
11/09/28 12:34:38.98
>>283が関数型言語の要件だというなら、プログラミング言語が関数型であるか否かなど瑣末なことだな
292:283
11/09/28 13:06:08.88
整理してみた。大きく３つのグループに分類できる。
・関数型言語(誰も文句無し)
・関数型プログラミングが可能な言語
・それ以外の手続き型言語
Haskell
---- 壁1. 純粋性(副作用)の壁 ----
SML/OCaml
---- 壁2. 型推論の壁 ----
Scheme
---- 壁3. 末尾再帰最適化/局所定義式の壁 ----
========<< 越えられない壁 >>========
Smalltalk/Ruby
---- 壁4. 条件判定式の壁 ----
Python/JavaScript
---- 壁5. クロージャ/ラムダ式の壁 ----
========<< 越えられない壁 >>========
C/C++/Java/Perl...etc
293:デフォルトの名無しさん
11/09/28 13:06:35.19
いや、>>283の三点は関数型言語の基準としてはどうかとは思うが、瑣末なことではないとは思う。
294:デフォルトの名無しさん
11/09/28 13:11:03.51
proper tail call と書いてくれ。意味が明確になるから
295:デフォルトの名無しさん
11/09/28 13:46:33.23
Python 2.5でif式（三項演算子）が入ってる
296:デフォルトの名無しさん
11/09/28 15:51:15.70
wikipediaにある定義では
「ファーストクラスの関数オブジェクトを持つ言語」ってのがある。
関数へのポインタしか使えないとかなら明確に違うとは言えそうだけど。
297:デフォルトの名無しさん
11/09/28 16:10:48.13
λ計算とβ簡約が鍵とか思ってたら、違う分類でござった。
しかも間違いだらけ…。
298:デフォルトの名無しさん
11/09/28 16:13:01.13
Perlの無名関数はラムダとして認められないの？
299:デフォルトの名無しさん
11/09/28 16:47:05.74
Pythonはデコレータを使えば末尾再帰の変換もできる
300:283
11/09/28 17:09:22.56
>>295
確かにif式はあるけど、Pythonのif式ってすごく特異というか汚い構文ですよね。
value = then_value if predicate else else_value
たとえば条件判定がネストした処理をコード化した場合、SMLだと
val value =
if x == 0 then (
if y == 0 then
1
else
2
) else (
.... 省略 ....
)
同じ処理をRubyなら
value =
if x == 0 (
if y == 0
1
else
2
end
) else (
.... 省略 ....
)
と、ほぼ類似のコード構造で、しかも適切なインデントで記述できます(=可読性のある記述ができる)。
SchemeとSmalltalkは構文が異なりますけど、これらの言語でも適切なインデントでコード化できます。
でも、このPhytonの構文だと、(自分の知識では)可読性のあるコードが書けないと思います。いかがでしょうか？
301:283
11/09/28 17:25:40.87
>>298
失礼、自分のPerl学習はPerl 4で止まっていました。(Perl 5のOOPがアレなのでRubyへ移行した為...)
Perlの無名関数はラムダ式です。>>283は誤りで、PerlはPython/JavaScriptと同じグループに入れるのが適切です。
>>299
いいかえると、Pythonはデコレータを(コーダが意識的に)使わなければ末尾再帰が最適化されない、ということです。
真の関数型言語であれば、言語処理系(インタプリタ)が自動的に判断して最適化処理が実行されるべきでしょう。
また、Rubyでも同様のプログラミング技法を用いれば末尾再帰の最適化が行えるようなので、Pythonと大差ありません。
・Rubyで末尾再帰最適化をする。 - athosの日記
URLﾘﾝｸ(d.hatena.ne.jp)
302:デフォルトの名無しさん
11/09/28 17:58:41.36
そもそも言語を比較してるのか処理系を比較してるのかハッキリしろよ
言語仕様として末尾再帰最適化を必要条件にしてるのはSchemeくらいだぞ
303:デフォルトの名無しさん
11/09/28 18:40:56.50
>>301
そこらのプログラム変形によるものはぜんぜん proper じゃないし、
下手するとスレッドセーフ（再入可能）どころか再利用可能ですらなかったりする。
>>302
逆に、言語仕様で末尾再帰最適化をうたってるのは Scheme ぐらいだけど、
ML や Haskell の言語仕様であれば、末尾再帰最適化はそんなに困難じゃないので。
（Cとかは、特に相互再帰の場合は不可能）
304:283
11/09/28 18:44:52.73
>>302
スマンけど、言語仕様(構文)と処理系(実装)とを一緒にして比較基準とさせてください。
手続き型言語のループ(反復)が、関数型言語ではすべて再帰として表現されるということは常識だと思います。
たとえば1万回のループは1万回の再帰呼び出しになる訳で、もしも1万回の再帰呼び出しくらいで
スタックオーバーフローが発生するようでは、真の関数型言語処理系として使い物にならないと断言します。
実際、普及しているHaskell/SML/OCamlの「実用的な言語処理系」は、すべて末尾再帰の最適化を実装しているハズ。
>>283の判断基準は(ソフトウェア開発の現場における)実用性という観点で選んでいます。
理論的/学術的には不正確なものだと思いますが、こういう基準もあると理解を願います。
もちろん全く別の切り口で判断基準を選んで提案してもらえれば、それはそれで大いに歓迎します。
305:デフォルトの名無しさん
11/09/28 19:00:55.36
だから proper tail call を無視すんなと。
あと lambda がない関数型言語なんてありえないから。
そして lambda が、「(ソフトウェア開発の現場における)実用性」とつながるかどうかは
俺は全く知らんが。
あるいは ML はいざとなったら副作用でプログラミングできることが、
「(ソフトウェア開発の現場における)実用性」として結構高く評価されているように
感じるのだが、そうすると「(ソフトウェア開発の現場における)実用性」で評価するのは、
Haskell を落とす結果につながると思うのだがどうか？
306:デフォルトの名無しさん
11/09/28 19:05:57.44
めんどくさい奴だなー
オレオレ基準なんてどうでもいいよ
307:デフォルトの名無しさん
11/09/28 19:18:56.39
Haskell の場合、たいていのコンパイラは
末尾再帰を、スタックを消費しない形へ自動的に変換してくれるが、
それが「最適化へと繋がるか」というと、必ずしもそうではない
他言語ならまず間違いなく処理速度もメモリ消費量も最適化へと導かれるが、
Haskell の場合は「それがどう遅延評価されるか」をちゃんと意識しないと、
末尾再帰の処理が最適化へと繋がるか自信を持って言えない
308:デフォルトの名無しさん
11/09/28 19:22:34.24
>>283
そもそも、ある言語が関数型であるか否かを判断する「理由」はなに？
関数型であるか否かを判断する必要があるのってどういう場合？
309:デフォルトの名無しさん
11/09/28 19:29:07.88
>>307
同じ末尾再帰なら、スタックを消費するより消費しない方が良いに決まってるだろ
310:283
11/09/28 19:29:30.30
>>305
>あと lambda がない関数型言語なんてありえないから。
これは当然ですね。>>286で書いたように、ラムダ式/クロージャの概念は非関数型言語でも導入が進んでいるので、
ある言語が関数型か否かの判断基準(境界線)としては弱いと考えて除外したにすぎません。
>そうすると「(ソフトウェア開発の現場における)実用性」で評価するのは、
>Haskell を落とす結果につながると思うのだがどうか？
Yesです。いわゆる一般的なソフトウェア開発現場に(正規順評価を用いる)Haskellは普及しないであろうと予測していますし、
少なくとも自分であれば現場には(作用順評価を用いる)ML族の導入を選びます。
311:デフォルトの名無しさん
11/09/28 19:32:54.94
>>292
Haskell
---- 壁1. 純粋性(副作用)の壁 ----
SML/OCaml/C++11
---- 壁2. 型推論の壁 ----
Scheme
---- 壁3. 末尾再帰最適化/局所定義式の壁 ----
========<< 越えられない壁 >>========
Smalltalk/Ruby
---- 壁4. 条件判定式の壁 ----
Python/JavaScript
---- 壁5. クロージャ/ラムダ式の壁 ----
========<< 越えられない壁 >>========
C/C++/Java/Perl...etc
312:デフォルトの名無しさん
11/09/28 19:46:26.26
なんやねん正規順評価って
日本語版SICPで使ってるようなキモイ無理やり訳した日本語使わんと普通に正格/非正格って言えばいいじゃない
313:デフォルトの名無しさん
11/09/28 20:23:27.69
>>307 が言ってるのは一時期山本さんがこだわってた余再帰の話だろ。
最近、余再帰と言うのも厳密には違ってたという話があったかもしれないがそれはともかく。
末尾呼び出しになるように手でコードを変形すると、引数に蓄積するように
なるけど、そういうことすると Haskell じゃ効率悪いかもよ、って話でしょ。
それはそれで正しいけど、そのことは proper tail call がちゃんと tail call elimination されるか
どうかという話にはかかわってこない。
314:283
11/09/28 20:33:17.09
>>308
正直言って、あまり考えていないです。
「「分ける」こと「わかる」こと」という分類学の本(講談社学術文庫)がありますけど、
関数型であるか否かを考えることで関数型言語とは何かを理解しようとしているだけです。
あえて言えば、局面に応じた言語の使い分けですね。
デフォはRuby、でもここはSMLでも書き直そう、ただここだけはHaskellのほうが直感的に書ける....というふうに。
315:デフォルトの名無しさん
11/09/28 21:23:56.47
>>314
> あえて言えば、局面に応じた言語の使い分けですね。
実用的な観点で分類をしようとしているそうだが、
> デフォはRuby、でもここはSMLでも書き直そう、ただここだけはHaskellのほうが直感的に書ける....
そのような細かな粒度で使用言語を切り替えることが本当に実用的なのか、
もう一度よく考えてみた方がよくないか
そのようなことをしていて本当に生産性や保守性が高まるの？
（というか、今まで実際に高まった？）
そんなことよりも、言語はある程度柔軟性のあるひとつのものに決めておいて、
その上で、ここで関数型の考え方を応用すれば問題をエレガントに解決できないか、
関数型の方で解決した事例の方法論がここでも使えないか、
それともここはオブジェクト指向の＊＊で考えた方が解決できそうか、
と考える方がよほど実用的だと思う
そう考えれば、何かの機能がデフォルトで使えるかどうかで分類するより、
関数型の方法論が流用し易いか、手続き型の方法論が流用し易いか、
という観点で分類した方がいいんじゃないのか
316:デフォルトの名無しさん
11/09/28 21:24:28.67
>>311
C++にくっついてるテンプレートという言語は純粋性の壁の向こうに居るでしょ。
モナドすら無いんだぜ。
317:283
11/09/28 23:24:02.75
>>315
関数型言語に対するアプローチは人それぞれ色々とあっていいと思います。
ただし、もしも最初に言語を決めて方法論を選ぶということであれば、自分の場合はRubyで決まりです。
SMLは片手間に半年ほど前から触り始めたにすぎず、
ようやく数Kstepほどのコードが書けるようになった程度の経験しかありませんから。
今はSMLの学習で得た関数型設計法/プログラミング技法をRubyソフトウェア開発へ反映させているところ。
現状の成果物(Rubyコードだけ、設計書は準備中)を以下の場所に置きました。
URLﾘﾝｸ(www.h6.dion.ne.jp)
(正式リリースではないので、この文書はホームページからはリンクを張っていません)
簡単にコードを解説すると、コード中のtransformer/下のモジュール群は純粋な関数定義で、
model/下のクラス群が抽象データ型定義です。
またtmstd/lsm下のLSMクラス群は、直積/直和/集積(列/集合/写像)という関数型データ構造を表現しています。
318:デフォルトの名無しさん
11/09/29 00:39:55.69
「問題を解決する為に数学的な関数を構築する」
これをするプログラミング言語が関数型言語であり、これが本質です
それ以外の末尾再帰最適化や条件判定式、局所宣言式など諸々は全て、
個々のプログラミング言語が個々の目的の為に加えた飾りです
IOへのアクセス手段も、外部ライブラリへのアクセス手段も飾りです
それが実用かどうかは、関数型言語かどうかとは一切関わらない別問題です
100%この本質だけでプログラミング言語が作られている訳ではもちろんありません
ですが、基本理念としてこの本質を据え、その上でこの本質が活きるよう、
できるだけ壊さないよう、実用や教育（や遊び？）といった目的に応じて飾りが加わります
本質を忘れると、本質を活かすように加えられた飾りを上手く活用できません
本質を忘れると、馬鹿な考えに至ったり、関数型プログラミング言語で問題を解決することが
非常に困難になります
「関数型の特徴を取り入れた」と一般的に言っているのは本質を忘れた馬鹿な発言のいい例です
それは、ある複数の関数型プログラミング言語が共通して持つ「便利な飾り」を、
取り入れ先のプログラミング言語に合うように仕立て直したというだけのことです
本質を考えれば、関数型言語としての特徴を取り入れた訳では全くないことが分かります
319:デフォルトの名無しさん
11/09/29 03:41:23.36
最近正式に仕様が承認されたC++11はラムダ式がある
320:デフォルトの名無しさん
11/09/29 08:25:05.48
ラムダ式だけあれば原理的には整数さえなしで計算が出来るわけだが、
本質云々で便利な飾りを無視するのはちょっとアレだろ。
321:デフォルトの名無しさん
11/09/29 08:50:49.90
本質だけ残したらLazy-Kみたいになるぞ
322:デフォルトの名無しさん
11/09/29 09:07:34.98
計算さえできればいいなら型なしになるだろうが、そりゃないよな今時
323:デフォルトの名無しさん
11/09/29 11:33:38.23
>>292
一番上にFP加えてくれ。
324:デフォルトの名無しさん
11/09/29 11:37:01.25
Proper tail callはメッセージパッシングスタイルの言語の特徴。
もともとACTORの研究から生まれた。
325:デフォルトの名無しさん
11/09/29 11:38:48.85
schemeのラムダ論文？
326:デフォルトの名無しさん
11/09/29 12:35:23.89
> 100%この本質だけでプログラミング言語が作られている訳ではもちろんありません
> ですが、基本理念としてこの本質を据え、その上でこの本質が活きるよう、
> できるだけ壊さないよう、実用や教育（や遊び？）といった目的に応じて飾りが加わります
この文章を意図的に無視して意見する方達ばかりで残念です
327:デフォルトの名無しさん
11/09/29 12:46:14.02
門外漢だがその理念の正当性はオーソライズされてんの？
328:デフォルトの名無しさん
11/09/29 12:58:29.17
本質という名のバズワード
329:デフォルトの名無しさん
11/09/29 13:18:10.38
>>326
十分レス着いてると思うが。。。(>>320-321)
欲張りだなぁ。。。
330:デフォルトの名無しさん
11/09/29 15:26:54.48
>304
OCamlってforもwhileもあるんだけど
URLﾘﾝｸ(caml.inria.fr)
331:デフォルトの名無しさん
11/09/29 15:41:34.91
>>326
駄文なんで読んでなかったよ。
332:デフォルトの名無しさん
11/09/29 17:15:41.79
>>330
OCamlさんってそんな人だったんだ…
もう信じられるのはHaskellだけです
333:デフォルトの名無しさん
11/09/29 17:28:32.09
純粋な人やね
334:283
11/09/29 18:17:12.26
>>298,323
FP
---- 壁0. 変数の壁 ----
Haskell
---- 壁1. 純粋性(副作用)の壁 ----
SML/OCaml/C++11
---- 壁2. 型推論の壁 ----
Scheme
---- 壁3. 末尾再帰最適化/局所定義式の壁 ----
========<< 越えられない壁 >>========
Smalltalk/Ruby
---- 壁4. 条件判定式の壁 ----
Perl/Python/JavaScript
---- 壁5. クロージャ/ラムダ式の壁 ----
========<< 越えられない壁 >>========
C/C++/Java...etc
335:283
11/09/29 18:22:33.58
>>334を訂正
X: SML/OCaml/C++11
O: SML/OCaml
336:デフォルトの名無しさん
11/09/30 20:14:01.41
条件判定式の壁ってのが相変わらず分からん
337:デフォルトの名無しさん
11/09/30 20:37:39.92
条件式があるかどうかみたい。
それが壁になるかどうかわからんが。
338:デフォルトの名無しさん
11/09/30 20:51:28.13
: ? の中に文が書けるかどうか、で分けてるのかな
339:283
11/09/30 21:23:04.77
>>336-338
条件判定が式として自然な形でコード化できるよう言語が設計されているか否か？という意味です。
誰もが関数型言語だと認める言語(>>334の最上段)であれば、当然これを満たしています。
Perl/Python/JavaScriptは条件判定(ifやcase)が(式ではなく)文として定義されているのでNGになります。
Pythonについては、if式はあるけれど「実用性に欠ける」設計であると判断しました。(>>300を参照)
もし value = if predicate ":" then_value else else_value という構文であればOKにしたかったのですが....。
# あくまで「俺様流判定基準」なので、納得いかないという意見が多々あることは承知してます
340:283
11/09/30 21:23:28.76
>>336-338
条件判定が式として自然な形でコード化できるよう言語が設計されているか否か？という意味です。
誰もが関数型言語だと認める言語(>>334の最上段)であれば、当然これを満たしています。
Perl/Python/JavaScriptは条件判定(ifやcase)が(式ではなく)文として定義されているのでNGになります。
Pythonについては、if式はあるけれど「実用性に欠ける」設計であると判断しました。(>>300を参照)
もし value = if predicate ":" then_value else else_value という構文であればOKにしたかったのですが....。
# あくまで「俺様流判定基準」なので、納得いかないという意見が多々あることは承知してます
341:283
11/09/30 21:24:31.67
二重カキコスマソ
342:デフォルトの名無しさん
11/09/30 21:32:37.30
>>340
俺様流判定基準をここで披露するのはなぜ？
ただのチラ裏とは違うの？
納得いかないという意見が多々あることは承知してますと言うけど、
別の基準や切り口を提案しても「アプローチは人それぞれ」で話を終わらせてるよね
343:デフォルトの名無しさん
11/09/30 21:33:47.82
pythonとrubyを無理やり別のカテゴリにする俺ルールだなw
344:デフォルトの名無しさん
11/09/30 21:42:03.04
えらい本で定義を調べてみると
CTMCP
＞関数型プログラミングとは， 完全値についての関数を定義することである． ここに出
＞てくる関数は， 数学的な意味における本当の関数である．これが計算するための唯一の
＞方法であるような言語を純粋関数型言語という
びっくりするぐらい単純だった
何が関数型言語かではなく、関数型プログラミングについて
簡潔に述べるのがポイントなのかなあ
345:283
11/09/30 22:11:15.25
>>342
なぜ？と言われても、それは2chだから、としか答えようがない。
自分なりの関数型言語に関する知識でネタをカキコしてるだけですよ。
ただのチラ裏なんだから、気にくわなければスルーすればいいだけのこと。
できるならば>>342自らが別の話題を振ってくれると、スレが活性化するでしょう。
別の切り口、たとえば>>318については、理論的/学術的には真摯な意見だと思います。
意見そのものに否定する要素は無かったので、あえてレスはしなかっただけです。
たとえばR.バード共著「関数プログラミング」(近代科学社)という本は、
まさに>>318の観点で書かれた典型的な教科書です。
346:デフォルトの名無しさん
11/09/30 22:26:21.03
>>283はバカの基準の参考にしる
347:デフォルトの名無しさん
11/09/30 23:15:35.76
>>345
>>342 も >>315 も >>318 も私です
>>315 については、
もしも最初に言語を決めて方法論を選ぶということであればどうするか、
とレスしてるだけだよね
> 何かの機能がデフォルトで使えるかどうかで分類するより、
> 関数型の方法論が流用し易いか、手続き型の方法論が流用し易いか、
> という観点で分類した方がいいんじゃないのか
という別の切り口の提案についてはどう思ってるの？
で、あなたの基準で＊＊は関数型と見なせる、＃＃は見なせないと分類できたとして、
その結果、どう関数型言語とは何かを理解すれば、
> デフォはRuby、でもここはSMLでも書き直そう、ただここだけはHaskellのほうが直感的に書ける....
これが実用的だという判断に繋がるわけ？
実用を考えて仕分けてるんだよね？
348:デフォルトの名無しさん
11/09/30 23:25:53.40
>>340
Pythonはif式の構文が順番通りならおkなのに
PerlやJSの三項演算子でダメな理由が解らないんだよ。
例えば >>300 なら
var value = (
x == 0 ?
(y == 0 ?
1
:
2
)
:
...省略...
)
となる。Perlの場合もだいたい一緒になるはずだ。
変数宣言がmy、文末にセミコロン、変数名の頭に記号（この場合全部$だな）が付くだけ。
349:デフォルトの名無しさん
11/10/01 00:23:32.15
JavaScriptとかCだと、文は書けないじゃん
GCCなら ({ 文 }) で書けるけど
350:デフォルトの名無しさん
11/10/01 00:35:44.86
は？
351:283
11/10/01 01:25:14.63
>>347
>という別の切り口の提案についてはどう思ってるの？
まず関数型言語に適したソフトウェア開発方法論というものが、
あれこれ分類を検討できるほど存在していない、という事柄があります。
もちろん>>345の教科書を含めて「数学的な活動としての関数型プログラミング」や、
形式的手法あるいは定理証明といった分野で活発な研究が行われているのは知っています。
ただし自分が求めているのは、現場に提案/適用できる実用的なソフトウェア設計論です。
たとえばOOPLであれば1992年に国内出版された「オブジェクト指向方法論OMT」があります。
当時はOOに対して悲観的な意見者が大半を占めていた時代でしたが、
この本の登場によって、国内でも一気にOOP/OODに関する注目が高まりました。
そして1995年の「デザインパターン」による設計手法のカタログ化(分類)によって一気に普及しました。
これに相当するような具体的な設計論が関数型言語に存在しますか？おそらく現状は No でしょう。
以上のように考えて、>>315で提案されたようなトップダウンな方法論は(今の自分には)無理だと判断しました。
352:283
11/10/01 01:26:45.17
>>347
>これが実用的だという判断に繋がるわけ？
現場でも受け入れられている言語の一つがRubyであり、自分もRubyには慣れ親しんでいます。
だから(自分には)デフォがRubyであり、Rubyで関数型風の(関数型っぽい)プログラミングが
どこまで可能かを試行錯誤している段階です。
その一方で強いデータ型付けの無いRubyという言語の限界も感じています。
だから、できる限り現在Rubyで開発しているコンポーネントをSMLへ移行したいと考えています。
353:デフォルトの名無しさん
11/10/01 01:28:29.28
モナド（IOMonadだけじゃなくてMaybeMonadとか）は関数型言語のデザインパターンかもな
354:デフォルトの名無しさん
11/10/02 01:46:38.22
とにかくRubyが大好きなんです！
355:デフォルトの名無しさん
11/10/02 02:42:04.90
参照透過性って何がいいだかよく分からん。
みんな説明下手すぎ。
356:853
11/10/02 03:07:10.76
>>355
一度動けば常に同じように動くとこ。
357:uy
11/10/02 04:58:19.53
>>355
たいして「良い」ことはなく、
あれば使う。なくても別に困らない 程度のものだから
直感的にわからないなら
別に知ろうとしなくて良いよ ゴミには無理だ
358:デフォルトの名無しさん
11/10/02 05:01:39.82
ゴミって、何？どういう意味？
359:デフォルトの名無しさん
11/10/02 08:51:01.20
「俺」と読み替えればいいよ
360:デフォルトの名無しさん
11/10/05 23:23:26.74
>>318
>「問題を解決する為に数学的な関数を構築する」
>
>これをするプログラミング言語が関数型言語であり、これが本質です
絶対主義/原理主義というか、ほとんど宗教勧誘の感覚に近いものがあるな
ア ナ タ ハ カ ミ ヲ シ ン ジ マ ス カ ？
361:デフォルトの名無しさん
11/10/06 00:33:33.17
>>318
> 「問題を解決する為に数学的な関数を構築する」
>
> これをするプログラミング言語が関数型言語であり、これが本質です
というような恥ずかしい大袈裟な言葉を平気で書けるのは、
君が関数プログラミングについて何も分かっていない事の証拠だね。
そもそも「数学的な関数」という言葉が何を表すかを理解せずに使ってるんだろう。
普通に数学で言う「関数」と関数プログラミング言語での「関数」は全然違う。
せめて学部レベルでも数学を専攻してちゃんと勉強した人間ならば
関数プログラミング言語での「関数」が数学での関数とはかけ離れた概念だと気づく筈だ。
そんな基本中の基本すら理解していないから上の引用箇所のような事を平気で書けるんだろうが。
362:デフォルトの名無しさん
11/10/06 00:50:05.30
とりあえず型があればうれしいです
363:デフォルトの名無しさん
11/10/06 01:00:55.45
型システムは最も実用的な形式手法とかいう話をたまに聞く
364:デフォルトの名無しさん
11/10/06 01:18:36.50
>>361
> 普通に数学で言う「関数」と関数プログラミング言語での「関数」は全然違う。
> せめて学部レベルでも数学を専攻してちゃんと勉強した人間ならば
> 関数プログラミング言語での「関数」が数学での関数とはかけ離れた概念だと気づく筈だ。
そんなことはない。
ラムダ計算が何のために作られたのか知らないのか？
ラムダ計算のみに依拠するようなら純粋な関数型言語(Haskellは理念的にはほとんどそう)の関数は、数学上の計算可能な関数と同じもの。
365:デフォルトの名無しさん
11/10/06 01:26:10.11
>>364
Haskellのモナドは数学の圏論を基礎にしているらしいけど、
Haskellでプログラミングする人は、すべて圏論をマスターしていなければならないってこと？
モナドの本質は圏論じゃないの？
その本質を理解しなければ関数型プログラミングではない、ってのが>>318の狂信的な主張
366:デフォルトの名無しさん
11/10/06 01:30:35.94
ラムダ計算といえば、情報学板の鯖が跳んでログが全滅したのは痛かった
今では見る影も無く寂れている
367:デフォルトの名無しさん
11/10/06 01:33:06.41
computable functionと集合論のtotal functionってかなり違う
だから検証などするときに形式化するときのモデルとして関数じゃなくて関係をよく使う
もはや関数型言語の関数なんてアナロジーとしての意味ぐらいしか成さないんだろうな
大目に見て決定的な2値の対応ぐらい？悲しいな
368:364
11/10/06 02:21:03.18
>>365
オレは>>361の
> 普通に数学で言う「関数」と関数プログラミング言語での「関数」は全然違う
という主張に反対しているのであって、>>318を擁護しているわけでもなんでもない。
「狂信」者ならどんな強引な理屈で非難してもよい、というわけではあるまい。
> モナドの本質は圏論じゃないの？
まぁ、もし「素因数分解の本質は数論」といってよければ、「モナドの本質は圏論」とも言っても良いんじゃの？ よく分からないけど。
ともあれ、数論をマスターしなければ素因数分解をアルゴリズムで使用できないわけではないのと同様、圏論をマスターしないとモナドが使えない、ということはない。
Haskellのモナドなんて、>>=とreturnを持ち、モナド則を満たし、do記法が使えるちょっと便利な型クラス、という認識でかまわない。
369:デフォルトの名無しさん
11/10/06 03:58:41.95
英語でfunctionalって言うと「関数の」って意味もあるが「汎関数」って意味もあるわけで。
つまり関数を実数とか関数とかに写像する「関数」。
普通の関数ならFortranでもあったわけで、わざわざ「関数の」と言うとも思えん。
たぶん当初は「汎関数」という含みがあったと思う。
Lispの影響が強くて、結局は意味のずれがあると思うけど。
370:デフォルトの名無しさん
11/10/06 07:30:06.49
あるもののの本質が何かということと、
そのあるものを現実的に実用的に使えているかといことは、違います
本質を意識しなくても、理解していなくても、
みな関数型言語を普通に問題なく使いこなしています
コンピュータ（計算機）の本質を理解していなくても、
老若男女みなそれぞれ自分の関わる範囲で普通に問題なく使いこなしていることと同じです
だからといって、本質が別の物に変わるわけではありません
本質は本質として昔から今まで変わらずしっかりとあります
関数型言語におけるそれの私なりの考えを主張したのが >>318 です
>>283 などは実際に使う側に焦点を当てて、
関数型言語とは何かを >>283 なりに考えた結果でしょう
本質が何かということと、実際に使えるかということ
これを区別せずに混同し続けると >>365 のような考えに至ります
>>365 は関数型言語に限らず、何に対しても、本質は＊＊だと主張されれば、
すべて＊＊をマスターしていなければならないと思い込んで思考停止するのでしょう
本質と実質の違いを考える事も、本質に対する自分なりの考えを持つこともなく
371:デフォルトの名無しさん
11/10/06 09:10:13.55
>>370
あなたのように教養があると、実際どれだけコードの質が上がるのか、
ちょっとうｐしてみてよ
372:デフォルトの名無しさん
11/10/06 10:43:22.79
>>366
あの板はようやく立ち上がった時も、
遅々としてスレが延びなかったから、今回も時間かかるだろうね。
373:デフォルトの名無しさん
11/10/06 10:51:24.04
>>367
computable functionと比べるならpartial functionでしょ。
そもそも計算論では"function"が数学的に定義されているから、
その文脈で"computable function"を持ち出すのは不適切だけども。
374:デフォルトの名無しさん
11/10/06 11:19:59.99
totalな場合は明示的にtotal computable functionっていう
通常computable functionっていう時はpartial computable functionを指すんだと思ってた
ほら計算論の文脈ではほぼ常に停止性の議論が常につきまとうから
375:デフォルトの名無しさん
11/10/06 12:13:37.94
>>370
ｽｺｺｺﾊﾞｼｯｽｺﾊﾞﾄﾞﾄﾞﾄﾞﾝｽｺﾊﾞﾝｽｺ ＿∧＿∧＿∧＿∧＿∧＿∧＿
从 `ヾ/゛／' "＼' /". | |
?? ≡≪≡ゞｼ彡 ∧＿∧ 〃ﾐ≡从≡=＜ うｐまだぁー？！！ ＞
. '=巛≡从ミ.（・∀・# ）彡/ﾉ≡》〉≡.|＿ ＿ ＿ ＿ ＿ ＿ ＿＿＿|
. ゛=!|l|》ﾘｎl⌒!Ｉ⌒Ｉ⌒I⌒Iﾂ从=≡|l≫,ﾞ ∨ ∨ ∨ ∨ ∨ ∨ ∨
《 l|!|!l!'~'⌒^⌒(⌒)⌒^~~~ヾ!|l!|l;"
. "l|l|（（ (〇) ））（（ (〇) ））|l|》;
`へヾ―-― ―-― .へヾ ﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞ
376:デフォルトの名無しさん
11/10/06 12:46:31.21
本質と実質が違うと主張している人に対して実用的コードを求める人って・・・
377:デフォルトの名無しさん
11/10/06 13:25:46.71
>>372
ネタを振って盛り上げようとすればいいよ。食らいついてくる人はいるから。
ネタの振り方を間違えるとダメだよ。煽らないと盛り上がらないと勘違い
してるようなコメントじゃ低俗なのがよくわかるし、低俗な連中しか
寄ってこなくなる。そんなのを寄せ付けないようにしつつ盛り上げる工夫を
考えてみればいいんじゃねえか。
378:デフォルトの名無しさん
11/10/06 13:27:37.23
>>372
ネタを振って盛り上げようとすればいいよ。食らいついてくる人はいるから。
ネタの振り方を間違えるとダメだよ。煽らないと盛り上がらないと勘違い
してるようなコメントじゃ低俗なのがよくわかるし、低俗な連中しか
寄ってこなくなる。そんなのを寄せ付けないようにしつつ盛り上げる工夫を
考えてみればいいんじゃねえか。
379:デフォルトの名無しさん
11/10/06 13:29:43.02
>>361
なんであれこれコメントが帰ってきてるかわかる？短くてもいいから
数学での関数と名乗れる 必要・十分・必要十分条件を説明してないからだよ。
フィーリングでわかるという事で納得する連中がいるスレではないのは
わかるだろ？聡明な頭脳を持ってるならば説明できるだろう？書いてみなよ
380:デフォルトの名無しさん
11/10/06 16:10:28.09
聡明てなんですか？
381:デフォルトの名無しさん
11/10/06 16:19:53.38
夜明けぜよ
382:デフォルトの名無しさん
11/10/06 16:23:26.21
ちょっと日本語不自由な人なのかね。
明晰な頭脳、聡明な人。
383:デフォルトの名無しさん
11/10/06 18:40:10.43
聡明を知らんのか。。。 ごめん来る場所じゃなかったみたい。
384:デフォルトの名無しさん
11/10/07 00:02:40.48
>>364
> そんなことはない。
> ラムダ計算が何のために作られたのか知らないのか？
そんな事は百も承知だ。
> ラムダ計算のみに依拠するようなら純粋な関数型言語(Haskellは理念的にはほとんどそう)の関数は、数学上の計算可能な関数と同じもの。
まず普通の数学、つまり数学の主流分野の代数学・幾何学・解析学で登場する関数つまり写像は計算可能である必要はないし
存在しか主張できない写像はいくらでも登場する。数学の主流分野では「計算可能」なんて条件はほとんど無意味。
君が言っている「数学上の」の「数学」は数学基礎論という普通の数学からは相手にされてない数学の辺境の中でも
辺境中の辺境の再帰関数論部落や証明論部落の住民が考えている「数学」だ。
数学基礎論でも普通の数学と多少は繋がりのあるモデル論部落や公理的集合論部落になればすぐに計算可能とは限らない写像が現れる。
最も簡単な例は選択公理が存在を主張する選択関数だ。
更にλ計算はindefiniteに対する関数値とある変数をパラメタとする関数そのものを厳密に区別する表記法としてのλ記法での「関数値の計算」が
どういう事なのかを分析する為に、λ記法を純粋に構文的な体系として形式化し対象化したものだから、
λ計算での計算はreductionという純粋に構文的な概念のみだ。
ところが関数プログラミング言語で実際に行われている計算は必ずしもそうではない。少なくとも純粋に構文的なものとして理解しようとすれば
気がおかしくなりそうな計算メカニズムを用いているケースは珍しくない。グラフ簡約とかな。
数学をせめて学部レベルほどもちゃんと学ばずに基礎論の解説か通俗書をチョイと齧ったぐらいで「数学上の」なんて言い切らない方がいいよ。
385:デフォルトの名無しさん
11/10/07 07:31:36.15
計算可能な関数は(普通の意味での)数学的な関数でもある
だから「関数型言語では数学的な関数を構築する」と言うのは全然問題ないだろ
386:デフォルトの名無しさん
11/10/07 07:41:09.08
集合論で言う関数はtotal functionの事なんだけどな
ただの対応付けでしかないものを関数とか呼ぶのが普通な数学って何だよ、圏論かよ
387:デフォルトの名無しさん
11/10/07 07:51:36.62
ちゃんとpartial functionという言葉があるのに何言ってんの？
ただの対応とpartial functionの区別が付かないとか頭大丈夫？