関数型言語Part5

1 ：デフォルトの名無しさん：2009/09/09(水) 13:31:46

Lisp Scheme ML Haskell FP Mirranda など
関数型言語について話し合いましょう。

前スレ
関数型言語Part IV
http://pc12.2ch.net/test/read.cgi/tech/1083649982/

関連スレ

Lisp Scheme Part27
http://pc12.2ch.net/test/read.cgi/tech/1248657331/

関数型言語ML (SML, OCaml, etc.), Part 6
http://pc12.2ch.net/test/read.cgi/tech/1245017721/

関数型プログラミング言語Haskell Part11
http://pc12.2ch.net/test/read.cgi/tech/1252382593/

Emacs Lisp 3
http://pc12.2ch.net/test/read.cgi/tech/1191875993/

2 ：デフォルトの名無しさん：2009/09/09(水) 13:50:58

テンプレ追加情報よろしく

3 ：デフォルトの名無しさん：2009/09/09(水) 14:12:27

【関数】Erlang【エリクソン】
http://pc12.2ch.net/test/read.cgi/tech/1176479959/

【.NET】F#について語れ【OCAML】
http://pc12.2ch.net/test/read.cgi/tech/1186030985/

4 ：デフォルトの名無しさん：2009/09/09(水) 19:28:02

関数型言語の定義なんて
・関数がファーストクラスオブジェクトとして扱える
・リスト操作が簡単
・ラムダが簡単
としか思っていないし、それ以上のことはどうでもいい
純粋とか非純粋とかマジどうでもいい

5 ：デフォルトの名無しさん：2009/09/09(水) 20:13:17

参照透明性ぢうやう

6 ：デフォルトの名無しさん：2009/09/09(水) 20:14:54

>>4
考えを改めると世界がよりよく見渡せるようになると思う。
今後もそんな目は要らないと言うのなら、どーでもいいが。

7 ：デフォルトの名無しさん：2009/09/09(水) 20:28:42

>>6
別にそんな一所懸命、何かをわかってるフリしなくていいです。

8 ：t ◆SQYzTdSfUA ：2009/09/09(水) 20:43:05

劣化の件は私も余計だと思ってましたので取り下げます
失礼しました

ところで、前スレの990の
>ソフトウェア設計(あるいはプログラミング)という行為を、(理論を背景にして)
>より抽象的に、より形式的に実践しようとすることは大切だし、それを多くの人に広めたい。
というのは同意見です
現場でも理論的な背景を知り実践していくべきです
そういう意味ではHaskell, OCaml, Scala, haXeあたりを進んで実戦投入していけば、
いやでも広まると思います
もし現場で設計を担当していて、開発言語を決定できる権限のある方はこれらの言語を推してください

9 ：デフォルトの名無しさん：2009/09/09(水) 20:45:09

>>4
JavaScriptは関数型言語か否か

10 ：デフォルトの名無しさん：2009/09/09(水) 20:48:36

>>8
納期に間に合わなかったら誰が責任とるの？

11 ：デフォルトの名無しさん：2009/09/09(水) 20:56:54

>>7
分かってないけどいーじゃん、フリぐらいさせろ。
別に大きく間違った事は言ってないよな。

12 ：t ◆SQYzTdSfUA ：2009/09/09(水) 21:04:27

>>10
Haskellじゃなくて他の"一般的な"言語を使っていたら納期遅れの責任を回避できるの？
どの言語を使おうが、責任の所在は変わらないと思う

13 ：デフォルトの名無しさん：2009/09/09(水) 21:04:59

>>8
末端の単純労働力のレベルを知ってて仰ってるのん？

14 ：t ◆SQYzTdSfUA ：2009/09/09(水) 21:13:58

>>13
はい、ある程度は知っています
C++やPHPを使わせるよりは逆に安全だと思っています
実際に某関数型言語(詳しくは書けません)で協力会社さんに依頼を出したことがあります
確かに出来上がったコードは期待以下でしたが、それでもヌルポが頻発するよりましでした

15 ：デフォルトの名無しさん：2009/09/09(水) 22:03:58

趣味で押しつけたのが原因ならお前のせいなんじゃねーの

16 ：t ◆SQYzTdSfUA ：2009/09/09(水) 22:49:42

当り前過ぎてためらいますが、やや気遅れしている人もいるかもしれず、関数型言語普及のために書きます
システム開発の現場の方へ：
もし趣味で学んだ関数型言語がシステム開発に有用だと思ったら、
上長やリーダー（システム設計の責任者）にその件をぜひ提言して下さい
その提言が受け入れられたからといって、万一プロジェクトが失敗した責任があなたに
降り掛かってくる事はありません
安心して提言しましょう

システム設計責任者へ：
どの言語を選ぼうが、結局のところ設計責任はあなたにあります
胸を張って自分がいいと思う言語を選択してください
たとえそれが趣味であろうとなかろうと
一般的であろうとなかろうと

17 ：デフォルトの名無しさん：2009/09/09(水) 23:17:30

などと供述しており動機は不明

18 ：デフォルトの名無しさん：2009/09/09(水) 23:48:18

当たり前過ぎるけど、
実用プログラミング言語なんて、
それをつかう一般的プログラマにとって、
言語自体が把握できる大きさと複雑さに抑えられていて、
対象とする問題記述に可能な限り簡易であればそれでいいのだと思う。

19 ：デフォルトの名無しさん：2009/09/09(水) 23:52:22

>>18
そうだとするとC++なんて実用言語としては論外だなｗ
C++をもちだすのはスレチだろうけど。

20 ：デフォルトの名無しさん：2009/09/10(木) 00:01:52

>>19
まったくその通り。

念のため>>18ではライブラリも含めての複雑さ大きさ。

21 ：デフォルトの名無しさん：2009/09/10(木) 00:23:47

>>20
でも複雑で巨大でも、使うプログラマからすれば必要な部分だけチョイスして
プログラムできればそれでいいんじゃないかと思うよ。
C++の全仕様を把握してるプログラマとかANSI CLの全ライブラリを熟知してるプログラマとか
存在しない（と思う）けど、別にそれは問題ないだろ。

22 ：デフォルトの名無しさん：2009/09/10(木) 00:28:54

K&R C が最強
はい論破

23 ：デフォルトの名無しさん：2009/09/10(木) 00:45:17

>>21
必要な部分だけ選択することができて、
名前などがうっかり重複してしまっても問題ないといいですね。

>>22
対象とする問題の種類と大きさによる。

24 ：デフォルトの名無しさん：2009/09/10(木) 01:35:18

>>23
大抵のプログラム言語は名前空間なりパッケージシステムなりで
名前の重複は実用上問題にならないか、問題が起きても発見できるんじゃねえ？

25 ：デフォルトの名無しさん：2009/09/10(木) 01:57:34

テンプレにScalaスレが無い……

26 ：デフォルトの名無しさん：2009/09/10(木) 02:11:06

Scalaスレあったのか……

27 ：デフォルトの名無しさん：2009/09/10(木) 15:15:17

プログラミング言語 Scala 2冊目
http://pc12.2ch.net/test/read.cgi/tech/1246289771/

28 ：デフォルトの名無しさん：2009/09/10(木) 15:19:10

Scalaスレも有るんでスカラね。

29 ：デフォルトの名無しさん：2009/09/10(木) 15:24:58

スッカラ忘れてたYo

30 ：ぅゅ ◆e6.oHu1j.o ：2009/09/19(土) 17:32:10

Lisperってどこにいけば会えるんだ
色々と質問攻めしたいんだけど

31 ：デフォルトの名無しさん：2009/09/19(土) 20:07:45

http://pc11.2ch.net/test/read.cgi/prog/1234958064/
マ板の名物精神病者につき、無視推奨

32 ：デフォルトの名無しさん：2009/09/19(土) 21:55:50

面白そうなヤツじゃないか。
Languageもまともに綴れないようだし。

33 ：デフォルトの名無しさん：2009/09/19(土) 22:15:06

ここにLisperなんてロートルを超越した◆XaaQNk.がいるから、議論するといい
http://pc12.2ch.net/test/read.cgi/tech/1242484767/

34 ：デフォルトの名無しさん：2009/09/19(土) 23:11:29

うゆって去年まで学生だったのか
おっさんだと思ってた
おっさんは頭おかしい奴多いからな

35 ：デフォルトの名無しさん：2009/12/27(日) 12:28:36

なあ、Jのスレ立てたら誰か来るかい？

36 ：デフォルトの名無しさん：2009/12/27(日) 12:41:18

>>4
> ・関数がファーストクラスオブジェクトとして扱える
> ・ラムダが簡単

なんだこれは。ちゃんと整理しろ。

37 ：デフォルトの名無しさん：2010/02/27(土) 08:52:54

これほどまでに簡潔に整理された定義は無いと思うが。

38 ：デフォルトの名無しさん：2010/02/27(土) 13:12:56

関数型言語のより簡潔な定義：

関数の返り値を使って処理を行うスタイルが徹底されている言語

39 ：デフォルトの名無しさん：2010/03/28(日) 13:37:56

ttp://live24.2ch.net/test/read.cgi/livebase/1269588909/94
94 ：どうですか解説の名無しさん：2010/03/26(金) 16:46:32.35 ID:A/YF/FyF:

40 ：デフォルトの名無しさん：2010/03/28(日) 16:39:34

確かに神IDだけど受ける層狭すぎだろｗ

41 ：デフォルトの名無しさん：2010/10/19(火) 07:36:49

まだあったのか

42 ：デフォルトの名無しさん：2011/01/10(月) 23:21:31

あげ

43 ：デフォルトの名無しさん：2011/06/23(木) 17:19:18.52

ほしゆ

44 ：天使 ◆KOAgYBL/Xg ：2011/06/30(木) 10:07:58.49

Ｌｉｓｐｅｒに、質問攻めしたかったんだけど、

もう、それはいいや

その段階は超えた

関数型言語って、わずかにズレてんだよなぁ････

クラスなんてものを使わず、関数でかいていくのはいいんだけど、
それだけじゃダメで
根底に1つ、クラスが必要であって

そのクラスオブジェクトにlambdaやメンバ変数やメンバ関数を、オブジェクトインスタンスごとに付け加えていく感じ
それによって、型＝データとなって、
プログラム中に同じ型が存在しなくなるみたいな、そういうやつ

関数型言語は、まだそれを夢想している段階の言語で、決定的なものが抜けているからオブジェクト指向言語にすら勝てない
2011年の今現在、関数型言語で関数型プログラミングするよりも
オブジェクト指向言語にて関数型プログラミングしたほうが圧倒的に優位

45 ：デフォルトの名無しさん：2011/06/30(木) 14:43:26.13

そういうノリで笑ってもらえるのは高校までだなあ

46 ：デフォルトの名無しさん：2011/06/30(木) 20:05:47.53

>>44 OOPと関数型の関係に興味あるなら、下を読むとよい。
OOPの発想をSMLで表現する方法が載っている
http://mlton.org/ObjectOrientedProgramming

47 ：デフォルトの名無しさん：2011/06/30(木) 22:41:51.86

というか、オブジェクト指向の機能持った関数型言語がないと思ってる時点で、
不勉強な馬鹿丸出しなんだが。
同時代関数型言語でオブジェクト指向機能ないのを探す方が難しい。

48 ：デフォルトの名無しさん：2011/07/01(金) 02:08:14.62

>>46-47
いやいや、君ら最近覚えたような人だろうけど、
そういうことじゃないんだよね
上のコテの「OOPLで関数型」は散々議論をし尽くされた上での結論なんだよ
ひよっこには理解はできんだろうが、まあ可能性を探してくれたまえよ・・・

49 ：デフォルトの名無しさん：2011/07/01(金) 02:14:06.97

自演の練習をしたほうが良いかと思いました

50 ：デフォルトの名無しさん：2011/07/01(金) 02:18:27.97

そうそう認めたくないんだよな
判る判る・・・

51 ：デフォルトの名無しさん：2011/07/01(金) 02:21:16.40

おっとsage忘れた
関数型の関数は重すぎるってことだな
さよなら・・・

52 ：デフォルトの名無しさん：2011/07/01(金) 03:37:00.13

>>48
（注：◆KOAgYBL/Xgはうゆのトリップのひとつ）
うゆ君は英語論文も英語ブログも全然読めないですよね。
「散々議論をし尽くされた」とはどこの議論の事でしょうか？
ム板で技術に関する嘘をまき散らすのは止めてください。

53 ：デフォルトの名無しさん：2011/07/01(金) 03:47:33.74

副作用がないオブジェクト指向設計は
実現可能か？

俺は無理だと思う。
オブジェクト指向と関数型は
相容れない。

54 ：デフォルトの名無しさん：2011/07/01(金) 03:50:23.47

副作用のない実用性のあるプログラムは実現可能か？

俺は無理だと思う。

55 ：デフォルトの名無しさん：2011/07/01(金) 05:58:04.66

xmonadやdarcsは実用的なうちに入らないんだな

56 ：デフォルトの名無しさん：2011/07/01(金) 11:07:10.17

関数型言語には副作用がないというのも初級者の陥りがちな間違い。
λ計算じゃないんだから。

57 ：デフォルトの名無しさん：2011/07/01(金) 11:16:38.92

つまり>>53は初心者と

58 ：デフォルトの名無しさん：2011/07/01(金) 20:25:46.65

>>56
純度を高くすると限りなくラムダ計算に近くなって、無くなると思うぞ

59 ：デフォルトの名無しさん：2011/07/01(金) 20:31:36.03

Haskellには副作用がないけど破壊的更新や入出力のあるプログラム書けるよ

60 ：デフォルトの名無しさん：2011/07/01(金) 21:46:11.02

変数への代入も副作用なんだね。

61 ：デフォルトの名無しさん：2011/07/01(金) 21:52:12.08

ラムダ計算自体と副作用の有無って無関係なんじゃないの

62 ：デフォルトの名無しさん：2011/07/01(金) 22:23:03.86

関数型言語というのは、条件分岐（if等）と繰り返し（for等）を
変数なしに実行できるような文法を持ってる言語のことだよ。

63 ：デフォルトの名無しさん：2011/07/01(金) 22:59:51.50

結論としてテンプレートメタプログラミング最強と

64 ：デフォルトの名無しさん：2011/07/01(金) 23:28:34.24

再帰呼び出しがあれば、すべて関数型言語ということか

65 ：デフォルトの名無しさん：2011/07/01(金) 23:29:01.80

>>63 いや、むしろテンプレートメタプログラミングで関数型言語的なもの
に興味を持って、解読不能なコンパイルエラーでいやになって、MLに移った
のだが。まあ、gcc2.95の時代なので、もっとましになっているとは思うが。

66 ：デフォルトの名無しさん：2011/07/02(土) 00:04:14.43

ばかじゃん

67 ：デフォルトの名無しさん：2011/07/02(土) 00:50:15.76

Haskellに副作用がないなんてよく言えるなあ。

>>58
思うって言われても…
現実のプログラミング言語で極限に近づいたものは何があるの？

68 ：デフォルトの名無しさん：2011/07/02(土) 01:04:59.38

また具体的な話なしか

69 ：デフォルトの名無しさん：2011/07/02(土) 04:56:56.34

>>67
言語の問題ではなく、スタイルの問題だよ
純度の高いスタイルで書けば、副作用は限りなくゼロに近付くということ

70 ：デフォルトの名無しさん：2011/07/02(土) 05:27:43.51

いや言語の問題として、Haskellには(参照透明性を破るという意味での)
副作用を持つ関数がほとんど存在しない
例外はunsafePerformIOなど使って定義された関数

71 ：デフォルトの名無しさん：2011/07/02(土) 05:27:54.05

ああん？お客さん？ああん？

72 ：デフォルトの名無しさん：2011/07/02(土) 05:29:42.65

>>70
ああん？生き別れの兄弟さん？ああん？

73 ：デフォルトの名無しさん：2011/07/02(土) 05:50:17.81

ああんっ…

74 ：天使 ◆uL5esZLBSE ：2011/07/02(土) 14:52:04.82

２０１１年になっても未だにJAVA使い続けてる奴ってさ
仕事で仕方なくならわかるけど

家でもJAVAやってるなら本当にバカだよね。哀れ
ゴミ

75 ：デフォルトの名無しさん：2011/07/02(土) 15:12:36.77

Javaバカにしてる子ってさ
変数に＄ついてる言語触ってるって事だよね

いちいちSHIFT＋４キーおして＄打ちまくってる感触はどう？

76 ：デフォルトの名無しさん：2011/07/02(土) 15:17:21.84

Javaバカにしてるレスなんて最近ないだろ

77 ：デフォルトの名無しさん：2011/07/02(土) 22:39:10.62

>>70
これでもYOME
http://en.wikibooks.org/wiki/Haskell/Understanding_monads/IO

78 ：デフォルトの名無しさん：2011/07/02(土) 23:04:55.02

え？オブジェクトって内部状態を持つものじゃないの？
副作用のないオブジェクトって何なの？

79 ：デフォルトの名無しさん：2011/07/02(土) 23:22:26.77

>>78
javaでいうとStringとか。
オブジェクトはメッセージに対応するメソッドを持っていればいいだけで
別に内部で状態を変化させなきゃならんとかいう決まりはないよ。

newObject = Message( oldObject, arg1, arg2 );

こういう形で十分成立する。

80 ：デフォルトの名無しさん：2011/07/03(日) 00:34:23.99

十分ではない
加工せず作って捨てる発想だと
効率が悪すぎるのさ
まあ幼稚園児では判らないかもしれない
つまり関数型の発想は園児レベル
その根底をぶち壊すしかない

81 ：デフォルトの名無しさん：2011/07/03(日) 01:00:52.02

破壊的変更を許しても意味的にimmutable、みたいな考え方をc++で見た気がするが
なんか名前がついてたと思うんだが思い出せない

82 ：デフォルトの名無しさん：2011/07/03(日) 01:04:41.43

もしかして： mutable

83 ：デフォルトの名無しさん：2011/07/03(日) 01:08:28.90

それだ。なんかﾜﾛﾀｗ

84 ：デフォルトの名無しさん：2011/07/03(日) 01:31:56.15

>>80 副作用を許しながら完全性・健全性を保っている言語は70年代からありますが

85 ：デフォルトの名無しさん：2011/07/03(日) 01:32:53.09

ループを再帰でやる、
比較をパターンマッチでやる、
辺りの概念は同意できるんだけど。
副作用そのもの扱いが確立されてない。
モナドみたいなごまかし方ってどうなのかね。

86 ：デフォルトの名無しさん：2011/07/03(日) 01:38:59.17

>>81
本当はCOWの事いいたかったんちゃうの？

87 ：デフォルトの名無しさん：2011/07/03(日) 01:41:28.12

つーか、変数に代入すること自体が
副作用なんだけどね。

副作用がだめというのなら
変数に入れてはいけない。

88 ：デフォルトの名無しさん：2011/07/03(日) 01:42:42.77

>>80
何が効率悪いの？
空間？速度？

89 ：デフォルトの名無しさん：2011/07/03(日) 01:44:25.37

>>87
イヤ。
10 = Xであるとき 11 = Xになってはいけないだけの話。
数学であるでしょ。アレがもとになってんの。

90 ：デフォルトの名無しさん：2011/07/03(日) 02:02:46.46

>>89
どうやったら、10=Xのとき
11=Xになるというんだ？

91 ：デフォルトの名無しさん：2011/07/03(日) 02:14:31.09

>>90
int X=10;
X=11;

92 ：デフォルトの名無しさん：2011/07/03(日) 02:16:41.03

やっぱり変数に代入することが
副作用じゃんｗ

93 ：デフォルトの名無しさん：2011/07/03(日) 02:21:26.16

f( x, e ) = if( x == e ) f( x + 1, e) else 0;
y = f( x );

ただし、これは副作用があるとは言わない。

94 ：デフォルトの名無しさん：2011/07/03(日) 02:25:11.17

f( x, e ) = if( x != e ) f( x + 1, e); else x;
y = f( 3, 5 );

間違えた、こんな感じか。意味ないけど。

95 ：デフォルトの名無しさん：2011/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 ：デフォルトの名無しさん：2011/07/03(日) 03:01:02.73

このようになにをやっているのか
訳が分からなくなるのが関数型言語です。

97 ：デフォルトの名無しさん：2011/07/03(日) 03:07:45.92

うむ
>>95を1行で要約すると？

↓よろー

98 ：デフォルトの名無しさん：2011/07/03(日) 03:10:54.36

1+1=田

99 ：デフォルトの名無しさん：2011/07/03(日) 03:11:32.25

まぁ、数学が解からんヤツには、式に矛盾がないことによる見通しの良さなんて解からんだろうて。
猫に小判、豚に真珠、馬の耳に念仏、非理数系に関数型。

100 ：デフォルトの名無しさん：2011/07/03(日) 03:13:17.93

理系は生産性がないってことか

101 ：デフォルトの名無しさん：2011/07/03(日) 03:15:46.99

amazonでさえ最初はlispで書いてあったんだ。
プロトタイプ作る生産性なら関数型の方が上だろ。
ただ、バカには使えないのと、パフォーマンスの調整がメンドイってのはあるけどな。

102 ：デフォルトの名無しさん：2011/07/03(日) 03:18:14.92

裸の王様スレ

103 ：デフォルトの名無しさん：2011/07/03(日) 03:18:57.77

人間は長い文章よりも点や丸で区切られた短い文章の方が読み易く感じるのですよ。

104 ：デフォルトの名無しさん：2011/07/03(日) 03:21:48.06

lispで書いたのは「関数型だから」ﾅﾉｶﾅｰ?

105 ：デフォルトの名無しさん：2011/07/03(日) 03:22:05.34

そういや何で生産性が下がるんだ？

106 ：デフォルトの名無しさん：2011/07/03(日) 03:25:07.28

関数型より生産性の高い言語か。まぁ、あるかもしれん。
俺は知らんから教えてくれ。

1.　比較元の関数型言語
2.　1より生産性の高いらしい言語

107 ：デフォルトの名無しさん：2011/07/03(日) 03:26:18.50

1.全ての関数型言語
2.C/C++

108 ：デフォルトの名無しさん：2011/07/03(日) 03:26:44.69

関数型は一部の便利な概念がちょっと使われてるだけで
それ単体では生産性というか生産能力自体無いと思うの

109 ：デフォルトの名無しさん：2011/07/03(日) 03:28:03.30

教えてくれ(ｷﾘｯ
ｷﾀｰ
何回繰り返すんですか

110 ：デフォルトの名無しさん：2011/07/03(日) 03:31:50.08

予想通り関数型の定義が曖昧のまま話が進んでるな
関数型で生産性の高い言語って何だ？
ハスケル厨とかに言わせるとLISPは関数型じゃないってよ

111 ：デフォルトの名無しさん：2011/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 ：デフォルトの名無しさん：2011/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 ：デフォルトの名無しさん：2011/07/03(日) 03:52:03.02

宣言は書いてもデータを持ってこないのが関数型

114 ：デフォルトの名無しさん：2011/07/03(日) 03:58:26.06

>>111-112
何をやりたいのか知らんが
開発工数と生産性の高さってあんま関係ないでしょ
マイナーすぎたら誰もメンテできなくて却下だし
どう見ても関数型に不利な結果になる

マイコンで動かす→CASMとか
iほんで → Objc
安藤idで → java
窓で → C#VBとか
ネトで → 色々

こういう定番がある所に関数型言語が入り込む余地を考えるに、
少なくともその環境のSDKが滞りなく使えることが条件
その上で生産性を示す必要がある

115 ：デフォルトの名無しさん：2011/07/03(日) 04:09:09.10

haskellがCの10倍生産性が高いと仮定しても、
10倍程度ならCで書いたほうが誰でも理解できてよろしい、
という世の中です。
100倍、1000倍、彼女が出きるとかなら判りませんが。

116 ：デフォルトの名無しさん：2011/07/03(日) 04:16:48.92

つーか工数以前に、人数集まるのｗｗ
やる前にプロジェクト破綻するのが予測できるってどうよ

117 ：デフォルトの名無しさん：2011/07/03(日) 04:18:04.71

>>77
Haskell界隈でもside effectという言葉の意味が一定してない
その記事で言ってるside effectは参照透明性を壊さない

>>85
IOモナドはごまかしどころか入出力を関数的に扱う自然な方法だと思う

118 ：デフォルトの名無しさん：2011/07/03(日) 04:25:49.70

haskellなんか覚えなくても
東電に入れば
収入が保障されたり
芋づる式に彼女ができたり
放射能出しっぱでも賠償しなくていい

119 ：デフォルトの名無しさん：2011/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行) 不明, 不明
　　(http://codepad.org/bHvTYKfo)
　・LOGO プロジェクト内容, 工数, 人数
　・Scheme プロジェクト内容, 工数, 人数
　・Mathematica プロジェクト内容, 工数, 人数
　・R プロジェクト内容, 工数, 人数
　・Unlambda プロジェクト内容, 工数, 人数
　・APL プロジェクト内容, 工数, 人数
　・XSLT プロジェクト内容, 工数, 人数
　・C プロジェクト内容, 工数, 人数
　・C++ プロジェクト内容, 工数, 人数
規模あたりの開発工数が少ない

120 ：デフォルトの名無しさん：2011/07/03(日) 04:30:10.27

ま、ユーザーになるだけなら
仕事で使わなくても、ちょっと触ればいいだけだしな。

121 ：デフォルトの名無しさん：2011/07/03(日) 04:33:58.50

「いるらしい」という不確かな情報でいるとカウントされちゃうわけか
話にならんのだがｗ

122 ：デフォルトの名無しさん：2011/07/03(日) 04:35:41.94

>>121
ttp://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
amazonに関しては事実だってな。

123 ：デフォルトの名無しさん：2011/07/03(日) 04:36:17.87

で、なんなのzipのコードってｗ
再発明コードで比較してって生産性の比較になんの？
どんだけ行数短いですよコンテスト？

124 ：デフォルトの名無しさん：2011/07/03(日) 04:39:03.05

とりあえず >>114-115 みたいなヤツらは、
机上の空論じゃなく事実(実績)を出せ。
プログラマーなんだろ。
文系やら厨房みたいな、俺の想像する生産性なんていらんから。

125 ：デフォルトの名無しさん：2011/07/03(日) 04:40:29.16

＞俺の想像する生産性
なんか始まった？

126 ：デフォルトの名無しさん：2011/07/03(日) 04:40:49.50

>>123
全く違うものを比較対象にしろと？
帰納法とか演繹とかしらないの？そもそもバカなの？

127 ：デフォルトの名無しさん：2011/07/03(日) 04:46:07.64

>>123 は、mp3のエンコーダとイメージビューアのソースコード見比べて
どっちが効率的だなとか考えるわけか・・・。

128 ：デフォルトの名無しさん：2011/07/03(日) 04:48:03.38

屁理屈で結論をうやむやにし始めました

129 ：デフォルトの名無しさん：2011/07/03(日) 05:04:22.67

zipの中身って単なる文字列とファイル操作でしょ。
awkみたいのが生産性高いことになってしまう。

130 ：デフォルトの名無しさん：2011/07/03(日) 05:10:35.22

>>128 不満ならあの表埋めろよ。
>>129 それならそれでいいじゃん。実際生産性がどのくらいか調べたいだけなんだし。
事実を客観的に判断するだけだ。あと何を持って文字列と言ってんのかしらんがzipは
文字列じゃないぞ。スライド辞書とかバイナリだらけ。

131 ：デフォルトの名無しさん：2011/07/03(日) 05:11:57.24

>>130
>>113

132 ：デフォルトの名無しさん：2011/07/03(日) 08:21:58.52

>>92
代入自体は副作用じゃなく「再代入」が副作用、かな

133 ：デフォルトの名無しさん：2011/07/03(日) 09:21:48.00

>>86 把握した。でも俺はこのままでいいんだ

134 ：デフォルトの名無しさん：2011/07/03(日) 10:18:02.91

なぜ関数型言語は実用的でないのか

135 ：デフォルトの名無しさん：2011/07/03(日) 10:41:39.19

自分の無知を指摘されたら、ファビよって関数型言語をdisり始めたw

136 ：デフォルトの名無しさん：2011/07/03(日) 11:55:03.97

>>79
それって、ただの手続き型（c、basic）じゃね？

137 ：デフォルトの名無しさん：2011/07/03(日) 12:14:29.80

>>136
副作用の有無の話なんだからその例で充分じゃね？
OOPLのオブジェクトだって、コンストラクタの引数で状態を設定したらあとは不変、にすれば副作用は無いんだから

138 ：デフォルトの名無しさん：2011/07/03(日) 12:31:38.65

純粋関数型は状態の概念を拒絶しすぎて複雑にしすぎてるし
マルチパラダイムは何でもできるゆえに結局いいところも悪いところも取り込んじゃうし
まだ研究段階を出ていないと思う。

139 ：デフォルトの名無しさん：2011/07/03(日) 14:17:09.90

IOモナドは複雑じゃないよ

140 ：デフォルトの名無しさん：2011/07/03(日) 15:49:41.95

Cのlibzipが見つかったんで追加。2行以上の改行とコメントは削除してカウント。
Cはlispの4倍だってさ。
あと紛らわしいんで実例未調査の言語を外してみた。

規模あたりの開発工数が多い↑
　・C zip開発,(4064行), 不明, 不明
　　(http://codepad.org/ZqNUwnvq)
　・LISP zip開発,(1118行) 不明, 不明
　　(http://codepad.org/bHvTYKfo)
規模あたりの開発工数が少ない↓

未調査言語
　・Concurrent Clean プロジェクト内容, 工数, 人数
　・Haskell プロジェクト内容, 工数, 人数
　・Miranda プロジェクト内容, 工数, 人数
　・Lazy K プロジェクト内容, 工数, 人数
　・F# プロジェクト内容, 工数, 人数
　・ML プロジェクト内容, 工数, 人数
　・OCaml プロジェクト内容, 工数, 人数
　・Scala プロジェクト内容, 工数, 人数
　・Erlang プロジェクト内容, 工数, 人数
　・LOGO プロジェクト内容, 工数, 人数
　・Scheme プロジェクト内容, 工数, 人数
　・Mathematica プロジェクト内容, 工数, 人数
　・R プロジェクト内容, 工数, 人数
　・Unlambda プロジェクト内容, 工数, 人数
　・APL プロジェクト内容, 工数, 人数
　・XSLT プロジェクト内容, 工数, 人数
　・C++ プロジェクト内容, 工数, 人数

141 ：デフォルトの名無しさん：2011/07/03(日) 15:51:09.48

>>140
マ板でやれよ

142 ：デフォルトの名無しさん：2011/07/03(日) 15:55:54.00

別にいいんじゃね。言語の話だし。
これからどの言語使おうってヤツらの参考資料になるだろ。

143 ：デフォルトの名無しさん：2011/07/03(日) 16:04:38.64

興味は有るけど、そういうスレを作って、そっちでやって欲しいな

144 ：デフォルトの名無しさん：2011/07/03(日) 16:13:45.38

撮影技術を語る板で、
NHK朝ドラ、水戸黄門が視聴率があるから一番すごいドラマって力説するか?

145 ：デフォルトの名無しさん：2011/07/03(日) 16:53:49.73

撮影技術を語る板で、
制作期間と使用された技法数を語るようなもんだろ。
視聴者 = ユーザー数だし。

146 ：デフォルトの名無しさん：2011/07/03(日) 17:16:06.02

>>144
例えが的外だなｗ

正しく対比させてやろう。

■撮影技術
○○技法を使って作られた作品（NHK朝ドラ、水戸黄門等）・・・1000作品
△△技法を使って作られた作品・・・800作品
□□技法を使って作られた作品・・・500作品

水戸黄門の視聴率・・・○％

■プログラム技術
C++を使って作られた作品（Firefox等）・・・1000作品
Javaを使って作られた作品・・・800作品
Perlを使って作られた作品・・・500作品

Firefoxのユーザー数・・・○万人

視聴率＝アプリのユーザー数。そんなのもで力説はしない。

力説するとしたら、その技法を使って作られた作品数だ。

147 ：デフォルトの名無しさん：2011/07/03(日) 17:38:27.10

最後がおかしい。
>力説するとしたら、その技法を使って作られた作品数だ。

それだったら普及してない言語はすべからくダメだろ。
その技法をつかって1つの作品を作るのに掛かった費用と期間だろ。

148 ：デフォルトの名無しさん：2011/07/04(月) 19:52:05.48

>>132
そもそも手続き言語覚え始めにx=2の次の行でx=3とか違和感ありまくりだったはずだと

149 ：デフォルトの名無しさん：2011/07/04(月) 20:00:26.33

>>148
俺も最初は違和感あったねえ、特に初めてBASIC触れたの小学生のときだったから
X = X + 1 が良くて X + 1 = X がダメな理由も分からなかった
左から右のほうがそれっぽいじゃん！とか思ってたw

150 ：デフォルトの名無しさん：2011/07/04(月) 20:46:57.44

俺、全く違和感なく受け入れてた
そもそも「言語の覚え始めの頃」という時期があったのかどうか

最初俺はベーマガとかプログラムポシェットのソースを読み上げる係だった
で、にーちゃんがそれを聞き取って、画面も見ずにひたすら打ち込む

にーちゃんが高校行ってからは、俺一人でソースを読んで打ち込んでた
そうこうしてるうちに、「こうプログラムすれば」->「こう動く」
という繋がりが頭の中にいっぱい作られた
何故それでできるのか、理由は置き去り

文法や理由を気にしだしたのは、ずーーーっと後のこと

> X = X + 1 が良くて X + 1 = X がダメな理由も分からなかった

そんな疑問、今の今まで思いつきもしなかった

お前等すげぇな

151 ：デフォルトの名無しさん：2011/07/04(月) 22:29:09.05

もしPCがイスラム圏で発明されていたらX+1=Xのほうが正しかったかもしれん。

152 ：デフォルトの名無しさん：2011/07/04(月) 23:12:55.45

アセンブラだとソースとデスティネーションの順序はどっちの流儀もあるわな
mov eax, 4
と
movl $4, %eax
とか

153 ：デフォルトの名無しさん：2011/07/04(月) 23:37:00.57

ASCIIは記号の数が少なすぎ

いい加減UNICODEでプログラミングしようぜ
⇒ とか ≠ とか使えるんだぞ。

154 ：デフォルトの名無しさん：2011/07/04(月) 23:41:40.76

問題は入力し辛いことだ

155 ：デフォルトの名無しさん：2011/07/04(月) 23:49:03.41

>>153
algol使え

156 ：デフォルトの名無しさん：2011/07/04(月) 23:51:47.87

あらこんなところに fortress が

157 ：デフォルトの名無しさん：2011/07/04(月) 23:59:21.29

APL再来

158 ：デフォルトの名無しさん：2011/07/05(火) 08:09:08.63

関数型が見直されてる理由がよくわからん。
副作用のデメリットなんて昔から言われてたし
昔と比べて関数型の生産性が上がってるとは思えないし。

159 ：デフォルトの名無しさん：2011/07/05(火) 08:21:27.49

>>158
マルチコアCPUの有効利用のためにマルチスレッド化が必須になって
手続型ではデバッグが難しくなったからではないでしょうか。

160 ：デフォルトの名無しさん：2011/07/05(火) 08:45:01.11

その割にはその方面で進展ないよね。

161 ：デフォルトの名無しさん：2011/07/05(火) 10:45:48.77

いや、手続き型の要素が多い言語でもSTMを採用し始めてる。

162 ：デフォルトの名無しさん：2011/07/05(火) 10:52:38.16

並列処理もあるかも知れんが、スクリプト言語に続いて、大手の手続き型言語も
クロージャの導入を計画したりしてるからその流れもあるんじゃね

163 ：デフォルトの名無しさん：2011/07/05(火) 12:34:57.46

>>158
インパクトの有るところでは、parl本家より何ヶ月も早く(当時)最新の仕様に準拠したparlインタプリタをhaskellで実装したのがきっかけだったような

164 ：デフォルトの名無しさん：2011/07/05(火) 22:59:41.02

JavaやC++でのクロージャの意義がわからん

165 ：デフォルトの名無しさん：2011/07/05(火) 23:03:38.19

C++でSTLのアルゴリズムのために関数オブジェクトを書いたことあったり
Javaでイベントハンドラ的なものを記述するためにいちいち匿名クラス書いたりしてる
んならクロージャのありがたみは分かるはず

166 ：デフォルトの名無しさん：2011/07/05(火) 23:03:58.99

>>164
イテレータとか書きやすくならね？

167 ：デフォルトの名無しさん：2011/07/05(火) 23:05:49.03

STMって関数型由来だっけ？

168 ：デフォルトの名無しさん：2011/07/05(火) 23:06:31.56

>>165
いや別に

169 ：デフォルトの名無しさん：2011/07/07(木) 11:22:58.89

>>167
元の論文"Software Transactional Memory"は言語に依存しない。
プログラミング言語で上手く扱う画期になったのが、
MSRの人たちが書いた"Composable Memory Transactions"
これはもちろんHaskellで取り扱ってる。
モナドの知識がSTMを扱う上で非常に役にたった。

170 ：デフォルトの名無しさん：2011/07/07(木) 21:36:13.20

Simon Peyton Jones ﾀﾝを MSR の人と呼ぶのは何か抵抗があるな...

171 ：デフォルトの名無しさん：2011/07/07(木) 21:49:35.63

>>170
Peyton
Pyton
Python

。。。なるほどな

172 ：デフォルトの名無しさん：2011/07/07(木) 23:35:48.37

ソフトウェアもアプリケーションも書かなくていいから、
楽に勤怠管理のシフトやエキスパートシステムこさえたい

173 ：デフォルトの名無しさん：2011/07/08(金) 00:00:24.88

>>170
けど実際そうだしなw
CLRべったりなことやっていたのは最初の一二年だけだったけど。

174 ：デフォルトの名無しさん：2011/07/09(土) 01:21:31.34

関数型言語もすっかり一般的になってしまったなあ

175 ：デフォルトの名無しさん：2011/07/09(土) 06:50:07.25

>>174
名前だけね

176 ：デフォルトの名無しさん：2011/07/09(土) 07:11:53.06

関数型っぽい言語なら沢山あるね
っぽい言語ならね

177 ：デフォルトの名無しさん：2011/07/09(土) 08:10:05.74

パソコンで使われるプログラムに限定すれば、もっともたくさんの実用的プログラムを作成してきた高級言語が関数型言語

理由は、yaccやJavaCCみたいなコンパイラコンパイラ言語は関数型言語だから

178 ：デフォルトの名無しさん：2011/07/09(土) 08:11:57.32

違うけど

179 ：デフォルトの名無しさん：2011/07/09(土) 08:39:44.87

yaccがHaskellみたいで、yacc がBNF(っぽいモノ)を採用してて、BNFのBackusが関数型言語の提唱者なのは偶然ではあるまい

180 ：デフォルトの名無しさん：2011/07/09(土) 08:40:40.09

宣言型と関数型の混同

181 ：デフォルトの名無しさん：2011/07/09(土) 09:07:39.28

yacc
・ファーストクラスの関数オブジェクトを持つ言語
・関数は副作用を持たない(持たせる方にテクニックが必要)
・参照透過性が保たれる

182 ：デフォルトの名無しさん：2011/07/09(土) 10:39:50.05

なんというか、関数型言語というカテゴリーが有名かどうかは
関数型プログラミングの考え方が浸透するかどうかに比べたら重要じゃないんじゃないか？

「Xは関数型言語だ」
として広く知られるよりも
「Xはプログラマがこういう性質を持つコードを書く手助けをするのでこういう風に楽ができる」
と広く知られて、それがまさに関数型プログラミングの利点なんだと広まる方が良さそうに感じるし
もっと言えば今プログラミングを学ぶ人がループや分岐を教わるときに
「構造化プログラミングだ！」と意識したりしないくらい浸透すれば言うことないと思う

183 ：デフォルトの名無しさん：2011/07/09(土) 11:51:43.42

「Xはプログラマがこういう性質を持つコードを書く手助けをするのでこういう風に楽ができる」
↓
「じゃあオブジェクト指向言語である○言語にもその機能を取り入れよう」
↓
「○言語に搭載されているXは関数言語由来なんだ」
↓
「だから教養知識として関数型言語を知っておくといいよ」
↓
「でも実際に使うのは○言語だけどね。使える人多いし、関数型言語と同じことできるし」
↓
「実際の開発ではフレームーワークやライブラリの数と質のほうが重要だからね」

184 ：デフォルトの名無しさん：2011/07/09(土) 12:04:08.69

参照透明性が必ず満たされていて、遅延評価を全く意識せず使える、
「オブジェクト指向言語である○言語」を実装したら次の書き込みをしてください。
それまで書き込み禁止ね。

185 ：デフォルトの名無しさん：2011/07/09(土) 12:27:40.13

>>183
もしそういう言語があるのなら、それのどこに問題があるの？
>>182の最後に書いたのはまさにそういう「関数型プログラミングとは何か？普段のやり方のこと」という状態
プログラミング言語の紹介で関数型言語だと書くのが
今「この言語にはなんと分岐とループ、そして驚くべきことにサブルーチンがあります！」と書くくらいスベる状態を「言うことない」と書いた
OOPもまだ到達してない地平だけど

186 ：デフォルトの名無しさん：2011/07/09(土) 12:52:56.46

> もしそういう言語があるのなら、それのどこに問題があるの？

問題はない。

ただ「実用的言語＋関数型の機能」 VS 「関数型言語 - 実用的な機能」
という比較になるのが現実だから
どうやっても関数型言語は普及しないってだけ。

関数型言語の機能が追加された実用的な言語としては
JavaやC#がある。

187 ：デフォルトの名無しさん：2011/07/09(土) 12:58:16.02

とりあえず
F#でOOPも使って書くコードの楽さ>>>>>>>>>>>>>>>>>>>>>>C#で関数型の機能も使って各コードの楽さ
なんだが。
より関数型的に書くならC#でかくのはCでOOPする並みに苦痛。

188 ：デフォルトの名無しさん：2011/07/09(土) 13:10:28.04

だから、参照透明性と遅延評価が実現できてるその「実用的言語」とやらが
どこにあるのか教えてくれよ。

189 ：デフォルトの名無しさん：2011/07/09(土) 13:30:36.01

オブジェクト指向と参照透過性は相性が悪い気が

190 ：デフォルトの名無しさん：2011/07/09(土) 13:37:17.87

>>188
Haskell

191 ：デフォルトの名無しさん：2011/07/09(土) 13:46:56.60

>>190
Haskellのどこがオブジェクト指向言語だ

192 ：デフォルトの名無しさん：2011/07/09(土) 14:16:35.16

>>188
参照透明性・・・引数の情報だけを使って処理を行えば良い。
遅延評価・・・ifを使って必要なときに処理をするロジックを書けばよい。

193 ：デフォルトの名無しさん：2011/07/09(土) 15:46:50.07

つまり、わかってません、ということですねわかります

194 ：デフォルトの名無しさん：2011/07/09(土) 15:53:23.60

int sum(int a, int b) {
return a+b;
}
と書けるからといってCの関数は参照透過性が保証されるとは言わないと思うが

>>186
「関数型言語－実用的な機能」は実用的な機能のない関数型言語だから、それだけでは関数型言語が流行らない説明にはならない
「ものが切れないステンレスのハサミより、ものが切れる鉄のハサミの方が売れるから、ステンレスのハサミは作っても売れない」と主張されたら、それはおかしいと感じるだろ？
ものが切れるステンレスと鉄のハサミで比較するか、ステンレスでは十分鋭い刃が（現時点の技術では、もしくは原理的に）製造できない根拠が必要じゃないか？

195 ：デフォルトの名無しさん：2011/07/09(土) 15:57:35.45

これだろ

http://d.hatena.ne.jp/w_o/20061008#p1

196 ：デフォルトの名無しさん：2011/07/09(土) 16:05:42.60

>>194
だから関数ごとに、参照透過性が保証されますって
ドキュメント残しておけばいいだけだって。

どうせ、参照透過性が保証された状態で、
やれることはどちらも変わらないのだから。

197 ：デフォルトの名無しさん：2011/07/09(土) 17:07:03.36

ドキュメントに書くだけじゃ型宣言は強制するのに型検査はしないようなもんだ

198 ：デフォルトの名無しさん：2011/07/09(土) 18:30:27.01

>>197
関数型言語だって、副作用をもたらす関数は作れるわけで、
参照透過性を強制してないじゃん。

結局はドキュメントでしょ？

199 ：デフォルトの名無しさん：2011/07/09(土) 18:45:04.60

副作用をもたらす関数は、特別な型を強制される

200 ：デフォルトの名無しさん：2011/07/09(土) 18:49:25.98

>>199
その関数を使う関数は、普通の関数になるから
あまり意味はない。

201 ：デフォルトの名無しさん：2011/07/09(土) 18:52:46.64

>>184
関数型言語である事と遅延評価を自然に使える言語である事は必ずしも一致しないんじゃないの

202 ：デフォルトの名無しさん：2011/07/09(土) 19:09:31.06

>>200
関数型言語では、そうはならない。

203 ：デフォルトの名無しさん：2011/07/09(土) 19:15:26.61

あと参照透明性と関数型言語であることも関係ないな。

ようは副作用をもたらさない関数には
特殊なアノテーションを付けるようにして、
副作用をもたらさない関数から呼び出せる関数は
アノテーションがついている物だけとすればいいわけだし。

関数はstatic限定にする必要があるね。

204 ：デフォルトの名無しさん：2011/07/09(土) 19:46:50.68

>>198
作れるけど、そういう部分は他とは違って見えるし、検査も行える

Cでコメントや別のファイルに「この関数は副作用を持たない」と書いた所で、それを守らなくても何も起きない
逆に副作用を持たない関数に副作用を持たないことを書き添え忘れても何も起きない
デフォルトは「副作用を持つかもしれないし、持たないかもしれない。副作用について誰も関知しない」だから
ドキュメントを書くことが求められるけど、書いたことを守っても守らなくても（または現状を正しく書いても間違って書いても）自分がやったことに気付くマークがない
だから「型宣言は強制するけど型検査はしない」ようなものだと書いてる

>>203
それはD言語のpureキーワードそのもの
逆の方が付け忘れた時の挙動が親切だが、FFIを考えるとそうなるな

205 ：デフォルトの名無しさん：2011/07/09(土) 23:25:53.15

>>204
> だから「型宣言は強制するけど型検査はしない」ようなものだと書いてる

分かりにくい。

「動的言語みたい」でいいだろｗ

206 ：デフォルトの名無しさん：2011/07/10(日) 00:20:36.21

>>205
動的言語は実行時に型検査するけど
Cは副作用についてコンパイル時にも実行時にも検査しない

207 ：デフォルトの名無しさん：2011/07/10(日) 01:16:14.01

Haskellばんざーい、MLはゴミだな

208 ：デフォルトの名無しさん：2011/07/10(日) 01:32:58.61

Cの関数に副作用があったときコンパイル時に確認するのって簡単に仕様拡張出来るよね？
なんでやらないんだろう

209 ：デフォルトの名無しさん：2011/07/10(日) 01:36:46.22

C: "We trust in you, programmers."

210 ：デフォルトの名無しさん：2011/07/10(日) 01:49:51.83

>>208
簡単じゃない。

211 ：デフォルトの名無しさん：2011/07/10(日) 02:28:32.54

>>172
1.メモ帳を開き"意見書"とタイトルを打ちます
2.希望の勤怠管理シフトデザインを入力し文書化します
3.上司の高田課長に提出します
4.高田課長から、篠原部長、織田常務、杉下社長まで承認が通るのをまちます
5.承認経路から与えられた管理者、総務の小杉に勤怠管理計画を提出します
6.新規勤怠管理計画始動のメールを社内全体に送信します
7.定期的な改訂、調査を行い今後の改善をしていきます
終わり

212 ：デフォルトの名無しさん：2011/07/10(日) 02:37:48.29

>>208
#define int const int
#define char const char
　　　　　・
　　　　　・
　　　　　・
　　　　　略

213 ：デフォルトの名無しさん：2011/07/10(日) 07:02:24.30

今時の関数型と云々するやつは、どれも、真の関数型じゃない

214 ：デフォルトの名無しさん：2011/07/10(日) 07:12:24.94

真の関数型とかどうでもいいけど、currying がない言語は使う気がしない

215 ：デフォルトの名無しさん：2011/07/10(日) 07:34:02.68

>>210 >>212
このレベルなのか・・・

216 ：デフォルトの名無しさん：2011/07/10(日) 11:09:21.56

そんなに簡単ならすぐに実装してくださいよw

217 ：デフォルトの名無しさん：2011/07/10(日) 12:11:08.95

curryingとpartial application(section)の混同される例は多い
カレーかや部分適用語るなら圏論におけるExponentiatioonまでは知っとけよ

218 ：デフォルトの名無しさん：2011/07/10(日) 12:28:20.57

>>216
>>204の最後にあるじゃん・・・

219 ：デフォルトの名無しさん：2011/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 ：デフォルトの名無しさん：2011/07/10(日) 13:13:27.27

解決できてるやん

221 ：デフォルトの名無しさん：2011/07/10(日) 13:34:28.07

const int const*とか無かったか

222 ：デフォルトの名無しさん：2011/07/10(日) 13:56:29.71

const int* const b = &a とかしても一緒
こうすると b 経由では *b も b も変更できなくなるけど
a 経由で*bを変更できるのは変わらない

223 ：デフォルトの名無しさん：2011/07/10(日) 14:23:47.70

Cのpointer aliasingの問題は素人が考えるよりずっと複雑。
配列や再帰データ構造が絡んだだけで、ほぼ解析不能になる。

224 ：デフォルトの名無しさん：2011/07/10(日) 14:42:31.15

だからポインタ使わなきゃいいって

225 ：デフォルトの名無しさん：2011/07/10(日) 14:46:18.09

>>224
つまり、文字列を引数に取る関数はどうすればいいのでしょうか？

226 ：デフォルトの名無しさん：2011/07/10(日) 14:46:38.64

そんなのCじゃねえ。
strcmpすら使えん。

227 ：デフォルトの名無しさん：2011/07/10(日) 14:48:38.89

restrict

228 ：デフォルトの名無しさん：2011/07/10(日) 14:50:30.55

関数型のスレで何いってるんだ・・・

229 ：デフォルトの名無しさん：2011/07/10(日) 14:51:34.61

>>225

230 ：デフォルトの名無しさん：2011/07/10(日) 15:02:31.12

>>227
restrictは違反したら未定義動作になるけど
エラーになるわけじゃないからなぁ

231 ：デフォルトの名無しさん：2011/07/10(日) 15:04:45.28

お前らC素人なんだから無理すんな

232 ：デフォルトの名無しさん：2011/07/10(日) 18:14:28.80

ポインタ抜きでCを使って何をしようと言うんだ

233 ：デフォルトの名無しさん：2011/07/13(水) 20:28:11.05

配列については、ポインタ使わず、戻り値を構造体にすれば、大体は凌げるとは思うが、
問題はループだよな。副作用抜きなら再帰しか無いわけだし、末尾最適化に祈るしか無い。

234 ：デフォルトの名無しさん：2011/07/13(水) 21:25:57.66

fold系を言語レベルでサポートしてやれば割と何とかなりそうじゃね？

235 ：デフォルトの名無しさん：2011/07/14(木) 00:52:39.96

>>233
あほだろ

236 ：デフォルトの名無しさん：2011/07/14(木) 07:41:51.56

>>233
配列の代わりにポインタのない構造体を使うってのはつまり型と要素数毎に

struct int3 {
　　int item1;
　　int item2;
　　int item3;
}

などを定義するってことか？馬鹿馬鹿しい
それで何かが良くなるとも思えないし、むしろ悪くなってるように見える
副作用を認めないと再帰しか認められないというのも正しくない
forやwhileによるループの表現力に影響するのは副作用の制限ではなく再代入の制限

237 ：デフォルトの名無しさん：2011/07/14(木) 07:53:13.06

アホか

構造体にくるめば、関数の引数や戻り値として、配列を、その先頭を指すポインタではなく、
中身まるごと値としてやりとりできるから、ってことだろ。わかりづらいが

238 ：デフォルトの名無しさん：2011/07/14(木) 07:56:49.95

いや、再代入は副作用だから正確な表現じゃないな

for (i = 0; i < len; i++) { ... }

という文はiに再代入しているが、この文が含まれる関数が外側から見て参照透過性を壊すとは限らないという意味

239 ：デフォルトの名無しさん：2011/07/14(木) 08:15:47.36

>>237
その方法も配列のサイズを宣言時に決めないといけないんじゃないか？

240 ：デフォルトの名無しさん：2011/07/14(木) 09:00:48.03

サイズ可変のベクタを渡したり返せるとか誰か言ってるか？
「だいたいは凌げる」の「だいたい」にそれは入らないってだけだろ。

241 ：デフォルトの名無しさん：2011/07/14(木) 09:22:15.69

内部実装くらい理解してくれ

242 ：デフォルトの名無しさん：2011/07/14(木) 09:23:16.36

具体的に頼む

243 ：デフォルトの名無しさん：2011/07/14(木) 11:12:12.70

配列を返り値でコピーするのか? ﾜﾗ

244 ：デフォルトの名無しさん：2011/07/14(木) 11:34:50.03

必要ならそうするさ
できるんだし

245 ：デフォルトの名無しさん：2011/07/14(木) 11:36:49.28

他の関数型言語のコードからCのコードへの
トランスレータ書いた方がマシなレベル

246 ：デフォルトの名無しさん：2011/07/14(木) 12:15:51.50

まあそういう結論になるわな

247 ：デフォルトの名無しさん：2011/07/14(木) 12:17:05.17

>>244
1960年代に逆戻りだな。

248 ：デフォルトの名無しさん：2011/07/14(木) 12:42:13.49

>>245 実際昔の GHC は（今でもターゲットによってはそうかな？）そういう実装だったし、
Stalin や Chicken という Scheme コンパイラはそれぞれの理由で C のコードを吐くけど、
基本的に人間が書くようなのとは全く別物のコードになるから、全然話が違うと思う。

>>247 どこが？
なんでも値全体をコピー、なんてのはむしろ最近の発想だと思うが。
PHP で配列を参照渡しじゃなくて普通に渡した時とか。

ていうか基本的にGCとかないCでやろうというのが無謀で、もうちょっとなんとかなる
言語でやろうよ、とは思うけど。

249 ：デフォルトの名無しさん：2011/07/14(木) 22:34:49.23

>>247
これははずかしい

250 ：デフォルトの名無しさん：2011/07/14(木) 22:36:36.23

このスレのレベルはこんなもんです

251 ：デフォルトの名無しさん：2011/07/14(木) 23:13:27.67

PHPとかw

252 ：デフォルトの名無しさん：2011/07/14(木) 23:14:16.93

な？

253 ：デフォルトの名無しさん：2011/07/19(火) 06:24:42.44

なんだって～

254 ：デフォルトの名無しさん：2011/07/20(水) 22:23:00.00

>>243
RVO効く環境なら引数で配列取るのと同等の速度が出るけどな。

255 ：デフォルトの名無しさん：2011/07/21(木) 12:09:25.56

ミーハーにも関数型言語に興味持ったんだが、
素人がわかりやすく勉強するには、どの言語＋ドキュメントが良いでしょうか？

Lispで階乗書いて、それから先が進まない程度のレベルなんですが。

256 ：デフォルトの名無しさん：2011/07/21(木) 12:25:29.76

>>255
プログラミングhaskellが入門者向けの内容で、薄くて良いよ

257 ：デフォルトの名無しさん：2011/07/21(木) 12:32:25.72

>>256
早速ありがとうございます。

258 ：デフォルトの名無しさん：2011/07/21(木) 12:50:15.23

lispはｵﾜ関

259 ：デフォルトの名無しさん：2011/07/30(土) 01:49:21.08

http://cufp.org/conference/schedule

こんなの見つけた
誰か行く人いる?

260 ：デフォルトの名無しさん：2011/09/26(月) 19:28:15.85

関数型言語のデフォルトスタンダードってなに？

261 ：デフォルトの名無しさん：2011/09/26(月) 19:40:51.26

>>260
> デフォルトスタンダード

【審議中】
　　　 ∧,,∧　 ∧,,∧
　∧ (´・ω・) (・ω・｀) ∧∧
(　´・ω)　Ｕ) ( つとﾉ(ω・｀ )
｜　Ｕ (　　´・) (・｀　　)　とﾉ
　ｕ-ｕ（l 　　 ) (　　　ﾉu-ｕ
　　　　 `ｕ-ｕ'.　`ｕ-u'

262 ：デフォルトの名無しさん：2011/09/26(月) 20:11:30.94

全く、それを言うならディフェンドスタンダードだろうが

263 ：デフォルトの名無しさん：2011/09/26(月) 20:18:30.76

真面目に言うとデファクトリ・スタンダード

264 ：デフォルトの名無しさん：2011/09/26(月) 21:03:36.71

de factoとか英語ですらないじゃないか・・

265 ：デフォルトの名無しさん：2011/09/27(火) 01:14:55.21

>>260
デファクトスタンダードなら、Haskellがそのために作られた。
実用的な汎用言語であるとともに、関数型言語の可能性を研究する目的で作られてる。

266 ：デフォルトの名無しさん：2011/09/27(火) 07:13:57.12

どのような目的で作られたかは関係なくて
どれが一番多く使われているかだろうがボケ

267 ：デフォルトの名無しさん：2011/09/27(火) 07:26:35.95

あなたがそう思うものがそうです。
ただし他人の同意を得られるとは限りません。

268 ：デフォルトの名無しさん：2011/09/27(火) 10:42:32.21

>>265
> デファクトスタンダードなら、Haskellがそのために作られた。

これはイギリス内の話です。念の為。

フランスにはOCaml派がいますし、
世界各地にSML派がいます。

269 ：デフォルトの名無しさん：2011/09/27(火) 11:56:45.85

schemeェ・・・

270 ：デフォルトの名無しさん：2011/09/27(火) 11:58:35.55

デファクトスタンダードがあるとすれば Common Lispなんじゃないの？
僕はHaskellとSchemeしかやってないけど。

271 ：デフォルトの名無しさん：2011/09/27(火) 12:03:42.42

ないない

272 ：デフォルトの名無しさん：2011/09/27(火) 17:46:25.69

Lispはもう関数型言語に数えるのなしにしようぜ

273 ：デフォルトの名無しさん：2011/09/27(火) 17:56:37.66

まぁ、手続き型言語にもデファクト・スタンダードなんかないしな。
かつてはCがそれに近かったが、いまは違うだろう。

274 ：デフォルトの名無しさん：2011/09/27(火) 18:31:15.48

でも、書籍のアルゴリズム紹介のときはCで書くのが圧倒的かな。
JAVAもかなり多いが。
洋物ならPythonとか。

まあ、Cバリアントは非常に多いから。細かい部分はおいておけば、
Cを理解できないプログラマ等はかなり少ないと思う。

研究者なんかだとMATLABしか理解できないって人は実際にいたが。

275 ：デフォルトの名無しさん：2011/09/27(火) 19:17:37.96

C++11 は関数型言語の要素が入ってきたから今後はこれがデファクトスタンダードになるんじゃね？

276 ：デフォルトの名無しさん：2011/09/27(火) 19:22:37.46

それはない。

277 ：デフォルトの名無しさん：2011/09/27(火) 22:09:39.28

ラムダごときで関数型なら大半が関数型だわ。
それは別として、C++のテンプレートは関数型。
あとXSLTも関数型。

278 ：デフォルトの名無しさん：2011/09/27(火) 23:35:24.24

なんでわざわざ「関数型の考えを取り入れた」なんて言うんだろ
単に、＊＊という新機能・新構文を加えた、だけでいいと思うが
その方が何ができて何ができないかが明確に分かる

関数型の考えが取り入れられた言語を使ってる人たちの大半は、
そもそも関数型ってどういうものか実際のところ理解していない
ならば、関数型の考えを取り入れたと言ったところで、
なんだか凄いという曖昧な印象しか持ち得ない

279 ：デフォルトの名無しさん：2011/09/28(水) 00:11:18.27

それお前

280 ：デフォルトの名無しさん：2011/09/28(水) 01:22:56.68

>>278
＞なんだか凄いという曖昧な印象しか持ち得ない
それが狙いなんじゃないの？
すごそうだから使ってみようって思ってもらうためのキャッチコピー。

281 ：デフォルトの名無しさん：2011/09/28(水) 04:47:41.88

手続型等に「関数型の考えを取り入れました」
なんて言われると、まるでマルチパラダイムこそ素晴らしく
「単なる関数型に勝る」という意味合いが含まれるな。
あ、でも実際そうなのか

282 ：デフォルトの名無しさん：2011/09/28(水) 07:12:16.38

>>280
言語開発者がそう言って宣伝するのなら分かる

が、たいていは記者がそう言っている
マルチパラダイムを大々的に宣伝してるのも、
言語開発者じゃなくてIT系の記者

283 ：デフォルトの名無しさん：2011/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 ：デフォルトの名無しさん：2011/09/28(水) 10:22:01.57

>>283
まずはクロージャーがあるかどうかだろう。
Cは関数ポインタがあるが、クロージャーはないので、関数型言語ではない(GCC拡張ならある)。

でも、JavaScriptと(2)については、スコープを任意につくるためにfunction(){ ... }();とかやる方法が定着している。
キモイけど。

285 ：デフォルトの名無しさん：2011/09/28(水) 10:44:11.96

funarg問題的にみて、あれ（GCC拡張）は外に持ち出せないからいかにも中途半端。
C言語の枠内で可能な限りのことをやってみました、という点では非常に面白いのだが。

286 ：283：2011/09/28(水) 11:28:52.95

>>284
>まずはクロージャーがあるかどうかだろう。
関数型言語を特徴付ける基準にはいくつかあって、クロージャはその一つだと思う。
でもSmalltalk/Rubyならブロックがあるから、関数型か否かを決める境界線(判断基準)としてクロージャは
弱いんじゃないかと考えて落とした。(他にラムダ式も同様の理由で判断基準から落とした。)

>でも、JavaScriptと(2)については、スコープを任意につくるためにfunction(){ ... }();とかやる方法が定着している。
これは無名関数を定義してからすぐ呼ぶことで、関数定義内の局所式(... の部分)を評価しているんだね。
確かに結果的には局所宣言式になるプログラミング技法だけど、言語要素としては実現されていないから
判断基準としてはNGになると思う。同じ事はRubyでも proc { ... }.call と書ける訳で、これをOKとは認めたくない。

287 ：283：2011/09/28(水) 11:37:42.50

JavaScriptについて、Firefox(JavaScript 1.7)ではlet式がサポートされたらしいから、
局所宣言式の基準(2)は限定付きでOKかも。

288 ：デフォルトの名無しさん：2011/09/28(水) 11:39:51.65

Smalltalk/Ruby/Python/JavaScript を関数型と認めない、という
ゴールが先にあって、そこから定義を逆算してるのか？

289 ：デフォルトの名無しさん：2011/09/28(水) 11:54:49.68

それもそれで一つの手ではあるな

290 ：283：2011/09/28(水) 12:02:01.58

>>288
そういうことになるね。
>>288の言語は(程度の差はあるけれど)どれも関数型プログラミングができる。
ここで関数型プログラミングというのは、副作用(破壊的代入や入出力)を極力抑えたプログラミング技法。
ただし、それはあくまで「関数型プログラミング技法」であって「関数型言語」ではない、という考え方。
では境界線をどこに引くべきか？と考えて残ったのが、>>283の「３項目をすべて満たす」という条件。

291 ：デフォルトの名無しさん：2011/09/28(水) 12:34:38.98

>>283が関数型言語の要件だというなら、プログラミング言語が関数型であるか否かなど瑣末なことだな

292 ：283：2011/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 ：デフォルトの名無しさん：2011/09/28(水) 13:06:35.19

いや、>>283の三点は関数型言語の基準としてはどうかとは思うが、瑣末なことではないとは思う。

294 ：デフォルトの名無しさん：2011/09/28(水) 13:11:03.51

proper tail call と書いてくれ。意味が明確になるから

295 ：デフォルトの名無しさん：2011/09/28(水) 13:46:33.23

Python 2.5でif式（三項演算子）が入ってる

296 ：デフォルトの名無しさん：2011/09/28(水) 15:51:15.70

wikipediaにある定義では
「ファーストクラスの関数オブジェクトを持つ言語」ってのがある。

関数へのポインタしか使えないとかなら明確に違うとは言えそうだけど。

297 ：デフォルトの名無しさん：2011/09/28(水) 16:10:48.13

λ計算とβ簡約が鍵とか思ってたら、違う分類でござった。
しかも間違いだらけ…。

298 ：デフォルトの名無しさん：2011/09/28(水) 16:13:01.13

Perlの無名関数はラムダとして認められないの？

299 ：デフォルトの名無しさん：2011/09/28(水) 16:47:05.74

Pythonはデコレータを使えば末尾再帰の変換もできる

300 ：283：2011/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：2011/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の日記
　　http://d.hatena.ne.jp/athos/20110119/p1

302 ：デフォルトの名無しさん：2011/09/28(水) 17:58:41.36

そもそも言語を比較してるのか処理系を比較してるのかハッキリしろよ
言語仕様として末尾再帰最適化を必要条件にしてるのはSchemeくらいだぞ

303 ：デフォルトの名無しさん：2011/09/28(水) 18:40:56.50

>>301
そこらのプログラム変形によるものはぜんぜん proper じゃないし、
下手するとスレッドセーフ（再入可能）どころか再利用可能ですらなかったりする。

>>302
逆に、言語仕様で末尾再帰最適化をうたってるのは Scheme ぐらいだけど、
ML や Haskell の言語仕様であれば、末尾再帰最適化はそんなに困難じゃないので。
（Cとかは、特に相互再帰の場合は不可能）

304 ：283：2011/09/28(水) 18:44:52.73

>>302
スマンけど、言語仕様(構文)と処理系(実装)とを一緒にして比較基準とさせてください。
手続き型言語のループ(反復)が、関数型言語ではすべて再帰として表現されるということは常識だと思います。
たとえば1万回のループは1万回の再帰呼び出しになる訳で、もしも1万回の再帰呼び出しくらいで
スタックオーバーフローが発生するようでは、真の関数型言語処理系として使い物にならないと断言します。
実際、普及しているHaskell/SML/OCamlの「実用的な言語処理系」は、すべて末尾再帰の最適化を実装しているハズ。

>>283の判断基準は(ソフトウェア開発の現場における)実用性という観点で選んでいます。
理論的/学術的には不正確なものだと思いますが、こういう基準もあると理解を願います。
もちろん全く別の切り口で判断基準を選んで提案してもらえれば、それはそれで大いに歓迎します。

305 ：デフォルトの名無しさん：2011/09/28(水) 19:00:55.36

だから proper tail call を無視すんなと。

あと lambda がない関数型言語なんてありえないから。
そして lambda が、「(ソフトウェア開発の現場における)実用性」とつながるかどうかは
俺は全く知らんが。

あるいは ML はいざとなったら副作用でプログラミングできることが、
「(ソフトウェア開発の現場における)実用性」として結構高く評価されているように
感じるのだが、そうすると「(ソフトウェア開発の現場における)実用性」で評価するのは、
Haskell を落とす結果につながると思うのだがどうか？

306 ：デフォルトの名無しさん：2011/09/28(水) 19:05:57.44

めんどくさい奴だなー
オレオレ基準なんてどうでもいいよ

307 ：デフォルトの名無しさん：2011/09/28(水) 19:18:56.39

Haskell の場合、たいていのコンパイラは
末尾再帰を、スタックを消費しない形へ自動的に変換してくれるが、
それが「最適化へと繋がるか」というと、必ずしもそうではない

他言語ならまず間違いなく処理速度もメモリ消費量も最適化へと導かれるが、
Haskell の場合は「それがどう遅延評価されるか」をちゃんと意識しないと、
末尾再帰の処理が最適化へと繋がるか自信を持って言えない

308 ：デフォルトの名無しさん：2011/09/28(水) 19:22:34.24

>>283
そもそも、ある言語が関数型であるか否かを判断する「理由」はなに？

関数型であるか否かを判断する必要があるのってどういう場合？

309 ：デフォルトの名無しさん：2011/09/28(水) 19:29:07.88

>>307
同じ末尾再帰なら、スタックを消費するより消費しない方が良いに決まってるだろ

310 ：283：2011/09/28(水) 19:29:30.30

>>305
>あと lambda がない関数型言語なんてありえないから。
これは当然ですね。>>286で書いたように、ラムダ式/クロージャの概念は非関数型言語でも導入が進んでいるので、
ある言語が関数型か否かの判断基準(境界線)としては弱いと考えて除外したにすぎません。

>そうすると「(ソフトウェア開発の現場における)実用性」で評価するのは、
>Haskell を落とす結果につながると思うのだがどうか？
Yesです。いわゆる一般的なソフトウェア開発現場に(正規順評価を用いる)Haskellは普及しないであろうと予測していますし、
少なくとも自分であれば現場には(作用順評価を用いる)ML族の導入を選びます。

311 ：デフォルトの名無しさん：2011/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 ：デフォルトの名無しさん：2011/09/28(水) 19:46:26.26

なんやねん正規順評価って
日本語版SICPで使ってるようなキモイ無理やり訳した日本語使わんと普通に正格/非正格って言えばいいじゃない

313 ：デフォルトの名無しさん：2011/09/28(水) 20:23:27.69

>>307 が言ってるのは一時期山本さんがこだわってた余再帰の話だろ。
最近、余再帰と言うのも厳密には違ってたという話があったかもしれないがそれはともかく。

末尾呼び出しになるように手でコードを変形すると、引数に蓄積するように
なるけど、そういうことすると Haskell じゃ効率悪いかもよ、って話でしょ。

それはそれで正しいけど、そのことは proper tail call がちゃんと tail call elimination されるか
どうかという話にはかかわってこない。

314 ：283：2011/09/28(水) 20:33:17.09

>>308
正直言って、あまり考えていないです。
「「分ける」こと「わかる」こと」という分類学の本(講談社学術文庫)がありますけど、
関数型であるか否かを考えることで関数型言語とは何かを理解しようとしているだけです。

あえて言えば、局面に応じた言語の使い分けですね。
デフォはRuby、でもここはSMLでも書き直そう、ただここだけはHaskellのほうが直感的に書ける....というふうに。

315 ：デフォルトの名無しさん：2011/09/28(水) 21:23:56.47

>>314
> あえて言えば、局面に応じた言語の使い分けですね。

実用的な観点で分類をしようとしているそうだが、

> デフォはRuby、でもここはSMLでも書き直そう、ただここだけはHaskellのほうが直感的に書ける....

そのような細かな粒度で使用言語を切り替えることが本当に実用的なのか、
もう一度よく考えてみた方がよくないか
そのようなことをしていて本当に生産性や保守性が高まるの？
（というか、今まで実際に高まった？）

そんなことよりも、言語はある程度柔軟性のあるひとつのものに決めておいて、
その上で、ここで関数型の考え方を応用すれば問題をエレガントに解決できないか、
関数型の方で解決した事例の方法論がここでも使えないか、
それともここはオブジェクト指向の＊＊で考えた方が解決できそうか、
と考える方がよほど実用的だと思う

そう考えれば、何かの機能がデフォルトで使えるかどうかで分類するより、
関数型の方法論が流用し易いか、手続き型の方法論が流用し易いか、
という観点で分類した方がいいんじゃないのか

316 ：デフォルトの名無しさん：2011/09/28(水) 21:24:28.67

>>311
C++にくっついてるテンプレートという言語は純粋性の壁の向こうに居るでしょ。
モナドすら無いんだぜ。

317 ：283：2011/09/28(水) 23:24:02.75

>>315
関数型言語に対するアプローチは人それぞれ色々とあっていいと思います。
ただし、もしも最初に言語を決めて方法論を選ぶということであれば、自分の場合はRubyで決まりです。
SMLは片手間に半年ほど前から触り始めたにすぎず、
ようやく数Kstepほどのコードが書けるようになった程度の経験しかありませんから。

今はSMLの学習で得た関数型設計法/プログラミング技法をRubyソフトウェア開発へ反映させているところ。
現状の成果物(Rubyコードだけ、設計書は準備中)を以下の場所に置きました。
　　http://www.h6.dion.ne.jp/~machan/tmdoc/example/_tmdoc/html/tmdoc.div.sources.html
　　(正式リリースではないので、この文書はホームページからはリンクを張っていません)

簡単にコードを解説すると、コード中のtransformer/下のモジュール群は純粋な関数定義で、
model/下のクラス群が抽象データ型定義です。
またtmstd/lsm下のLSMクラス群は、直積/直和/集積(列/集合/写像)という関数型データ構造を表現しています。

318 ：デフォルトの名無しさん：2011/09/29(木) 00:39:55.69

「問題を解決する為に数学的な関数を構築する」

これをするプログラミング言語が関数型言語であり、これが本質です

それ以外の末尾再帰最適化や条件判定式、局所宣言式など諸々は全て、
個々のプログラミング言語が個々の目的の為に加えた飾りです
IOへのアクセス手段も、外部ライブラリへのアクセス手段も飾りです

それが実用かどうかは、関数型言語かどうかとは一切関わらない別問題です

100%この本質だけでプログラミング言語が作られている訳ではもちろんありません
ですが、基本理念としてこの本質を据え、その上でこの本質が活きるよう、
できるだけ壊さないよう、実用や教育（や遊び？）といった目的に応じて飾りが加わります

本質を忘れると、本質を活かすように加えられた飾りを上手く活用できません
本質を忘れると、馬鹿な考えに至ったり、関数型プログラミング言語で問題を解決することが
非常に困難になります

「関数型の特徴を取り入れた」と一般的に言っているのは本質を忘れた馬鹿な発言のいい例です
それは、ある複数の関数型プログラミング言語が共通して持つ「便利な飾り」を、
取り入れ先のプログラミング言語に合うように仕立て直したというだけのことです
本質を考えれば、関数型言語としての特徴を取り入れた訳では全くないことが分かります

319 ：デフォルトの名無しさん：2011/09/29(木) 03:41:23.36

最近正式に仕様が承認されたC++11はラムダ式がある

320 ：デフォルトの名無しさん：2011/09/29(木) 08:25:05.48

ラムダ式だけあれば原理的には整数さえなしで計算が出来るわけだが、
本質云々で便利な飾りを無視するのはちょっとアレだろ。

321 ：デフォルトの名無しさん：2011/09/29(木) 08:50:49.90

本質だけ残したらLazy-Kみたいになるぞ

322 ：デフォルトの名無しさん：2011/09/29(木) 09:07:34.98

計算さえできればいいなら型なしになるだろうが、そりゃないよな今時

323 ：デフォルトの名無しさん：2011/09/29(木) 11:33:38.23

>>292
一番上にFP加えてくれ。

324 ：デフォルトの名無しさん：2011/09/29(木) 11:37:01.25

Proper tail callはメッセージパッシングスタイルの言語の特徴。
もともとACTORの研究から生まれた。

325 ：デフォルトの名無しさん：2011/09/29(木) 11:38:48.85

schemeのラムダ論文？

326 ：デフォルトの名無しさん：2011/09/29(木) 12:35:23.89

> 100%この本質だけでプログラミング言語が作られている訳ではもちろんありません
> ですが、基本理念としてこの本質を据え、その上でこの本質が活きるよう、
> できるだけ壊さないよう、実用や教育（や遊び？）といった目的に応じて飾りが加わります

この文章を意図的に無視して意見する方達ばかりで残念です

327 ：デフォルトの名無しさん：2011/09/29(木) 12:46:14.02

門外漢だがその理念の正当性はオーソライズされてんの？

328 ：デフォルトの名無しさん：2011/09/29(木) 12:58:29.17

本質という名のバズワード

329 ：デフォルトの名無しさん：2011/09/29(木) 13:18:10.38

>>326
十分レス着いてると思うが。。。(>>320-321)
欲張りだなぁ。。。

330 ：デフォルトの名無しさん：2011/09/29(木) 15:26:54.48

>304
OCamlってforもwhileもあるんだけど
ttp://caml.inria.fr/pub/docs/manual-ocaml/expr.html

331 ：デフォルトの名無しさん：2011/09/29(木) 15:41:34.91

>>326
駄文なんで読んでなかったよ。

332 ：デフォルトの名無しさん：2011/09/29(木) 17:15:41.79

>>330
OCamlさんってそんな人だったんだ…
もう信じられるのはHaskellだけです

333 ：デフォルトの名無しさん：2011/09/29(木) 17:28:32.09

純粋な人やね

334 ：283：2011/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：2011/09/29(木) 18:22:33.58

>>334を訂正

X: SML/OCaml/C++11
O: SML/OCaml

336 ：デフォルトの名無しさん：2011/09/30(金) 20:14:01.41

条件判定式の壁ってのが相変わらず分からん

337 ：デフォルトの名無しさん：2011/09/30(金) 20:37:39.92

条件式があるかどうかみたい。
それが壁になるかどうかわからんが。

338 ：デフォルトの名無しさん：2011/09/30(金) 20:51:28.13

: ? の中に文が書けるかどうか、で分けてるのかな

339 ：283：2011/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：2011/09/30(金) 21:23:28.76

341 ：283：2011/09/30(金) 21:24:31.67

二重カキコスマソ

342 ：デフォルトの名無しさん：2011/09/30(金) 21:32:37.30

>>340
俺様流判定基準をここで披露するのはなぜ？
ただのチラ裏とは違うの？

納得いかないという意見が多々あることは承知してますと言うけど、
別の基準や切り口を提案しても「アプローチは人それぞれ」で話を終わらせてるよね

343 ：デフォルトの名無しさん：2011/09/30(金) 21:33:47.82

pythonとrubyを無理やり別のカテゴリにする俺ルールだなw

344 ：デフォルトの名無しさん：2011/09/30(金) 21:42:03.04

えらい本で定義を調べてみると

CTMCP
＞関数型プログラミングとは，完全値についての関数を定義することである．ここに出
＞てくる関数は，数学的な意味における本当の関数である．これが計算するための唯一の
＞方法であるような言語を純粋関数型言語という

びっくりするぐらい単純だった
何が関数型言語かではなく、関数型プログラミングについて
簡潔に述べるのがポイントなのかなあ

345 ：283：2011/09/30(金) 22:11:15.25

>>342
なぜ？と言われても、それは2chだから、としか答えようがない。
自分なりの関数型言語に関する知識でネタをカキコしてるだけですよ。
ただのチラ裏なんだから、気にくわなければスルーすればいいだけのこと。
できるならば>>342自らが別の話題を振ってくれると、スレが活性化するでしょう。

別の切り口、たとえば>>318については、理論的/学術的には真摯な意見だと思います。
意見そのものに否定する要素は無かったので、あえてレスはしなかっただけです。
たとえばR.バード共著「関数プログラミング」(近代科学社)という本は、
まさに>>318の観点で書かれた典型的な教科書です。

346 ：デフォルトの名無しさん：2011/09/30(金) 22:26:21.03

>>283はバカの基準の参考にしる

347 ：デフォルトの名無しさん：2011/09/30(金) 23:15:35.76

>>345

>>342 も >>315 も >>318 も私です

>>315 については、
もしも最初に言語を決めて方法論を選ぶということであればどうするか、
とレスしてるだけだよね

> 何かの機能がデフォルトで使えるかどうかで分類するより、
> 関数型の方法論が流用し易いか、手続き型の方法論が流用し易いか、
> という観点で分類した方がいいんじゃないのか

という別の切り口の提案についてはどう思ってるの？

で、あなたの基準で＊＊は関数型と見なせる、＃＃は見なせないと分類できたとして、
その結果、どう関数型言語とは何かを理解すれば、

> デフォはRuby、でもここはSMLでも書き直そう、ただここだけはHaskellのほうが直感的に書ける....

これが実用的だという判断に繋がるわけ？

実用を考えて仕分けてるんだよね？

348 ：デフォルトの名無しさん：2011/09/30(金) 23:25:53.40

>>340
Pythonはif式の構文が順番通りならおkなのに
PerlやJSの三項演算子でダメな理由が解らないんだよ。
例えば >>300 なら

var value = (
    x == 0 ?
        (y == 0 ?
            1
        :
            2
        )
    :
        ...省略...
    )

となる。Perlの場合もだいたい一緒になるはずだ。
変数宣言がmy、文末にセミコロン、変数名の頭に記号（この場合全部$だな）が付くだけ。

349 ：デフォルトの名無しさん：2011/10/01(土) 00:23:32.15

JavaScriptとかCだと、文は書けないじゃん

GCCなら ({ 文 }) で書けるけど

350 ：デフォルトの名無しさん：2011/10/01(土) 00:35:44.86

は？

351 ：283：2011/10/01(土) 01:25:14.63

>>347
>という別の切り口の提案についてはどう思ってるの？

まず関数型言語に適したソフトウェア開発方法論というものが、
あれこれ分類を検討できるほど存在していない、という事柄があります。
もちろん>>345の教科書を含めて「数学的な活動としての関数型プログラミング」や、
形式的手法あるいは定理証明といった分野で活発な研究が行われているのは知っています。
ただし自分が求めているのは、現場に提案/適用できる実用的なソフトウェア設計論です。

たとえばOOPLであれば1992年に国内出版された「オブジェクト指向方法論OMT」があります。
当時はOOに対して悲観的な意見者が大半を占めていた時代でしたが、
この本の登場によって、国内でも一気にOOP/OODに関する注目が高まりました。
そして1995年の「デザインパターン」による設計手法のカタログ化(分類)によって一気に普及しました。
これに相当するような具体的な設計論が関数型言語に存在しますか？おそらく現状は No でしょう。
以上のように考えて、>>315で提案されたようなトップダウンな方法論は(今の自分には)無理だと判断しました。

352 ：283：2011/10/01(土) 01:26:45.17

>>347
>これが実用的だという判断に繋がるわけ？

現場でも受け入れられている言語の一つがRubyであり、自分もRubyには慣れ親しんでいます。
だから(自分には)デフォがRubyであり、Rubyで関数型風の(関数型っぽい)プログラミングが
どこまで可能かを試行錯誤している段階です。
その一方で強いデータ型付けの無いRubyという言語の限界も感じています。
だから、できる限り現在Rubyで開発しているコンポーネントをSMLへ移行したいと考えています。

353 ：デフォルトの名無しさん：2011/10/01(土) 01:28:29.28

モナド（IOMonadだけじゃなくてMaybeMonadとか）は関数型言語のデザインパターンかもな

354 ：デフォルトの名無しさん：2011/10/02(日) 01:46:38.22

とにかくRubyが大好きなんです！

355 ：デフォルトの名無しさん：2011/10/02(日) 02:42:04.90

参照透過性って何がいいだかよく分からん。
みんな説明下手すぎ。

356 ：853：2011/10/02(日) 03:07:10.76

>>355
一度動けば常に同じように動くとこ。

357 ：uy：2011/10/02(日) 04:58:19.53

>>355
たいして「良い」ことはなく、

あれば使う。なくても別に困らない　程度のものだから

直感的にわからないなら
別に知ろうとしなくて良いよ　ゴミには無理だ

358 ：デフォルトの名無しさん：2011/10/02(日) 05:01:39.82

ゴミって、何？どういう意味？

359 ：デフォルトの名無しさん：2011/10/02(日) 08:51:01.20

「俺」と読み替えればいいよ

360 ：デフォルトの名無しさん：2011/10/05(水) 23:23:26.74

>>318
>「問題を解決する為に数学的な関数を構築する」
>
>これをするプログラミング言語が関数型言語であり、これが本質です

絶対主義/原理主義というか、ほとんど宗教勧誘の感覚に近いものがあるな

ア　ナ　タ　ハ　カ　ミ　ヲ　シ　ン　ジ　マ　ス　カ　？

361 ：デフォルトの名無しさん：2011/10/06(木) 00:33:33.17

>>318
> 「問題を解決する為に数学的な関数を構築する」
>
> これをするプログラミング言語が関数型言語であり、これが本質です

というような恥ずかしい大袈裟な言葉を平気で書けるのは、
君が関数プログラミングについて何も分かっていない事の証拠だね。
そもそも「数学的な関数」という言葉が何を表すかを理解せずに使ってるんだろう。

普通に数学で言う「関数」と関数プログラミング言語での「関数」は全然違う。
せめて学部レベルでも数学を専攻してちゃんと勉強した人間ならば
関数プログラミング言語での「関数」が数学での関数とはかけ離れた概念だと気づく筈だ。
そんな基本中の基本すら理解していないから上の引用箇所のような事を平気で書けるんだろうが。

362 ：デフォルトの名無しさん：2011/10/06(木) 00:50:05.30

とりあえず型があればうれしいです

363 ：デフォルトの名無しさん：2011/10/06(木) 01:00:55.45

型システムは最も実用的な形式手法とかいう話をたまに聞く

364 ：デフォルトの名無しさん：2011/10/06(木) 01:18:36.50

>>361
> 普通に数学で言う「関数」と関数プログラミング言語での「関数」は全然違う。
> せめて学部レベルでも数学を専攻してちゃんと勉強した人間ならば
> 関数プログラミング言語での「関数」が数学での関数とはかけ離れた概念だと気づく筈だ。

そんなことはない。
ラムダ計算が何のために作られたのか知らないのか？

ラムダ計算のみに依拠するようなら純粋な関数型言語(Haskellは理念的にはほとんどそう)の関数は、数学上の計算可能な関数と同じもの。

365 ：デフォルトの名無しさん：2011/10/06(木) 01:26:10.11

>>364
Haskellのモナドは数学の圏論を基礎にしているらしいけど、
Haskellでプログラミングする人は、すべて圏論をマスターしていなければならないってこと？
モナドの本質は圏論じゃないの？
その本質を理解しなければ関数型プログラミングではない、ってのが>>318の狂信的な主張

366 ：デフォルトの名無しさん：2011/10/06(木) 01:30:35.94

ラムダ計算といえば、情報学板の鯖が跳んでログが全滅したのは痛かった
今では見る影も無く寂れている

367 ：デフォルトの名無しさん：2011/10/06(木) 01:33:06.41

computable functionと集合論のtotal functionってかなり違う
だから検証などするときに形式化するときのモデルとして関数じゃなくて関係をよく使う
もはや関数型言語の関数なんてアナロジーとしての意味ぐらいしか成さないんだろうな
大目に見て決定的な2値の対応ぐらい？悲しいな

368 ：364：2011/10/06(木) 02:21:03.18

>>365
オレは>>361の

> 普通に数学で言う「関数」と関数プログラミング言語での「関数」は全然違う

という主張に反対しているのであって、>>318を擁護しているわけでもなんでもない。
「狂信」者ならどんな強引な理屈で非難してもよい、というわけではあるまい。

> モナドの本質は圏論じゃないの？

まぁ、もし「素因数分解の本質は数論」といってよければ、「モナドの本質は圏論」とも言っても良いんじゃの？　よく分からないけど。
ともあれ、数論をマスターしなければ素因数分解をアルゴリズムで使用できないわけではないのと同様、圏論をマスターしないとモナドが使えない、ということはない。
Haskellのモナドなんて、>>=とreturnを持ち、モナド則を満たし、do記法が使えるちょっと便利な型クラス、という認識でかまわない。

369 ：デフォルトの名無しさん：2011/10/06(木) 03:58:41.95

英語でfunctionalって言うと「関数の」って意味もあるが「汎関数」って意味もあるわけで。
つまり関数を実数とか関数とかに写像する「関数」。
普通の関数ならFortranでもあったわけで、わざわざ「関数の」と言うとも思えん。
たぶん当初は「汎関数」という含みがあったと思う。

Lispの影響が強くて、結局は意味のずれがあると思うけど。

370 ：デフォルトの名無しさん：2011/10/06(木) 07:30:06.49

あるもののの本質が何かということと、
そのあるものを現実的に実用的に使えているかといことは、違います

本質を意識しなくても、理解していなくても、
みな関数型言語を普通に問題なく使いこなしています

コンピュータ（計算機）の本質を理解していなくても、
老若男女みなそれぞれ自分の関わる範囲で普通に問題なく使いこなしていることと同じです

だからといって、本質が別の物に変わるわけではありません
本質は本質として昔から今まで変わらずしっかりとあります

関数型言語におけるそれの私なりの考えを主張したのが >>318 です

>>283 などは実際に使う側に焦点を当てて、
関数型言語とは何かを >>283 なりに考えた結果でしょう

本質が何かということと、実際に使えるかということ
これを区別せずに混同し続けると >>365 のような考えに至ります
>>365 は関数型言語に限らず、何に対しても、本質は＊＊だと主張されれば、
すべて＊＊をマスターしていなければならないと思い込んで思考停止するのでしょう
本質と実質の違いを考える事も、本質に対する自分なりの考えを持つこともなく

371 ：デフォルトの名無しさん：2011/10/06(木) 09:10:13.55

>>370
あなたのように教養があると、実際どれだけコードの質が上がるのか、
ちょっとうｐしてみてよ

372 ：デフォルトの名無しさん：2011/10/06(木) 10:43:22.79

>>366
あの板はようやく立ち上がった時も、
遅々としてスレが延びなかったから、今回も時間かかるだろうね。

373 ：デフォルトの名無しさん：2011/10/06(木) 10:51:24.04

>>367
computable functionと比べるならpartial functionでしょ。
そもそも計算論では"function"が数学的に定義されているから、
その文脈で"computable function"を持ち出すのは不適切だけども。

374 ：デフォルトの名無しさん：2011/10/06(木) 11:19:59.99

totalな場合は明示的にtotal computable functionっていう
通常computable functionっていう時はpartial computable functionを指すんだと思ってた
ほら計算論の文脈ではほぼ常に停止性の議論が常につきまとうから

375 ：デフォルトの名無しさん：2011/10/06(木) 12:13:37.94

>>370
　　　　　　　　　　ｽｺｺｺﾊﾞｼｯｽｺﾊﾞﾄﾞﾄﾞﾄﾞﾝｽｺﾊﾞﾝｽｺ　　＿∧＿∧＿∧＿∧＿∧＿∧＿
　　　　　　　　　　　　从　`ヾ/゛／'　　"＼' /".　　　　|　　　　　　　　　　　　　　　　　　　|
　　　　　　　?? ≡≪≡ゞｼ彡 ∧＿∧ 〃ﾐ≡从≡=＜　　　　　うｐまだぁー？！！　　　＞
.　　　　　　　　　 '=巛≡从ミ.（・∀・# ）彡/ﾉ≡》〉≡.|＿　＿　＿　＿　＿　＿　＿＿＿|
.　　　　　　　　　゛=!|l|》ﾘｎl⌒!Ｉ⌒Ｉ⌒I⌒Iﾂ从=≡|l≫,ﾞ　　 ∨　 ∨　∨　∨　∨　∨　∨
　　　　　　　　　　《 l|!|!l!'~'⌒^⌒(⌒)⌒^~~~ヾ!|l!|l;"
.　　　　　　　　　　"l|l|（（　(〇)　））（（　(〇)　））|l|》;
　　　　　　　　　　　`へヾ―-―　　　 ―-―　.へヾ　　　　ﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞﾄﾞ

376 ：デフォルトの名無しさん：2011/10/06(木) 12:46:31.21

本質と実質が違うと主張している人に対して実用的コードを求める人って・・・

377 ：デフォルトの名無しさん：2011/10/06(木) 13:25:46.71

>>372
ネタを振って盛り上げようとすればいいよ。食らいついてくる人はいるから。
ネタの振り方を間違えるとダメだよ。煽らないと盛り上がらないと勘違い
してるようなコメントじゃ低俗なのがよくわかるし、低俗な連中しか
寄ってこなくなる。そんなのを寄せ付けないようにしつつ盛り上げる工夫を
考えてみればいいんじゃねえか。

378 ：デフォルトの名無しさん：2011/10/06(木) 13:27:37.23

379 ：デフォルトの名無しさん：2011/10/06(木) 13:29:43.02

>>361
なんであれこれコメントが帰ってきてるかわかる？短くてもいいから
数学での関数と名乗れる必要・十分・必要十分条件を説明してないからだよ。
フィーリングでわかるという事で納得する連中がいるスレではないのは
わかるだろ？聡明な頭脳を持ってるならば説明できるだろう？書いてみなよ

380 ：デフォルトの名無しさん：2011/10/06(木) 16:10:28.09

聡明てなんですか？

381 ：デフォルトの名無しさん：2011/10/06(木) 16:19:53.38

夜明けぜよ

382 ：デフォルトの名無しさん：2011/10/06(木) 16:23:26.21

ちょっと日本語不自由な人なのかね。
明晰な頭脳、聡明な人。

383 ：デフォルトの名無しさん：2011/10/06(木) 18:40:10.43

聡明を知らんのか。。。ごめん来る場所じゃなかったみたい。

384 ：デフォルトの名無しさん：2011/10/07(金) 00:02:40.48

>>364
> そんなことはない。
> ラムダ計算が何のために作られたのか知らないのか？

そんな事は百も承知だ。

> ラムダ計算のみに依拠するようなら純粋な関数型言語(Haskellは理念的にはほとんどそう)の関数は、数学上の計算可能な関数と同じもの。

まず普通の数学、つまり数学の主流分野の代数学・幾何学・解析学で登場する関数つまり写像は計算可能である必要はないし
存在しか主張できない写像はいくらでも登場する。数学の主流分野では「計算可能」なんて条件はほとんど無意味。
君が言っている「数学上の」の「数学」は数学基礎論という普通の数学からは相手にされてない数学の辺境の中でも
辺境中の辺境の再帰関数論部落や証明論部落の住民が考えている「数学」だ。
数学基礎論でも普通の数学と多少は繋がりのあるモデル論部落や公理的集合論部落になればすぐに計算可能とは限らない写像が現れる。
最も簡単な例は選択公理が存在を主張する選択関数だ。

更にλ計算はindefiniteに対する関数値とある変数をパラメタとする関数そのものを厳密に区別する表記法としてのλ記法での「関数値の計算」が
どういう事なのかを分析する為に、λ記法を純粋に構文的な体系として形式化し対象化したものだから、
λ計算での計算はreductionという純粋に構文的な概念のみだ。

ところが関数プログラミング言語で実際に行われている計算は必ずしもそうではない。少なくとも純粋に構文的なものとして理解しようとすれば
気がおかしくなりそうな計算メカニズムを用いているケースは珍しくない。グラフ簡約とかな。

数学をせめて学部レベルほどもちゃんと学ばずに基礎論の解説か通俗書をチョイと齧ったぐらいで「数学上の」なんて言い切らない方がいいよ。

385 ：デフォルトの名無しさん：2011/10/07(金) 07:31:36.15

計算可能な関数は(普通の意味での)数学的な関数でもある
だから「関数型言語では数学的な関数を構築する」と言うのは全然問題ないだろ

386 ：デフォルトの名無しさん：2011/10/07(金) 07:41:09.08

集合論で言う関数はtotal functionの事なんだけどな
ただの対応付けでしかないものを関数とか呼ぶのが普通な数学って何だよ、圏論かよ

387 ：デフォルトの名無しさん：2011/10/07(金) 07:51:36.62

ちゃんとpartial functionという言葉があるのに何言ってんの？
ただの対応とpartial functionの区別が付かないとか頭大丈夫？

388 ：デフォルトの名無しさん：2011/10/07(金) 07:58:57.23

非決定計算はright uniqueじゃないから関数ですらないじゃん
関係にまで弱化させないと駄目、でも集合論で関数と言って関係を指すとかありえない
じゃあ関係と関数が等価になるのはどんな分野？といいたい、その一つとして圏論を例に出した

389 ：デフォルトの名無しさん：2011/10/07(金) 08:14:07.90

codomainをベキ集合にすれば関数に書き直せるよ？馬鹿なの？

390 ：デフォルトの名無しさん：2011/10/07(金) 08:55:40.92

関数型プログラミングとは、プログラムを式にすることだと思う
逆に、手続き型プログラミングは手順化することだと思う

391 ：デフォルトの名無しさん：2011/10/07(金) 09:47:34.55

>>384

> まず普通の数学、つまり数学の主流分野の代数学・幾何学・解析学で登場する関数つまり写像は計算可能である必要はないし
・・・
> 最も簡単な例は選択公理が存在を主張する選択関数だ。

この部分は、数学でいう関数には計算可能でないどころか、存在することしか分からない関数もある、ってことだよね、要は。
それはそうだけど、それがなんで

> 普通に数学で言う「関数」と関数プログラミング言語での「関数」は全然違う

という言明を正当化するのか分からん。数学でいう「関数」の全部を扱えなくとも、その一部を扱えていれば十分じゃん。

加法と乗法しか習っていない小学生の使う自然数は、大学生の使う自然数とは別のものなのか？
もしそうだというなら、それこそ、過度に数学基礎論的な見方だと思う（嫌いではない）。

> ところが関数プログラミング言語で実際に行われている計算は必ずしもそうではない。少なくとも純粋に構文的なものとして理解しようとすれば
> 気がおかしくなりそうな計算メカニズムを用いているケースは珍しくない。グラフ簡約とかな。

グラフ簡約はいいだろ。
数学者が証明過程でいちいち論理学レベルの変形を事細かに書かないようなもんだろ。

数学基礎論を悪し様に言いつつも、オマエの言っていることには数学基礎論的な潔癖性を感じる。

392 ：デフォルトの名無しさん：2011/10/07(金) 23:19:24.10

オブジェクト指向のほうが現実的
関数型は局所解

393 ：デフォルトの名無しさん：2011/10/08(土) 00:27:35.62

また意味不明な話の振り方を…

394 ：デフォルトの名無しさん：2011/10/08(土) 00:53:56.93

壊れた機械のように同じこと繰り返してるだけ。無視して。

395 ：デフォルトの名無しさん：2011/10/08(土) 00:58:27.68

>>392
Ocaml最強？

396 ：デフォルトの名無しさん：2011/10/08(土) 01:02:20.61

OCamlのOは....

397 ：デフォルトの名無しさん：2011/10/08(土) 01:35:27.30

Object指向はOmake

398 ：デフォルトの名無しさん：2011/10/08(土) 01:50:07.33

Oho,MyGoodes!!

399 ：デフォルトの名無しさん：2011/10/08(土) 22:15:59.52

横からスマンが、思うに計算可能な関数と数学的意味の関数の差というのは
一体何なのか？ということをまず示さないとわけがわからなくなると思う。
計算可能な関数にできることでも数学的意味の関数ではできないことも
あるだろうし、逆に数学的意味の関数にできることでも、計算可能な関数では
できないこともあるはずだ。

400 ：デフォルトの名無しさん：2011/10/08(土) 22:33:09.00

計算可能関数なんて自然数上の partial function （の一部）に過ぎない

401 ：デフォルトの名無しさん：2011/10/09(日) 02:20:29.58

完全関数なんてpartial functionの一部に過ぎない
関数なんて関係の一部に過ぎない
関係なんて直積集合の一部に過ぎない

402 ：デフォルトの名無しさん：2011/10/09(日) 04:42:48.32

Om*k* とかくと卑猥ですね。

403 ：デフォルトの名無しさん：2011/10/09(日) 09:33:10.35

四つん這いで片足上げてるようにも見えるしな

404 ：デフォルトの名無しさん：2011/10/10(月) 19:02:16.93

>>391
> > 普通に数学で言う「関数」と関数プログラミング言語での「関数」は全然違う
>
> という言明を正当化するのか分からん。数学でいう「関数」の全部を扱えなくとも、その一部を扱えていれば十分じゃん。

数学での関数概念は外延的。
プログラミングでの関数概念は内包的。

405 ：デフォルトの名無しさん：2011/10/10(月) 19:12:12.84

>>404
> 数学での関数概念は外延的。

アホ？

406 ：デフォルトの名無しさん：2011/10/10(月) 19:46:36.15

>>405
アホと言いがかりをつけた以上、それに続く反論文を書かないと
逆効果、アホは>>405じゃね？って思われるだけだよ。

407 ：デフォルトの名無しさん：2011/10/10(月) 19:58:33.16

思っておけばいいじゃん
アホって思ってるならいちいち反応するなよ

408 ：デフォルトの名無しさん：2011/10/10(月) 19:59:55.06

> アホって思ってるならいちいち反応するなよ

>>405のこと？

409 ：デフォルトの名無しさん：2011/10/10(月) 21:22:10.48

> 数学での関数概念は外延的。

へー。じゃあどっかに関数のリストが書いてあんのか？w

410 ：デフォルトの名無しさん：2011/10/10(月) 23:43:47.62

>>405,409
数学をちゃんと勉強するんだな。まずは『集合と位相』って類のタイトルの教科書から始めろ。
数学での関数は外延的な概念だという言葉の意味すら理解していないらしいが。

411 ：デフォルトの名無しさん：2011/10/11(火) 00:07:48.58

>>410
こんなアホ見たことねー
「まずは『集合と位相』って類のタイトルの教科書から始めろ」（キリッ

412 ：デフォルトの名無しさん：2011/10/11(火) 00:18:07.87

このスレには、ろくに数学できない落ちこぼれなのに
変に数学にかぶれた馬鹿がいるみたいだな。
>>384とか>>404とか。

413 ：デフォルトの名無しさん：2011/10/11(火) 02:19:49.55

内容で反論できない人は411とか412みたいなことを書くんですね
分かります

414 ：デフォルトの名無しさん：2011/10/11(火) 07:36:14.35

真面目な質問なんだけど、ここでいう外延的ってどういう意味？
内包的という言葉と対になってるから、外延的説明という意味での「外延」と思ったんだけど
どうやら違うみたいだ

415 ：デフォルトの名無しさん：2011/10/11(火) 07:47:19.68

あと、>>404は外延的定義と内包的定義では内容が異なるという主張のようなので
外延性の公理が成り立たない公理系を対象としてるようだけど、
普通の数学も計算論も外延性の公理は前提として採用してると思うが

416 ：デフォルトの名無しさん：2011/10/11(火) 22:21:21.58

http://queue.acm.org/detail.cfm?id=2038036

C#のタプルとかヒドすぎｗ

417 ：405：2011/10/11(火) 22:27:00.69

外延性の公理だけでなく、置換公理や分出公理も全く知らんのだろうな。
数学は無知でも、内包記法のアイデアがどこから生まれたかくらい知っていればねえ。

418 ：デフォルトの名無しさん：2011/10/11(火) 22:33:22.13

wikipediaでも引っ張って来れる単語繋ぎ合わせただけで
薄っぺらなのがまるわかりwww

ま、具体的な事を書いたら>>388のように恥かくから、
頑張ってボカして書いてるんだよねw

419 ：デフォルトの名無しさん：2011/10/11(火) 22:34:18.71

ところで、これって何の話をしてるの？

420 ：デフォルトの名無しさん：2011/10/11(火) 22:40:16.19

何の話をしてるのか分からないレベルなら帰った方がいい

421 ：デフォルトの名無しさん：2011/10/11(火) 22:45:55.38

少なくともプログラミングとは関係無い話になってるな

422 ：デフォルトの名無しさん：2011/10/11(火) 23:00:18.11

関数の定義の話がどうして公理的集合論の話になったのか詳しく

423 ：デフォルトの名無しさん：2011/10/11(火) 23:05:11.91

全部404が悪い

424 ：405：2011/10/11(火) 23:27:09.74

>>422
関数は特殊な集合だから。

425 ：デフォルトの名無しさん：2011/10/12(水) 07:50:51.54

集合以外のすべては集合でできている

426 ：デフォルトの名無しさん：2011/10/12(水) 08:35:09.04

別に数学的にどうこうってのは割とどうでも良くて
プログラミングとしての関数、関数型とは何ぞや、ってのが本来重要なことでしょ
数学的な話を突き詰めてもそこは出て来ないと思うの

427 ：デフォルトの名無しさん：2011/10/12(水) 09:06:33.22

彼らにとってプログラミングとしての関数型なんてどーーでもいい話なわけで、
自分の主張を押し通したり相手を罵倒するための手段が「数学」だったりする

428 ：デフォルトの名無しさん：2011/10/12(水) 09:39:37.84

彼らにとってプログラミングとしての関数型なんてどーーでもいい話なわけで、
自分の主張を押し通したり相手を罵倒するためのマジックワードが「現場」だったりする

429 ：デフォルトの名無しさん：2011/10/12(水) 09:51:46.03

現場はモノ産むけどな

430 ：デフォルトの名無しさん：2011/10/12(水) 10:03:33.24

理論なしにモノが作れると思っている奴は、
強度計算も信号システムもない飛行機や高速鉄道に乗ればいいと思うよ。

431 ：デフォルトの名無しさん：2011/10/12(水) 10:22:23.33

理論がわからないでモノ作ることもあるよ
鉄とある金属の組み合わせで熱膨張収縮が低くなる合金があるけれどその原理がわかったのはつい最近。
理論だけで作られてるものなんてほとんどないんじゃない？多くの物は理論と経験の組み合わせ。物によっては経験がほとんどとかもあるでしょ。

432 ：デフォルトの名無しさん：2011/10/12(水) 10:26:19.73

しかしお前等が使ってる計算機は理論がなきゃ作れなかったな
モノが存在する前に計算論の基礎は出来上がってたしな

433 ：デフォルトの名無しさん：2011/10/12(水) 10:35:22.05

>>432
じゃぁものが飛んできた時にニュートン力学から相対性理論まで物理法則を駆使して機敏に避けるがいいよ＼(^o^)／

434 ：デフォルトの名無しさん：2011/10/12(水) 10:36:46.04

現場の発想ってのは、まずは動くモノを作れだね
いかに理論として優れていても、それがモノ作りに適用できなければ評価されない

435 ：デフォルトの名無しさん：2011/10/12(水) 10:46:07.56

実際的な仕事と理論的な仕事とを別々にするのは不自然だし、
有害であるというのが、ずっと以前からの私の考え方である。
ソフトウェアの設計にしろハードウェアの設計にしろ、
コンピュータの分野でなされてきた実際的な仕事のほとんどは、あやしげで見苦しい。
なぜならそれを行った人間は、自分の仕事の基礎となっている基本的な原理について、
何ら理解していないからである。抽象数学や理論的な仕事の多くは役に立たない。
なぜならそれは現実のコンピュータの分野となんの接点も持たないからである。....(以下略)

436 ：デフォルトの名無しさん：2011/10/12(水) 10:51:21.85

ドカタが現場でどれだけ頭ひねっても
安全性のある暗号方式は生まれなかっただろうけどな

437 ：デフォルトの名無しさん：2011/10/12(水) 12:36:05.87

>>435
略さずに最後まで話せよ

438 ：デフォルトの名無しさん：2011/10/12(水) 12:36:24.18

極論バトルになっててわろた

おまえらってほんと馬鹿

439 ：デフォルトの名無しさん：2011/10/12(水) 14:08:11.13

>>436
でもプログラミングとして重要なのは
その暗号方式が安全かどうなだけだ
過程なんてのは割とどうでもいい

440 ：デフォルトの名無しさん：2011/10/12(水) 14:10:31.99

(>>435の続き)
教育および研究のための集団である Programing Research Group の
中心的な目的は、このような隔離が怒り得ないような環境を
設定することなのである。　　　　　　Christopher Strachy, 1974年

441 ：デフォルトの名無しさん：2011/10/12(水) 14:14:46.62

前の世紀における分析と物理の関係のように、
次の世紀において計算と数学的論理が実りのある関係を
持つようになることを期待するのは当然のことである。
この関係を発展させるには、応用と数学的優雅さの
両方に対して関心を持つことが必要である。
　　　　　　　　　　　　John McCarthey, 1967年

442 ：デフォルトの名無しさん：2011/10/12(水) 14:34:51.80

なんだただの権威主義か

443 ：デフォルトの名無しさん：2011/10/12(水) 14:40:27.49

物事を善悪の2元論のように簡単に分類できると考えている厨二病の人が集まるスレはここですか(´・ω・｀)

444 ：デフォルトの名無しさん：2011/10/12(水) 15:14:14.11

>>439 暗号の正しい理解なくして安全な運用なんてありえないけどな

445 ：デフォルトの名無しさん：2011/10/12(水) 15:32:58.44

世の中には池沼と天才しかいない

446 ：デフォルトの名無しさん：2011/10/12(水) 17:29:57.92

>>445
という事は、池沼じゃない凡人は天才なのか

447 ：デフォルトの名無しさん：2011/10/12(水) 22:56:02.80

理論を産めば現場。
おまえは理論の言葉を真似してるだけ

448 ：デフォルトの名無しさん：2011/10/14(金) 21:42:03.47

基本ができてれば応用は効く。ただそれだけ

449 ：デフォルトの名無しさん：2011/10/14(金) 22:23:04.17

いま日本で、関数プログラミングが熱い「函数プログラミングの集い」レポート
　http://www.infoq.com/jp/articles/FunctionalProgramming_20111005

ここ数年、関数型プログラミングやそれをサポートする言語が静かなブームになっている。
昔から、Lispは自然言語処理やAIで使わ>れ、JVM上で動く Clojureなどは今も根強い人気を誇るが、
新しく登場した言語（といってもアカデミックな世界では10年以上の歴史があるものがほとんどだが）として、
ErlangやHaskell、OCamlそしてScalaといった言語の勉強会が各地で開かれ盛況である。
(....中略....)
午前中はまず、「関数型」、「関数プログラミング」とは何を指すのか、に関する
山本和彦さんによるチュートリアルである。世の中には「関数型」の共通定義はなく、あえて言うと、
必要に応じて関数を引数にどんどん適用していくことで計算するパラダイムである、という解説があった。
議論の前に、各人の言う「関数型」が何を指すのか擦り合わせが必要である。
また、関数プログラミング（Functional Programming）には機能的・実用的なプログラミングという意味が
本来あるということに気づかせてくれた。
関数プログラミングのコツは、「バグの入り込まない小さな関数を組み合わせてプログラミングする」ことである。
最終的には、コンビネータと呼ばれるDSL（これが小さな部品関数を組み合わせる仕組み）を使って
プログラムを作るのが関数型プログラミング手法の目標だと非常に明快に示された。

450 ：デフォルトの名無しさん：2011/10/14(金) 23:58:43.98

豆蔵：http://www.mamezou.com/
関数型プログラミングをコンサルのネタに使いたいもんだから流行させようとしているんだろう。

451 ：デフォルトの名無しさん：2011/10/15(土) 00:22:55.19

熱いとか言っても、一部の声の大きな人がごちゃごちゃ言ってるだけで
実際はこんなもんだからなぁ。

この中で関数型言語ってどれでしょうか？ｗ

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Position Oct 2011 Position Oct 2010 Delta in Position Programming Language Ratings Oct 2011 Delta Oct 2010 Status
1 1 Java 17.913% -0.25% A
2 2 C 17.707% +0.53% A
3 3 C++ 9.072% -0.73% A
4 4 PHP 6.818% -1.51% A
5 6 C# 6.723% +1.76% A
6 8 Objective-C 6.245% +2.54% A
7 5 (Visual) Basic 4.549% -1.10% A
8 7 Python 3.944% -0.92% A
9 9 Perl 2.432% +0.12% A
10 11 JavaScript 2.191% +0.53% A
11 10 Ruby 1.526% -0.41% A
12 12 Delphi/Object Pascal 1.104% -0.45% A
13 13 Lisp 1.031% -0.05% A
14 14 Transact-SQL 0.909% +0.09% A
15 23 PL/SQL 0.903% +0.30% A-
16 24 Lua 0.802% +0.25% A
17 16 RPG (OS/400) 0.757% +0.05% A--
18 15 Pascal 0.721% -0.05% A
19 - Assembly* 0.622% - B
20 17 Ada 0.609% -0.09% B

452 ：デフォルトの名無しさん：2011/10/15(土) 09:13:19.08

1980年に、世の中で圧倒的に使われているのはFORTRANだ、C言語なんていらないと
言っていた奴等を思い出すなぁw

453 ：デフォルトの名無しさん：2011/10/15(土) 09:48:58.76

セミナーでしか儲からないとかね・・・
既存の技術を置き換えるには余程のメリットを示さないというのを込みにしても
まだまだ関数型言語は実用に耐えうるだけの技術では無いんだなぁと

454 ：デフォルトの名無しさん：2011/10/15(土) 09:56:25.64

宇宙開発ではまだ使われてないから実用に耐えない
勘定系ではまだ使われてないから実用に耐えない

そうやって必死に思い込んでるのは自由だから一人でやっててね

455 ：デフォルトの名無しさん：2011/10/15(土) 10:08:34.80

オレはHaskell Loveな人だけど、>>451の表とかみるとちょと考えさせられるな。
カス言語であり、低脳プログラマホイホイであることについて衆目が一致しているJavaとPHPのランクの高さとか。

456 ：デフォルトの名無しさん：2011/10/15(土) 10:11:57.27

使われてるといってもまだ一部だろう
宇宙開発でも実際に運用される機械のシステムはそれはもう枯れたものが使われてるし
勘定系といってもトレードシステムみたいなクォンツの方々が矢継ぎ早に生み出すモデルを
速くかつ正確に実装する簡単なお仕事みたいな特殊なものに限られてて
基幹システムなんてもう腐臭を放つようなものばっかり
そもそも現在普及している関数型言語では関数型言語の特徴である形式手法との相性がいいというのを生かしきれるものじゃないんだよ
型システムで作り出せる制約がまだまだ弱すぎるんで

457 ：デフォルトの名無しさん：2011/10/15(土) 10:30:18.28

>>451
関数型言語の機能を取り入れてる言語は赤丸急上昇中だがな
c++/c#/python/ruby

458 ：デフォルトの名無しさん：2011/10/15(土) 10:31:17.90

あ、javaも8でlambda入るんだっけ

459 ：デフォルトの名無しさん：2011/10/15(土) 10:35:30.17

入らないといわれてるよ

460 ：405：2011/10/15(土) 10:46:06.55

>>459
いや7で見送られただけ。
最近もシンタックスで動きがあった。
問題はOracleに買われて人が離れたこと。

461 ：デフォルトの名無しさん：2011/10/15(土) 14:02:33.29

むかしはトレード関係でAPLなんか使われてたと聞いたことがあったな

462 ：デフォルトの名無しさん：2011/10/15(土) 14:10:30.41

http://cufp.org/jobs
こんなのもあるから、関数型の仕事もなくはないし、
セミナーとかじゃなくまともな仕事を増やそうとしている人たちもいる

463 ：デフォルトの名無しさん：2011/10/15(土) 14:34:13.18

もうF#で作ったソフト、客先にリリースしてるよ。
速度も問題ないし自分的にもC#の時よりもバグがなく作るのも早かった。
色々コンポーズできるのとimmutableのところを多くしたせいだと思う。

464 ：デフォルトの名無しさん：2011/10/15(土) 15:03:05.99

裏山すし

465 ：デフォルトの名無しさん：2011/10/22(土) 00:56:02.48

@n_k28 美化乙

466 ：デフォルトの名無しさん：2011/10/22(土) 09:40:18.88

rubyより簡潔で、rubyよりも高速で、rubyよりも安全な言語があるのに
なぜrubyは利用され続けるのだろうか？
COBOLやJavaと同じように老害プロジェクトを生み出してはいないだろうか？
老害プログラマを生み出してはいないだろうか？

467 ：デフォルトの名無しさん：2011/10/22(土) 09:48:55.48

>>466
rubyスレでまったく同じレスを見たって事は・・・
誤爆か？

468 ：デフォルトの名無しさん：2011/10/22(土) 11:56:01.78

ドワンゴでは #Scala がアツイらしい。
http://twitter.com/#!/j5ik2o/status/126325746984693761

469 ：デフォルトの名無しさん：2011/10/22(土) 12:56:10.99

まったくもってどうでもいいな

470 ：デフォルトの名無しさん：2011/10/22(土) 13:01:44.49

そういやテオリアたんはSchemeやHaskell推してたな

471 ：デフォルトの名無しさん：2011/10/22(土) 16:39:27.04

scalaってbetter Javaで使おうとしてるだけだろうし、関数型として扱う
のは違和感ある。

472 ：デフォルトの名無しさん：2011/10/22(土) 16:46:42.55

>>471
激しく同意

473 ：デフォルトの名無しさん：2011/10/22(土) 17:29:15.08

関数型言語だとやっぱりUMLみたいなダイアグラムは書かないんですか？

474 ：デフォルトの名無しさん：2011/10/22(土) 19:41:30.08

「みたいな」の範囲によるけど、リスト構造とかグラフ構造のややこしいアルゴリズムの解説とかでは
図は必須だね。

475 ：デフォルトの名無しさん：2011/10/22(土) 19:58:24.09

>>473
というかUMLってなんか役に立つ？

476 ：デフォルトの名無しさん：2011/10/22(土) 20:11:51.57

UMLはOOPの印象が強いなあ
CLOSとか使って商用アプリ書くとしたら、書くこともあるのかな？

477 ：デフォルトの名無しさん：2011/10/22(土) 20:29:07.91

関数型でアプリ作る時って、どういう設計手法なの？
メジャーなのって何かある？

478 ：デフォルトの名無しさん：2011/10/22(土) 21:01:51.16

っWolfram|Alpha

479 ：デフォルトの名無しさん：2011/10/22(土) 21:07:37.44

>>478
どういう意味

480 ：デフォルトの名無しさん：2011/10/22(土) 21:15:19.57

関数型言語で作られたメジャーなアプリ

481 ：デフォルトの名無しさん：2011/10/22(土) 21:19:55.50

そっか、質問の仕方が悪かった

メジャーな設計手法って何かあるのかな？

メジャーじゃなくても、関数型であることを考慮した設計手法って
どんなのがあるんだろ

ACM の Digital Library で "Functional Design Approach" とか
"Functional Design Methodology" とか検索かけてみたけど、
PDF で読めるものでめぼしいものが見つけられなかった
（キーワードが悪いのかな）

482 ：デフォルトの名無しさん：2011/10/22(土) 21:45:11.08

別に特別な手法は必要じゃなくて、
C言語で書くときと同じように設計すればいいと思う

483 ：405：2011/10/22(土) 23:44:42.55

UMLが役に立つかどうかは、人によるところもあるから、さておいて、
>>476はclass diagramしか知らないじゃないの?
Interaction daigram, State diagram, Activity diagramは、
関数型言語でも使えるでしょ。

class diagramにしても、simonpj先生がHaskellのtype definitionは、
UMLのようにhigh level designなので、programで扱いやすいと言った例が。

484 ：デフォルトの名無しさん：2011/10/22(土) 23:52:20.99

State diagram と関数型言語って相性いいの？

状態をできるだけ持たないような設計を目指すのが関数型だと思ってたけど

485 ：デフォルトの名無しさん：2011/10/23(日) 00:41:49.11

状態を引数で渡して、遷移した状態を返値で受け取って、それをまた引数で渡して・・・
っていうのを繰り返すのをState diagramで管理する？

486 ：デフォルトの名無しさん：2011/10/23(日) 00:43:43.69

状態を持たないものしか作らないの間違いだろ

487 ：デフォルトの名無しさん：2011/10/23(日) 00:57:26.36

>>483
で、UMLの中で最も知られている/大切な class diagram に相当する視覚的表現というのは
関数型設計パラダイムには存在するの？自分は知らない.... 存在しないんじゃないのかな

488 ：デフォルトの名無しさん：2011/10/23(日) 00:59:55.87

>>471
そういう用途なら、Groovyの適しているわ

489 ：デフォルトの名無しさん：2011/10/23(日) 01:16:13.92

>>484
>状態をできるだけ持たないような設計を目指すのが関数型だと思ってたけど

基本的にはその通り。ただし、解決すべき問題が本質的に状態を含んでいる場合がある。
たとえば信号機は blue/red/yellow という点滅状態が必要で、それが実世界のプログラミング。

>>485
>状態を引数で渡して、遷移した状態を返値で受け取って、それをまた引数で渡して・・・

そのプロセスを再帰式で定義する方法で正しい。少なくとも Erlang では、そのもの。

というか、state diagram に関しては昔から形式的定義もあるし、関数型設計で活用するのに支障は無い。

490 ：デフォルトの名無しさん：2011/10/23(日) 01:35:14.62

>>483
>class diagramにしても、simonpj先生がHaskellのtype definitionは、
>UMLのようにhigh level designなので、programで扱いやすいと言った例が。

Haskellの type definition は high level design かもしれないが、
それは text representation にすぎない。UMLの visual representation との比較は無意味。
質問の意味を取り違えているし、先生の話を鵜呑みにしては逝けませんという好例だ。

491 ：デフォルトの名無しさん：2011/10/23(日) 02:38:45.93

たとえば、自動販売機の状態遷移図があったとして、それを実装しようとした時、
OOP なら素直にクラスを作って、素直に状態遷移の処理が書ける
デザインパターンにもあるくらいだし

一方、これを関数型で実装しようとすると、状態遷移図の読み取ってから、
それをコードに落とすまでに、素直に作業が進むとは言いがたいと思う
（実際にそういう経験が多々ある）
図ではそれぞれの状態は分かれて書かれているのに、
関数型のコードにすると局所化されずに関係が全体に広がってしまう感じ

なんていうか、図とコードの一体感が薄い

OOP だって図とコードが一対一に対応しているわけでは決して無いんだけど、
OOP の場合は他人のコードを読んで、それを逆に状態遷移図に起こすことも、
そのコードが元々ちゃんとした状態遷移図からコード化してるのなら比較的素直にできる
それくらいには図とコードの一体感がある

関数型の場合、それが難しいと感じるケースが多い

状態遷移自体は必要なのだから何らかの図は必要なのだが、
今までの UML の状態遷移図が関数型にフィットしていないのか、
それともそれを関数型のコードに落とす手法に問題があるのか、
それとも単に私がまだまだ未熟なだけなのか

492 ：デフォルトの名無しさん：2011/10/23(日) 04:41:02.62

そんな難しいことここで言うなよｗ

493 ：デフォルトの名無しさん：2011/10/23(日) 05:59:43.71

状態という考え方と関数型プログラミングとは馴染まないんだよ。
そもそも状態遷移をガンガン使うって事は変数の値を次々に書き変える事で処理を進める手続き的パラダイムで考えてるって事だからね。
もちろん、そういうパラダイムの処理を関数型でシミュレートする（状態を表す引数を次々に渡す）事はできるが、
本来の関数型のパラダイムはそういう変数への破壊的な代入（バインディングとは等価でない代入）を避けるべきだという哲学に基づいているから
馴染まなくて当然だし、そういう状態遷移の処理を書くのならば関数型よりも手続き型の方が自然に書けて当然なんだよ。

494 ：デフォルトの名無しさん：2011/10/23(日) 08:26:39.32

>>491-493
お前らにまとめて聞きたい
お前らはCのような手続き型言語であれば状態遷移機械を書けるのか？
実は書けない、あるいは今まで書いた事が一度も無いんじゃないのか？
情けない奴ら、お前らの将来はIT土方一直線で決定だ

反論があるなら、その前にまずWikipediaでトピック「有限オートマトン」にある
数学モデルの節を読め
ここではトランスデューサ型で決定性オートマトンだけを見ればいい
面倒であればトピック「ミーリ・マシン」を直に見てもいい

これだけ簡潔な数学的定義があるのに、まだ難しいとか馴染まないとか言うつもりか？！

495 ：デフォルトの名無しさん：2011/10/23(日) 08:33:19.05

foldlは実はミーリマシンなんだよな

496 ：デフォルトの名無しさん：2011/10/23(日) 08:37:33.40

>>493
>本来の関数型のパラダイムはそういう変数への破壊的な代入を避けるべきだという

再帰的に状態値を次々に渡していくのなら、破壊的代入にならないのではないかと....小一時間

497 ：デフォルトの名無しさん：2011/10/23(日) 10:08:38.46

状態絡みはFRPに落とし込めばおけー(´・ω・｀)

498 ：デフォルトの名無しさん：2011/10/23(日) 10:12:57.04

>>491
状態機械を素直に書けない関数型言語があるってのはちょっと信じられない
>それともそれを関数型のコードに落とす手法に問題があるのか、
>それとも単に私がまだまだ未熟なだけなのか
このどちらかだと思う

具体的なコーディングは次のような感じ

1. 各状態に対応する関数を一つづつ作って、それらが
次状態に対応する関数を末尾呼び出しするようにする
コーディングは楽だけど、状態機械側から能動的に入力を取ってくる方法がある場合に限る

2. そうでない場合は、状態に対応する型を定義する
2-1. 一般には関数を使う。Haskellの記法で、
newtype State = State (Input -> IO (Output, State))
みたいな
2-2. 一目で全体を見渡せる小さい状態機械なら、具体的な列挙型のほうが楽なこともある
data State = State1 | State2 | State3...
みたいな

Haskellだと、スレッド+チャネルを使ったり継続モナドを使ったりすれば、あらゆる状態機械を1.の方法で書ける
（そのぶんコードが複雑になるので、本当にやるかどうかはケースバイケース）

499 ：デフォルトの名無しさん：2011/10/23(日) 10:13:50.54

FRPはまだまだ使えない技術
M$もRxでReactiveの方にも力入れてたのに結局Async選んだからな

500 ：デフォルトの名無しさん：2011/10/23(日) 10:14:30.34

>>493
状態遷移を避けるべきなんて言ってる関数型言語は聞いたことがない
(教科書にはそう書いてあるかもしれないが、それは手続き型言語にどっぷり漬かった
学習者のための方便で、実際にコードを書くときに盲目的に従うものじゃない)
大抵、一つのプログラムには、関数的に書いた方が素直な部分と
手続き的に書いた方が素直な部分が共存してる
いわゆる実用的な「関数型言語」は、この両方を簡単に扱えるように作られてる

501 ：498：2011/10/23(日) 10:18:06.84

あ、「型を定義する」うんぬんは、静的型付けの言語を想定してた
動的な場合は、頭の中かコメントで定義すれば良いはず

502 ：デフォルトの名無しさん：2011/10/23(日) 10:34:59.09

>>499
AsyncとFRP（Rx)は別物だよ。
Asyncは主にIOなどの実行に時間がかかるものに対しての継続の制御方法で、Rxは解釈にもよるだろうがデータフローの意味合いが強く、その中に継続のコントロールも入っていて両者を組み合わせて使うことも可能。

503 ：デフォルトの名無しさん：2011/10/23(日) 10:36:17.43

関数型は状態を持たないと言うよりも、"副作用の原因となる"状態を持たない。

504 ：デフォルトの名無しさん：2011/10/23(日) 10:40:34.61

でも正式採用されたのはAsyncだけだよねっていう

505 ：494：2011/10/23(日) 10:52:37.48

>>498,500
ようやく、平常な水準で語ってくれる人が登場してくれて安心した

自動販売機/信号機/通信プロトコルといった実時間システム(Real Time System)は、
動いて当たり前、バグ0で数年間連続稼働するのがマジで求められる世界
病院の生命維持装置や宇宙船の航行制御装置などを想像すれば分かってもらえるハズ
だから、そういったソフトウェア品質/安全性を求む組み込み系の開発現場(の一部?)では
堅固な型体系を持つ関数型言語への強い期待があったりする

そんな訳で、関数型言語に状態機械は馴染まない/難しいみたいな発言は哀しいんだYo....

506 ：デフォルトの名無しさん：2011/10/23(日) 11:14:55.76

そういう人たちが言う関数型ってhaskellみたいなもんじゃなくてStrong functional programmingとかTotal Functional Programmingのことでしょ
依存型がもっと軽量に扱えるようにならんと話にならん

507 ：494：2011/10/23(日) 11:33:03.10

>>506
そのStrong functional programming/Total Functional Programmingとは何？
少なくともHaskellはシミュレーションやモデル検証には適しているかもしれないが、
状態機械の「実装言語」としては全く認識していない。(今のC/C++実装を置き換えたい....)
軽量/簡潔な言語仕様のSML処理系を候補にしたいと思ってる。(OCamlは仕様/実装とも重すぎ)

508 ：デフォルトの名無しさん：2011/10/23(日) 11:36:26.03

http://en.wikipedia.org/wiki/Total_functional_programming

509 ：デフォルトの名無しさん：2011/10/23(日) 11:50:54.55

>>508
Total_functional_programmingって初めて知るけど、全域関数しか認めない帰結として無限ループが使えない、よってチューリング完全ではない、という理解でO.K.？
無限ループが使えない、って組み込み系としてはかなりダメダメのような…

無限ループが絶対に使えない「安全な領域」と無限ループがありえる「危険な領域」を、C#のunmanaged codeみたいに、あるいはHaskellのIOモナドみたいに隔離してあつかえる言語が望ましいのかも

510 ：デフォルトの名無しさん：2011/10/23(日) 12:10:59.72

たとえば状態Ａと状態Ｂ、状態Ｃがあるとする
今状態Ａであるときにイベントｘが起きたら、
状態Ａが保持してる内部の変数の値とxで計算して、
その結果ｙをまた状態Ａの内部変数に格納する
ｙの値によって次に状態Ｂか状態Ｃへ遷移する

こういう場合、OOP なら素直に状態毎にクラスを作る
あるいは一つのクラスのインスタンスを状態毎に作る
で、状態Ａを表現するインスタンスのメンバ変数は、
そのインスタンスの中で完結していて外に出ることはない

一方、関数型でこれを実現するとき、
「状態を引数に入れて、計算して、戻り値として状態を返す」
ということを（再帰的に）繰り返すという方法をとると、
状態Ａの内部変数に相当する値も色んなところへ運ばれる事になる
そうしないと、また状態Ａに戻った時に計算できない

また、Haskell の State モナドのような仕組みを使っても同じ
本来は内部に閉じ込めておくべき情報が外に出ることに変わりはない

たとえ何らかの方法で、状態Ｂや状態Ｃの計算をしてる時には
状態Ａの内部変数に相当する値にはアクセスできない仕組みがあるとしても、
その仕組みを作っている時は、色んなところへ情報が漏れることを
ちゃんと意識してプログラミングする必要がある
（一般的な OOP ならその仕組みは改めて作る必要は無い）

また、状態Ａの計算の最後に状態Ｂを末尾呼び出しする方法は、
状態間の繋がりがますます強くなる

情報の漏れと結合度の強さ、これらをもう少し改善する方法はないだろうか

511 ：494：2011/10/23(日) 12:11:59.06

>>508
紹介ありがとう
ただ、ざっとリンク先を読んでみたけど明らかに違う
そういった数理的な完全性という狭い分野での品質向上を求めているわけじゃなくて、
開発工程全体に渡る効果を期待しているし、現状を一切切り捨てるという判断は到底無理

おそらくリンク先のトピックはCafeObjのような形式的手法やCoqのような定理証明系、または
このスレならHaskellベースの帰納的な(純粋関数型の?)設計手法が該当するんだろう
そういった手法は提供範囲を限定すれば効果はあるだろうけど、開発工程全体への波及は期待できない
たとえば仏生まれのCoqなら、もしOCaml処理系全体の定理証明が完成すれば認識を改めたい

512 ：デフォルトの名無しさん：2011/10/23(日) 12:14:18.96

チューリング完全でないのはその通りだけど、
何かを出力し続ける、あるいは外界と相互作用する無限ループは(余再帰という形で)扱えるはず
特定の値を求めるべき関数が無限ループするのは禁止

513 ：デフォルトの名無しさん：2011/10/23(日) 12:17:44.03

>>510
> 一方、関数型でこれを実現するとき、
> 「状態を引数に入れて、計算して、戻り値として状態を返す」
> ということを（再帰的に）繰り返すという方法をとると、
> 状態Ａの内部変数に相当する値も色んなところへ運ばれる事になる
> そうしないと、また状態Ａに戻った時に計算できない

ん？？？　ここが不可解
それって、あなたがいっているOOPでも、状態Aから状態Bに遷移しても「状態Aのインスタンス」を保持しておいて、状態Aに戻ったときにそれを復帰させるってこと？

それはもう状態マシンの設計として破綻してない？
なんか、状態マシンと別の何かをごっちゃにしているような・・・

514 ：509：2011/10/23(日) 12:20:59.83

>>512
余再帰とか高度なことは分からないので十分に理解できないけど、考えてみると、
たしかにほとんどの「無限ループ」はプログラム全体（あるいはエントリポイント）をインプットからアウトプットへの関数として定義すれば、
いいような気はする。

515 ：デフォルトの名無しさん：2011/10/23(日) 12:22:15.05

>>510
情報の漏れに関してはHaskellやOCamlならモジュールで隠す
隠蔽の単位がクラスからモジュールになっただけで、一般的なOO言語とそんなに違わない

結合度については、状態機械なら、自分が次にどの状態に
移行するかを知ってなきゃいけないのは仕方ないんじゃね

516 ：デフォルトの名無しさん：2011/10/23(日) 12:27:29.68

>>510
let..inとかwhereで関数内関数（または変数）じゃ駄目なん？
モジュールだって在るし。

517 ：デフォルトの名無しさん：2011/10/23(日) 12:50:22.99

ＧＣあるとリアルタイム制御厳しいよね
ＧＣのない関数型言語ってあるのかな？

518 ：デフォルトの名無しさん：2011/10/23(日) 12:55:01.75

>>517
実験レベルのものなら
https://github.com/pikatchu/LinearML

519 ：デフォルトの名無しさん：2011/10/23(日) 13:00:15.82

ぴかちゅー
線形型か・・・

520 ：デフォルトの名無しさん：2011/10/23(日) 13:03:37.00

>>517
遅延評価の関数適用順序がリアルタイム性も考慮して進化してったら、そう言う用途にも使える様にならんかな。。。

521 ：494：2011/10/23(日) 13:04:09.78

>ＧＣあるとリアルタイム制御厳しいよね

[過去] Linuxでリアルタイム制御厳しいよね
　　　組み込み系にJava VMって重すぎるよね

[現在進行形] 組み込み系にRubyって.......

勘弁しておくれ

522 ：デフォルトの名無しさん：2011/10/23(日) 13:08:08.48

>>513
正直、何か別のものと混同してる感じは自分もする
状態マシンというものを勝手に拡張して解釈しているかも知れん

結合度の事はとりあえず置いておいて、>>510 の前半で言いたかったのは、
C# だとこんな感じなる状態遷移の実装（文法や初期化とかは気にするな）
実際に状態遷移させるのは別のクラスで状態遷移表なんかを使ってやってるとする

class State {
public int next (int e);
}

class StateA : State {
private int x;
public State next (int e) {
x = f(x, e); // 適当な関数 f によって計算
return x;
}

状態Ａの次にどの状態に遷移するかは状態Ａのメンバ関数 next の戻り値に依るんだけど、
その戻り値が状態Ａが保持してるメンバ変数 x に依存してる
つまり、状態Ａのメンバ変数 x はずっと保持しておかなければならない
他のクラスのインスタンスからもアクセスされてはいけない

こういうパターンって普通にあるよね（ゲームなんか作ってるとよくある）

これ、関数型（わたしは Haskell しか使えないけど）だと、
自分では未だになかなか綺麗に関数型らしく書けなくて毎回悩むところ
（IORef で妥協するのは何か気持ち悪い）

523 ：デフォルトの名無しさん：2011/10/23(日) 13:13:26.14

>>522
まぁ IORef 使ったって、結局その IORef 型の変数の値を運ぶことになるんだけどね

524 ：デフォルトの名無しさん：2011/10/23(日) 13:20:17.85

関数型らしく書こうとするのを止めればいいんじゃね
IORefを使って綺麗に書けるならそうしない理由はないと思う

525 ：デフォルトの名無しさん：2011/10/23(日) 13:21:45.28

大抵のFRPはそのIORefのプールを保持して適切にアップデートするような作りになってるな
とりあえず上のコードで喩えるとxが消えて
見かけ上はStateAはeと別の信号fから違う信号を生成するってだけの関数ぐらいには楽に変えられる

526 ：デフォルトの名無しさん：2011/10/23(日) 13:29:53.83

成熟したFRPライブラリが存在しない現状、
アプリ全体を関数型でかっこよく書くのは諦めた方が速い

527 ：デフォルトの名無しさん：2011/10/23(日) 13:30:09.36

なんだかんだで関数型言語は組込でもRubyに負けちゃうのかな。

528 ：デフォルトの名無しさん：2011/10/23(日) 13:33:46.08

>>522
それ Haskellなら

module State (State, next) where
class State s where
　next :: s -> e -> s

module StateA (StateA(), stateA) where
data StateA = StateA Integer

sateteA = StateS

instance State StateA where
next (StateA i) e = f i e
　　where
　　　f = ...

みたいにすれば良いんじゃね？

529 ：494：2011/10/23(日) 13:35:04.52

>>522
状態機械どころか、OOP(GoF)のState Patternですらない

クラス名 State や StateA は状態という概念である必然性が無い。
たとえば Room と RoomA や Level と LevelA でもかまわない。
単にあるオブジェクトが別のオブジェクトへ変化するだけ。
それは状態機械ではないし、State Pattern ですらない。

530 ：デフォルトの名無しさん：2011/10/23(日) 13:36:08.51

回路設計に関数型言語とかあったけどあれも死んだっぽいな
証明支援系を利用した超強力な形式手法をサポートしたものぐらいじゃないと
手続き型でもどうにかなるものに対しては置き換える価値を示せないのだろうな
逆に言えばそういうのじゃないとどうしようもない複雑すぎる問題が増えてくれば自然にそっち方向にシフトしていくと思う

531 ：デフォルトの名無しさん：2011/10/23(日) 13:43:54.98

>>527
秋月電気にpic様のbasicインタプリタ置いてる時点で、rubyの方がまだ可能性は在るんだろうな

532 ：デフォルトの名無しさん：2011/10/23(日) 13:49:49.54

>>525
大抵のFRPがどれを指してるのか分かんないんだけど、
たとえば Yampa や reactive は確かに内部で IORef は使ってる

でもそれって、それらのライブラリ内で自身の構造を保つ為に使ってるのであって、
そのライブラリのユーザー側が定義した情報を遷移させても保つ為のものでは
ないような気がするんだが

もう一度 FRP ライブラリをよく見てみます

>>528
StateA --> StateB --> StateC --> StateA と回った時、
最初に StateA の next を計算した時の値は、
次の StateA の next を計算する時にまた使わなければならないけど、
それはどこかに保存しておくか、遷移時に運ぶデータとして連れて行かないといけない

>>529
やはり勘違いしていたか
申し訳ない、全然話が別だったね

じゃあ、状態機械とか State Pattern の話ではなくて、
純粋に単なる >>522 のようなパターンの時に、
関数型ではどうしてるのかなという話で
（わたしはこういうパターンでも、同じような図を描いて設計してた）

533 ：デフォルトの名無しさん：2011/10/23(日) 14:54:25.29

ハード的には状態機械は
f.reset(env, orig_state) -> f(env, state)
f(env, state) -> f(env, state')
ってな形のフィードバックループで実現するんだが,

state を変数にするか，関数の名前のにするのか程度の違いじゃないのか?

f の内部レジスターが state になることがほとんどだから,
個人的には，関数名が違ってる方が理解しやすいが...

# つか, わざわざ外部に状態用のレジスターを作るのはトランジスタの無駄

534 ：デフォルトの名無しさん：2011/10/23(日) 15:18:51.26

とんちんかんな事いっているかもしれないが
組み込みとリアルタイム制御を混同しているような
人に待ってもらえるアプリならばrubyでも問題ない

車の制御系をlinux,java,ruby,haskellでできるのか
ブレーキかけた時にGCが始まってしまうと困るのだが

関数型言語がすばらしいというのはわかるが
じゃあ、C、アセンブラに代わりうるものなのかな

535 ：デフォルトの名無しさん：2011/10/23(日) 15:23:21.87

>>534
リアルタイム制御の話は一瞬出て、一瞬で終わっただろ

誰もCやアセンブリに代わるとも言ってねぇし

536 ：デフォルトの名無しさん：2011/10/23(日) 16:12:54.58

でも当然研究はされてると思う

537 ：デフォルトの名無しさん：2011/10/23(日) 19:28:33.75

研究されているとかイチイチ気にしないほうがいいぜ。
どうせドンピシャな研究してても説明下手くそなのと、よくわからん秘密主義で
余計コストかかるだけだよ。

538 ：デフォルトの名無しさん：2011/10/23(日) 20:13:16.50

この手の研究は大抵 SIGPLAN に論文が投稿されて、
たった25ドルで一年間読み放題だ

539 ：デフォルトの名無しさん：2011/10/23(日) 22:11:17.49

ソフトリアルタイムシステムまでは
Erlangっていう実績がある
RubyのRiteもソフトリアルタイムまでをターゲットにしていたはず

問題はハードリアルタイムなシステムで、
NASAの国際宇宙ステーションだったかの、制御プログラムが仕様通り動作することを
定理証明支援系で検証した話を聞いたことが、あるような無いような

540 ：デフォルトの名無しさん：2011/10/24(月) 04:38:46.24

>>496
> >>493
> >本来の関数型のパラダイムはそういう変数への破壊的な代入を避けるべきだという
>
> 再帰的に状態値を次々に渡していくのなら、破壊的代入にならないのではないかと....小一時間

だから変数への破壊的代入に比べて引数を引きずり回さねばならないってのは不自然あるいは煩雑な記述だろうが。
状態遷移の考え方から素直に生まれたのが内容を破壊的に書き換え可能なメモリとそれへの代入命令をベースとする
手続き型プログラミングのパラダイム。
関数型プログラミングのパラダイムでベースとなっている概念はメモリを用いずに値をどんどん変換という考え方。

541 ：デフォルトの名無しさん：2011/10/24(月) 09:36:18.43

>>540
破壊的な代入を隠蔽したのがFRPだと思ふ(´・ω・｀)

542 ：デフォルトの名無しさん：2011/10/24(月) 09:49:23.20

隠蔽してメリットあんの？

543 ：デフォルトの名無しさん：2011/10/24(月) 10:06:52.98

>>540

>>496のつっこみはたしかに日本語に不自由している感じはあるが、一般論として

> だから変数への破壊的代入に比べて引数を引きずり回さねばならないってのは不自然あるいは煩雑な記述だろうが。

というのには反論したい。

例えば、ある種のステートマシンは、Haskellなら

state1 (Event1:es) = state2 es
state1 (Event2:es) = state3 es
state2 (Event1:es) = state1 es
state2 (Event2:es) = state3 es
state3 (Event1:es) = state1 es
state3 (Event2:es) = state2 es

みたいに書くことができる。

これは破壊的更新を避けて値を引きずり回しているけど、破壊的更新をするよりも、自然かつ簡明になっていると思う。

544 ：405：2011/10/24(月) 19:10:41.86

>>539
昔オランダでマイナス標高地の水位制御のシステムが関数型言語で書かれたことあるよ。
後にConcurrent Cleanにつながる処理系だったと記憶するけど、言語名は忘れた。

545 ：405：2011/10/24(月) 19:21:09.07

Deforstration！

546 ：デフォルトの名無しさん：2011/10/24(月) 22:54:52.70

>>542
関数型的に扱える別にFRPが破壊的代入を必ずしもしてるという意味ではないけど。

547 ：デフォルトの名無しさん：2011/10/25(火) 08:23:40.94

jp.techcrunch.com/archives/20111024creator-of-lisp-john-mccarthy-dead-at-84/

548 ：デフォルトの名無しさん：2011/10/25(火) 13:31:30.59

http://mainisusuallyafunction.blogspot.com/2011/10/quasicrystals-as-sums-of-waves-in-plane.html

この手のグラフィックってやっぱり関数型が得意とするところかな。

549 ：デフォルトの名無しさん：2011/10/25(火) 13:58:37.19

５４８に関連して、http://repa.ouroborus.net/
を見てて、下のデモを見てるとリアルタイムで動いてるようよ

550 ：デフォルトの名無しさん：2011/10/26(水) 00:35:42.34

関数型ｗ
OOが新しかったころと同じｗ

551 ：デフォルトの名無しさん：2011/10/26(水) 00:40:50.31

それはオブジェクト指向のように
関数型もいずれ広まるという意味？

552 ：デフォルトの名無しさん：2011/10/26(水) 00:42:46.21

普通に広まるでしょ。
といっても既存の言語に特徴が取り入れられたりってのも含めてだけど。
そういう意味ではすでに広まっているとも言えなくもない。

553 ：デフォルトの名無しさん：2011/10/26(水) 01:03:22.77

ooよりインパクトもメリットも小さい

554 ：デフォルトの名無しさん：2011/10/26(水) 01:04:18.36

ooにメリットなんて無かった

555 ：デフォルトの名無しさん：2011/10/26(水) 01:20:18.73

>>553
OOのほうがインパクトが大きいというのはあるかなー
でもどちらかというのではなくOO+関数型となるというのが正解だと思う。

556 ：デフォルトの名無しさん：2011/10/26(水) 01:43:18.68

関数型の人間にとって、OOって「無用の長物」になりがちだからね。
OO慣れした人が大切だと思ってたあんなことこんなことがことごとく
関係がないという世界だしね。

マルチバラダイム言語になってきてるけどさ。common lispはシンプ
ルだけどカッコで敬遠されて、C++は泥沼のような状態なってったよね。
手続きが関数型の要素を入れてきてるけど、どれも複雑怪奇な
傾向は残ってるよね。更に複雑怪奇な方向に舵を取ってる印象
もあるよね。あのままじゃ超えられない壁があると思うよ。

ハードウェアの方向性とも関連してくるけど、ようやく関数型の
Meritが生かされる時代に変わってきたと思うよ。関数型はLisp
から始まったので、まだ５０年くらいしかない。５０年たってようやく
という感じだと思うよ。

557 ：デフォルトの名無しさん：2011/10/26(水) 01:47:25.32

GUIは状態が基本だし関数型は部分の開発効率向上寄与にとどまるよ

558 ：デフォルトの名無しさん：2011/10/26(水) 02:00:16.54

>>557
GUIとか、正直、どうでもいい。

559 ：デフォルトの名無しさん：2011/10/26(水) 02:09:42.94

>>557
入出力まわりはことごとく状態だからね。そこを上手に扱う方法
は一応Haskellでも考えられてるよね。副作用のある場所と
ない場所をわけられる利点があることをお忘れなく。
もちろん、Haskellほど処女っぽさのない関数型も多数あるからね。

560 ：デフォルトの名無しさん：2011/10/26(水) 02:13:22.15

>>557
FRPの概念取り入れればM、VMの部分は状態の概念をだいぶ無くせる。

561 ：デフォルトの名無しさん：2011/10/26(水) 02:25:36.77

>>559
純情関数型言語Haskell

562 ：デフォルトの名無しさん：2011/10/26(水) 04:20:15.12

なんだか>>558が可哀相な人の気がしてきた

563 ：デフォルトの名無しさん：2011/10/26(水) 07:24:48.55

>>557
gui関数型で書きやすいんだが、、、

564 ：デフォルトの名無しさん：2011/10/26(水) 08:50:23.16

>>559
入出力以外にも沢山の状態を扱うことはあるから
手続き型自体は無くならんだろうけどな

565 ：デフォルトの名無しさん：2011/10/26(水) 09:15:14.90

あまりの反応ばかりワロタ

566 ：デフォルトの名無しさん：2011/10/26(水) 09:30:59.38

>>564
なくなることはないだろうし、関数型が今までより盛んになる環境が整った
というだけの話だよ。少なくとも手続きはブルーカラー言語として絶対に残るよ。

567 ：デフォルトの名無しさん：2011/10/26(水) 10:03:27.06

なにも作れないホワイトカラーｗ

568 ：デフォルトの名無しさん：2011/10/26(水) 10:26:32.86

>>567
ブルーカラーの設計がくそで、マジやめてほしい。
会社で100ms スリープポーリングとかバカなの？死ぬの？

569 ：デフォルトの名無しさん：2011/10/26(水) 10:27:52.07

つーか俺がお前に殺されるっつーねん
手続きゆとりマジ悪魔

570 ：デフォルトの名無しさん：2011/10/26(水) 10:50:17.52

手続きと関数型って右利き左利きのアナロジーと同じだね。
社会が右利き向けに作られてるから右利きに有利になってるし、
左利きは右利きに矯正されることも多かった。
左利きの人には両手利きになる場合もあるけど、右利きから
両手利きは生まれにくい。

同じように、手続き言語に合うハードウエアの世界に生きてるから
手続きが有利にはなってる。関数型をやったところで手続き型も
学ぶ必要が多くなってる。当然、関数型使いは手続き型も使える
人が多いけど、手続き型から関数を触れる人は少ない。

だから手続きは生き残っていくとは言えるだろう。

571 ：デフォルトの名無しさん：2011/10/26(水) 10:53:20.72

君が社長になってブルーカラー退職させて全員ホワイトカラーにすればいい。

572 ：デフォルトの名無しさん：2011/10/26(水) 11:00:23.40

様々な新技術が関数型で生まれ、手続き型に輸入されるって図式が続いてるし
今後もそういう関係が続いてくんじゃないかなあ
「今の関数型」が普及する頃には、今の関数型の要素は
手続き型言語にも常識となって入ってて
その頃には関数型言語ってのはもっと先を行ってるのでは

573 ：デフォルトの名無しさん：2011/10/26(水) 11:58:05.35

>>556
> ハードウェアの方向性とも関連してくるけど、ようやく関数型の
> Meritが生かされる時代に変わってきたと思うよ。関数型はLisp
> から始まったので、まだ５０年くらいしかない。５０年たってようやく
> という感じだと思うよ。

Lispは手続き型言語の元祖とも言うべきFortranやCobolと同じぐらい古くからある言語だぞ
そもそも機械語によるプログラミングを脱して最初の高級言語たちが開発されてから50年余りしか歴史がない

574 ：デフォルトの名無しさん：2011/10/26(水) 17:42:42.65

LISPつくったジョン・マッカーシーが亡くなったというのにお前らと来たら

575 ：デフォルトの名無しさん：2011/10/26(水) 18:36:42.95

>>574
別にLISPが無くなるわけじゃねーからいいんだよ！(´Д⊂ｸﾞｽﾝ

576 ：デフォルトの名無しさん：2011/10/26(水) 18:47:23.20

関数型の親がなくなったから >>547でさり気なく話題を出して、さらに
>>556でさらにそれを意識させるようにしてきてたんだけど、無関心すぎて
残念に思ってたところなんだよ。>>574-575

577 ：デフォルトの名無しさん：2011/10/26(水) 18:54:44.63

しかしむしろ現代風の関数型言語の祖といえるミルナーさんは昨年すでに亡くなられてしまったし

578 ：デフォルトの名無しさん：2011/10/26(水) 18:55:31.40

作品が偉大なのであって、作者はどうでもいい

579 ：デフォルトの名無しさん：2011/10/26(水) 18:55:37.53

LISPは生き続けるさ、俺たちの心のなかにな！

使えよ！

580 ：デフォルトの名無しさん：2011/10/26(水) 19:35:30.84

lispは関数型言語としては終わってる言語
略してｵﾜ関

581 ：デフォルトの名無しさん：2011/10/27(木) 16:32:00.38

関数型言語のスレが厨の集まりになる時代が来るなんて…

582 ：デフォルトの名無しさん：2011/10/27(木) 17:08:09.38

>>581
haskellのところを見てみろよ。思いっきり荒らされてる。自演っぽい連続投稿でね。

583 ：デフォルトの名無しさん：2011/10/27(木) 19:18:47.56

関数型言語もいよいよメジャーになってきたということだな

584 ：デフォルトの名無しさん：2011/10/27(木) 19:35:39.18

まあな。その反面、ここもこれまでのような役割はできんだろうな。
悪貨は良貨を駆逐する(グレシャムの法則)を地で行く展開になってしまうからね。
Haskellスレなんてもうそうなってる。

585 ：デフォルトの名無しさん：2011/10/27(木) 19:48:20.26

これまでどような役割だったのか

586 ：デフォルトの名無しさん：2011/10/27(木) 22:38:38.78

自慰行為

587 ：デフォルトの名無しさん：2011/11/10(木) 19:47:23.83

F#のIDE適性って潜在的にC#を超えれるんですか？

588 ：デフォルトの名無しさん：2011/11/10(木) 19:50:56.82

人が型を書かない分、型推論が働く。と言う意味ではC#よりはIDEとの相性悪いかも。

589 ：デフォルトの名無しさん：2011/11/10(木) 22:30:20.73

型書かなくていいんだからそもそもいらない

590 ：デフォルトの名無しさん：2011/11/11(金) 07:47:29.18

いや、単に同じ機能は実装出来るだろうけど、若干は重くなるだろうなって。。。

591 ：デフォルトの名無しさん：2011/11/11(金) 12:42:01.57

>>590
> 若干は重くなるだろうなって。。。

若干というのがどの程度を想定してるのか知らんが、
体感できるほど遅くなるとは思えない

インタプリタが問題なくリアルタイムに処理している型推論の仕事を
IDE に実装して遅くなるなんて、まず考えられん

592 ：デフォルトの名無しさん：2011/11/19(土) 10:47:32.74

http://scan.netsecurity.ne.jp/article/img/2011/11/13/27625/93.html
tokuhirom、ma.la？っていう人の話だけ聞きたい
色々なスレで見かけるけどWEB業界で有名らしいね
動画ありませんか？

593 ：忍法帖【Lv=40,xxxPT】：2011/11/28(月) 01:40:47.97

bump!

594 ：デフォルトの名無しさん：2011/11/28(月) 19:43:49.77

>>580
lispはclojureとなって生まれ変わりました。
っていうかもう使ってるし。
scalaでもコード量1/4程度にしかならんかったけど、clojureだと1/10とか
になったりする。
ていうかマクロなにこれ最強すぎ。

595 ：デフォルトの名無しさん：2011/11/28(月) 20:07:53.87

俺は、比較的小さくない規模のアプリ作ってると、
コード量というものの重要度が低くなっていく

それよりも、自分の昔のコードを見て
何をやってたのかすぐに思い出せるとか、
他人のコードを見て計算を追うのにイライラしない、
という意味でのコードの可読性の方が大事になってくる

コードの可読性を増すためなら、コード量が10倍になっても気にならん
それでも、たいてい計算量は10倍も増えんし

当然、可読性を高めて、かつコード量が減らせれば尚良いが

596 ：デフォルトの名無しさん：2011/11/28(月) 20:26:11.44

>>595
そのへんClojureスレにNovigの作法の文章の和訳のURLを貼ったから
そっちを参考にしてくれ。あの考え方は関数型やってれば参考になることは
多いと思うんで。594とは別人ですがね。
英語が良ければ下記をどうぞ
http://webcache.googleusercontent.com/search?q=cache:P6VhrTuoxPUJ:norvig.com/luv-slides.ps

597 ：デフォルトの名無しさん：2011/11/28(月) 20:41:37.92

>>596
いや、すまん
Clojure がどうとか lisp がどうとかという話じゃなくて、コード量に反応した
（Clojure は名前と、lisp をベースにした事くらいしか知らん）

例えばブロック崩し程度の小さなゲームを作ってる時でも、
あの言語ならこのコード量をもっと減らせるのになぁ、
と思うことなんて俺は無いなという話

あの言語（のあの構文）ならもっと分かりやすく書けるのになぁ、
と思うことはあるけど

その分かりやすさにはシンプルというのも入ってて、
結果的にコード量が減らせるかもしれんが、
あくまで羨望してるのは分かりやすさであってコード量じゃない

極論を言えば、コード量なんて言語のアドバンテージにならん、という持論の話

それはそれとして、Novigの作法とやらには興味あるので読んでみるよ

598 ：デフォルトの名無しさん：2011/11/28(月) 21:39:47.83

コードを書く時間の大半は「これなんだっけ」と「いじって大丈夫だっけ」だよね．
コメントや型情報がなかったり，設計がひどくて変更箇所が不明瞭だと，
ぶん殴りたくなるよね，過去の自分を．

599 ：494：2011/11/28(月) 21:59:39.52

>>598
>ぶん殴りたくなるよね，過去の自分を

自分もそうだから、ワロタよw

600 ：デフォルトの名無しさん：2011/11/28(月) 22:13:28.29

>>597-599
了解
コメントって大事だよね。コメントのほうが多いことある。苦笑
あと関数名も。関数名だけで難読化すること可能ですもんね。苦笑

601 ：デフォルトの名無しさん：2011/11/28(月) 22:25:28.61

>>600
自分も自分のためにコメントをたくさん書いてる(´・ω・｀)

602 ：デフォルトの名無しさん：2011/11/28(月) 23:19:43.80

アルゴリズムができるだけ素直な式で表現されているとか
静的な部分が手続き的じゃなくちゃんと宣言的に書かれているとか

そういった関数型言語としての「計算式の書き方」
に関しての分かりやすさを俺は言いたかったんだが・・・

まぁいいや

603 ：デフォルトの名無しさん：2011/11/29(火) 09:03:40.53

>>595
コードの可読性ってコード量そのものじゃん。

他人の書いたコードをみるのも
100行みるより10行で済むんだぜ。

604 ：デフォルトの名無しさん：2011/11/29(火) 09:10:25.72

PerlやLispのわけわかめコードで5行になっていたとしても果たして其れがわかりやすいかは疑問だ。

605 ：デフォルトの名無しさん：2011/11/29(火) 09:22:00.68

LISP5行でワケワカメなコードってどんなだよ
あの系列はコード書いた人間がパーザみたいなもんだから
(それが括弧が多くなる理由でもあるんだがw)
どう足掻いても読みにくいが、それでも解りにくくは滅多にならないと思うが…
まあ「やってる処理内容は解るが、それで何がしたいのか解らない」
ってコードは多いんだけどさw

Perlはまあ、仕様の隙を突くような書き方すりゃ解りにくくはなるかな

606 ：デフォルトの名無しさん：2011/11/29(火) 09:23:23.74

コード量を否定するやつは
今後関数を使うな。

607 ：デフォルトの名無しさん：2011/11/29(火) 09:46:26.67

コードの評価指標が明晰さだとして，それに最も大きな影響を与える変数は
コードの長さか，スタイルか，機能か，それとも他の何かか，って話？
それは言語ごと違うんじゃないかな……

608 ：デフォルトの名無しさん：2011/11/29(火) 09:49:57.60

これが関数脳ですｗ

609 ：デフォルトの名無しさん：2011/11/29(火) 11:35:28.14

まあ確かに
「コード量をいかに少なくできるかコンテスト」
で優勝するようなコードは論外だな。

一方で適切に関数を導入して重複コードを書かないのも意義がある。

こういうバランスのとれた概念
を一言で表すことが出来れば
いいんだけど。

610 ：デフォルトの名無しさん：2011/11/29(火) 12:32:06.99

>>609
「分かりやすいコード」

611 ：デフォルトの名無しさん：2011/11/29(火) 12:56:05.88

ゴルフ的な意味で短いというならば、それはあまり意義はないと思う。
でも、関数を簡潔に書ける人は、多くの関数を
５行までで書いてしまう。分岐があってもせいぜい１０行だ。

612 ：デフォルトの名無しさん：2011/11/29(火) 13:00:25.08

>>605
たぶん604にはmap系/reduce/filterなどが入り組んだ５行は読めないんだろう。
あるいは、マクロで関数やマクロを作る系統の入り組んだマクロも５行クラス
でかけないことはないかな。
初級者ではこの２つは厳しいからな。

613 ：デフォルトの名無しさん：2011/11/29(火) 19:37:34.21

リスパーな方達は、他人の書いたマクロは
自分の頭の中でスラスラと処理を再現できるものなのでしょうか？

614 ：デフォルトの名無しさん：2011/11/29(火) 20:19:17.90

短く書くためには、仕様も大事だと思う
プログラムにしたときになるべく例外処理の少ない自然な仕様じゃないと

615 ：デフォルトの名無しさん：2011/11/29(火) 20:41:49.63

>>613
つmacroexpand-1

マクロ展開コードはどれだけ効率後回しでわかりやすさを追求しても
バチは当たらないってばっちゃが言ってた

616 ：デフォルトの名無しさん：2011/11/29(火) 21:41:00.17

>>615
プログラムが記述された文字列を
そのまま「読んで」「理解できるか」という意味で訊きました

やはり、他人のマクロは展開しないと読めないものなのでしょうか

617 ：デフォルトの名無しさん：2011/11/30(水) 00:16:13.10

あまり変な書き方をしてなければただのリスト処理だから
リスト処理が読めれば読める

618 ：デフォルトの名無しさん：2011/11/30(水) 00:40:02.56

Schemeのsyntaxマクロもパターンマッチを知ってれば読める
ただしdefmacroのようなレガシーマクロで透けて見えたような
単純なリスト処理による置き換えとは違って、マクロシステム
寄りの理解が必要になり、～が判れば誰でもとは言えなくなる

619 ：デフォルトの名無しさん：2011/11/30(水) 00:59:21.28

なれが必要だけどね。Clojureのマクロは更に簡単になってるけど
マクロでマクロや関数を作るようなことをする場合はひと工夫いる。
（多分、作者はこれをさせたくないんだと思う。読みにくさでは悪名高いので。）

620 ：デフォルトの名無しさん：2011/11/30(水) 02:04:03.02

センスの無いマクロの一例
http://www.chino-js.com/ja/tech/srfi/srfi-26/srfi-26.html
こういう一見何が便利なのかさっぱり判らない構文が、
恐らく短くなるというだけで一時期もてはやされたような気がするが
個人的にはやめてもらいたい
素直にlambdaで書いた方がずっと判りやすい

621 ：デフォルトの名無しさん：2011/11/30(水) 07:26:58.38

俺にはすごく読み易く見える
普段Scheme使ってないからかもしれんが

622 ：デフォルトの名無しさん：2011/11/30(水) 08:41:01.61

(cut + <> (* 2 <>))　とかできないし，同じ引数を二度使えないので微妙だったりする．
clojureは　#(+ %1 (* 2 %2)　とかできる．ただしネストできない．いずれにせよ書き捨てには便利．

cutはしたいことがはっきりしている分いいマクロなんじゃないの（loopと同じで好みはあるけど）．

623 ：デフォルトの名無しさん：2011/11/30(水) 10:20:53.21

ネストもいけるBoost.Lambda+Boost.Eggがいかに変態かというのが証明されたな
まぁ>>620での観点だと明らかにアウトなんだけど・・・

624 ：デフォルトの名無しさん：2011/11/30(水) 10:28:39.12

変態の源は式テンプレート

625 ：デフォルトの名無しさん：2011/11/30(水) 13:46:45.39

cutて名前が嫌

626 ：デフォルトの名無しさん：2011/11/30(水) 17:15:12.49

ところで関数型やっててスパゲティコード書いたことある人おる？
OOPみたいなことになりそうにないが。

627 ：デフォルトの名無しさん：2011/11/30(水) 18:54:19.19

一つの関数定義の内部がぐちゃぐちゃなのは良くやる
設計レベルのスパゲッティはたまに

628 ：デフォルトの名無しさん：2011/11/30(水) 19:00:28.23

>>627
その前者の方なら、俺もたまにあるな

でもそういうのってさ、手続き型に比べてけっこう早い段階から気づかない？
このままコーディングしていくとなんかヤバイなって
何となく兆しが見えるというか、そういうのに敏感になる

コードの形の綺麗さを意識するようになるからかな

関数型では、気づいたらスパゲッティだったというのは少なくとも無いな

629 ：デフォルトの名無しさん：2011/11/30(水) 20:11:35.18

このコードはヤバイ、

630 ：デフォルトの名無しさん：2011/12/01(木) 09:28:29.85

この間F#でUIアプリ作ったんだが、確かにややこしくなったところはオブジェクトの部分かなー
Reactive的に書けばすっきりしそうなんだけど。

631 ：デフォルトの名無しさん：2011/12/01(木) 10:44:03.23

スパゲッティコードってのがgotoありきの概念だからなあ。
こっちはこっちでpoint freeとかあるし。
パラダイムよりコーディングスタイルのほうが重要でしょ。
銀など弾丸はないってそういうことでしょ？

632 ：デフォルトの名無しさん：2011/12/01(木) 14:26:57.77

「銀など弾丸はない」、そういうことだろ？ｷﾘｯ

633 ：デフォルトの名無しさん：2011/12/01(木) 14:56:06.82

おまえは小学生か

634 ：デフォルトの名無しさん：2011/12/01(木) 16:34:27.89

おそらくは「銀の弾丸などはない」と言いたかったのだと思うが、
日本語が不自由なところを見ると、関数型言語よりも先に
勉強すべきことが多い小学生レベルのヤシであるのは確かだね

635 ：デフォルトの名無しさん：2011/12/01(木) 16:39:46.32

銀も弾丸は無いあるよ

636 ：デフォルトの名無しさん：2011/12/01(木) 16:55:31.11

銀の弾丸は無いかもしれないけど、銀箔のハリボテ弾丸なら
有りそうだな。やっぱり、猫には銀のスプーンだよ。

637 ：デフォルトの名無しさん：2011/12/01(木) 17:16:29.00

銀玉鉄砲ならあるよ、と返すのがお約束だろ？

638 ：デフォルトの名無しさん：2011/12/01(木) 19:23:11.23

なんの話してるの？

639 ：デフォルトの名無しさん：2011/12/01(木) 21:03:35.37

カリー化って結局関数のタマネギだよな。って話。

640 ：デフォルトの名無しさん：2011/12/01(木) 21:10:14.54

ニンジンやお肉も入れてほしい

641 ：デフォルトの名無しさん：2011/12/01(木) 22:39:44.49

-- wikiカリー化より
特にMLとHaskellでは関数は常に一つの引数のみを取り、複数の引数を取る関
数とは、単にネストされた複数の一引数関数の糖衣構文にすぎない。
--
だから関数タマネギの扱い方の話だなって。

642 ：デフォルトの名無しさん：2011/12/01(木) 22:54:09.38

ハスケルカリー
ハウスザカリー

似すぎてこわい

643 ：デフォルトの名無しさん：2011/12/14(水) 14:12:31.00

関数型言語でもスパゲッティになる(ならざるを得ない)場合はあるでしょう。
自分が使っているコードにもそういう場所があって、反省してみると、
データの再帰的な定義に逆らうかたちでアクセスする場合に起こりがちな気
がします。

例えば、リストのリストを行列見立てて、アクセスすることを考えます。
(例えば、条件を満たす要素をnを取り出すなど)
val xss =
[ [1.0 , 2.0, ~3.0, 4.0]
, [~10.0, 20.0, 30.0, 40.0, 50.0]
, [100.0, ~200.0, 300.0]
, [1000.0, ~2000.0, 3000.0, 4000.0, 5000.0, 6000.0]
]

このときに、列方向(内側のリストに沿って)アクセスする場合は、
要素への操作をfとして
app (app f) xss
と簡潔に書けますが、行方向にアクセスする場合にはかなり複雑に
なります。

644 ：デフォルトの名無しさん：2011/12/14(水) 14:19:16.27

で、fが単純なもの(例:負の数を取ってくる)だと、アクセスする手続きの中
に直接書きたくなりますが、アクセスの複雑さにまぎれて何をしているのか
わかりにくくなります。つぎのようにストリームとして分離すれば多少まし
になるのかも知れません。

(* 横断的に読み取る手続きをつくる関数 *)
fun transReader (xss: real list list) = let
val buf2 = ref xss
val buf1 = ref (nil: real list)
fun hd' xs = case xs of nil => nil | x::xs => [x]
fun tl' xs = case xs of nil => nil | x::xs => xs
fun fetch () =
case !buf1
of nil => (buf1 := List.concat (map hd' (!buf2))
;buf2 := map tl' (!buf2))
| _ => ()
fun get () =
case !buf1
of nil => NONE
| x::xs => (buf1 := xs; SOME x)
in
fn () => (fetch(); get())
end

645 ：デフォルトの名無しさん：2011/12/14(水) 19:43:06.54

>>643
行方向と列方向の認識が一般とは逆のような気がする

xss の例だと 1.0 -> 2.0 -> ~3.0 -> 4.0 という順でアクセスするのが行方向、
1.0 -> ~10.0 -> 100.0 -> 1000.0 という順でアクセスするのが列方向

それはそれとして、リストのリストに対してある方向へのアクセスが扱いにくいのなら、
転置してから扱いやすい方向でアクセスすれば良いだけですよね

貴方が使っている関数型言語では転置が難しいと言うのでしたら申し訳ないが

646 ：645：2011/12/14(水) 19:45:57.77

>>643
スマン

行方向と列方向の認識は >>643 の方が正しいかも
Excel のセルも下向き方向が行方向っていうもんな

647 ：643：2011/12/14(水) 23:32:27.68

>>645
あいまいな書き方をしてしまったかもしれない。
ひとつの行は横の並び、ひとつの列は縦の並びなのだが、「行方向」といったとき、
行を指定する添え字を変化させるのか、行をひとつ取ってその要素をなめる
方向(=列の添え字を変化させる)のか、の2種類の解釈ができる。

すこし考えてみましたが、おっしゃる通り転置で良いと思います。
あるいは、要素をもう追加しないことが分かっている場合には、
ほぼ同じコストで実現できる配列化もありですね。

ストリーマを構成したのは、行列を複製するのを惜しんだわけですが、
map hd' (!buf2)で列ベクトルを切り取る操作をしているので、
全要素にアクセスする場合、これは無意味はですね。

648 ：デフォルトの名無しさん：2011/12/15(木) 22:49:33.17

関数型言語で安定したWebフレームワークが存在するものといえばどれでしょうか？
ドキュメントやコミュニティーがしっかりしているFWがあればいいのですが

649 ：645：2011/12/15(木) 23:18:12.86

>>648
言語 : Haskell
ライブラリ : snap (http://snapframework.com/)

まだバージョン 1.0 になっていないが、
本体もドキュメントもしっかりしてる

コミュニティーってのは、利用者やファンが群がってるところか？
snap 限定なら上記アドレスの本家サイトにも書かれているが IRC がそれかな
他では特に聞かないな
議論をしたいのなら普通に stackoverflow とかですればいいと思う

・・・自分でもちゃんと調べたのか？

650 ：デフォルトの名無しさん：2011/12/17(土) 15:32:01.10

>>649
ありがとうございます
Haskellならyesodの話はよく聞くんですけどね
触ってみます

651 ：デフォルトの名無しさん：2012/01/27(金) 05:59:51.36

やるきなさすぎ

652 ：デフォルトの名無しさん：2012/02/09(木) 09:33:08.80

yesod本でるね。

653 ：デフォルトの名無しさん：2012/02/19(日) 11:34:13.39

関数型初心者に教えてくれ。
・末尾再帰って普通のループより何がうれしいの。
・カリー化って何の役にたつの。

654 ：デフォルトの名無しさん：2012/02/19(日) 11:56:20.91

>・末尾再帰って普通のループより何がうれしいの。
プログラマの立場から見るとあまり変わらない
相互末尾再帰すれば単純なループ以外のものも書けるくらい
言語の立場から見ると、わざわざループ専用構文と破壊的代入を用意しなくても
ループが実現できてうれしい
>・カリー化って何の役にたつの。
いちいちラムダ式を書くよりも部分適用が楽

655 ：デフォルトの名無しさん：2012/02/19(日) 20:32:09.16

こんばんわ、
私たちは

カンです、スーです、ミキです、
三人合わせて

656 ：デフォルトの名無しさん：2012/02/19(日) 21:39:46.94

カスミです

657 ：デフォルトの名無しさん：2012/02/26(日) 00:24:54.42

Cも関数型言語なの？
僕が持ってるCの入門書には、関数を作っていくプログラミング言語って書いてある。

658 ：デフォルトの名無しさん：2012/02/26(日) 00:27:27.24

Cは手続き型。すなわちコマンドの羅列が基本。
Cにおける関数は構造化やモジュール化の手段。

659 ：デフォルトの名無しさん：2012/02/26(日) 00:28:33.45

>>657
とりあえず、Wikipediaで関数型言語を調べてから質問に来い

660 ：デフォルトの名無しさん：2012/02/26(日) 02:52:14.47

>>653
再帰で書いたほうがスッキリとかけることが多い。
で、末尾再帰だとそれがコンパイル時に最適化してgotoに落とせてはやくできる。

カリー化はある一般的な関数を、ある条件のもとでの特殊な別の関数に無駄な記述なく書ける。
ある時のコンテキストで専用の関数に仕立て上げられる。その後の記述がスッキリ。

まぁ両方共メリットがわからなければ使わなくていいんじゃないかと。

661 ：デフォルトの名無しさん：2012/02/26(日) 08:50:59.77

C言語辞典とかいう本のひとつに嘘が書いてあったので、
C言語は関数型言語というデマがひどく広がってる。

662 ：デフォルトの名無しさん：2012/02/26(日) 12:12:37.93

javascriptの方がよっぽど関数言語だよね

663 ：デフォルトの名無しさん：2012/02/26(日) 13:03:58.60

関数ポインタがある時点で初期のC#よりは関数型

664 ：デフォルトの名無しさん：2012/02/26(日) 13:15:46.65

ねーよ。
obj.call(arg) とでもして呼べばいいだけじゃねぇか。

665 ：デフォルトの名無しさん：2012/02/26(日) 20:57:28.02

>>661
僕の持ってたC言語の入門本にはC言語は関数を中心に組み立てる関数型言語と書いてあった。
捨てたからタイトルも忘れたけど。

666 ：デフォルトの名無しさん：2012/02/26(日) 21:41:00.60

>>665
それは関数型言語の意味を履き違えてる

667 ：デフォルトの名無しさん：2012/02/26(日) 22:02:20.41

C言語の関数はなんで関数じゃないの？

668 ：デフォルトの名無しさん：2012/02/26(日) 22:14:33.72

関数型言語の文脈における関数というのは、
参照透過性が保たれた関数のこと

そのような性質を持った関数をファーストクラスとして扱うことを
主な目的にして設計された言語を関数型言語という
（この性質を壊す処理は程度の差こそあれ例外的なこととして扱われる）

C言語の関数はそのような性質が保証されていないし、
ファーストクラスとしても設計されていない

669 ：デフォルトの名無しさん：2012/02/26(日) 22:21:39.14

C言語の関数は、「値を返すこともできる手続き（プロシジャないしルーチン）」のことを「関数」と呼んでるだけで、
関数型言語における、いわゆる数学的な（参照透明性があるのが基本である）関数とは違うものだから。

> C言語の入門本にはC言語は関数を中心に組み立てる関数型言語と書いてあった

↓これと同様の、
ttp://c-faq.com/ansi/voidmainbooks.html
> Perhaps its author counts himself among the target audience.
という系の本だとみなすべき指標のひとつだな。

670 ：デフォルトの名無しさん：2012/02/26(日) 22:27:33.21

広まりっぷりから見るに、河西本か三田本か林本のどれかあたりにでも書いてあったのかなぁ

671 ：デフォルトの名無しさん：2012/02/27(月) 01:32:50.74

Cに関数しかなく、手続きがない。
だから関数型だって馬鹿はK&Rが翻訳される前からいた。

672 ：デフォルトの名無しさん：2012/02/27(月) 05:14:40.64

分かったふりしたやつが多いな

673 ：デフォルトの名無しさん：2012/02/27(月) 08:32:29.09

>>671 1981年に初版の翻訳が出てるが、1970年代に関数型言語という言葉を知っていて、
なおかつそんなバカがいたのか？ちょっと信じられんが。

674 ：デフォルトの名無しさん：2012/02/27(月) 08:43:53.97

1970年代にも関数型言語はそこそこ有名だったと思うが
C や Unix はあまり知られていなかったような。

K&R の翻訳以前に出てた日本語の C の本って 1冊しか知らないや。

675 ：デフォルトの名無しさん：2012/02/27(月) 08:43:57.08

Cは関数型言語じゃない
でFA

676 ：デフォルトの名無しさん：2012/02/27(月) 10:09:55.45

FAもなにも>>658で即答すべきだったのに、このスレときたら・・・

677 ：デフォルトの名無しさん：2012/02/27(月) 10:24:35.73

しょうがねぇだろ、かなりの範囲にデマが広まっちまっているんだ

678 ：デフォルトの名無しさん：2012/02/27(月) 15:13:06.38

>>674
昔は情報源が雑誌。

679 ：デフォルトの名無しさん：2012/02/27(月) 15:56:23.08

70年代といったら、マイコン雑誌の数誌が出たばかり、
『コンピュートピア』は技術系の内容はからっきしで、bitしかない時代。

bitにそんなアホが載ったとも思えん。

680 ：デフォルトの名無しさん：2012/02/27(月) 22:48:04.02

>>679
思えん理由についてくやしく
主観はいらない

681 ：デフォルトの名無しさん：2012/02/28(火) 00:32:53.80

ぼくはC言語を使っていて、関数型言語を使ったことないんですけど、
C言語の関数と、関数型言語の関数は何が違うのですか(´・ω・｀)

682 ：デフォルトの名無しさん：2012/02/28(火) 00:52:54.55

スレ嫁ばわかるだろ

683 ：デフォルトの名無しさん：2012/02/28(火) 00:57:57.50

顔文字使うのをやめれば分かることもある。

684 ：デフォルトの名無しさん：2012/02/28(火) 18:57:59.32

>>681
例えば

int count (void)
{
　　　static int i = 0;
　　　return i++;
}

void main (void)
{
　　　printf("%d\n",count());
　　　printf("%d\n",count());
}

と言う関数を作れば、実行結果は

0
1

となるが、関数型言語の関数は文字を表示する関数などの特別な関数以外は基本的に同じ引数（引数なしなら、引数なしも）なら、同じ結果が返ってくる
そして、一番の特徴は、初期化のみ代入を許し、以後は代入が出来ない

一見不便に見えるが、そのおかげで参照透明性が保たれ、マルチスレッド化はしやすい

もう一つの特徴として、最近のＬＬを中心に取り入れられている特徴は、関数の引数に関数を渡せる
これは、関数ポインタで同等のことが出来るが、汎用性では圧倒的に関数型言語の方がうえ

本格的にコーディングされるとさすがに勝てないが、お手軽末尾最適化関数のfoldlを使えば、スタック消費しないし、素直に書いたＣのコードと同じ程度の速さは出る
Ｃの素直なreverse関数：http://ideone.com/FLe0A
Haskellのreverse関数：http://ideone.com/O7h5F

685 ：デフォルトの名無しさん：2012/02/28(火) 20:47:03.54

多分質問者は理解できないだろう

686 ：681：2012/02/28(火) 21:08:14.14

わかるもん(´・ω・｀)
そういう風に書けばいんだろ。
ぼくはCのプロだし。
・同じ引数なら同じ結果
・代入は初期化のみ

687 ：681：2012/02/28(火) 21:09:54.24

っていうか、ちょっと人が知らない言語を知ってるぐらいで
威張らないでほしいし(´・ω・｀)そういうのはキモヲタって言われるよ？

688 ：デフォルトの名無しさん：2012/02/28(火) 22:08:18.74

誰が威張っていようがいまいが、そんなことはどうでも良いと思います
要は今まで皆さんの説明で知りたかったことが理解できたかどうかです

納得いかない部分があればポイントを絞って再度質問し、
納得いったのならお礼を言って終えればいいだけなのでは？

689 ：681：2012/02/28(火) 22:13:59.43

どうもありがとうございました！

690 ：デフォルトの名無しさん：2012/03/01(木) 16:08:01.50

別の言語のソース(m4)見てて
Curryという名前で、例えば

func(1)(2)(3)

　　　↓

func(1, 2, 3)

にするマクロがあり
>Perform argument currying.
というコメントがあったんだけど、
これカリー化じゃなくてその逆(非カリー化)だよね?

スレ違いな質問だけど、カリーに詳しそうなここで聞いてみた。

691 ：デフォルトの名無しさん：2012/03/01(木) 18:26:25.85

そだね。
カリー化は１引数化のことだから。

カリー化の逆は部分適用だっていうケースが多いけど、
その多引数化が真逆だね。

692 ：デフォルトの名無しさん：2012/03/01(木) 20:02:44.13

>>690
とりあえず、Haskellでは、

curryは二つ組のタプル一つを受け取る関数を、二つの引数を取る関数にする
uncurryはその逆

定義
curryadd a b = a + b

tupleadd (a,b) = a + b

実行結果
*Main> curryadd 1 2
3
*Main> tupleadd (1,2)
3
*Main> uncurry curryadd (1,2)
3
*Main> curry tupleadd 1 2
3

693 ：デフォルトの名無しさん：2012/03/01(木) 23:58:30.33

>>691,692
ふーむ・・・
考え方的には>>691で
Haskell実装では逆になるという事かな?

694 ：デフォルトの名無しさん：2012/03/02(金) 00:25:01.03

関数型言語でWebのシステムは作れますか。
何か実績はありますか。

695 ：デフォルトの名無しさん：2012/03/02(金) 09:05:45.02

HaskellとかMLで？
それともLisp系で？

単に煽りたいだけなら死ね。

696 ：デフォルトの名無しさん：2012/03/02(金) 10:10:49.14

質問に答えられないｗ

697 ：デフォルトの名無しさん：2012/03/02(金) 10:24:33.47

ググればすぐみつかるだろ
lispacheとかhunchentootとか
http://weitz.de/hunchentoot/
自分はchickenで動くspiffyとawfulが好きかな

698 ：デフォルトの名無しさん：2012/03/02(金) 10:50:57.16

>>696 HaskellかLispかも答えられない＝最初からまともに質問する気が無い。

699 ：デフォルトの名無しさん：2012/03/02(金) 12:34:26.11

>>694
Webのシステムというのがどういうものを指しているのか分からないが、
Web フレームワークなら例えば Haskell で Yesod などいつくかある

クラウドシステムを構築するとかでも、どんな言語でもできるが、
こちらの方は実績は知らんな

700 ：デフォルトの名無しさん：2012/03/02(金) 13:06:50.56

>>694
Yesodはもうすぐオライリーから本がでる程度にはメジャーです。
http://shop.oreilly.com/product/0636920023142.do
http://www.snoyman.com/img/book-cover.png

>>698
まともでないのはド素人の質問に死ねと返す方でしょう。

701 ：694：2012/03/03(土) 00:03:28.76

>>695
煽りじゃありません(´・ω・｀)
ぼくは関数型言語を使ったことがないので、活用事例を知りたかったのです。

702 ：デフォルトの名無しさん：2012/03/03(土) 01:53:54.67

OCamlにはocsigenというWebフレームワークライブラリが昔からある。
http://ocsigen.org/
js_of_ocamlでクライアントも作れる。

703 ：デフォルトの名無しさん：2012/03/03(土) 13:57:15.95

Kahuaとかも

http://www.kahua.org/show

704 ：694：2012/03/03(土) 14:02:15.81

ありがとうございます。
色々あって書物まで出るのですね。

ついでに質問なんですけど、
>>695 みたいに色々あるみたいなんですけど、
前回のWebの話は別として、
これから関数型言語を勉強するには Haskell ML Lispのどれがおすすめですか。

ぼくはプログラミングはCとPHPを勉強しました(´・ω・｀)

705 ：デフォルトの名無しさん：2012/03/03(土) 14:24:33.56

人によって違うだろ。
関数型言語の考え方を学びたいならHaskellでいいんじゃない？

706 ：694：2012/03/03(土) 14:25:58.61

はい、考え方を学びたいです。

707 ：デフォルトの名無しさん：2012/03/03(土) 14:37:59.16

OCamlのほうがいいかもしんない。

708 ：694：2012/03/03(土) 14:47:59.38

>>707
あ、はい。
すすめてくれる人は、できれば理由も教えてくれるとありがたいです。
そろそろ出かけますので、夜までレス読めません。

709 ：デフォルトの名無しさん：2012/03/03(土) 15:03:39.13

>>708
Haskell は普及が進んできている。遅延評価で純粋なので、関数的という点は上。
遅延評価（がデフォルト）という点が、コンピュータのプログラムとしてはちょっと非直感的なので
学習の壁になる可能性がある。

OCaml も同じくらい普及している。引数がデフォルトでは遅延評価じゃないというのが
Haskell との大きな違いのひとつ。

710 ：デフォルトの名無しさん：2012/03/03(土) 15:16:16.05

>>706
関数型の「考え方」を知りたいなら、圧倒的にHaskell。

ただし、標準入出力の処理でみんなつまづくので、Hello Worldプログラムを書くのはちょっと高い壁がある。
だから、インタプリタ(GHCiがデファクトスタンダード)でスーパー電卓的に使ってみるのが良い。

711 ：デフォルトの名無しさん：2012/03/03(土) 15:26:25.72

どうせモナドでつまづくんだから、OCamlでモナドのひとつも定義して動かしてみてから
Haskellを勉強しても良いと思うぜ

712 ：デフォルトの名無しさん：2012/03/03(土) 15:59:16.17

なんで人はモナドで躓くんだろ？

713 ：デフォルトの名無しさん：2012/03/03(土) 16:20:37.82

>>712
いまHakellを勉強する人は良くも悪くも「意識の高い」人だから、
「モナドは圏論から来た概念で～」とか言われると、数学の勉強を始めてしまうから。

「doと<-はおまじないです」でかまわない人が増えたら、つまづかなくなるだろ

714 ：デフォルトの名無しさん：2012/03/03(土) 19:17:12.43

>>713
それが躓く理由なら、OCamlでモナドを定義しても相変わらず躓くな
圏論から来た概念なことには違いないのだから、言われれば数学の勉強を始めるのだろう

715 ：デフォルトの名無しさん：2012/03/03(土) 19:20:28.52

しかし、Haskellそっちのけで数学の勉強を始めてしまうのは躓くとは違うな
何も躓いていない

むしろスムーズにHaskellから数学に移行している
そこからのまたHaskellに滑らかにＵターンしてこればいい

従って、躓く原因は他にあるな

716 ：デフォルトの名無しさん：2012/03/03(土) 19:55:28.28

>>712
>なんで人はモナドで躓くんだろ？

そこにモナドがあるから

一般的な手続き型言語/オブジェクト指向言語は
正格評価(非遅延評価)を採用し、副作用(入出力や破壊的代入)を前提にしている
だからそういった言語に慣れた「ふつうの」プログラマにとって、
正格評価や副作用は潜在意識下に存在し、それが自然なものであると(無意識に)理解している

それがHaskellでは、わざわざモナドを使わなければまともなプログラミングできない
言い換えると、ふつうのプログラマにとって、モナドの存在そのものが「異質」に見える

717 ：デフォルトの名無しさん：2012/03/03(土) 20:04:46.41

>>712
俺的にはモナド使うと誰得なんですか的なところがつかめんかった。
HaskellerじゃないのでIOモナドはあまり関係ないし。
今は書いてあるコードの後ろにゴニョゴニョした部分を後ろにおっつけられるようにフックしつつデータをたらい回せる機能という理解になってしまってる。
のでFunctor→Applicative→Monadの発展の流れってのをイマイチ理解してないよ・・・

718 ：716：2012/03/03(土) 20:58:15.37

一部訂正

X: それがHaskellでは、わざわざモナドを使わなければまともなプログラミングできない
O: それがHaskellでは、わざわざモナドを使わなければ実用的なプログラミングができない

719 ：デフォルトの名無しさん：2012/03/03(土) 21:02:45.49

表示的意味論で繰り返し使われる手法を
抽象化してまとめたのがモナド。
意味論から出たデザインパターン。
ボトムアップ一辺倒の人は分からない概念。
うまくまとめたってだけで、なくてもなんとかなるから。

720 ：デフォルトの名無しさん：2012/03/03(土) 21:13:07.25

>>717
> 俺的にはモナド使うと誰得なんですか的なところがつかめんかった。

モナドを「わざわざ」って思ってしまうのは、入門書に載っているような、
ターミナル相手の入出力の使い方しか知らないからだと思うんだ

たとえば Web フレームワークの Yesod で Web ページを定義する時、
ヘッダやフォームなどの部品は全てモナドなんだが、
わざわざなんて感じは無く、かなり自然に記述できる
そこでは、「順序を意識すること無く宣言的に記述する」
ためにモナドが利用されている

wx で GUI の見た目を定義する場合もモナドを使うが、
ほとんど宣言的に記述できるように工夫されてる
（本当は DnD なんかもっとモナドを活用して宣言的に書けるはずなんだが、
今は未だライブラリで提供されてはいないな）

こういうモナドの活用例とその仕組みを入門書で知る事ができれば、
躓く人も少しは減ると思うんだ

721 ：デフォルトの名無しさん：2012/03/03(土) 21:23:35.66

手続き型言語の世界には、
・プログラム = アルゴリズム + データ構造
という有名な言葉がある
これをHaskell流に見立てると、以下のようになる
・プログラム = 数式 + 代数的構造
つまり、「Haskellプログラミングとは数学的活動である」と見なすことができる

更には、Haskellには無限リスト、リスト内包表記、ガード、インデントベースといった
数学固有の記述法に適した構文が巧妙に組み込まれているから、
こうした数学的素養のある人にとって、Haskellはこのうえもない関数型言語に感じるはず

また>>715はモナドに関するカキコだけど、より一般的に解釈すれば、
初心者がHaskellを触るによって「数学的活動としてのプログラミング」の第一歩を
自然と歩むことになることを意味する
これは「正しい」プログラミング設計作法を学ぶためには、とても好ましい道筋だと思う

722 ：デフォルトの名無しさん：2012/03/03(土) 23:41:08.94

数学かどうかっていう対立軸は微妙だと思うよ
haskellが数学ならCだって数学でしょ

723 ：デフォルトの名無しさん：2012/03/04(日) 01:37:16.99

だよな、Cは関数でプログラミングするから関数型言語なわけで、
関数を使うんだからCも数学だよね

724 ：デフォルトの名無しさん：2012/03/04(日) 01:46:17.12

C言語は数学を使わずに説明できるのに
Haskellは数学を前提にするのは、分かってる人にしか分からない説明を
助長するだけだと思うんだが

「数学をわかってる」人って、そんなにいないと思う

725 ：デフォルトの名無しさん：2012/03/04(日) 02:10:26.82

haskellが背景にしている数学って圏論とか言うやつだろ
そんなの理系でも殆どの人が知らないよ

MLは型付きラムダだから、知っている人が少しは多そうだけど
それでも非常にマイナーな分野なのは間違いない

726 ：デフォルトの名無しさん：2012/03/04(日) 02:44:10.59

>>721
> ・プログラム = 数式 + 代数的構造

いや、アルゴリズムはちゃんと記述するよ、Haskellでも。

727 ：デフォルトの名無しさん：2012/03/04(日) 02:45:21.71

MLだってfunctorってのがあるから圏論は絡んでくるし、
型理論は形式推論理解しない人には難しい。

728 ：デフォルトの名無しさん：2012/03/04(日) 09:25:34.34

それはC言語にはポインタがあるから計算機アーキテクチャを理解しなければ使えない、
とか言ってるのと同じ。

729 ：デフォルトの名無しさん：2012/03/04(日) 10:35:03.22

>>728
まぁ、実際、ある程度は計算機のアーキテクチャを理解しないとCは使いこなせないだろ。
「理論的には」Cの仕様はもっと抽象化されているのかもしれないけど、メモリがどうとか考えていたほうがむしろ簡単。

730 ：デフォルトの名無しさん：2012/03/04(日) 11:42:24.36

規格が限定している通り、他の変数や配列の個々の要素などを指せる機能、
と考えるのは？

731 ：デフォルトの名無しさん：2012/03/04(日) 12:09:20.35

>>721
おおむね同意だが
Haskellにおいてもと言うか、命令型言語よりも、よりダイレクトに
「プログラミング＝アルゴリズム＋データ構造」だ

732 ：デフォルトの名無しさん：2012/03/04(日) 12:11:09.15

>>728
最低限、メモリの仕組みは知らないとまともに使えないだろ

733 ：デフォルトの名無しさん：2012/03/04(日) 12:19:25.49

Cでh実用なメモリの知識なんて応用情報()の参考書に載ってる程度で充分

734 ：デフォルトの名無しさん：2012/03/04(日) 13:07:56.00

ＬＬでさえも

x = 1
x = x + 10

print x

これで11と表示されるのを自然だと思わないといけない以上、メモリの知識からは逃れられないよね

Haskellは、そう言う意味じゃメモリの知識から開放されてるとも言えるけど、そのメリットは
ＰＣ以外の上でも実行可能と言うことになる

人間とか、未知のアーキテクチャな何かとか

735 ：デフォルトの名無しさん：2012/03/04(日) 13:10:14.00

メモリの知識以外では公理的意味論の初歩を学ぶという道もある

736 ：デフォルトの名無しさん：2012/03/04(日) 13:20:01.18

ポインタの加減で指すアドレスは、対象とするオブジェクトのサイズに応じて変わる、と考えるより、
+ n で配列の要素 n 個ぶんずれる、と考えるほうが自然だと思うが。

737 ：デフォルトの名無しさん：2012/03/04(日) 13:21:13.92

> x = 1
> x = x + 10
>
> print x
>
> これで11と表示されるのを自然だと思わないといけない以上、メモリの知識からは逃れられないよね

x = 1
y = x
x = x + 10

print y
これで10と表示されるのが自然だと思わないといけない以上、メモリだと強弁するのは無理があるよね

738 ：デフォルトの名無しさん：2012/03/04(日) 13:30:53.47

>>736
自然というか、抽象度がより高いと言える

どちらを自然と思うかは文脈や環境による

739 ：デフォルトの名無しさん：2012/03/04(日) 13:36:36.70

規格上はダメなのかもしれないが（よくしらない）、実際には、void *を構造体へのポインタに型変換して使うとかよくあるわけで、
またそういう操作を前提にしたライブラリを作ったりするわけで、やっぱりメモリがどうとか、構造体のマップがどうとか、
考えないとCを使いこなしているといえないだろ

740 ：デフォルトの名無しさん：2012/03/04(日) 13:41:55.86

ポインタを使うならメモリアドレスの知識が必要なのは当然で
>>734 の書き込みが意味不明なだけ。

x = 1
x = x + 10
print x

これが 11 になるのは変数と代入の概念がわかってりゃいいだけで
メモリ関係ねーよ

741 ：デフォルトの名無しさん：2012/03/04(日) 13:56:28.44

>>720
そういうモナド使うとこんなのがこんなふうにかけてナイスなの的なものが探しやすく転がってるといいんだけどね。
自分はF#erなんだが、非同期処理を簡潔に書けるモナド使ったasync workflowってのがあって仕組みはよーわからんかったが、モナド便利と思った。

742 ：デフォルトの名無しさん：2012/03/04(日) 14:11:46.29

そーいう問題じゃなくて「モナドとは何か？」が難しすぎなんだよ

743 ：デフォルトの名無しさん：2012/03/04(日) 14:52:20.27

その答えは答えを求めないことなんじゃないかと最近思い始めた
少なくとも初学者にとっては

744 ：デフォルトの名無しさん：2012/03/04(日) 15:42:52.29

>>743
チュートリアルの最後に出てくるような「高度な機能」が難しいならわかる。

Haskell が厳しいのは、他のどの言語でも簡単に書けるようなことが
Haskell ではモナドを使わなければ書けない。
某隔離スレ的に言えば、モナドを使わなければ Haskell はそれこそ玩具。

そして、そのモナドが Haskell で一番難しい。
Haskell は、このジレンマが難しいとこだな。

745 ：デフォルトの名無しさん：2012/03/04(日) 15:47:48.23

モナドを使うこと自体に難はないでしょう

746 ：デフォルトの名無しさん：2012/03/04(日) 15:54:26.33

一番難しいとまではいかんがCにおけるポインタみたいな類のものよかは遥かに判りづらいとは思う

747 ：デフォルトの名無しさん：2012/03/04(日) 15:56:43.60

とりあえず、「なんかよくわからん型クラス」と思っておく。

748 ：デフォルトの名無しさん：2012/03/04(日) 15:57:11.86

readFile :: FilePath -> IO String

なんで戻り値が String にならないの？
という初学者の素朴な質問にどう答えられるか。

749 ：デフォルトの名無しさん：2012/03/04(日) 16:14:09.93

>>748
参照透過性が保証できないから

これくらいは初学者用の入門書に必ず書かれていると思うが

750 ：デフォルトの名無しさん：2012/03/04(日) 16:23:42.36

∀a b. a = b → f a = f bのような性質から説明するにしてもどこかで天下り的な公理を仮定せねばならん
そうすることで何が嬉しいかという所からな

751 ：デフォルトの名無しさん：2012/03/04(日) 16:25:13.92

>>749
答えになってないような。
IO String 型だとどうして参照透過性が保証できるの？

752 ：デフォルトの名無しさん：2012/03/04(日) 16:54:53.88

x = 1
y = x
x = x + 10

print y

これって出力　１　だよね　11　って出る言語があるの？

753 ：デフォルトの名無しさん：2012/03/04(日) 17:01:27.05

参照透明性に似た概念として関数性(∀ a b. a = b -> f a = f b)と
RealWorldを使ったIOのアナロジー
関数型の値の同値関係として外延的同値(∀ x. f x = g x)を考えれば
String -> IO StringはString -> RealWorld -> (String, RealWorld)になって
末尾の直積部分のString又はRealWorldが異なるとしても第二引数のRealWorldが違うことより関数性の前提が偽であるから
関数性が成り立つと仮定した場合にその否定の証拠たりえない

という言い逃れができる(笑

754 ：デフォルトの名無しさん：2012/03/04(日) 17:09:44.62

>>751
逆だよ

readFile 関数が内部で行うことが参照透過性を保証できないから、
String 型ではなく IO String 型を使用させるを得ない

readFile 関数が参照透過性を保証できるのなら String 型を使ってる

なんで readFile 関数が内部で行うことが参照透過性を保証できないかと言えば、
引数である Srring 型のある値に対して、戻り値として返す String 型の値が
いつ如何なる時でも同じ値になるとは限らないからだ

それは、例えば読み込むファイルの内容が一時間前と変わっているかもしれないから
そうなれば同じ引数に readFile 関数を適用しても、戻り値が同じにならない

同じになる場合もあれば、ならない場合もあり、同じだという保証ができない

755 ：デフォルトの名無しさん：2012/03/04(日) 17:16:25.27

保証が無いという保証

756 ：デフォルトの名無しさん：2012/03/04(日) 17:16:58.62

いや、 IO を使うとなぜそれが許されるのかを説明しないと

757 ：デフォルトの名無しさん：2012/03/04(日) 17:23:07.34

IO型の値は参照できないから

758 ：754：2012/03/04(日) 17:23:11.24

>>751
初学者相手なら >>754 のような説明で十分だが、もう少し厳密に言っておく

本当は IO String 型を返す関数でも参照透過性は保証されていると考えられる

readFile 関数が返す IO String 型の値は文字列そのものではなく、
「引数で指定されたパスのファイルから文字列を得るという内容を含むアクション」という値だ

この値を解釈して意図通りに実行するのは実行系の役割だ

こう考えれば、引数である String 型のある値に対して、
戻り値の IO String 型のある値は、いつ如何なる時でも同じ対応関係にあると言える

が、初学者はここまで考える必要はなく、
IO モナドの中の型の値が参照透過性を保てないんだなと考えれ、
できるだけ参照透過性が保てる普通の関数を使うよう意識していればいい

759 ：754：2012/03/04(日) 17:28:31.61

>>758
猛者達に突っ込まれる前に言っておく

> 「引数で指定されたパスのファイルから文字列を得るという内容を含むアクション」という値だ

これは readFile 関数を使う我々プログラマ側から推測できるアクションの内容だ
この関数の中では他にも目に見えない様々なアクションがモナドという皮で包まれているかも知れん

だが、引数の値が同じなら、同じ内容のアクションが返ってくる事は言える

ついでに、
> 保てないんだなと考えれ、

保てないんだなと考えて、

760 ：デフォルトの名無しさん：2012/03/04(日) 18:06:48.94

>>758
「そんなややこしい仕組みを持ち込むメリットがどこにあるのか」
が、分からないんですよ。

IO モナドを使わなければ参照透明だといわれても
そもそも Main が IO () なわけで。

761 ：デフォルトの名無しさん：2012/03/04(日) 18:08:10.36

参照透過性があると型推論やり易いとか
OCamlは苦労してるらしい

762 ：デフォルトの名無しさん：2012/03/04(日) 18:23:30.24

メリットじゃなくて、参照透過性を課す事により現実問題プログラミングできなくなる事を回避する策では？

ではモナドの仕組みで必要十分、言い換えると、モナドがそのためにもっとも簡便な手段なんだろうか？
もしくはモナドのようにするしかない理由は何？
って疑問に答えようとすると、圏論がどうのとかって方向に行ってしまうのでしょう。

763 ：デフォルトの名無しさん：2012/03/04(日) 18:39:47.48

参照透過性のない言語で「凡人」が普通にプログラミングしているのが現実なので、
参照透過性のために難しい理論を持ち込まなければいけないとなれば
「凡人」はメリットよりデメリットが大きいと思ってしまうのでしょう
Haskellの問題は、この点について「凡人」を納得させる言葉を未だに持っていないことでは

764 ：デフォルトの名無しさん：2012/03/04(日) 18:39:56.65

参照透明性が無いとできない最適化とかあるから

765 ：デフォルトの名無しさん：2012/03/04(日) 18:45:02.73

自分は別に IOモナド自体はそんなに難しく感じなかったな。
bind も「ああ、継続を簡単にしたものね」としか思わなかった。

ただ、IOモナドでなくても、たとえば readFile が (world,s)
みたいなタプルを返すだけでもいいんじゃないのか、あとは普通に
パターンマッチで s を取りだせばいいんじゃないか、とは思った。

766 ：デフォルトの名無しさん：2012/03/04(日) 18:50:50.46

モナドは便利だから色々なモナドを使いたいんだけど
まともにプログラミングしようと思ったらIOモナドは必須なので
複数のモナドを組み合わせて使うのにモナド変換子が必要になって
初心者はつまづく

767 ：デフォルトの名無しさん：2012/03/04(日) 19:18:54.44

>>764
最適化のために参照透明性が重要だというなら
C より早くして実績で示すしかないだろう

768 ：デフォルトの名無しさん：2012/03/04(日) 19:23:18.53

>>763
> Haskellの問題は、この点について「凡人」を納得させる言葉を未だに持っていないことでは

べつに問題だとは思えないな
「凡人」のままで止まらない人だけが Haskell を学び始めればいいと俺は思う

参照透過性のない言語で普通にプログラミングしている「凡人」が、
その気持ちや頭を切り換えないまま安易に Haskell を学ぼうとするからダメなんだよ

そういう人は他言語のパラダイムとか、
クラスなどの他言語の道具との比較や比喩で理解しようとする
自ら壁を作っておきながら、分からないと愚痴る
躓く最大の原因はこれだと思うよ

比較はけっこう熟練してきたなと感じてからでいいんだよ
その頃には自然と、他言語との繋がりも分かってくる

頭を切り換えれば、本当にスラスラと学習が進むんだがな
銀行員から和紙職人に転職するくらいの気持ちがなきゃ手を出すなと言いたい

769 ：デフォルトの名無しさん：2012/03/04(日) 19:24:07.42

>>766
お前の中ではどの程度までが「初心者」に入るんだよ

770 ：デフォルトの名無しさん：2012/03/04(日) 19:38:35.60

>>768
ですよね。普通の人向けの言語ではないですよね。

771 ：デフォルトの名無しさん：2012/03/04(日) 19:39:42.75

>>767
最適化のために参照透明性が重要なんじゃない
純粋関数型の体裁を作る為に参照透明性が重要なんだよ

参照透明性があると、ある部分で最適化がしやすいが、
それは結果であって目的ではない（最適化しやすくなることは初めから分かっていたが）

それに参照透明性があると、ある部分で最適化がしやすいのは、
何も関数型に限らず C などの手続き型でも同じだ

例えば引数に const を付けてポインタが示す内容が変更されない事を保証すれば、
その部分に限って参照透明性が保たれ、最適化しやすくなると言える

ところで、なぜその実績を示すのに C より早くする必要がある？
最適化における参照透明性の重要性を示すのなら、
同一言語において参照透明性がある場合とない場合で比較すれば済む話だと思うが

772 ：デフォルトの名無しさん：2012/03/04(日) 19:40:13.09

Haskell はプログラムを書くための言語ではなく
数学を学ぶための言語だと思う方がいい

773 ：デフォルトの名無しさん：2012/03/04(日) 19:42:48.33

>>770
普通の人でも学べる言語だよ
私は普通だったし、私の周りの人間も普通だ

意識して頭を切り換えようとしない人には学べないんだよ

意思と目的があれば、普通の人は切り替えようとする

774 ：デフォルトの名無しさん：2012/03/04(日) 19:44:46.82

Haskellで数学とか片腹痛し

775 ：デフォルトの名無しさん：2012/03/04(日) 19:48:19.54

>>772
そんなことはない

Haskell の設計の目的のひとつは実用的なプログラムが書けるようする事だ
http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/

その目的は忘れられることなく着実に進化している

Haskell を使って数学の何を学ぼうと言うんだ？
純粋に数学を学ぶよりも Haskell を使った方が近道なのか？

776 ：デフォルトの名無しさん：2012/03/04(日) 19:52:26.22

>>773
最終学歴は？

777 ：デフォルトの名無しさん：2012/03/04(日) 19:53:19.89

中卒

778 ：デフォルトの名無しさん：2012/03/04(日) 19:53:22.63

残念ながら私の周りの Haskeller の大半は院卒ですよ

779 ：デフォルトの名無しさん：2012/03/04(日) 19:54:02.62

私の周りでは院卒が普通だという言い方もできますがね

780 ：デフォルトの名無しさん：2012/03/04(日) 19:56:45.35

言語の有用さの証明には学歴は低い程いい
むしろ小学校すら言ってませんが？みたいなプランテーション労働者から成功したHaskellプログラマーとか出たら人気出るよ

781 ：デフォルトの名無しさん：2012/03/04(日) 19:57:57.71

>>776
高卒だが？

782 ：デフォルトの名無しさん：2012/03/04(日) 19:58:17.87

>>780
そうですね。なので「残念ながら」と書きました。

モナドを理解しなくとも Haskell プログラムを書けるかもしれません。
が、残念ながら Haskell プログラマの大半はモナドに興味を持ち
大半は圏論に興味を持ち
大半は理論的な勉強を始めます。

残念ながら Haskell はそういう人達の言語です。

783 ：デフォルトの名無しさん：2012/03/04(日) 20:00:19.55

>>780
そんなもので人気が出ると逆に迷惑だな

意識して頭を切り換えようとしない馬鹿が大量に入門してきて、
C より遅いだの、メリット無いだの騒ぐんだろ

ほんと嫌になるな

784 ：デフォルトの名無しさん：2012/03/04(日) 20:01:09.14

学歴とか全く関係ないからw

785 ：デフォルトの名無しさん：2012/03/04(日) 20:02:10.48

>>783
なんだ今と同じじゃないかｗ
人気出るデメリット無いな

786 ：デフォルトの名無しさん：2012/03/04(日) 20:05:10.19

>>785
いや、俺が個人的に迷惑だと感じてるだけだ

馬鹿大量入門にメリットを見いだせる人もそりゃ大勢いるだろう

787 ：デフォルトの名無しさん：2012/03/04(日) 20:13:46.35

>>765
> ただ、IOモナドでなくても、たとえば readFile が (world,s)
> みたいなタプルを返すだけでもいいんじゃないのか、

表示的意味論で継続を使った意味付けがまさにそんな感じです。
その辺の手法をひとまとめにしたのがmonadなんです。

788 ：デフォルトの名無しさん：2012/03/04(日) 23:55:50.58

>>782
だとすると、計算機科学でPh.Dを取ろうというのでない限り、手を出さない
方がいいということにならない?
門外漢ながら型推論の仕組みが知りたいので、基礎の基礎であるλ計算から
ひまを見つけて勉強しているが、大変むつかしい。

789 ：デフォルトの名無しさん：2012/03/05(月) 00:22:27.92

そんな回り道せずにTypes and Programming Language嫁
読書会もやってるから参加して詳しい人に聞け

790 ：デフォルトの名無しさん：2012/03/05(月) 00:44:51.87

>>789 ありがとう。
目次と宣伝文句を見てみたが、実用本位の書き方っぽいですね。
買ってみます。

791 ：デフォルトの名無しさん：2012/03/05(月) 06:02:42.14

顕正新聞平成24年2月5日号「原発全廃特集号」

原発は日本を滅ぼす、即時全廃せよ
人のDNAを破壊、国土を居住不能にする
代替は天然ガス・コンバインドサイクルで十分
惨禍もたらすを知って推進するは犯罪

ttp://d.hatena.ne.jp/kensho01/20120208/1328718592

792 ：デフォルトの名無しさん：2012/03/05(月) 20:28:15.01

漏れもそろそろ関数型使ってみようと思ってるんだけど
ハスケルはオキャムルかチョウベリバマヨウヨマー

やっぱ実用的なのはオキャムルかなー

793 ：デフォルトの名無しさん：2012/03/05(月) 20:32:26.23

>>792
ふざけてんなら関数型は無理だ
止めた方が良い

794 ：デフォルトの名無しさん：2012/03/05(月) 20:42:15.73

漏れはいつだって本気だぜ

795 ：デフォルトの名無しさん：2012/03/05(月) 21:08:54.45

>>792
Haskell行っとけ。まだ灰汁が薄めのScalaもよいかも

796 ：デフォルトの名無しさん：2012/03/05(月) 21:13:15.10

>>792
OCaml使うなら、python/rubyで良いじゃんって感じするな・・・

一応、Haskellも実用的なソフトの紹介とかあった（このサイトもpandocというHaskell製汎用ドキュメントコンバータで書いてるそうな）
http://tanakh.jp/pub/unisys-tech-2011-11-09.html#1

797 ：デフォルトの名無しさん：2012/03/05(月) 21:18:08.50

よっしゃ、じゃあ漏れハスケるぜ！

798 ：デフォルトの名無しさん：2012/03/05(月) 21:18:16.66

Haskell は普通に商業的に使われている
http://www.haskell.org/haskellwiki/Haskell_in_industry

799 ：デフォルトの名無しさん：2012/03/05(月) 22:13:14.11

型推論が強力なOCamlとスクリプトなんて同じどころか対極に位置するわ

800 ：デフォルトの名無しさん：2012/03/06(火) 00:00:43.39

素朴な疑問なんだけど
lazy eval な処理系って realtime なシステムに適用可能なの？

801 ：デフォルトの名無しさん：2012/03/06(火) 00:44:06.77

O'Haskellというのがあるらしいがどんな言語なのかね。

802 ：デフォルトの名無しさん：2012/03/06(火) 00:46:48.02

>>800
適用可能か、どの程度まで可能か、何が適用を妨げているか、
という事をちゃんと検証した実例が今は未だ見当たらない

個々の大学や、会社の研究部署では研究しているところもあるかも知れんが、
例えば ACM の論文なんかを漁っても、そういう報告は見当たらない
単に私の探し方が悪いのかも知れんが

803 ：デフォルトの名無しさん：2012/03/06(火) 01:10:20.57

>>800
MonadiusがHaskellでシューティングゲームを作れる事を実証しましたが、
実行しているとだんだん重くなるという問題点も発見されました。
遅延評価がどの程度までレイテンシ保証可能なのかは知りませんが、
少なくとも今のHaskell実装はリアルタイムシステムに適用不可能ですね。

804 ：デフォルトの名無しさん：2012/03/06(火) 01:32:37.12

>>800
遅延評価そのものは正格評価と簡約回数に差は無いので適用できると思う
が、ＬＬが組み込みに向かないのと同じで、関数型言語もメモリを食う

Ｃはメモリを切り詰めようと思えば切り詰められる様な機械よりな言語仕様なのが強み
（プログラマの負担も増えるが、逆に言えば、細かい所までプログラマが触ることができる）

言語部分とライブラリ部分がＯＳ開発を意識して分かれてるのも特徴
(Ｃの言語部分は、ＯＳの機能が無い前提の仕様になってる。入出力はおろか、メモリ管理機能すら#includeで読み込むライブラリ関数）

Haskellも、デフォルトで読み込まれるモジュールを使わなくてもＣと同じように入出力以外で困ることは無いんだけど、多分、言語自体がOSの機能を前提に作られてると思う（主にメモリ管理機能）
OSも所詮は便利ライブラリ群でしかないんだけど、それを実行ファイルのランタイムに含めるとなると、大きくなりすぎるので、やっぱり組み込みには不向き
（それ以前にＧＣ搭載の時点で組み込みに不向きなんだが・・・）

Android(Java)の例もあるので、スマフォみたいにOSが乗ってる組込み分野なら、自分たちが思ってるほど不向きでは無いのかも知れない

少なくとも、遅延評価なＣ言語があっても、組込み言語として全然問題は無い

805 ：デフォルトの名無しさん：2012/03/06(火) 01:42:38.59

>>801
オブジェクト指向なＨａｓｋｅｌｌ
最近、モナド＝プラットフォームで、いわゆるモナド指向とでも言うべきもの？
ＩＯモナド＝命令型コンテクストで、理論的には論理型言語や、オブジェクト指向もモナドのコンテクストのひとつとして作れるっての読んでちょっと混乱中
http://tanakh.jp/pub/unisys-tech-2011-11-09.html#1

806 ：デフォルトの名無しさん：2012/03/06(火) 01:45:42.05

ごめん
2行目以降は普通のHaskellについての感想ね

807 ：デフォルトの名無しさん：2012/03/06(火) 03:50:22.03

>>804
>遅延評価そのものは正格評価と簡約回数に差は無いので適用できると思う

リアルタイムシステムで重要なのはスループットではなくレイテンシ保証です。
遅延評価がリアルタイムシステムで使えないとされているのは、
簡約回数が多いからではなく、簡約のタイミングを制御しにくいからです。

808 ：デフォルトの名無しさん：2012/03/06(火) 08:13:00.14

>>807
「真のプログラマはHaskellを使う」で評価順序をすごい細かく制御する技法が紹介されていなかったっけ？
まあ、それは高度かつ煩雑な技術なので、そういうのを持ち出して比較することに意味があるのか、という疑問はあるが。

リアルタイム処理でCが好まれるのは、コンパイル結果を推測できない、実際の動作は処理系任せである、
というのを嫌う技術者のプライドが大きいと思う。

実際、医療系とかで「いやー、それはコンパイラのバグですかねー」とか言われたら、困るし。

809 ：デフォルトの名無しさん：2012/03/06(火) 10:41:44.08

>>808
そこまで評価順序を気にするんならHaskell使うのは本末転倒だろｗ
向き不向きがあるんだから、評価順が予測通りに出来る言語使えばいいんじゃない？

810 ：デフォルトの名無しさん：2012/03/06(火) 10:53:45.31

型に厳しいCとか研究が進んでるし、そういうの使えばいいんじゃねーの？

811 ：デフォルトの名無しさん：2012/03/06(火) 10:56:23.60

>>808
評価順の制御とレイテンシーは関係なくね?

> リアルタイム処理でCが好まれるのは
GC がある言語が嫌われるのは事実だが, 特に Cが好まれてるとは思えない.
手頃なアセンブラの大替え品って所だろ

812 ：デフォルトの名無しさん：2012/03/06(火) 11:29:00.60

どうでもいいが「だいたい」で「代替」って変換できると思う

813 ：デフォルトの名無しさん：2012/03/06(火) 19:20:21.83

C++もテンプレート使い出すと楽しいけど
haskellもいろんな意味で楽しそう

814 ：デフォルトの名無しさん：2012/03/07(水) 01:04:31.08

関数型とオブジェクト指向が合体した言語はありませんか？

815 ：デフォルトの名無しさん：2012/03/07(水) 01:06:01.42

OCamlがいいんじゃない？

816 ：デフォルトの名無しさん：2012/03/07(水) 01:20:35.98

Scalaも

817 ：デフォルトの名無しさん：2012/03/07(水) 03:05:01.08

Ruby
Common lisp

818 ：デフォルトの名無しさん：2012/03/07(水) 09:50:10.65

Rubyは関数型とは言い難い
文字列すらmutable前提だし

819 ：デフォルトの名無しさん：2012/03/07(水) 10:19:08.57

immutableとかmutableって関数型言語と関係あるの？

820 ：デフォルトの名無しさん：2012/03/07(水) 10:29:39.50

first classな関数を数学の意味での関数(functionalなN-ary relation)と対応させる為には必要

821 ：デフォルトの名無しさん：2012/03/07(水) 11:16:41.25

>>820
数学をやる上でmutableとかimmutableとか普通考えないだろ
というかimmutableだって考えはごく一部の数学分野で必要とされるだけじゃないの

822 ：デフォルトの名無しさん：2012/03/07(水) 12:23:03.74

immutableだと等式推論による比較的容易な検証ができるけど
mutableだと最も単純なやり方でもHoare論理を使った面倒なものになる
これはpascal風の擬似言語で書かれた逐次実行、ループ、分岐が使われたsumをHoare論理を使って検証することと
適当な関数型言語におけるsumを自然数に置ける帰納法を使って検証することを比べてみればよくわかる
関数型言語が一般的にこのような流儀の形式手法を重視しているなら関係はあると言ってもいいんじゃないかな？

823 ：デフォルトの名無しさん：2012/03/07(水) 12:36:46.88

と思ったけど状態を持つ値を直積型とか使って美味く扱ってやれば別に不可能なんてことはないか
ただ教科書で説明する分には判りづらさが跳ね上がるだけ
やはり入門書を書く上での都合というのもあるのかな？
関数型言語を使って飯食ってる人達は大抵副作用バリバリのコード書いてるという事実を知るとよりそういう考えが強まる

824 ：デフォルトの名無しさん：2012/03/07(水) 12:46:12.81

>>823
> 関数型言語を使って飯食ってる人達は大抵副作用バリバリのコード書いてるという事実

ちょっと違う

副作用バリバリのコードと、副作用の無いツルツルのコードとを明確に分ける

更に言えば、副作用バリバリのコードは可能な限りライブラリの中に隠す

バリバリとツルツルをまぜてたんじゃ飯食えるほどの仕事はできん

825 ：デフォルトの名無しさん：2012/03/07(水) 12:48:09.63

>814
関数型とオブジェクト指向が合体した言語というが、
それがどういう機能を持っている事、何ができる事を期待してるんだ？

826 ：デフォルトの名無しさん：2012/03/08(木) 00:17:04.04

C言語は関数型なの↓

Ｃ言語は関数ができなくても、理解可能か？
http://toro.2ch.net/test/read.cgi/tech/1090089115/

827 ：デフォルトの名無しさん：2012/03/08(木) 01:38:19.90

関数型言語　C
http://toro.2ch.net/test/read.cgi/tech/1331138122/

828 ：デフォルトの名無しさん：2012/03/09(金) 01:56:00.56

D言語

829 ：デフォルトの名無しさん：2012/03/16(金) 21:13:20.15

haskellのスレ消えちゃったね。テンプレがあったら作ったんだけど

830 ：デフォルトの名無しさん：2012/03/17(土) 20:03:40.89

自分もHaskellスレは欲しい

831 ：デフォルトの名無しさん：2012/03/18(日) 04:28:30.65

関数型プログラミング言語Haskell Part18
http://toro.2ch.net/test/read.cgi/tech/1331902463/

832 ：デフォルトの名無しさん：2012/03/18(日) 07:00:54.23

>>831
thanks!
さっそくお気に入り登録した

833 ：デフォルトの名無しさん：2012/03/19(月) 22:29:21.89

関数型って最低限チャーチ関係の演算は出来て当然なんだよな

834 ：デフォルトの名無しさん：2012/03/19(月) 22:37:55.51

「チャーチ関係の演算」とは具体的に何を指している？

835 ：デフォルトの名無しさん：2012/03/19(月) 23:17:29.52

チャーチ数とかラムダ演算

836 ：デフォルトの名無しさん：2012/03/19(月) 23:43:09.95

たとえば純粋関数型と言われる Haskell ではチャーチ数をどうやって表現するの？

値構築子を関数と見なせば、チャーチ数と似たような構造で自然数を表現できるし、
その上で閉じた演算ができるのだけれど、じゃあこれがチャーチ数かと訊かれれば、
ちょっと違うような気がする

http://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%A0%E3%83%80%E8%A8%88%E7%AE%97#.E8.87.AA.E7.84.B6.E6.95.B0.E3.81.A8.E7.AE.97.E8.A1.93

837 ：デフォルトの名無しさん：2012/03/20(火) 00:15:14.64

もう少し言えば

チャーチ数は >>836 のリンク先のように自然数の「構造」を関数で表現したものだ
例えば自然数の 2 は、何かに関数を2回適用するという構造として表現している

しかし、他の関数型言語のことは知らんが、
少なくとも Haskell では関数を使って何かの「構造」を表現する事はできない
Haskell の関数は、あくまで何かを計算する事しかできない
関数では不可能な構造を表現するために代数データ型が存在している

例えば何かに関数を2回適用したのか、それとも3回適用したのかを知るには、
その関数適用の構造ではなく、適用した結果に対して自然数の2や3を対応付けるしかない

もちろん、2回適用したものと3回適用したものとの和を計算するのも、
その関数適用の構造そのもので和を計算するのではなく、
関数を適用した結果が対応する「値」に対して和を計算するしかない

関数を適用した結果を代数データ型というある種の構造を表現する値に対応付けることはできる
その方法で構造を自然数に対応付けるのが >>836 の例なのだが、
これは関数で自然数の構造を表現しているのではなく、
あくまで代数データ型で自然数の構造を表現しているのだから、
もはやチャーチ数とは呼べない（構造の形自体は似たように作れるが）

よって、チャーチ数の表現およびその上での演算ができるのが最低限と言われると、
少なくとも Haskell は関数型ではなくなってしまうと私は思う

838 ：デフォルトの名無しさん：2012/03/20(火) 00:22:50.19

template<class> struct F;
template<class> struct Count;
template<class type> struct Count< F<type> >
{
enum{ value = Count< type >::value + 1 };
}

template<class type> struct Count< void >
{
enum{ value = 0 };
};

Count< F< F< F< F<void> > > >::value == 4;

C++のtemplateの方がまだ関数型なのか？

839 ：デフォルトの名無しさん：2012/03/20(火) 00:26:26.44

あ、間違えた
×　template<class type> struct Count< void >
○　template<> struct Count< void >

840 ：デフォルトの名無しさん：2012/03/20(火) 02:59:07.51

>>837
まさか、昔書いたコードを引っ張り出すことになるとわw

-- 自然数を定義
data NaturalNum = Zero | PlusOne NaturalNum
deriving (Eq,Ord,Show,Read)

-- 加算を定義
Zero +^ n = n
m +^ Zero = m
m +^ n = inc m +^ dec n

-- 減算を定義
Zero -^ n = n
m -^ Zero = m
m -^ n | m == n = Zero
m -^ n = dec m -^ dec n

-- インクリメント（１＋）を定義
inc n = PlusOne (n)

-- デクリメント（１－）を定義
dec (PlusOne (n)) = n

-- 自然数を独自自然数へ変換
int2NaturalNum 0 = Zero
int2NaturalNum n = PlusOne (int2NaturalNum (n-1))

-- 独自自然数を自然数へ変換
naturalNum2int Zero = 0
naturalNum2int n = 1 + naturalNum2int (dec n)

841 ：デフォルトの名無しさん：2012/03/20(火) 03:04:19.80

あ、関数そのものを自然数として表現できるか？か・・・
うーん、時間が有るとき挑戦してみよう

842 ：デフォルトの名無しさん：2012/03/20(火) 03:17:44.71

ぱっと思いついただけだから、違うかもだけど・・・

Prelude> let null = 0
Prelude> let f = (1+)
Prelude> f $ f $ f null
3

843 ：デフォルトの名無しさん：2012/03/20(火) 07:42:39.05

お前ら、チャーチ数をぜんぜん理解していないなwww

844 ：デフォルトの名無しさん：2012/03/20(火) 08:27:05.60

まあ代数データ型で定義されるデータコンストラクタも関数の一種ですけどね
静的型なので普通の関数とは区別されてますが

845 ：デフォルトの名無しさん：2012/03/20(火) 10:21:15.73

>>842
そうやって表現した自然数3の「構造」と、
同じように表現した自然数4の「構造」とを足して、
自然数7という数値ではなく、自然数7という「構造」がラムダ式のみで得られるか
ということだよ

チャーチ数がラムダ式で表現する自然数7という「構造」は、
λf x. f (f (f (f (f (f (f x)))))) だ

846 ：デフォルトの名無しさん：2012/03/20(火) 10:42:53.44

型無しラムダ計算でしかできない技法を、型付きラムダ計算ベースのプログラミング言語で
できないぞやーいやーい、と言っているお子様のいるスレはこちらですか？

847 ：デフォルトの名無しさん：2012/03/20(火) 11:32:41.98

>>846
私は Haskell を揶揄しているつもりは毛頭ない
Haskell の他言語に対する利点欠点など、今回の話では何も関係ないからどうでいい

チャーチ数の定義が Wikipedia に載っているものであるならば

「１引数関数 f と任意の x を受け取り、f を x に n 回適用する『関数』を返す関数」

Haskell でその定義どおりにチャーチ数およびの上での演算は表現できないのではないか
したがって、関数型言語ならばそれができて当然とは言えないのではないか
と私は言っている

更に、そもそも Haskell では関数を使って構造を定義することはできないと私は考える

また >>846 に反論するが、
たとえ Haskell が今の形を保ったまま型無し言語に変わったとしても、
依然として Haskell の関数で構造を表現する事はできないのではないだろうか
Haskell だと関数の構造は隠されており、何回適用したかは外から見えない

値構築子も関数の一種だという意見も一方ではあり、
たとえば >>840 で表現できるというと言う人もいるだろうが、
それは上記の定義における「任意の x」を「ある特定の x」に限定したものではないだろうか
もちろんそれは、関数が何回適用されたかの数を保存する構造を持ったある x だ

848 ：デフォルトの名無しさん：2012/03/20(火) 12:17:06.20

＞更に、そもそも Haskell では関数を使って構造を定義することはできないと私は考える
まぁ、ランクＮ多相使えばできるけどな。

ttp://d.hatena.ne.jp/maoe/20110402/1301677925

849 ：デフォルトの名無しさん：2012/03/20(火) 13:06:30.40

>>848
申し訳ない
言語としてのHaskellを考える時は Haskell 2010 Language Report を参照している
http://www.haskell.org/definition/haskell2010.pdf

それはそれとして、言語拡張を使った >>848 の例は面白そうなので、
これでチャーチ数およびその上での計算ができるか検証してみる

850 ： [―{}@{}@{}-] デフォルトの名無しさん：2012/03/20(火) 22:38:25.55

newtype使ってこう書くのって上手くいく? (newtypeを使うのが許されるのなら)
それともどこかに落し穴がある?

newtype MyNum a r = MyNum { unNum :: ((MyNum a r -> r) -> r -> r) }

-- 続きはgistで
https://gist.github.com/2135612

少なくとも+ - * == factは関数とMyNumだけで書けてるっぽい。Intへの変換も可能。

851 ：デフォルトの名無しさん：2012/03/20(火) 23:35:48.23

>>850
上手くいくというのを、チャーチ数の定義と同義だという意味で言ってるのなら、
○○的帰納法で試しかめてみれば良いんじゃないか

0 の時にチャーチ数の定義と同義か確かめる
x の時にチャーチ数の定義と同義だとして x+1 の時にチャーチ数の定義と同義か確かめる

852 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/02(月) 17:34:49.72

http://www.amazon.co.jp/dp/0486478831/ これ誰か読んでみた人いる？
ドーバーだけに安いんだけどな。元は1989年の本。

853 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/02(月) 17:36:16.25

中身をチラミしてみると、lispとMLで解説してるみたいだね。

854 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/02(月) 18:10:39.12

昔読んだよ。
型なしのλ計算に、かなり素朴な方法で複合型を導入してる。
だから厳密さはないが、それなりに面白い。
ただのPostscript版があるからちょっと読んでみれば？
>>853
いや、最後の二章でMLとLiispを扱ってるだけ。

855 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/02(月) 18:37:12.66

Lambda-Calculus and Combinators: An Introduction はお奨めでしょうか？
look insideしたら簡単に書いてくれてる気がする

856 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/05(木) 12:50:00.85

>>854
情報さんくす。読んでみます。

857 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/05(木) 13:53:20.55

>>855
それは「Hindley and Seldin」とも呼ばれたりする定番本です。
簡単ってことはないけど、手元に一冊あれば今後も色々と参照すること間違いない本。
この本の内容が簡単という人は、この世界に進んだほうがいいと思われ

858 ：デフォルトの名無しさん：2012/08/19(日) 13:06:42.60

F#の話題あまり聞かないけどどうなったのかな？流行ってる or 流行りつつあるの？

859 ：デフォルトの名無しさん：2012/08/19(日) 13:20:31.76

現時点で流行ってる or 流行りつつあるのであれば、
こんなに話題がないという状態がおかしい。

まだ少数の個人レベルで楽しんでいる状態だろう。

860 ：デフォルトの名無しさん：2012/08/19(日) 18:41:56.78

>>858
少なくとも欧米の方だと大分評価されてて主に金融向けとかで求人もたくさんある。
日本でも使ってる所いくつかあるみたい。
自分も金融向けだけどクライアントからクラウドまで使い倒してる。
もうC#は嫌ぽ(´・ω・｀)

861 ：デフォルトの名無しさん：2012/08/19(日) 20:13:57.04

日本の金融の求人の主流はまだCOBOL
アメリカも変わらないと思う

862 ：デフォルトの名無しさん：2012/08/19(日) 21:34:24.06

最近の手続き型は関数型の一部を取り込む例がありますが、
逆はどうなんでしょう？

863 ：デフォルトの名無しさん：2012/08/19(日) 21:46:14.68

>>862
そうしてできたのがC言語
当時において、記述力・実行効率・コンパイラの規模等のバランスのもっとも良かった言語

864 ：デフォルトの名無しさん：2012/08/19(日) 21:57:04.34

はっきり言って卑怯なんだよ、最近の手続きは

865 ：デフォルトの名無しさん：2012/08/19(日) 21:59:31.79

意味分からん

866 ：デフォルトの名無しさん：2012/08/19(日) 22:39:26.00

>>862
そうそう、C言語は(手続きが無くて)関数だけでプログラミングするから関数型言語だよな

...... こうですか？よくわかりまへんw

867 ：デフォルトの名無しさん：2012/08/19(日) 22:51:24.87

高階関数っぽいものを書ければ関数型言語と思ってる低能はガチでいる

868 ：デフォルトの名無しさん：2012/08/19(日) 23:05:53.59

＊＊ができたら関数型言語、関数型言語には＃＃が必要

とかいうものも、特にないよな

869 ：デフォルトの名無しさん：2012/08/19(日) 23:15:07.57

>>866
C#のラムダ式とか

870 ：デフォルトの名無しさん：2012/08/19(日) 23:43:23.33

盗むなら盗ませときゃいいんだよ。
プールの時間にパンツを盗まれたクラス一の美少女宜しく
平然としてればいい

871 ：デフォルトの名無しさん：2012/08/20(月) 00:15:36.71

レベル下がりすぎｗ

872 ：デフォルトの名無しさん：2012/08/20(月) 00:20:01.06

レベル下がってなかった時はこのスレってどんな会話してたの

873 ：デフォルトの名無しさん：2012/08/20(月) 00:21:52.44

ぬるぽの圏論的な解釈

874 ：デフォルトの名無しさん：2012/08/20(月) 03:14:05.39

>>869
流れの読めなさに爆笑した。

875 ：デフォルトの名無しさん：2012/08/20(月) 08:57:59.86

>>862
手続き型が関数型の一部を取り込んだのは後から出てきたアイデアだからでしょう。
手続き型が先に広まったから手続き型のアイデアは最初から関数型に取り込まれています。

さらに後から出てきたアイデア(オブジェクト指向など)は
手続き型に取り込まれてから関数型に取り込まれても
関数型が手続き型の一部を取り込んだとはとはみなされません。

>>874
流れが読めてないのは真面目な質問に対してボケた>>866だと思います。

876 ：デフォルトの名無しさん：2012/08/20(月) 09:08:46.32

イタタタタ

877 ：デフォルトの名無しさん：2012/08/20(月) 09:11:18.19

どうした、心房中核欠損症か？

878 ：デフォルトの名無しさん：2012/08/20(月) 13:54:31.50

>>875
＞手続き型のアイデアは最初から関数型に取り込まれています。

例えば何が取り込める？

879 ：デフォルトの名無しさん：2012/08/20(月) 14:32:37.57

横レスですが、
引数を先行評価する言語での、
引数の左からの逐次実行とかどうですかね。

もともと証明論から生まれた帰納関数、チューリングマシン、ラムダ計算が
コンピュータより先行していて、ノイマン型コンピュータは後発なので、
関数型言語は一種の先祖帰りとみなすことも可能です。

880 ：デフォルトの名無しさん：2012/08/20(月) 15:10:36.13

Lisp系言語でいえばdefineがその代表だろうね

881 ：デフォルトの名無しさん：2012/08/20(月) 22:51:19.22

>>878
OpenGLのコールバックは関数型だと宣伝されてました

882 ：デフォルトの名無しさん：2012/08/20(月) 23:09:56.15

C言語の標準ライブラリ関数sort()は、高階関数の概念をもとにしている
したがってCは関数型言語である

...... こうですか？よくわかりまへんw

/*** 許してw >>875 ***/

883 ：デフォルトの名無しさん：2012/08/20(月) 23:12:43.90

>>878
セルを破壊的に更新するLispのsetqとか

884 ：デフォルトの名無しさん：2012/11/03(土) 14:35:53.78

Maximaで出来ないことをCoqでなら出来ないかと考え、勉強を始めていたのだけど、
全く意味が分からず、挫折して一年以上が経過していた。

最近、Haskellを真面目に勉強するところから始めようかなと思い、
Graham Hattonの『プログラミング Haskell』を読み始めた。
それで、第3章の「型とは～集合である」という表現を見て光明が見えた気がした。

数式処理の数式はリストだったので、
今まで、命題もリストなのだという先入観があった。

しかし、型が集合ならば、証明が型推論であっても不思議ではない。

885 ：デフォルトの名無しさん：2012/11/08(木) 08:56:25.80

かりーはわーどらんべっくいそもるふぃずむ

886 ：デフォルトの名無しさん：2012/11/13(火) 23:32:07.34

型は命題なので型推論は命題推論
命題は証明ではない

887 ：デフォルトの名無しさん：2012/11/25(日) 13:37:51.40

流れぶった切りですまん。

今、習作として正則表現エンジンを作ろうと思ってるんだけど、
NFAを組み立てるとき循環グラフ?になるよね。

a(bc)*d

っていう正則表現だったら、
a->ε->(b->c)->εの所へもどる
. 　->d
とかそんなグラフになると思うんだけど
(b->c)を作っているときはεの節が作られていなくて、
εの所へ戻る枝?が作れません。

Cなんかだと(b->c)とかのグラフ群オブジェクトを作る時、
最後の枝を外から書き換えられるようにしてεを完成させるときに
(b->c)のオブジェクトに対して自分のところに戻ってくるように
書き換えました。

immutableでやりたいので書き換えは無しでやろうとすると
どうすればいいのでしょうか?

一般的に循環グラフをimmutableで構築するにはどうすれば
いいのでしょうか ?

教えてください。
お願いします。

　

888 ：デフォルトの名無しさん：2012/11/25(日) 15:02:02.64

letrec

889 ：デフォルトの名無しさん：2012/11/25(日) 16:35:06.07

型無しラムダ計算からSKIコンビネータ計算への変換はbracket abstractionという手法でできるらしいのですが、
多相型のある型付きラムダ計算からSKIコンビネータ計算への変換方法って何か知りませんか？

890 ：デフォルトの名無しさん：2012/11/28(水) 23:05:10.82

まず服を脱ぎます

891 ：デフォルトの名無しさん：2013/01/05(土) 19:20:40.59

Concurrent Cleanを年末年始に触っていたんだけど、スレもなくなってるし、もう終息なんだろうか？

892 ：デフォルトの名無しさん：2013/01/05(土) 19:22:28.12

途中で送っちゃったよ。

関数型言語の話題はHaskell以外あまり出てこないし盛り上がらない。
大学の関連部門だけなのかな？それともどこかで密かに熱くやってるの？

893 ：デフォルトの名無しさん：2013/01/05(土) 22:00:51.17

Cleanはともかく、OCamlやその派生（ScalaとかF#）とかはそれなりに盛り上がってないか？

894 ：デフォルトの名無しさん：2013/01/06(日) 12:09:13.96

すぐに使えておいしい部分はスクリプト言語とかにも輸出されていったから
減ってるように見えるだけで、
関数型もいい意味で空気になったのかなあと

895 ：デフォルトの名無しさん：2013/01/06(日) 12:40:05.80

IFPHが標準教科書になっちゃったからCleanの出番が減った。ただそれだけ
HaskellもCleanもMirandaの方言だから競合しやすいしね

896 ：デフォルトの名無しさん：2013/01/06(日) 15:04:06.69

一番おいしい型理論の部分を輸入したスクリプティング言語があるのなら教えてほしいものだが

897 ：デフォルトの名無しさん：2013/01/06(日) 15:45:49.09

プログラム運算キチガイの本が主流になるとか世も末やな

898 ：デフォルトの名無しさん：2013/01/06(日) 16:02:37.82

どうなるべきだと考えてるんだ？

899 ：デフォルトの名無しさん：2013/01/06(日) 22:19:25.57

Haskellは副作用がないけれども入出力できる、というのは次のように説明されることが多いようだけど。

Haskell 言語（副作用なし、つまり入出力もない）　→　IOが中間言語Xを生成　→　中間言語Xが副作用（入出力）を担当。

これは屁理屈だ、と思う。

900 ：デフォルトの名無しさん：2013/01/06(日) 22:22:13.22

だーかーら、Haskellに副作用はあるんだっつーの
単に、副作用のある部分と無い部分を上手に切り分けられるようにしてるだけで

901 ：デフォルトの名無しさん：2013/01/06(日) 22:27:12.93

でも、Haskellは純粋関数型言語と言われるじゃん。
純粋詐欺なの？って思ってぐぐったら↓

「純粋関数型言語では、参照透過性が常に保たれるという意味において、全ての式や関数は副作用を持たない。」

「参照透過性が常に保たれると言う意味」じゃない場合で副作用がありうる、と言うことか…でも意味が分からないw
だれか平易な解説お願いします

902 ：デフォルトの名無しさん：2013/01/06(日) 22:39:47.11

その辺のカラクリはこうだ。たとえばIOモナドを使うこういう式があるわな

main=putStrLn "hello"

で、このときputStrLn "hello"の戻り値は何だと思う？わかるか？
こんな調子で全部副作用の汚いところはmainが引き受けるわな。で、mainの値は変化してるか？　してないだろ
これが「式の値が変化してない」＝「参照透過性が保たれている」のカラクリだ

903 ：デフォルトの名無しさん：2013/01/06(日) 22:54:53.26

原理的にはこんな感じ？

入出力するプログラムは副作用を持っていて参照透過性も無い
Haskellは、入出力するプログラムを組めないが、入出力するプログラムを返すプログラムを組める
入出力するプログラムを返すプログラムは、副作用を持たず参照透過性を保持することが可能

904 ：デフォルトの名無しさん：2013/01/06(日) 23:19:13.37

副作用がない＝インプットが同じならアウトプットも必ず同じ
IOモナドは実行の度にランタイムシステムからRealWorldというパラメータ
を受け取っている
このパラメータが毎回変化するために、異なるインプット→異なるアウトプット
となることでHaskellプログラムの中では純粋なままであるという理屈
だからプログラムは純粋だけど、ランタイムシステムが純粋じゃないと言える

905 ：デフォルトの名無しさん：2013/01/06(日) 23:45:06.22

つまり’動的に透過’みたいなことか

906 ：デフォルトの名無しさん：2013/01/07(月) 01:51:43.56

表示的意味論のまんま。

907 ：デフォルトの名無しさん：2013/01/07(月) 14:51:40.94

表示的意味論を出さない巷の関数型言語入門は無茶

908 ：８99：2013/01/07(月) 20:37:17.54

純粋関数型 = 翻訳中のどこかでは、参照透過な構造になっている。
手続き型、非純粋関数型 = 翻訳中のどこでも、参照透過な構造を作れない。い

という風に考えたいけれども。。

純粋関数型言語の処理系は、翻訳のどこかで、参照透過な論理構造を作り上げる。
参照透過だから、いろいろ美味しく料理できる…かもしれない。

でも、料理した結果(機械語)は参照透過性は失われ、副作用ばりばり。
そうではなければ、実用性まったくないし。

909 ：デフォルトの名無しさん：2013/01/07(月) 20:54:13.95

機械語に参照透過性があるとかないとかいうのは言葉の使い方がおかしいだろ
少なくとも「変数」「式」の概念がないと参照透過という言葉は意味を持たない

910 ：デフォルトの名無しさん：2013/01/07(月) 21:11:43.41

機械語だって表示的意味論で意味付けできるから、極端な事言えば大差ない。
ただ表示的意味論でよく使われる手法をmonadとして整理したので、
monadでI/Oなどの副作用を扱ったコードの意味が扱いやすいものであるのは間違いない。

911 ：デフォルトの名無しさん：2013/01/07(月) 22:25:08.37

役に立たない学者崩れが昨夜から居ついたね

912 ：デフォルトの名無しさん：2013/01/07(月) 23:01:24.49

関数型スレらしいじゃないか

913 ：デフォルトの名無しさん：2013/01/11(金) 07:39:21.78

>>910
表示的意味論が適用できたってそれだけじゃだめだろ
参照透過性の定義を「式を、その値に束縛した変数で置き換えても結果が同じ」だとするなら、
その言語で「式」「変数」というのが何を意味するのかを決めて初めて議論できる
要するに、プログラムの意味だけ見てもそれが参照透過かどうか判断することはできなくて、
構文まで参照する必要がある

914 ：デフォルトの名無しさん：2013/01/11(金) 22:05:05.32

機械語には変数はない

915 ：デフォルトの名無しさん：2013/01/11(金) 23:03:37.08

レジスタは変数じゃん
単に名前を自分で付けられないだけで

916 ：デフォルトの名無しさん：2013/01/11(金) 23:18:03.32

>>915
変数ではなく、むしろHaskellでいうところのStateモナドに近い

917 ：デフォルトの名無しさん：2013/01/12(土) 00:10:26.44

汎用レジスタは変数かもしれないけど、物によっては何らかのハード状況で勝手に値変えられるものもいるだろうし、
機械語を参照透過と言って良いのかい。
機械語でも制約が何かいるのんじゃないのか。

でもそれ以前に>>908の「料理した結果(機械語)は参照透過性は失われ、副作用ばりばり」と言うのはどういう事を言っているのかしら

918 ：デフォルトの名無しさん：2013/01/12(土) 12:20:23.31

Haskellのコードは参照透過だけど翻訳実行すると副作用が出る、これはどういうことだ？って話だろ
多分「参照透過なのはコードだけ」
「副作用が出るのは処理系（コンパイラ、インタプリタ）のせい」ってのが
イマイチ理解出来てないんだと思う

919 ：デフォルトの名無しさん：2013/01/12(土) 13:09:34.35

これを読めば一発で分かる

IO inside - Haskell Wiki
http://www.haskell.org/haskellwiki/IO_inside

920 ：デフォルトの名無しさん：2013/01/12(土) 14:31:51.47

分かるのかもしれんけど長いな (´･ω･`)

921 ：デフォルトの名無しさん：2013/01/12(土) 18:59:17.84

>>918
Haskellに副作用はない
出力されるIO()は参照透過

IO()の実行結果が参照透過でないだけ

922 ：デフォルトの名無しさん：2013/01/12(土) 20:13:33.88

俺は状況計算みたいなもんだと思ってる。

923 ：デフォルトの名無しさん：2013/01/13(日) 06:44:31.21

>>921
参照透過であることは認めるのだけど、副作用がないというのは詭弁だと思う。
感情をこめて言えば
「言葉の定義を適当にいじって、Haskellすごい、純粋関数型は特別と言っている信者どもうざい」

「Cコード→実行ファイル」のコンパイルだって、副作用ないといえるだろ。
どの言語でも、コンパイルは１入力１出力で、副作用はないし。実行すると副作用が表面化する。

924 ：デフォルトの名無しさん：2013/01/13(日) 06:47:18.06

世界の窓をIOに絞った結果、副作用を扱いつつ参照透過な構造にできた、というなら理解できる。
実行速度最適化に扱いやすい構造だと思う。

世界の窓が２個以上になると、参照透過にできなくなるけれども。 Foreign Function Interfaceで
unsafe系が係るとか・。

925 ：デフォルトの名無しさん：2013/01/13(日) 07:13:53.36

>>923の意見に全面的な同意はできないけど、少なくとも>>921は詭弁だね
Haskellに副作用はある。そのためのIOモナドなんだから。
ただ単に副作用の出る部分とそうでない部分をうまく切り分けてるだけだよ。

926 ：デフォルトの名無しさん：2013/01/13(日) 07:50:43.37

いや単純に「副作用」という言葉の定義が（Haskellコミュニティ内ですら）揺れてるんだよ
「副作用」を「参照透過性を破るもの」と定義する派(結構ポピュラー)に従えば、
Haskellに副作用はないし、たとえばHaskell->JavaScriptに変換した結果
副作用のあるプログラムが出てくるのは何も問題ない
(逆にJavaScript->Haskellに変換すれば、意味は同じで副作用のないプログラムが出てくる)

927 ：デフォルトの名無しさん：2013/01/13(日) 07:59:50.26

Haskellに副作用はない、というのは本当は言いすぎで、
「HaskellからunsafePerformIOやIOを返さないforeign importを除いたものに
副作用はない」という意味だと思ってくれ

928 ：デフォルトの名無しさん：2013/01/13(日) 09:07:11.79

Haskellプログラムに副作用は無い
Haskell処理系に副作用があり、プログラムからは完全に分離されている
これはunsafePerformIO等も例外ではない
Haskellの副作用について議論する時はHaskellプログラムとHaskell処理系(ランタイムシステム)
を区別する必要がある

929 ：デフォルトの名無しさん：2013/01/13(日) 09:18:55.94

それでいいんだが、
>>921はその必要な区別をしなかったから詭弁と叩かれてる

930 ：デフォルトの名無しさん：2013/01/13(日) 09:21:07.97

「Haskellプログラム」に副作用はあるよ。
単に「Haskellのソースコードが参照透過」ってだけ。
まあ言いたいことは分かるけど、言葉は正しく使わんとな

931 ：デフォルトの名無しさん：2013/01/13(日) 10:51:33.09

「副作用」よりも、「参照透過性」の定義のほうが問題だと思う
入出力の不要なプログラムなんてありえない
入力に対して出力が一意なら、参照透過だといえないだろうか

932 ：デフォルトの名無しさん：2013/01/13(日) 11:54:08.65

関数の定義やな∀x y. x = y -> f x = f y
参照透明性とは関数が関数であるということを言う！ハァ？
そうだとしてもIO a同士の同値ってどう定義するんだと
RealWorld -> (a, RealWorld)な値の同値を外延的な同値にしてもRealWorld同士の同値とは？という話に

933 ：デフォルトの名無しさん：2013/01/13(日) 12:21:12.15

>>931
参照透明性の定義∀e1,e2. e1=e2 ⇒ e[e1/p]=e[e2/p]
http://msakai.jp/d/?date=20090705
>>932
IO aの同値の定義は、IO aをDialogueへ変換してDialogueの外延的同値で頑張れないか
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.2504

934 ：デフォルトの名無しさん：2013/01/13(日) 15:34:42.90

Haskellのソースコード上構造は参照透過とは思わないけどね。
さまざまな手段（ライブラリや糖衣構文）で、手続き的プログラミングや再代入が再発明されているから。

ソースコードを読み込んで、軽度に解析した構文木が参照透過になっていると言ったほうが良いと思う。
実行ファイルになるときには、その参照透過性は再び失われる。

つまり、参照透過なのは中間段階だけ。
中間段階に限定しても参照透過になっている言語は珍しく、それを純粋関数型とか言っている・・とか。
（論理型言語は知らないけど、どうなんだろう・・）

935 ：デフォルトの名無しさん：2013/01/13(日) 17:44:16.94

do糖衣構文でソースコード上では参照透明性が破れているように見えるのは確か
その上で参照透明であることの意味を考えた
・モナド使って間接的に副作用を表すと、副作用を型で認識できる
・パラメトリシティにより型を見るだけでその実装が解ることがある
・let多相の値制限が無くなる
・副作用が無いから行える最適化がある

936 ：デフォルトの名無しさん：2013/01/13(日) 19:27:11.00

IO() の実行結果はhaskellの実行結果ではない(haskellの責任ではない)
haskellの関数としての実行結果は、IO()の構築まで(C言語で言うなら、.cソースコードから実行ファイルを生成するまで)

ゆえに、IO()は参照透過であり、haskellに副作用はない

937 ：デフォルトの名無しさん：2013/01/13(日) 19:32:35.85

IO()って参照透過性の定義対象なのかい？意味が分からん

938 ：デフォルトの名無しさん：2013/01/13(日) 20:30:47.35

>>934
>Haskellのソースコード上構造は参照透過とは思わないけどね。
>さまざまな手段（ライブラリや糖衣構文）で、手続き的プログラミングや再代入が再発明されているから。
ちょっと思い浮かばないので具体例くれ

939 ：デフォルトの名無しさん：2013/01/13(日) 21:00:49.11

>>936
>IO() の実行結果はhaskellの実行結果ではない
>haskellに副作用はない
その言い方だとHaskellは標準入出力すらまともに扱えないクソ言語ってことになるだろ
きちんと「Haskellのコード」と「Haskellの処理系」を区別しろよ

940 ：デフォルトの名無しさん：2013/01/13(日) 21:21:38.11

>>939
Haskellは標準入出力を扱うアクションを扱うだけだから、Haskellは標準入出力を扱わない
区別するのは「Haskellのコード」と「Haskellの処理系」じゃなくて、「Haskellのコード&Haskellの処理系」と「アクションの処理系」

Haskellはアクションまでは仕様にあるけど、アクションの向こう側は仕様にないのでHaskellではない
(仕様上は、アクションのコンストラクタはなく、アクションの向こう側はユーザからは見えない)

941 ：デフォルトの名無しさん：2013/01/13(日) 21:32:07.89

つまり"hello, world"と標準出力に表示するコードはHaskellでは書けないってこと？

"hello, world" と標準出力に表示するアクションを扱うコードは書けるが、
仕様の外なので、そのアクションが"good night"と表示しようとも誤りではなく
別にHaskellの規格には違反していないと？

942 ：デフォルトの名無しさん：2013/01/13(日) 21:39:38.91

>>935
実用言語としてのHaskellや純粋関数型言語には期待していて、
特に「副作用が無いから行える最適化がある」という部分にかなり期待している。

でも、実行という現実面には触れない・・「黒板上の理論言語」のように扱っている人がいるね。。

参照透過になっているのは解析中の中間表現に限られるけれど、
最適化という側面から見ると、それで十分だと思う。

943 ：デフォルトの名無しさん：2013/01/13(日) 21:39:38.73

>>941
というか、"hello, world" と標準出力に表示するアクションを扱うコード「しか」書けない

944 ：デフォルトの名無しさん：2013/01/13(日) 21:55:00.19

副作用の存在を、言語が面倒を見る範囲から全面的に排除すると、
結果的に実行できない黒板言語になってしまう・・ようだな。

高速で実行でき簡潔に書けるソースと処理系がほしいのであって、
抽象的で「象牙の塔」のような黒板言語はいらないし、

945 ：デフォルトの名無しさん：2013/01/13(日) 22:03:53.47

実行はできるけど、入出力に責任は持たない
つまり計算結果を 2 と表示するプログラムが、実際には F と表示するかもしれない
そんないい加減な仕様が、Haskell

946 ：デフォルトの名無しさん：2013/01/13(日) 22:06:59.50

必要なのは、抽象的思考がそのままコードになる「象牙の塔」のような黒板言語です
抽象的構造以外の部分で速さや簡潔さを改善されると逆に困ります

947 ：デフォルトの名無しさん：2013/01/13(日) 22:12:09.60

長らく前から、純粋関数型言語は実用を本気で目指しているはずなんだけどな・・。
黒板モデルが重要なら、プログラミング言語ではなく数学になってしまう。

948 ：デフォルトの名無しさん：2013/01/13(日) 22:13:16.15

>>945
画面に2 と表示するつもりでコード作っても実際には紙に F と印字するかもしれないのが標準出力だから、それを「汚染」と表現してわざわざコードから分離しようとしたのがそもそもの話

949 ：デフォルトの名無しさん：2013/01/13(日) 22:23:02.53

>>947
「実用」の意味によるが、保守のしやすさとアルゴリズムと実装の同値性の自動検証性を追及するなら、数学との間に敷居があると困る
抽象的構造に依存しない性能は、ハードの進歩でどうでもいい話になってしまった

ハードに制約がある携帯アプリとかなら話は別だが

950 ：デフォルトの名無しさん：2013/01/13(日) 22:38:58.74

「実行を考慮しない黒板モデル」と書いたほうがよかったかな。
アルゴリズムだけが重要で、その処理についてはまったく考えない。
ただの表現用の言語・・・。ではないはずだよね。

純粋関数型言語は、実用言語、つまり（手の上だけではなく）
コンピュータ上で高速に実行して量的になんらかの成果を得るという
ツールになっているはずで。いろんな意味で、その効率の良さは注目されているはず。
でもなければ私はHaskellに足を踏み入れないよ。

951 ：デフォルトの名無しさん：2013/01/13(日) 22:44:22.98

速度よりも保守
効率よりも正しさ

952 ：デフォルトの名無しさん：2013/01/13(日) 22:52:05.25

実行速度も効率、保守性も効率。
自分の表現したいものを効率的に実現できるツールはなにか？
早く間違いなく・・・。どれがツールとして優れているか。なんだけどな・・。

953 ：デフォルトの名無しさん：2013/01/13(日) 22:52:38.96

糞スレage

954 ：デフォルトの名無しさん：2013/01/13(日) 22:53:46.23

速度＝実行速度と作成速度の和・・・。
　保守性が高ければ作成速度は高い・・・少なくとも低下しにくいわけで。

955 ：デフォルトの名無しさん：2013/01/13(日) 23:28:01.79

学習コストが高い

956 ：デフォルトの名無しさん：2013/01/13(日) 23:32:56.07

>>955
もうすぐ自動コーディングが完成するから待ってて

957 ：デフォルトの名無しさん：2013/01/13(日) 23:46:15.80

学習コストは高いと思う。他のパラダイムと比較すると、難しい。
しかし、１人でプログラミングするのが目的なら、大きな欠点でないと思う。
そもそもプログラミングには膨大な時間がかかるし、その一部を学習にあてたって・・。

958 ：デフォルトの名無しさん：2013/01/19(土) 15:24:54.38

コンビネータSとKがあって、それぞれ
S＝λx・λy・λz (x z (y z))
K＝λx・λy x
Ｉ＝S K S（恒等変換）
と定義されてる時、λxSを上のS, K, Iを使った式に書き換えると (K S)になるらしいけど、どうやってやるの？
変換途中の式を教えて下さいな。多分、情報系学部レベルの話題だと思うんだが…。

せっかく自習してるんだからもうちょっと悩んだ方がいいのかなw

959 ：デフォルトの名無しさん：2013/01/19(土) 15:47:29.14

単にKでλxSに適用された第一引数を捨ててるだけか。しょうもなorz

960 ：デフォルトの名無しさん：2013/01/19(土) 17:47:03.01

ついでに俺から問題を出してやろう
SとKで不動点コンビネータを作れ

961 ：デフォルトの名無しさん：2013/01/19(土) 17:54:40.61

上のは"Functional Programming and Parallel Graph Rewriting"のPDFを偶然拾って読んでたんですわ。

本で自習してると、ふと引っかかって分からなくなってしまうことがあるのが、大学で講義受けるのと違って辛い。
あとでなんでも無い所だったと分かるのだけど、ともすると挫折のきっかけに。
優秀な諸兄はそんなことないですか？w

962 ：デフォルトの名無しさん：2013/01/27(日) 17:06:27.24

どなたか　concurrent clean で、2,3,4次元の配列の
任意の場所に値をセットする方法を教えてください。

Adj ma = {{ma.[i,j] \\ i <- rowindex} \\ j <- colindex}
where
rowindex = [0..maxindex ma]
colindex = [0..maxindex ma.[0]]

ではだめです。
よろしくお願いします。

963 ：デフォルトの名無しさん：2013/01/27(日) 20:28:31.81

WIndowsで無料で開発環境がそろえられる前提でおすすめの言語はなんですか？

964 ：デフォルトの名無しさん：2013/01/27(日) 20:29:04.29

あと関数型言語がはじめてです

965 ：デフォルトの名無しさん：2013/01/27(日) 20:48:20.95

http://www.haskell.org/platform/windows.html

966 ：デフォルトの名無しさん：2013/01/27(日) 22:39:19.81

F#
http://msdn.microsoft.com/ja-jp/library/vstudio/dd233154.aspx

967 ：デフォルトの名無しさん：2013/01/29(火) 22:59:32.33

>>962
何とかできました。
ところで関数型言語は入出力が面倒ですね。
Delphiなんかだったら何も考えずにあっという間に書けるのに。

968 ：デフォルトの名無しさん：2013/01/29(火) 23:57:15.82

>>967
どんな風に書いたの？

969 ：デフォルトの名無しさん：2013/01/30(水) 11:34:16.42

>>968
勉強中で、何とかできたというだけですので、改善点があったらご教示ください。
４次元で示しますと、まず

MyArray4 :: {{{*{#Int}}}}
MyArray4 ={{{{0 \\ k<-[0..1]}\\ j<-[0..2]} \\ i<-[0..1]} \\ h<-[0..2]}

で構造を作ります。空の構造を作る方法はわかりませんでした。
あとは、

set={MyArray4 & [0,1,0,1]=10}
や
set ar h i j k v ={ar & [h,i,j,k] = v}

あるいは、まとめてセットするときは

setall={MyArray4 & [h,i,j,k] = h+i+j+k \\ h<-[0..2],i<-[0..1],j<-[0..2],k<-[0..1]}

のように書いてみました。一応意図どおりに動くようです。

970 ：デフォルトの名無しさん：2013/01/30(水) 11:39:58.40

>>968,969
勘違いしていましたか？
delphiのほうでしたか?。
それでしたら、Formにコンポーネントを貼り付けて、
prepertyを設定して、eventを選んでチョコチョコと書き込むだけです。
具体例によって違いますし、ここには示しにくいです。

971 ：デフォルトの名無しさん：2013/03/07(木) 00:25:40.81

関数型プログラミングの本読んでたら"eureka definition"と何度か出てるんだけどどういう意味か分かる人います？

ぐぐってもよく分からないし、辞書引いてもピンと来ない。用語？
それともただの英単語として使われてる？

972 ：デフォルトの名無しさん：2013/03/07(木) 18:55:14.01

エウレカ！って叫んでしまうほど見事な定義ってことなのかな。
コロンブスの卵的な。

973 ：デフォルトの名無しさん：2013/03/07(木) 19:07:30.16

簡約系で導出して新規に付加された簡約ルール定義のことを、
eureka definitionって言うけれど、どういう系統の話で出てきたのかな?

974 ：デフォルトの名無しさん：2013/03/08(金) 10:02:03.36

まあRentonは関係無いな

975 ：971：2013/03/08(金) 13:07:17.46

ちょっと間を置いて分からなかった箇所を再読してみたんですが、>>972氏のような「これだ！」的な意味かなと思えてきました。
例として、リストを逆順にする関数を再帰で記述したい

→まずfoldを使って記述
→帰納法的な手順で、(n+1)個の要素がある場合をn個の場合＋αの形に変形
→再帰的記述のできあがり、これがEureka definitionだ！

と言った文脈で使われてました。レントンとか月光号とかは関係ないです。

976 ：デフォルトの名無しさん：2013/03/08(金) 13:46:41.16

やはりプログラム変換の話ですね。
じゃあ書いた人は>>973のようなことを念頭に置いていると思います。
技術用語として覚えたほうがいいです。
もちろん972の人が書いた意味からこういう名前が付けられてます。

例えばかなり古い文献ですが↓です。
http://www.diku.dk/OLD/undervisning/2005e/224/papers/Burstall-1977-TransSystem.pdf
A Transformation System for Developing Recursive Programs
RM BURSTALL, J DARLINGTON

こういう変換フェーズのことを"eureka step"と呼んでます。
この変換は一般的ルールからは自明でない発見的なものなのです。
上の文献ではっきりそう定義してます。
プログラム変換屋では完全に定着している用語です。
最近は論理プログラミングや制約プログラミングが多いですが。

977 ：971：2013/03/08(金) 15:54:02.49

丁寧な紹介ありがとうございます。PDFは後ほど読んでみます。

978 ：デフォルトの名無しさん：2013/03/08(金) 19:23:11.51

Bird-Meertens Formalismの前身みたいな内容やな

979 ：デフォルトの名無しさん：2013/03/08(金) 19:45:05.41

そうそう。
Birdさんはeurekaって用語使ってなかったと思うけど。

980 ：デフォルトの名無しさん：2013/03/27(水) 23:55:55.99

ハスケル　オキャムル　エフシャープ♪（呪文）

981 ：デフォルトの名無しさん：2013/03/28(木) 12:00:42.53

型システム入門プログラミング言語と型の理論
ttp://www.ohmsha.co.jp/kaihatsu/archive/2013/01/17112000.html

発売ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━!!!!

982 ：デフォルトの名無しさん：2013/03/28(木) 12:03:33.97

ごめんこっちの方がよかった
ttp://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06911-6