トップページ⇒tech
1001コメント284KB

関数型と手続き型

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2006/04/16(日) 00:46:11
大きな二つの流れである関数型と手続き型について議論･学習するスレです。
両者のメリット、デメリット、得意･不得意分野などをまなびませう。
0002デフォルトの名無しさん2006/04/16(日) 00:59:14
関数型なんて一部のマニアが趣味で使っているだけだろ。
0003デフォルトの名無しさん2006/04/16(日) 01:08:41
手続き型は文系・原始人
関数型は理系・知的
0004デフォルトの名無しさん2006/04/16(日) 01:09:18
エージェント指向
0005デフォルトの名無しさん2006/04/16(日) 01:28:33
erlangは関数型だけど，実用的なものに使われてるよ。

0006デフォルトの名無しさん2006/04/16(日) 06:01:15
一階述語論理は？
0007デフォルトの名無しさん2006/04/16(日) 07:30:18
>>2
関数型は馬鹿を切り捨てるぶん、浸透しにくいよね。
0008デフォルトの名無しさん2006/04/16(日) 08:28:21
C++はSTLのあたりから結構関数型風に傾いていないか？
0009デフォルトの名無しさん2006/04/16(日) 09:15:10
C#でのdelegate、Generics,インターフェースを駆使したものでの生産性と関数型の生産性は異なるの？
0010デフォルトの名無しさん2006/04/16(日) 12:26:25
>>7
教育の問題だと思う。初めてプログラミングを教えるときに使う言語をPrologとかSchemeみたいなのにすれば浸透すると思う。
私は命令型の言語よりもPrologのような論理型言語を使った方がプログラムしやすい。
0011デフォルトの名無しさん2006/04/16(日) 12:29:59
>>10
Prologは言語というよりも証明支援系・・・かな？
0012デフォルトの名無しさん2006/04/16(日) 12:35:27
>>11
ふつうのプログラミング言語だよ。ライブラリは少ないかもしんないけど。
0013デフォルトの名無しさん2006/04/16(日) 12:44:23
手続き型→一般人
関数型→厨房・暇人
0014デフォルトの名無しさん2006/04/16(日) 13:39:51
手続き型のアホに対する優しさは異常
0015デフォルトの名無しさん2006/04/16(日) 13:48:00
>>8
無い。
0016デフォルトの名無しさん2006/04/16(日) 14:16:38
object is poormans closer!!!!!!!!!!!!
0017デフォルトの名無しさん2006/04/16(日) 14:17:43
>>14
手続き型っていうか、代入型は初心者がバグを書くのを助けてくれる。
0018デフォルトの名無しさん2006/04/16(日) 14:18:13
>>15
使ってない人が反応しなくていいです(^^)
0019デフォルトの名無しさん2006/04/16(日) 14:35:21
>>18
お前のことだろw

0020デフォルトの名無しさん2006/04/16(日) 15:17:58
>>8
関数型というより静的(コンパイル時)に決められるものは
徹底的に静的に決めるということだな。
仮想関数はなるべく使わない。クラスを避ける。
自然と関数指向になる。
0021デフォルトの名無しさん2006/04/16(日) 16:45:23
ここで手続き型と関数型の違いについて質問でてるけど、まともな答え返ってこないね。
ttp://pc8.2ch.net/test/read.cgi/tech/1140717775/
0022デフォルトの名無しさん2006/04/16(日) 16:46:17
>>20
> 関数型というより静的(コンパイル時)に決められるものは
> 徹底的に静的に決めるということだな。
>仮想関数はなるべく使わない。クラスを避ける。

という説明から

> 自然と関数指向になる。

これにはならんのだが。
関数型というものを、勘違いしている人のいうセリフだな。
0023デフォルトの名無しさん2006/04/16(日) 17:14:11
手続き型と関数型の違いはプログラミングスタイルじゃないかな。

  * 手続き型

    状態の変化を脳内でシミュレーションし，プログラムを作成。その状態の変化というのが代入などの副作用。

  * 関数型

    事実を定義し，それらの事実と事実との関係を構築しプログラムを作成。
0024デフォルトの名無しさん2006/04/16(日) 17:17:15
関数型、手続き型でおのおの得意なプログラム、苦手なプログラム、出来ないプログラムってあるの？
0025デフォルトの名無しさん2006/04/16(日) 17:18:21
できないプログラムはありません。実はラムダ式に帰着できちゃいます。
0026デフォルトの名無しさん2006/04/16(日) 17:19:43
関数型の生産性と持続可能な発展性は美味しい
0027デフォルトの名無しさん2006/04/16(日) 17:20:35
向き不向きは？
後ラムダ式に帰着できるって言うのはマシン語に帰着できるというような極論？
0028デフォルトの名無しさん2006/04/16(日) 17:23:12
遅延評価があるとリアルタイム処理が難しくならない?
0029デフォルトの名無しさん2006/04/16(日) 17:26:47
>向き不向きは？
あると思う。
>後ラムダ式に帰着できるって言うのはマシン語に帰着できるというような極論？
その通り。
0030デフォルトの名無しさん2006/04/16(日) 17:29:41
関数型は馴染みが無いが、説明的なところを読んで解釈して書いてみる。
間違ってたらｽﾏｿ。

関数型は参照透過性を前提としているから、
途中の「代入」などの状態変化要因がある限り本当の関数型にはなりえない。
なにせ関数型はプログラムの全てを"数学的な意味での関数"として記述するので参照透過性が保たれるのは当然。

f(a,b,c) = 3*a^3 - 5*b^2 + c
こういう代数方程式をプログラムとして記述するのが関数型。
(手続き型は手順というかフローチャートをプログラムとして記述するもの）
(論理型は複数の命題の組み合わせをプログラムとして記述するもの）

関数型ならこうプログラムが組める(こんな言語あるかは知らんが)

hlwd(str) = strcat("Hello! ", str)
main(argv) = putstr(hlwd(argv))

　>main("World")
　Hello! World

手続き型で書くとこうなる(こっちも言語仕様は適当)
main(argv){
　string str="Hello! ";
　strcat(str,argv); //第1引数と第2引数の文字列を結合し、第1引数へ返す
　print(str)
}
0031デフォルトの名無しさん2006/04/16(日) 17:31:39
あらゆる計算モデル、つまりチューリングマシン、帰納的関数論、またはActor理論、etc..はλ計算で表現できます。
0032デフォルトの名無しさん2006/04/16(日) 17:42:13
結局さぁ・・・
普通のプログラムだと、データ受信したとか、入力があったとか何らかの起点があるよね？
そこからの流れが関数として書かれてるってこと？
状態の保持とかどうすんの？
状態持つとかだったら、オブジェクト型のほうが人の思考になじみやすいってこと？
で、どこら辺で生産性があがるのよ？
0033デフォルトの名無しさん2006/04/16(日) 17:44:02
んな小難しいことしなくても

手続きっぽいの
kekka = nanka_no_function( nantoka kantoka )
if kekka then
　print ( "dekitayo!" )
else
　print ( "dekine-yo!" )

関数っぽいの
print (
if nanka_no_function( nantoka kantoka ) then
"dekitayo!"
else
"dekine-yo!"
)
0034デフォルトの名無しさん2006/04/16(日) 17:47:23
あ、手続きのは"dekitayo!"とかをstringの変数に入れたほうがよかったか。
バカっぽくてごめん。
0035302006/04/16(日) 17:49:33
関数型には if も else も存在しない。
なぜなら状態という概念が無いから状態によって変化、分岐するということが無いから。
0036デフォルトの名無しさん2006/04/16(日) 17:50:19
なぁそのコンパクトに書けるっていうのじゃなくてさぁ･･･ほらこう･･･あるだろ？
関数型がこう･･･いいって言われるものがさぁ･･･あるんだよな？
0037デフォルトの名無しさん2006/04/16(日) 17:51:21
生産性は下がるんじゃねーの？関数型はマイナーなんだし。
0038デフォルトの名無しさん2006/04/16(日) 17:58:08
>>35
嘘をつくな。
例えば
abs x = if x > 0 then x else -x
は数学的な意味で関数だ。
0039デフォルトの名無しさん2006/04/16(日) 18:00:45
>>37
そういう次元の話じゃない。
0040デフォルトの名無しさん2006/04/16(日) 18:17:12
関数っていうのは基本的には、
特定の集合に特定の一つの集合を結びつける規則という縛りしかない。
0041デフォルトの名無しさん2006/04/16(日) 18:26:42
確かに馬鹿文系に無理に使わせるのは却って生産性を下げるな。
使いこなせないだろうから。
0042デフォルトの名無しさん2006/04/16(日) 18:29:41
×生産性があがる
○抽象性があがる
0043デフォルトの名無しさん2006/04/16(日) 18:34:20
ラムダとかクロージャとか、
最近の手続き型言語と言われてる言語にも
それなりに導入されてるしな。
直接的なものでなくとも、
言語機能を使えばそれなりに簡単に実装できる、とか。

純粋な手続き型言語ってのはそのうち死滅しそうだが、
だからといって純粋な関数型言語もずっとマイナーでいつづけるだろうな。
0044デフォルトの名無しさん2006/04/16(日) 20:00:58
これが手続き型、
if( ... ) { ... } else { ... }

これが関数型。
... ? ... : ...

if を使わないで、三項演算子だけを使って作れば関数型っぽくなる。

0045デフォルトの名無しさん2006/04/16(日) 20:02:32
人間の考え方は、手続き型です。

だから手続き型の方が人間に分かりやすいのです。
0046デフォルトの名無しさん2006/04/16(日) 20:11:12
>>44
if使う使わないの話は関数型，命令型に関係ない。

もともとCは関数型のスタイルでプログラミングするように設計されてない。Cで関数型プログラミングできないことはないけどやりにくい。
0047302006/04/16(日) 20:32:15
>38
ttp://ja.wikipedia.org/wiki/%E7%B5%B6%E5%AF%BE%E5%80%A4
数学上の絶対値の定義。

＞abs x = if x > 0 then x else -x
これ数学的な意味での関数の書き方じゃないから。

Cでかくとこうなるけどね。
double abs(double x){
　if(x > 0) ;
　else x*=-1;
　return x;
}

そもそも条件分岐している時点で｢状態｣が存在しているわけだから純粋な関数型じゃない。
0048デフォルトの名無しさん2006/04/16(日) 20:39:16
>>47
お前が言うところの「数学的な意味での関数の書き方」て何よ
0049デフォルトの名無しさん2006/04/16(日) 20:44:08
>>48
自然言語が入っちゃマズイとか、
連続していないといけないとか、
定義域が実数じゃないといけないとか、

なんだか色々元の定義とは別のもの仮定してそう。

関数型と数学の関数は違うんじゃないのかな。
0050デフォルトの名無しさん2006/04/16(日) 20:46:35
>>47
条件分岐のどこに状態がある?値を渡す時間によって帰ってくる値が変わるっていうなら状態があるっていうけど。
0051デフォルトの名無しさん2006/04/16(日) 20:48:22
もうこいつら何について話してるのかわかんね。コンテキストがあってねー。
0052デフォルトの名無しさん2006/04/16(日) 20:49:46
結論：誰も分かってる奴がいない。
0053デフォルトの名無しさん2006/04/16(日) 20:50:55
>>51-52
MediatorパターンとAdapterパターン使って。
0054382006/04/16(日) 21:08:29
>>47
数学を引き合いに出したのがまずかったなら言い直すが、
abs x = if x > 0 then x else -x
は正しいHaskellの関数定義(MLでもちょっといじれば通るはず)。
0055302006/04/16(日) 21:27:18
>54
そういうことでなら納得。確かに参照透過性は損なわれないわけだし。
0056デフォルトの名無しさん2006/04/16(日) 21:45:19
つまり、数学のための言語であって
実用的じゃないのが関数型でいいの？
0057デフォルトの名無しさん2006/04/16(日) 21:50:40
>>56
よくないです
0058デフォルトの名無しさん2006/04/16(日) 21:54:04
>>56
違う。
モデル化する方法が異なるだけ。
ディジタル回路を扱うときに使う言語とアナログ回路を扱うときに使う言語の違いのようなもの。

それに実用的に使える。
0059デフォルトの名無しさん2006/04/16(日) 23:03:43
ビジネスというのは最初がローコストに見えることが重要。
安く導入して保守費用で儲けたりさ。そういう観点から見ると手続き型しかありえんのだわ。
0060デフォルトの名無しさん2006/04/16(日) 23:24:44
つはっかーと画家
0061デフォルトの名無しさん2006/04/17(月) 01:02:51
手続き型の言語ばかりやっていると新しい言語の習得が難しくなりコストがかかる。
Schemeみたいな関数型と手続き型の両方のプログラミングスタイルが気軽に扱える言語を覚えた方がトータルで考えると低コストだと思う。

0062デフォルトの名無しさん2006/04/17(月) 03:48:16
手続き型に組み込まれた関数型は実用的だけど、
純粋関数型は実用的だとは思えない。
0063デフォルトの名無しさん2006/04/17(月) 03:50:57
たとえば、Javaの総称型が関数型言語の多相型を取り入れたものだということは明らかなんだけど、
元からの言語仕様に強制的にねじ込んだものだからひどく煩雑なつくりになっている。
あれなら素直に関数型言語を使ったほうが良いとさえ思う。
0064デフォルトの名無しさん2006/04/17(月) 03:56:53
>>62
純粋関数型言語で作られた実用的なアプリ。

http://www.wings3d.com/

思う、思わないはどうでも良いけど、要は使いようですぜ。
頭脳が固まっちゃったら、もうお仕舞いだけどね。

;; 予め言っておくが、他にはって聞かれたら、次は darcs 出すから聞くなよ。
;; 際限無いからな。
0065デフォルトの名無しさん2006/04/17(月) 04:18:01
>>64
英語じゃなくて日本語のやつは無いの？
0066デフォルトの名無しさん2006/04/17(月) 10:24:28
>>64　正直オブジェクト指向に頭が固まってるんだが･･･関数型だとオブジェクトとかどうとらえるの？
そうはとらえんのか？
たとえば、ブラウザ作るとして開いてるページとその中身のhtmlとかはどんな感じに保持するの？
0067デフォルトの名無しさん2006/04/17(月) 11:29:57
>>66 俺も。○○指向、という点ではオブジェクト指向に
頭が固まっちゃってる。問題を解決するに当たって
どんな風にクラスにモデル化するかということばかり
考えてしまう。関数型プログラミングとオブジェクト指向
プログラミングって相性悪い？

ぜんぜん的はずしてるかもしれないけど、 Emacs Lisp
いじってるときはオブジェクト指向の頭が取れてる気がする。
0068672006/04/17(月) 11:43:11
で、なんで相性悪いって気になるのか
仕事中にもかかわらずぼーっと考えてみたんだけど、
オブジェクトの内部状態って関数型プログラミング
ではどうやってあらわすのよ？ってオモタ。
0069デフォルトの名無しさん2006/04/17(月) 11:49:23
>>68
純粋な関数型ではないけどSchemeだったらクロージャと代入を使ってオブジェクトを作る。
純粋な関数型の場合，詳しくはないけど，クロージャとモナドを使うんじゃない?
0070デフォルトの名無しさん2006/04/17(月) 11:52:43
>>69　挿すっと今度は逆にオブジェクト指向を関数型で実現するのに無理してる。最初からオブジェクト指向言語使えばいいのにって感じになるのか？
0071デフォルトの名無しさん2006/04/17(月) 12:05:02
>>70
うん。オブジェクト指向で考えた方が楽なら無理して関数型を使う必要はないと思う。SmalltalkとかRubyみたいな言語を使った方がいいと思う。

0072672006/04/17(月) 12:07:44
>>71 それが混在してるのが悩ましいところなんだよな。
0073デフォルトの名無しさん2006/04/17(月) 12:34:49
逆に手続き型の言語なのに、マシンの状態をイメージしないで
プログラミングするのはカンベンしてﾎｽｲ。人の能力に限りはあるけど、
できるだけそうするように努めるべき。
0074デフォルトの名無しさん2006/04/17(月) 12:37:20
>>71　そうすると、関数型で作るときはオブジェクト的な考え方はしないの？
例であげた、ブラウザ作るときに複数ページを保持するようなものはどうするの？
0075デフォルトの名無しさん2006/04/17(月) 12:56:54
つStateT
0076デフォルトの名無しさん2006/04/17(月) 12:59:16
ストリームとか使うんでない?
0077デフォルトの名無しさん2006/04/17(月) 13:07:42
結局状態を保存しないと無理なんじゃ
0078デフォルトの名無しさん2006/04/17(月) 14:57:57
実際の動作は状態を保存するようなことになるけど、
形式的にはステップごとに状態をバケツリレーしていく感じ。

手続き型
[状態0] -処理1-> [状態1] -処理2-> [状態2] -> ...

関数型
関数x(.. 関数2( 関数1(状態0) ) .. )
0079デフォルトの名無しさん2006/04/17(月) 15:02:09
>>78　処理と処理の間に空白があるときは？たとえば入力してしばらくしてから修正するときとか。
その間はどっかに状態保持するよね？
0080デフォルトの名無しさん2006/04/17(月) 15:23:44
Lispいじるときは関数＝クロージャだから
あまり「手続き型と真っ向対立」みたいなことは思わないなぁ
各関数が各環境を持っているわけで
0081デフォルトの名無しさん2006/04/17(月) 15:29:31
>>79
引数として状態が渡される。
関数nは状態を変更する処理と思えばよい。
入力してしばらくしてからと言う場合はその間に状態を変更する関数が実行されていないか、
もしくは恒等関数( f(x) = x )が実行されていると考えてもよい。
0082812006/04/17(月) 15:34:24
>関数nは状態を変更する処理と思えばよい。
正確には関数nは状態を受け取って次の状態を返す関数。
0083デフォルトの名無しさん2006/04/17(月) 15:37:35
>>81　状態を変更する処理が実行されない間は住所録？どこかに保持されるんじゃないんですか？
オブジェクト指向なら普通
class AddressBook{
void Add(Address addr);
void Delete(string key);
}
見たいなクラスでシングルトンかなんかでアクセスされてインスタンスはひとつがずっと保持されるんだが。
0084デフォルトの名無しさん2006/04/17(月) 15:40:18
>>83
引数として状態が渡されて、引数はその関数を計算する間定数として保持される。
0085デフォルトの名無しさん2006/04/17(月) 15:46:00
>>84　いやだから、入力処理があるよね？で削除処理があるよね？その間どこに保持されるんですか？

0086672006/04/17(月) 15:50:05
>>85 そういうのは副作用で系外に・・・
って、そういうのは反則？
0087デフォルトの名無しさん2006/04/17(月) 15:50:36
>>83
純粋でない関数型言語の場合は、普通にローカル変数を使う。
x = add_address(empty_address_book, "a");
print(x);
// ここで何か別のことをやる。
x' = add_address(x, "b");
print(x');

純粋な関数型言語ではいろいろ妙なことをやるけど、
結果的に似たようなコードになる。
そもそも、逐次処理は手続的に書くのが最善の事が多いから、
関数型言語でも手続的に書けるようになっている。
0088デフォルトの名無しさん2006/04/17(月) 15:51:53
純粋じゃない関数的プログラミングっつったら↓みたいなイメージあるけど間違ってる？

AddressBookって変数を用意して
AddressBook = CreateAddressBook();
AddressBook = AddAddress( AddressBook "Tokyo");
AddressBook = AddAddress( AddressBook "Osaka");
AddressBook = DeleteAddress( AddressBook "Tokyo");

みたいにしていくイメージがあるけどこれでいいの？
0089デフォルトの名無しさん2006/04/17(月) 15:52:53
「状態」っていうのを変数と値の組を記録したデータベースと考えて、
状態0はそれが空のものと考えると、

状態1 = {(住所録, {})} = 新しい住所録作成(状態0)
状態2 = {(住所録, {Aさんの住所})} = Aさんの住所追加(状態1)
状態3 = {(住所録, {Aさんの住所, Bさんの住所})} = Bさんの住所追加(状態2)
状態4 = {(住所録, {Bさんの住所})} = Aさんの住所削除(状態3)

といった感じ。
0090882006/04/17(月) 15:53:03
リロードし忘れましたごめんなさい
0091デフォルトの名無しさん2006/04/17(月) 15:55:12
>>89　結局そのいずれかの状態にあたるものはグローバル変数なり何なりアクセスできるところにおいてあるということ？
0092デフォルトの名無しさん2006/04/17(月) 15:57:51
>>91
いや、その状態にアクセスする関数間を全部引数として引きまわすのが原則。
0093デフォルトの名無しさん2006/04/17(月) 15:59:10
>>92　だとしたら、入力とか削除とかなにされるかわからないときはどんなコードになるんです？
0094デフォルトの名無しさん2006/04/17(月) 16:01:31
>>93
>入力とか削除とかなにされるかわからない
意味が分からん。もうちょっと詳しく。
0095デフォルトの名無しさん2006/04/17(月) 16:05:22
>>94　んーたとえばさっきの住所録みたいなやつ。
>>89　みたいなやつでおのおのの作業（A追加、B追加、A削除)の間にユーザーが行うまでに間がある場合
0096922006/04/17(月) 16:07:15
ごめん。>>92は俺の勘違い。
>>89にあるような「状態」はグローバルにあると考えていい。
0097デフォルトの名無しさん2006/04/17(月) 16:11:32
オブジェクト指向だとデータとメソッドを一体化させるけど、関数型はそれをしないということ？
あと>>96のようにするならば、関数型の状態を変えないからバグが出にくいとかというのはそのばあいには適用されないということ？
0098962006/04/17(月) 16:15:47
混乱させてすまん。>>89の話は(俺が正しく理解してるなら)どちらかというと概念上の話
(あるいは実装の詳細)で、
「関数型言語のインタプリタを作る際にグローバルな状態を活用できる」位の意味に取ってくれればいい。
実際の関数プログラミングでは、データは全部関数間を引きまわす。
0099962006/04/17(月) 16:17:57
で、
>おのおのの作業（A追加、B追加、A削除)の間にユーザーが行うまでに間がある場合
だけど、>>87の説明で分からないところはあるか？
0100デフォルトの名無しさん2006/04/17(月) 16:23:28
>>95
要するに並列処理の場合でしょ。
ちょいややこしいけど、処理のリストを2つ考えてそれを適当に混ぜて1つのリストにしてしまうものを考える。
処理A : abcdef
処理B : ABCDEF
混ぜたやつ : aAbBCcDdeEfF
そして混ざったやつを先頭から順に、
状態1 = a(状態0)
状態2 = A(状態1)
...
状態n = F(状態n-1)
のような感じに計算する。
0101デフォルトの名無しさん2006/04/17(月) 16:24:03
>>99　>>87でわからないところは特にないです。
が、プログラム全体の構造がやっぱりいまいち理解できてないかな･･･
0102デフォルトの名無しさん2006/04/17(月) 16:28:31
自分はハッカーと画家で言われてたようなLISPのきわめて高い生産性に興味があったんだがそれは>>9でいわれてるようなもので可能なものとはまったく異なるものなの？
0103デフォルトの名無しさん2006/04/17(月) 16:30:07
LISPはプログラミング言語じゃありません
0104デフォルトの名無しさん2006/04/17(月) 16:40:14
>>103
LISPがプログラミング言語って書いてあるのはどのへんですか？
0105962006/04/17(月) 16:46:54
>>101
例えば、対話的に追加と削除が出来る住所録のCUIあぷりはこういう感じに書ける。
void loop(address_book book)
{
 command c = get_command();
 if(is_remove_command(c))
   loop(remove_address(book, command_value(c)));
 else if(is_add_command(c))
   loop(add_address(book, command_value(c)));
 else if(is_show_command(c))
 {
   print_address_book(book);
   loop(book);
 }
}

int main()
{
 loop(empty_address_book());
}
0106デフォルトの名無しさん2006/04/17(月) 16:59:29
>>105　そうかくと手続き型と何もかわらんねぇ。
0107デフォルトの名無しさん2006/04/17(月) 17:20:02
>>105
最後のifに対応するelseがないのはまずくない？
まぁ、 else loop(book); でもつければいいだけのことだけど。
0108デフォルトの名無しさん2006/04/17(月) 20:20:54
>>66
レコード型で表現可能

関数型言語でオブジェクト指向はできるかどうか、という質問は非常に多いね。
関数型言語のスレには是非テンプレに入れておいてもらいたいな。
0109デフォルトの名無しさん2006/04/17(月) 22:59:13
ステートマシンみたいな状態の保存必須の事を関数型言語でどうやって表現するの？
結局(setq hoge (func fuga))なの？

というか状態の保存って概念は関数型とか以前な話でFA?
0110デフォルトの名無しさん2006/04/17(月) 23:11:09
>>109
普通に表現できる。
type StateMachine = Input -> (Output, StateMachine)
言い替えると、
「ステートマシンとは、Inputを引数に取って、Outputとステートマシンを返す関数である」
とする。
0111デフォルトの名無しさん2006/04/17(月) 23:57:30
>>109
だから、チューリングマシンでできることはλ計算でできるんだって。
C言語やJavaのような代入型言語でできて関数型言語でできないことはないの。
0112デフォルトの名無しさん2006/04/18(火) 00:16:06
保守性とか可読性とかまったく違うところ目指してる？
0113デフォルトの名無しさん2006/04/18(火) 02:54:34
はい
0114デフォルトの名無しさん2006/04/18(火) 03:25:07
関数型の利点
http://www.sampou.org/haskell/article/whyfp.html
0115デフォルトの名無しさん2006/04/18(火) 10:49:46
代入型言語でプログラミングするなら、レジスタ、CPUキャッシュ、物理メモリの状態を
把握できるようになるべき。それをして初めて関数が多言語並みの厳密なプログラミングができるようになる。
代入型言語でプログラミングしてるやつはやってることがいい加減なくせにそのことにあまりにも無頓着すぎ。
0116デフォルトの名無しさん2006/04/18(火) 10:52:02
>>115
> 代入型言語でプログラミングするなら、レジスタ、CPUキャッシュ、物理メモリの状態を
> 把握できるようになるべき。
それはアセンブリ言語やらC言語などの比較的低級言語の場合だけ。
高級なプログラミング言語では、そういった低レベルなことを忘れても良いように作られるべきなんだよね。
0117デフォルトの名無しさん2006/04/18(火) 10:58:46
>>116
>高級なプログラミング言語では、そういった低レベルなことを忘れても良いように作られるべきなんだよね。

これはドキュンコーダー向けの愚民化コピーだろう。こんなの真に受けてどうするｗ
0118デフォルトの名無しさん2006/04/18(火) 11:01:20
>>115
>関数が多言語並みの厳密なプログラミング

具体的にはどういう事?
「物理メモリの状態」というのも具体的に何を指しているの?
0119デフォルトの名無しさん2006/04/18(火) 11:03:51
>>115
日本語でおｋ
0120無知蒙昧2006/04/18(火) 11:07:22
http://www.sampou.org/haskell/article/whyfp.html
この文章では、説得力ゼロじゃんとか感じた無知蒙昧なオイラにだれかご教授いただけると幸いです。
ここに書いてあるメリットは、最近はC#でもJavaでもPerlでも容易かつスムーズにできると思うんですが。
high-orderはC#の匿名メソッドで。
遅延評価はデザインパターンで。
もちろん、シンタックスは、関数型のが美しいし、可読性もよいけど、
この文章からだと、そんな劇的に生産性が異なるほどとは、ぜんぜんピンときません。
自分でdynamic arrayのクラスを切って、それでLISPのmap関数やapplyに
ラムダ式を渡すような感じで匿名メソッド(クロージャっぽい機能もある)を
渡すように記述することで、極力foreachやforを使わないように書く癖がついてますし。
つまり、それらをデータ構造定義と数式で書き直したとしても、
大して違いはないようなやたらと宣言的に「見える」コーディングスタイルなわけなんですが。
状態云々とか、宗教じゃなくって、関数型言語だと、具体的に、どうしてこれよりも
ずっとソースコード量が減るのか、そこを教えて欲しいです。
0121デフォルトの名無しさん2006/04/18(火) 11:07:34
>>117曰く、「俺は凄いコーダなんだぜ」
0122デフォルトの名無しさん2006/04/18(火) 11:10:04
>>120
代入文って冗長でしょ？
0123& ◆9EVNtil89o 2006/04/18(火) 11:22:41
冗長な代入文なんて、そもそも書いたりしませんよ。
LISPだって、ラムダ式が長くなりすぎなときは、
普通にdefunして、式をsymbolにbindするじゃないですか。
そういう風に式をブロック化することで可読性と再利用性と
デバッガビリティーが向上するからです。
ぼくがC#で代入文を使うときも、それとほとんど同じような感覚で使うんですよ。
つまり、長くなりすぎた式を、部分式に分割して、それに名前をつける目的で、
それを変数に代入する。
だから、結局、それをhaskellに置き換えたとしても結局、やはりその
代入文の右側にある式は、haskellの右側の式とほとんどおなじになっちゃうし、
haskellの左側にある関数名は、C#の変数宣言とほとんどおなじになってしまい、
ソースコードの見た目はほとんど変わらない。
0124デフォルトの名無しさん2006/04/18(火) 12:11:01
C#とかだと変数の型宣言が必須だから、型推論してくれるHaskellと比べるとその分冗長になるとは思うが、
同じ物を同じようなやり方で書くのなら見た目がほとんど同じになるのは当然でしょう。
0125無知蒙昧2006/04/18(火) 12:18:57
型推論自体は、関数型言語とは関係ないですよね。
だって、手続き型なのに型推論機能のついている言語はありますよね。
Pythonとか。
C#の次のバージョンからは、型推論機能も少しは入るらしいし。
「同じものを同じようなやり方で書く」と言っているのではなく、
「より少ないソースコード量やシンプルな表現で記述しようとするにも関わらず、
避けがたい結果として、同じようなソースコード量や表現になってしまう」
ことを問題としています。
0126デフォルトの名無しさん2006/04/18(火) 12:39:24
関数型言語なら短くなる、じゃなくて、
lisp的なマクロがある言語なら短く書ける、じゃねーの？
0127デフォルトの名無しさん2006/04/18(火) 13:03:46
短さならPerl最強
0128& ◆nF6VLM6wpw 2006/04/18(火) 13:10:48
実感値としては、中規模以上のプログラムだと、
「短さならPerl最強」は完全に間違いだと思う。
「lisp的なマクロがある言語なら短く書ける」は結構
実質的には当たっているが、関数型言語の話とは関係ない。
だって、LISPマクロと同等の機能を手続き型言語に入れれば
それで済んじゃう話だもん。
0129デフォルトの名無しさん2006/04/18(火) 13:20:19
.NETで使える関数型ってあるの？
0130デフォルトの名無しさん2006/04/18(火) 13:21:57
Pythonは動的型付けであって、型推論ではないでしょ。
0131デフォルトの名無しさん2006/04/18(火) 13:24:58
純粋関数型＋変数への代入機能(状態保存機能)＝手続き型
っていう認識でおｋ？
0132デフォルトの名無しさん2006/04/18(火) 13:37:13
>>128
それを言っちゃおしまい。

「関数型言語なら短く書ける」は結構実質的には当たっているが、本質的ではない。
だって、関数型言語と同等の機能を手続き型言語に入れればそれで済んじゃう話だもん。

でも、ほいほい何でもかんでも入れちゃうのは文法とかの整合性が取れなくなったりしてまずいと思う。
0133デフォルトの名無しさん2006/04/18(火) 13:54:52
>.NETで使える関数型ってあるの？
つ http://d.hatena.ne.jp/akiramei/20040305
Haskell、もStandardMLも、LISPもありますよ。
0134デフォルトの名無しさん2006/04/18(火) 14:08:37
>>131たぶんおｋ
0135デフォルトの名無しさん2006/04/18(火) 14:19:55
>>134
でたらめ言うな。
0136デフォルトの名無しさん2006/04/18(火) 15:32:24
関数型ってのは関数に値を渡して返ってきた値をまた他の関数へ渡す。このようなスタイルでプログラムを書いていく言語を関数型と言って，代入はあまり使われない。

純粋って言われるのはホントに関数と関数との組合せでプログラムを組み，代入を使わない。又は，代入が使えない。

命令型ってのは変数の値を代入により変えていくようなスタイルでプログラムを書くための言語。

別に関数型だからと言って命令型のプログラムが作れないわけではない。同様に命令型の言語でも関数型プログラミングは可能。

ただ，設計の目的が異なるため関数型ように設計された言語は関数型のプログラムを書き易い。
0137デフォルトの名無しさん2006/04/18(火) 15:57:48
C 言語だとカリー化とかがなぁ。
こんな風にゴリ押しできないこともないみたいだけど、
何だかなぁ。

ttp://nicosia.is.s.u-tokyo.ac.jp/pub/essay/hagiya/h/curry
0138デフォルトの名無しさん2006/04/18(火) 16:14:00
ﾊｷﾞﾔ先生って今のC++についてはどう思ってるんだろ
0139デフォルトの名無しさん2006/04/18(火) 16:33:10
カリー化もそうだが、ラムダはもっと深刻かも。
GCC の内部関数を利用すれば、
近い事はできなくもないが・・・。
0140デフォルトの名無しさん2006/04/18(火) 16:55:38
boost:lambda も面白いな
0141デフォルトの名無しさん2006/04/18(火) 18:08:59
>>136　純粋な関数がたって状態の管理どうするの？
0142デフォルトの名無しさん2006/04/18(火) 18:57:15
>>141
>>110みたいにするのでは？
0143デフォルトの名無しさん2006/04/18(火) 19:15:50
>>141　んー代入と何が違うのかわからん･･･orz
0144デフォルトの名無しさん2006/04/18(火) 19:20:14
すべての処理を const への参照を取って const への参照を返す
って書き方にしたら、関数型言語っぽくなる？
0145デフォルトの名無しさん2006/04/18(火) 19:20:32
状態を扱うときに代入スタイルと大差なくなるのは自然じゃないか？
0146デフォルトの名無しさん2006/04/18(火) 19:22:14
>>145は>>143へのレス
0147デフォルトの名無しさん2006/04/18(火) 20:35:40
>>144
「ほとんどすべての変数を const」 にすると相当それっぽくなる。
0148デフォルトの名無しさん2006/04/18(火) 20:46:11
>>147
関数内部の一時的な自動変数もだめ？
もちろん副作用は起こさないようにして。
0149デフォルトの名無しさん2006/04/18(火) 21:01:59
処理速度は関数型の方が速いの？
代入行わないからなんとなく速そうなんだけど。
0150デフォルトの名無しさん2006/04/18(火) 21:03:54
>>149
の真ん中あたり
ttp://www.unixuser.org/~euske/doc/python/python-lisp-j.html
0151デフォルトの名無しさん2006/04/18(火) 21:09:21
>>148
お遊びだから自分が満足できるだけやればいいんじゃない？
とりあえず for (int i = 0; i < 10; ++i) が禁止になるだけでも結構楽しいよ。
0152デフォルトの名無しさん2006/04/18(火) 21:11:26
>>148
>関数内部の一時的な自動変数もだめ？
関数型の特徴(利点・欠点)はそういう小規模なレベルで特に顕著だと思う。
0153デフォルトの名無しさん2006/04/18(火) 21:13:21
>>151
それくらいだと、末尾再帰の最適化を期待して書くのと
あんまり変わらないかな
0154デフォルトの名無しさん2006/04/18(火) 21:36:18
(define true (lambda (x y) x)))
(define false (lambda (x y) y)))
(define if (lambda (x y z) (x y z)))
0155デフォルトの名無しさん2006/04/18(火) 23:07:44
>>154
はいはい、λ式があれば条件分岐もできるってことね。
0156デフォルトの名無しさん2006/04/19(水) 00:41:05
Smalltalkもifがないよね。
0157デフォルトの名無しさん2006/04/19(水) 00:44:11
参照透明性(同じのを渡せばいつも同じ答えが返ってくる性質)が保たれていると，コンパイル時の最適化がしやすいから，速くできる。

その分，代入があるといつも同じ状況に応じ答えが違うから，コンパイル時にコードを書き換えたりするような最適化がしにくい。あまり速くできない。
0158デフォルトの名無しさん2006/04/19(水) 01:20:41
巨大配列を扱うような数値計算って
純粋関数型で扱えるの？
0159デフォルトの名無しさん2006/04/19(水) 01:41:58
>>158
苦手かもしれないけど、出来ないことはない。
基本的に、手続き型言語で表現できることは
(破壊的代入も含めて)純粋関数型言語でも表現できる。
例えばHaskellでは、普段使う変数は変更不可だし、普段使う関数に副作用はないけど、
効率よく変更可能な「変数もどき」や副作用つきの「関数もどき」がある。
0160デフォルトの名無しさん2006/04/19(水) 03:50:11
>>159
なるほど。
やっぱそのあたりは
如何に純粋関数型言語と言えども
使えるようにはなってるんだ。
ただ、一工夫してあるということやね？
0161デフォルトの名無しさん2006/04/19(水) 17:34:28
>>159
:.:.:.:.:.:.:.:.／ ／　　　　　　　　　　　　　　　　　　　　　 丶､
:.:.:.:.:.:／,／　　　　　　　　　＼　　　　　　ヽ　､　　　　　　＼
:.:.:.:/ ／　　　　　　　　　　　　＼　　　___　ヽ　＼ 　 　 　 　 i
:.:./／　　　l　　　　　 ,　　　　 　 ヽ-弋　 ヽ ヽ　 ＼　　　　　l
V/　　 l　 l　　　　　,-Ａ-､　　　　 ﾊ　lヽ 　 　 l　　 l　　　　 l.
/　　　 l　l　　　,r Ti　l　ヽ　　　　 l ヽl　ヽ　　 l　　/　　 　 /
　　　　 l l　　／　/ l ｌ　　 ヽ　　　ｌ　　　　l　 /　 /　　 ,l　/.
　　　　 ! l､　 　 /　 l!　　　　l　 ／　,rー ､l/|　れ　 ／l／
　　　　　| '、　 /　　 ,ｨ‐-､　l／　　'´　　　　k´/ ／:.:|
､_　　　　＼', /　　／　　　　　　　　　　　/// 'i　＼:.:|　　　もうだめだー
:.:l' - ､＿　＼　　/　　　　　　　　　　　　 　 　 }　　ヽ|
:.:|: :|　(　(￣´　　　///　　　　_ , -ｧ　　　　 ノｌ 　　 ||
､.|: :ゝ､__ -ヽ、　　　　　　　　l´　　ﾉ　　　／l　l.　　 ||
. ||　　 l: :'ｰ '　' - ､　　　　　　'ー '　　, イ : : l　l.　　||
/||　. :l: : : : : : : : : ｨｰ' ｪ､　-----r ' l´ ヽｌ.、: :!　ｌ　 ||
. ||. : l: : : : : :, -‐‐'　 ﾉ　 ￣ 7､　/ヽ lヽ:.:.:.:.´ ヽl　ヽ||
: ||: :l: : : :r' ´:.:.:.:.:.:.:.:.:＼　　/　Ｙ┐ヽl |:.:.:.:.:.:.:.:.:.:´'､.||
: || l: : ,ｨ':.:.:.:.:.:.:.:.:.:..:.:.:.:.:.:ヽ/　　 l　l　 /:.:.:.:.:.:. _ ／', ||ヽヽ
: ||l: : : >､_:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.ヽ､　 l　l /, -ー 'i ´._,ノ' ||: :|ヽゝ
: ||: : : :ﾄ､　/ ｰ ｔ---y--ーi‐‐‐i＼／ヽ,-'ー ' ´　　/ lヽ、

誰かHaskellを２次元化してください。
0162デフォルトの名無しさん2006/04/19(水) 22:16:31
>>161
ttp://pggirls.asukaze.net/index.php?%B2%E8%C1%FC%2FHaskell%A4%BF%A4%F3
0163デフォルトの名無しさん2006/04/19(水) 22:48:25
神さまありがとう
ぼくに友達をくれて

Haskell に会わせてくれて
Haskell に会わせてくれて

ありがとうぼくの友達
Haskell に会わせてくれて
0164デフォルトの名無しさん2006/04/19(水) 22:57:37
Haskellたんはツンデレですか？
0165デフォルトの名無しさん2006/04/19(水) 22:58:14
Haskell で射精した。
0166デフォルトの名無しさん2006/04/20(木) 21:46:32
>>163
元ネタの悪党が友達ってのもすげぇ詩だよな
0167デフォルトの名無しさん2006/04/20(木) 23:49:33
保守の都合でここにカメムシ置いときますね
　　　　　　 ,.
.._ 　 　　 / 　ﾌﾟ〜ﾝ
　 ＼　__,!
　　　 〕-`ｰ;、
　 」`;{ヾ￣.} l'_
　 _/~|　＼l　}=､
　　　<ヽ/ `i/　 ＼._
　　　 _)
0168デフォルトの名無しさん2006/04/21(金) 10:40:15
何でカメムシなんだよ？
0169デフォルトの名無しさん2006/04/21(金) 11:36:55
カメムシってなんとなくラムダに見えなくない？
0170デフォルトの名無しさん2006/04/21(金) 11:50:14
岩手の喧嘩祭といえば、六尺褌一丁の男達が、神輿を担いでぶつかり合う、
勇壮な祭として、この地方に知られている。
祭のあと、男達は集会所に集まり、普段着に着替え、飲み合う。
六尺は、激しい祭でドロドロボロボロになるから、使い捨てで、ゴミとして出される。
俺はいつもそれが狙いだ。
捨てられている六尺の、できるだけ汚れてる奴を10数本ほど、
こっそりさらって家に持ち帰る。
そして、深夜、俺一人の祭が始まる。
俺はもう一度汚れた六尺のみ身に付け、部屋中にかっさらってきた六尺をばら撒き、
ウォーッと叫びながら、六尺の海の中を転げ回る。
汚れた六尺は、雄の臭いがムンムン強烈で、俺の性感を刺激する。
前袋の中のマラは、もうすでに痛いほど勃起している。
六尺の中に顔を埋める。臭ぇ。
汗臭、アンモニア臭や、股ぐら独特の酸っぱい臭を、胸一杯に吸い込む。溜まんねえ。
臭ぇぜ、ワッショイ！　雄野郎ワッショイ！と叫びながら、前袋ごとマラを扱く。
嗅ぎ比べ、一番雄臭がキツイやつを主食に選ぶ。
その六尺には、我慢汁の染みまでくっきりとあり、ツーンと臭って臭って堪らない。
その六尺を締めてた奴は、祭で一番威勢が良かった、五分刈りで髭の、40代の、
ガチムチ野郎だろうと、勝手に想像して、鼻と口に一番臭い部分を押し当て、
思いきり嗅ぎながら、ガチムチ野郎臭ぇぜ！俺が行かせてやるぜ！と絶叫し、
マラをいっそう激しく扱く。
他の六尺は、ミイラのように頭や身体に巻き付け、
ガチムチ野郎の六尺を口に銜えながら、ウオッ！ウオッ！と唸りながらマラを扱きまくる。
そろそろ限界だ。
俺は前袋からマラを引き出し、ガチムチ野郎の六尺の中に、思いっきり種付けする。
どうだ！気持良いか！俺も良いぜ！と叫びながら発射し続ける。
本当にガチムチ野郎を犯してる気分で、ムチャクチャ気持ち良い。
ガチムチ野郎の六尺は、俺の雄汁でベトベトに汚される。
ガチムチ野郎、貴様はもう俺のもんだぜ！
俺の祭が済んだあと、他の六尺とまとめて、ビニール袋に入れ押し入れにしまい込む。
また来年、祭で六尺を手に入れるまで、オカズに使う。
押し入れにはそんなビニール袋がいくつも仕舞ってあるんだぜ。
0171デフォルトの名無しさん2006/04/21(金) 14:32:14
(´・ω・｀)誤爆


(´・ω・｀)ぶち殺すぞ
0172デフォルトの名無しさん2006/04/21(金) 19:00:46
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　,,､ - ｰ― ｰ- ､
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ､- ' ~:::::::::　　　　;;;;;;;;　~''-､
　　　　　　　　　おいお前！　　　　　　　　　　　　　　　　　 , ''~;　; ;;;;;;;::::::::::::::::::::::;;;;;;;;;;;;　 ;;;;ヽ
　　　　　　　　　　　　　　　　　　　　　　　　 ,､　　　　　　　r";; ; ;;;; ;;;; z;;;;;;;;:::::::::::::::;;;;;;;;;;;;;;;;　;;; ヽ
　　　　　　　　　　　　 　　　 　　　　　　　　i;;|　　　　　　r';;;;;; ;;;;rr'(（t"t､;;;､ - ｰｰ ､;;;;;_;;;;;;､;;;;;;;; t
　　　　　　スレの名を言ってみろ！　　 |;;;|　　　　　 ';;;;;;;;r';（;;ヽ,､-;;'''";;､､､;;;;;;;;r'"ii 」ｰ ､)'yヽ､i
　　　　　　　　　　　　　　　　　　 　　　　　|;;; |　　　　　i;;;;､i~t''ｏ't;;;;;;;;≪,,,｡,~'ヽ;;ノ　;ii i;;､､,;;~',､'ｿ ）
　　　　　　　　　　　　　　　　　　　　　　　|;;;;; |　　　　 i ;;;t'､､o｢"｀'ｰ ''"~~~~~~,,,,､::-';;;　~'-ゝ;;ヽ｡ｿ
.　　　　　　　　　　　　　　　　　　　　　　 |;;;;;; |　　　　 | ;;'t､ｧo)ｰ- ''"r'' ,､":::: r'､~~~;;; ~'';;- ､''"*i/
　　　　　　　　　　　　 |;;; t,　　　　　　　 |;;;;;;;; |.　　　　| ;;;;t,ｭｱ;;;;:::／/',, i;;i ::::: i;;;i　::;;;ﾘ~i　:: ::~'ｱ,,ﾉ
､､ ,,,,,,,　　　　　　　　　|;;;;　t　　　　　　 |;;;;;;;;　|　　　　| ;;;;;;;t't;;:／;;/;､ ', i;;i :::: |z;i　 ; ﾘ;;i :::ﾘﾘ : 〉j
;;;;;;;;;;;;;;;;~~~~~ヽ''''''' ､,,,,|;;;; h:ヽ　　　　　|;;;;;;;; :: |.　　　 | ;; ;;;;;;i／;;; /i;;;t,､. i;;i ::: |ﾆ| ;;;;/ｮﾘ :/;/::/::/
　""""""""""''ヽ;;;;;ヽ;;;;~ '' ｰ｀､　,,,,,,,,,|;;;;;;;;;;;;　|　　　 i,,;;;;;;／;;;;:::/::t／ﾘi |;;i :: |;;;i ;; /;;/ ://:::/ /
,,,,,,,,,,,,,;;;;;;;;;;;;:::::::::::t;;;;;;;t;;;;;;;;;;;;;;;;;;~' ､二､,,~~~::''''ｰ- ､,,ﾉ;;;／;;;;:::: /ｰ'"'' ,ｲi |;;;t__i;;t ;;/;;/: //::/　i,r'|　　　　/i
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;|;;;;;;;;i　　::::::::::::;;;;;;ヽ;:::::~'' ,,z､::,,,:::::;>'";;;;;::::: /､､;;;;／::￣::::::::::::::~":::ヽ''〈::/ ''" ,/　　　 /; |
0173デフォルトの名無しさん2006/04/21(金) 21:35:24
今、lispを少し勉強したけど、たいして違いがわからん。
関数形式で表すだけで、やっていることは同じように感じる。
0174デフォルトの名無しさん2006/04/21(金) 21:51:06
>>173
ははは、奇遇だな
俺もFortranとCの違いがわからないんだよー
0175デフォルトの名無しさん2006/04/22(土) 00:05:38
俺もvbとjavaの違いが分からん
0176デフォルトの名無しさん2006/04/22(土) 00:56:46
おらはC#とJavaの違いがわからん
0177デフォルトの名無しさん2006/04/22(土) 02:40:55
俺はひまわりとなでしこの違いが分からん。
0178デフォルトの名無しさん2006/04/22(土) 03:16:22
>>173
Common Lisp はマルチパラダイムな言語だからね。
違いを感じたいなら Scheme やった方が良いかと。
0179デフォルトの名無しさん2006/04/22(土) 03:17:00
ネスカフェとマキシムの違いが分からんが、言語は処理系の違いにもうるさい（やかましいだけ）
01801732006/04/22(土) 10:19:36
もしかして、何を皮肉ってるか理解されてない？
0181デフォルトの名無しさん2006/04/22(土) 12:13:28
>>180
もしかして、何を皮肉ってるか理解されてない？
0182デフォルトの名無しさん2006/04/22(土) 12:18:03
みんな、きもちいいことしてる？
0183デフォルトの名無しさん2006/04/22(土) 12:34:28
まあ、俺が言いたいことはだな、Python最高
0184デフォルトの名無しさん2006/04/22(土) 14:19:43
Python は関数型と手続き型のいいとこ取り？
0185デフォルトの名無しさん2006/04/22(土) 14:25:10
>>184
全然違う
0186デフォルトの名無しさん2006/04/22(土) 15:08:49
>>185
お前が全然違う
0187デフォルトの名無しさん2006/04/22(土) 17:03:12
pythonはなにげにぼくらの期待の星
0188デフォルトの名無しさん2006/04/22(土) 17:06:29
ここで空気を読まずにHSP!HSP!HSP!
0189デフォルトの名無しさん2006/04/22(土) 18:14:13
戯言を皮肉とは言いませんね。
0190デフォルトの名無しさん2006/04/22(土) 19:00:43
関数型言語はたしかにアルゴリズムを簡潔に表現できる。
が、パフォーマンスを気にしてチューニングすると
プログラムが手続き型言語っぽくなってしまう。
機械語自体が手続き型言語だから。
ならはじめから手続き型言語でいいじゃんって思う今日このごろ。
0191デフォルトの名無しさん2006/04/22(土) 19:05:34
ラムダ計算を効率よくできるラムダコンピュータを作ってください
0192デフォルトの名無しさん2006/04/22(土) 19:18:34
>>190
それって disassemble とかして検証してるの?
0193デフォルトの名無しさん2006/04/22(土) 19:29:00
完璧な処理系が作れることを前提とした言語
0194デフォルトの名無しさん2006/04/22(土) 19:50:15
>>191
関数型言語の歴史＝如何にλ式を現行マシンで効果的にコンパイルするか

じゃないの。
0195デフォルトの名無しさん2006/04/22(土) 20:04:43
>>194
関数型言語の歴史
ではなくて、
関数型言語の実装の歴史
でしょ。
0196デフォルトの名無しさん2006/04/22(土) 22:57:29
>>184
それはRubyの話。
0197デフォルトの名無しさん2006/04/22(土) 23:03:38
>>178
Schemeですか。
了解。
0198デフォルトの名無しさん2006/04/22(土) 23:13:58
純粋じゃない関数的プログラミングについて書いてるいい本って何かない？
とりあえず onlisp は読んだ。
0199デフォルトの名無しさん2006/04/22(土) 23:23:46
関数型言語と関数言語ってくべつして呼称すべきですよね？
0200デフォルトの名無しさん2006/04/23(日) 01:38:42
>関数言語
はつみみです
0201デフォルトの名無しさん2006/04/23(日) 07:35:52
関数言語って何ですか？
0202デフォルトの名無しさん2006/04/23(日) 10:26:42
俺が最初にC言語の勉強をしたとき(もう15年以上前だけど)

「C言語は関数型言語だよ、関数言語じゃないよ、
　あくまで「関数型」だよ。関数の形をしているけど、
　同じ引数を与えたからといって同じ結果が得られるとは
　限らないでしょ？だから関数じゃない。関数の形をしているだけ。
　これに対して、世の中には本当の関数言語というのがある。」

と説明してあった本がありました。
0203デフォルトの名無しさん2006/04/23(日) 10:37:53
>>202
晒しキボン
0204デフォルトの名無しさん2006/04/23(日) 14:32:20
その基準で言うと、Haskellみたいなのが「関数言語」っつー事？
0205デフォルトの名無しさん2006/04/23(日) 15:48:13
「C言語」と言ってる時点で駄目本決定。
0206デフォルトの名無しさん2006/04/23(日) 15:56:08
>>202
つーことは関数型言語には現在の時刻を返す関数はないんだな？
0207デフォルトの名無しさん2006/04/23(日) 15:58:48
確かに昔はそんな本がゴロゴロしていたな。

さすがに今はそんな本は見かけなくなった。
google で検索をかければ、それが嘘か本当かすぐ分かるもんな。
いい時代になったもんだ。
0208デフォルトの名無しさん2006/04/23(日) 16:01:21
あるよ。
f(x) = x
0209デフォルトの名無しさん2006/04/23(日) 16:02:00
>>205
void乙
0210デフォルトの名無しさん2006/04/23(日) 16:45:41
作って分かるCプログラミングは隠れた名著
0211デフォルトの名無しさん2006/04/23(日) 21:41:40
なんで「C言語」と言ったらダメなのか分からんのだが。
0212デフォルトの名無しさん2006/04/23(日) 22:13:53
>>210
ほんとに隠れてるよな
0213デフォルトの名無しさん2006/04/23(日) 22:20:16
>>211
BASIC言語
C#言語
C++言語
Pascal言語
Java言語
Javascript言語
FORTRAN言語
Perl言語
Ruby言語
Python言語
Lisp言語
OCaml言語
Haskell言語
Prolog言語
0214デフォルトの名無しさん2006/04/23(日) 22:27:55
>>213
それと同じことだろ？
多少不恰好なだけであって、
そんなんでダメと言い切る理由が無い。
0215デフォルトの名無しさん2006/04/23(日) 22:32:00
隠れて分かるCプログラミング
0216デフォルトの名無しさん2006/04/23(日) 22:33:19
http://homepage3.nifty.com/catfood/up/src/up4748.txt
http://www.google.com/Top/Computers/Programming/Languages/

ここに出ている言語を、関数型と、手続き型に分類してください
0217デフォルトの名無しさん2006/04/23(日) 22:43:54
>>216
「論理型」とかはどうすんのさ？
0218デフォルトの名無しさん2006/04/23(日) 23:21:04
>216
一通り読んで言語名でないものは取り除けよ。
マークアップ言語もな。
0219デフォルトの名無しさん2006/04/24(月) 10:23:58
>>214
誰も言ったらダメなんて言ってないんだが。
0220デフォルトの名無しさん2006/04/24(月) 13:08:01
>>219 >>205
"C"だと短くて日本語の語感としてあわないからなんだろうな。
0221デフォルトの名無しさん2006/04/24(月) 13:59:31
C言語って全く違和感がない。
当方、38歳。
0222デフォルトの名無しさん2006/04/24(月) 14:55:01
私も違和感ない。
当方、21歳。
0223デフォルトの名無しさん2006/04/24(月) 14:57:52
同じく違和感ない。
当方、27歳。
0224デフォルトの名無しさん2006/04/24(月) 15:58:49
for文に違和感あり。
当方、20歳
0225デフォルトの名無しさん2006/04/24(月) 18:10:13
さらにボケて
0226デフォルトの名無しさん2006/04/24(月) 18:32:04
高子さん、晩ご飯はまだかいの
0227デフォルトの名無しさん2006/04/24(月) 18:42:30
さきほどお召しになりましたでしょ。
0228デフォルトの名無しさん2006/04/24(月) 23:46:57
Cってまだ経験無い
当方、37歳。
0229デフォルトの名無しさん2006/04/25(火) 00:00:13
Cに満たない人も多いので油断は禁物でーす
0230デフォルトの名無しさん2006/04/25(火) 00:30:41
中括弧{}だらけに違和感あり。
当方、32歳。
0231デフォルトの名無しさん2006/04/25(火) 00:54:31
Lisper?
0232デフォルトの名無しさん2006/04/25(火) 01:40:27
Delphian?
0233デフォルトの名無しさん2006/04/25(火) 02:42:41
Haskeller?
0234デフォルトの名無しさん2006/04/25(火) 06:02:55
実はコボラーだったりして。
0235デフォルトの名無しさん2006/04/25(火) 10:59:22
こぼちゃんは手続き型？

世代が違うので分からん
0236デフォルトの名無しさん2006/04/25(火) 14:22:54
コボルはデータ指向型という感じだなぁ。
0237デフォルトの名無しさん2006/04/25(火) 14:43:13
>>236
データ指向型って何ですか？

ん〜なかなかイメージ湧きません。
0238デフォルトの名無しさん2006/04/25(火) 15:44:01
SQLとか
0239デフォルトの名無しさん2006/04/25(火) 17:45:18
>>238
データの集合に対する関係を構築してプログラムを作成するって感じ？

0240デフォルトの名無しさん2006/04/25(火) 20:48:49
C#でのカリー化って、こんな感じでOK?
List<int> l1 = getList();
int x = calcX();
List<int> l2 = l1.map(delegate(int y){add(x,y);});
移植性もあるし、そんな複雑にもなってないというか。
0241デフォルトの名無しさん2006/04/25(火) 20:53:30
>>240
言いたいことは分かるが、それを指してカリー化と言うのは誤用じゃないだろうか。
02422412006/04/25(火) 20:57:05
説明不足だな。
add(x)(y)という形でaddを使えるように定義するのがカリー化で、
>>240みたいなのは「関数の部分適用」というはず。
0243デフォルトの名無しさん2006/04/25(火) 21:01:24
>>206
ねーよｗｗ
0244デフォルトの名無しさん2006/04/25(火) 21:12:00
Concurrent Cleanにはあるが。
0245デフォルトの名無しさん2006/04/25(火) 23:17:36
カリー化のカリーはハスケル・カリーのカリー
だからみんなHaskellをやるんだ！
0246デフォルトの名無しさん2006/04/25(火) 23:59:22
とん汁作ってたら味付けが変になったんで
適当に香りの強めの香辛料がばがば入れてったら
カリー化した
0247デフォルトの名無しさん2006/04/26(水) 00:20:48
ＶＢプログラマ　Ｃプログラマのお仕事
http://www.vb-c.net/
0248デフォルトの名無しさん2006/04/26(水) 00:24:43
>>243
^^;
0249デフォルトの名無しさん2006/04/26(水) 01:27:01
カリー化使ったコードは遅い。
スピードが要求されるアルゴリズムの計算では避けるのが普通。
カリー化とはそういうもの。
わざわざHaskellに乗り換えてまで使うほどの価値はない。
0250デフォルトの名無しさん2006/04/26(水) 01:30:34
カリー化でうれしいのは

  * 関数の再利用率が高まる
  * ソースコードの可読化向上

でスピード要求せずにコードの美しさを追求するならいいかもね。
0251デフォルトの名無しさん2006/04/26(水) 01:36:07
Haskellって人にやさしいんじゃなくてコンパイラにやさしい言語なんじゃないかっておもた。

Haskellってほんとに使う人のことを考えて設計されてんのかな?
変数の名前付けとかインタプリタの対話性の難しさはきつい
0252デフォルトの名無しさん2006/04/26(水) 01:38:33
せめてラムダ計算の何たるかを知ってから、関数型言語を語ってくれ。
0253デフォルトの名無しさん2006/04/26(水) 01:54:43
>>252
λ計算が分からないと関数型言語を使っちゃいけないと?
0254デフォルトの名無しさん2006/04/26(水) 01:57:12
使ってもいいけど語っちゃいかんだろな。
0255デフォルトの名無しさん2006/04/26(水) 01:59:38
>>254
λ計算まじめにやってないから資格ないかぁ。
全ての計算がλ式で表わせるってのがλ計算?

まぁλ計算って何だといわれて答えられないから簡潔に教えてください。λ計算って何?
0256デフォルトの名無しさん2006/04/26(水) 03:47:10
>>251
コンパイラにやさしいって事は無いんじゃないの。
コンパイル遅いらしいし、文法もかなり人間向きな感じ。
0257デフォルトの名無しさん2006/04/26(水) 05:59:21
遅レスだが、ＣをＣ言語って呼ぶのは検索し辛いからだと思ってた…
考えてみりゃＣってWeb普及前からあるんだっけ。
0258デフォルトの名無しさん2006/04/26(水) 08:34:24
お前が生まれる前からあるよ
0259デフォルトの名無しさん2006/04/26(水) 11:39:09
>>255
・変数はλ式
・M,Nがそれぞれλ式なら(MN)もλ式
・xが変数でMがλ式なら(λx.M)もλ式
0260デフォルトの名無しさん2006/04/26(水) 12:03:08
まぁ、興味があったら以下の本も読んでおくと良いよ（難易度は上から順、重要度は下から順）
・コンピュータサイエンス入門-論理とプログラム意味論
・計算論-計算可能性とラムダ計算
・The Lambda Calculus: Its Syntax and Semantics
0261デフォルトの名無しさん2006/04/26(水) 12:11:27
アマ向きだなハスケルは
速度はまあいいから簡単にスッキリ記述できてバグも高度に少なく
保守も容易で持続可能な発展を見込める
ただし、言語自体理解するのに高度な知能を要求されるという矛盾も秘めている
頭はいいけど資産が無い奴向きかな？
0262デフォルトの名無しさん2006/04/26(水) 12:15:07
使う分には知識はそんなに要らないよ。
使うための環境をそろえている、まさにその段階が現状なんだから、もう少し待たないとね。
0263デフォルトの名無しさん2006/04/26(水) 13:25:57
　　　　　 　　　,､=＝-,.､ -- ､.. -- ､
　　　　　 　 　 　 ／　__／-‐｀:.:.:`~:.:.:.:.‐:｀ヽ
　　　　　　　　　 　,r／´: . /: . /: . : . : ､: . :｀ヾrz､
　　　　　　　 r‐r＝７ーｧ彡ｿ:.:l:.:.:.:.:.:.ﾊ:.:'; .ヽ:.:.ヽヘ　　いやー　今日も湧いてますなあ
　　　　 　 ／ /{ 　{{ ´_r_´:;l.:‐+.､:..: /- l:､!:.:.:';:.ヾ: .:ヽ
　　　　 ／　　　＼__>r:.T|ﾊ!ヽ|　ヽﾉ　　ｿﾊ:.:.:l:.:.:}:.:.:.:l
　　　／　　　 ＿／:l:.l!:.:l:| z=＝｀　　＝=ﾐ､ｊ:ﾉ:.:/:.:.:.:.|
　　/　　　　　 /ﾊ:.:.:|ヽ(.l::!　　　　､　　　　ノィ/|:.:.:.:!:|
　 /　　　　　/　　`;:ﾄ　 {:人　　 「_ ﾌ　　 /:.:ﾘ　|::::.バ
　 {　　　　ノﾉﾍ､ 　ヾ　　ヾドヽ､_　　_, イﾌジ　 ｊ!ノ
　　＼　　　　 　ヾー--r-､　　ﾞ}　~´ {=､ ´　　 ´
　　　　ヽ､　　　　ﾍ　 ト| l ￣{ﾌ 　 　 ﾏヽ_
　　　　　　｀丶　　　　| ﾞ､'､　 |r=＝=､/ 　 ｀ヽ
　　　　　　　 　｀丶､　l　 ﾄヽ `､ 　　/　　　／ﾊ
　　　　　　　　　　　 ヾl!/　｀ヽ､ヽ／___ .／l　　 !
　　　　　 　 　 　 　 　 {__／￣ﾃ{]≦-､　　Y'´　|
　　　　　　　　　　　　 <　　　´_ハ　ヽ ＼　}　　|
　　　　　　　　　　　　　lﾄ､ /´/:;|: lヽ 　 　〉'　　|
　　　　　　　　　　　　 //`ｰ`´　|　|_ﾉ___r{:.　　 |
　　　　 　 　 　 　 　 〈」‐=､__　 l| =＝､　ﾊ　　 |
0264デフォルトの名無しさん2006/04/26(水) 15:17:19
λは単に基礎
ジェネリックを使ってどのように全体を構築するか考える方が大事
0265デフォルトの名無しさん2006/04/26(水) 18:28:38
>>260
> まぁ、興味があったら以下の本も読んでおくと良いよ（難易度は上から順、重要度は下から順）
Barendregtが一番易しいということ？
あの電話帳を全部読むのはかなりの高難易度だと思うが。飛躍は少ないけど。
0266デフォルトの名無しさん2006/04/26(水) 18:39:03
>>265
難易度は上から順　って言ったら、一番上に書いてあるのが一番易しいってことだろ・・
0267デフォルトの名無しさん2006/04/26(水) 18:53:02
>>266
こういう場合高い方が上じゃね？
0268デフォルトの名無しさん2006/04/26(水) 18:56:05
>>267
逆だとおも
0269デフォルトの名無しさん2006/04/26(水) 19:05:25
「以下は、難度について昇順、重要度について降順」
これが言いたかった事か？
0270デフォルトの名無しさん2006/04/26(水) 19:15:55
難易度順と言うと簡単な方から難しい方へ、
重要度順と言うと重要な方から重要じゃない方へ、
というイメージがある。
0271デフォルトの名無しさん2006/04/26(水) 19:18:12
まぁ、そんなことはどうでもいいことだ。
0272デフォルトの名無しさん2006/04/26(水) 19:37:48
>260は「重要度は下から順」を「一番下が一番重要」という意味で使っている。
これに基づけば、「難易度は上から順」は「一番上が一番難易」と解釈できる。

「一番難易」を「一番難」とみなすか「一番易」とみなすかが意見のわかれる
ところだな。
0273デフォルトの名無しさん2006/04/26(水) 19:43:41
まあ、紛らわしい表現なのは確かだな。
長くなっても、曖昧さを無くした表現を採るべきだな。
0274デフォルトの名無しさん2006/04/26(水) 20:03:26
自然言語だし、いいんじゃない？
0275デフォルトの名無しさん2006/04/26(水) 20:06:45
コミュニケーションがとれればいいけどね。
とれてない以上、何とかした方が良さげ。
0276デフォルトの名無しさん2006/04/26(水) 20:26:42
たとえば、時計回りを物理学では右回りというが、生物学では左回りだという。
常識的には時計回りは右回りだと思っている人が大半だろう。
新聞のような文章でも時計回りと右回りは同じ意味で使っているし、自然言語では社会通念としての「常識」というのが重要なのだろうね。
論文でもない限り、そんなに厳密にしなくてもいいじゃない。
どうでもいいけど。
0277デフォルトの名無しさん2006/04/26(水) 20:37:48
で、その社会通念としての「常識」は
今回の場合存在するのか？
0278デフォルトの名無しさん2006/04/26(水) 20:38:27
どうでもいいらしいのでスルー。
0279デフォルトの名無しさん2006/04/26(水) 20:39:36
>>277
ムきになるなよ＾＾；
0280デフォルトの名無しさん2006/04/26(水) 20:40:21
本題からそれるのが好きな方が多いみたいだね。
0281デフォルトの名無しさん2006/04/26(水) 20:45:09
>>280
ムきになるなよ＾＾；
0282デフォルトの名無しさん2006/04/26(水) 21:20:55
>>272
ああ何となくわかる、
おいらは話の流れ的に260が言わんとすることを「基礎を大事に考えてくれ」と言う前提があるものと解釈したので難易度が上からってのを
「難しく専門向けであり、興味を持つのはよいがあまりその立ち位置じゃ重要視しないでよいよ」の意味にとってしまったのだな。

うむ、ニュアンスが伝わりにくい文字だけの会話って難しいね。
0283デフォルトの名無しさん2006/04/26(水) 22:05:29
こういうときこそ、仕様記述言語Zの出番だろ。
0284デフォルトの名無しさん2006/04/26(水) 22:11:59
>>249
カリー化すると遅くなるのって、関数をコール回数が増えるから?
素人質問でｽﾏｿ。
0285デフォルトの名無しさん2006/04/27(木) 22:20:50
もっと議論したまえ
0286デフォルトの名無しさん2006/04/27(木) 22:27:09
　 　 　 　　　　　　,:::-､ 　 　 　　__
　　　　　　,,r 　　〈:::::::::） 　　　ｨ::::::ヽ
　 　 　　〃 　　,::::;r‐'´ 　 　 　 ヽ::ノ
　　　　,'::;' 　　/::/ 　__
　 　 　l:::l 　　ｌ::::ｌ　/:::::) 　 ,:::::､ 　ｊi
　　　　|::::ヽ　ｊ::::ｌ、ゝ‐′ 　ﾞ:;;:ﾉ　,j:l
　　　　}:::::::ヽ!::::::::ゝ、 <:::.ｧ ＿_ノ::;! 　
.　 　　{::::::::::::::::::::::::::::`='=‐'´:::::::::/
　　　　';::::::::::::ﾄ､::::::::::::::i＾i::::::::::::/
　 　 　 ｀ｰ--'　ヽ:::::::::::ｌ l;;;;::::ノ
　　　　　　　　　　`ｰ-"

【ラッキーコアラ】
このレスを見た人はコピペでもいいので
10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ
出世しまくるわ体の悪い所全部治るわでえらい事です。
0287デフォルトの名無しさん2006/05/07(日) 02:54:27
template <class R, class A, class B> class curry2 {
　typedef R(*)(A, B) func_t;
　func_t _f;　
public:
　curry2(func_t f) { _f = f; }
　curry2_1<R, A, B> operator() (A a) { curry2_1<R, A, B>(f, a); }
};

template <class R, class A, class B> class curry2_1 {
　typedef R(*)(A, B) func_t;
　func_t _f;
　A _a;
public:
　curry2_1(func_t f, A a) { _f = f; _a = a}
　R operator() (B b) { _f(_a, b); }
};

>284
コンストラクタ・コピーコンストラクタ合わせたら相当沢山呼んでる事になるな。
さらに途中引数を一時保存する_aみたいな変数も必要になる。
curry2_1の状態であっちこっちコピーし回るとしたらA=4バイトとしても
8バイト。
0288デフォルトの名無しさん2006/05/07(日) 14:41:16
他スレで、手続き型の言語が全てだと思い込んで○○言語最高とか偉そうに語っている
椰子を見ると、さぶいなと感じる今日このごろ。
たくさんの言語をマスターしているつもりなら、Schemeぐらいは勉強してほしい。
0289デフォルトの名無しさん2006/05/15(月) 00:56:21
ラムダ計算ＡＢＣ
http://members.at.infoseek.co.jp/nbz/ref/lambda.html
を読んでみて思った素朴な疑問
足し算、かけ算みたいなfのネストを増やす方向の演算が出来るのはわかるけど、
引き算みたいなfのネストを減らす方向の演算はどうやってやるんだろう。
0290デフォルトの名無しさん2006/05/15(月) 01:24:11
他にもやりかたはあるかもしれないけど、俺が知ってるのは以下のもの。

まず、aとbのペアをλf.fabで表す事ができる。逆にペアpが与えられたとき、
第一要素はp(λxy.x)、第二要素はp(λxy.y)でアクセスできる。aとbのペアを(a, b)と略記する。
z = (0, 0)
s (x, y) = (y, y+1)
とすると、zとsはλ式で書ける。整数nについてnszはzにsをn回適用したもの、つまり
(n-1, n)というペアであるから、この第一要素を取ることでn-1(n=0の時は0)が得られる。
ここまでの操作を関数化してnからn-1への関数predを書くことができる。すると
n pred mでm-nが計算できる。
0291デフォルトの名無しさん2006/05/15(月) 03:02:48
>>289
Church numeric?
0292デフォルトの名無しさん2006/05/16(火) 03:26:56
>>290
なるほど、cons,car,cdrを使うようなイメージか。
たしかにそれならできそう。
いきなり疑問が解決したよ、感謝！
>>291
だね。こういうのをチャーチ数っていうんだってはじめて知ったよ。
0293デフォルトの名無しさん2006/05/16(火) 03:32:29
関数型ってλがらみの話をすることしかできない言語？
言語を使って何かをしようって感じがまったく感じられず
ひたすら式について語っているのしかみたことないんだけど。
0294デフォルトの名無しさん2006/05/16(火) 03:34:37
>>293
こういうことをしてる人もいる。
ttp://www.geocities.jp/takascience/haskell/monadius_ja.html
0295デフォルトの名無しさん2006/05/16(火) 05:34:28
現在の最新、最高の技術を使って、関数型(Lispとはいわない)マシンを
作ると、何か問題点があるのだろうか。
0296デフォルトの名無しさん2006/05/16(火) 05:42:25
>>293
どんな言語も計算をするために使うものですよ。
0297デフォルトの名無しさん2006/05/16(火) 05:49:22
ひたすらオブジェクトについて語っているだけの人も多いなあ。
0298デフォルトの名無しさん2006/05/16(火) 05:57:01
Rのつくアレかな
0299デフォルトの名無しさん2006/05/16(火) 07:53:04
関数型に理解を示せない奴はプログラマとして正味期限が来ている
アセンブリしかできないプログラマが今受けている視線と同じような物を
近い将来浴びる事になるだろう
0300デフォルトの名無しさん2006/05/16(火) 08:45:05
>>294
＞Haskellでもどうにかゲームは作れるぞということは示せましたが、 実行してたら遅くなるとかいった、Haskellの仕組みをよく知らないと分からない問題はお手上げです。 もっともっとゲームを作りやすくする方法があるはず。 つぎは、みんなにまかせた！
とか書いてある、やはりリアルタイム応答の分野(ゲームぢゃないぞ)には向かないのかねぇ。
0301デフォルトの名無しさん2006/05/16(火) 08:54:53
コンパイラの性能の問題じゃないの？
複数の演算装置を持つような構成に最適化するとなると関数型の方が楽になるかもよ

PS3の方向が成功すれば関数型でなけりゃゲームには無理とか言われるかもね
0302デフォルトの名無しさん2006/05/16(火) 10:09:18
>>299
アセンブラ馬鹿にすんな
0303デフォルトの名無しさん2006/05/16(火) 11:26:29
まぁその都度言語覚えればいいだろな。

言語習得難しくないし
0304デフォルトの名無しさん2006/05/16(火) 15:53:55
>>302
しかできない事を馬鹿にしたのだが
アセンブリは馬鹿にしてないよ
0305デフォルトの名無しさん2006/05/16(火) 18:18:55
自分に向けられた刃を、他の「大物」に向けられたものであるかのように
無理矢理ねじ曲げて解釈し、そこから相手をドン・キホーテ的に捉えてみせるのは
割とポピュラーな逃亡術の一つです :-)
0306デフォルトの名無しさん2006/05/16(火) 19:22:56
example:○国人

ウリの主張に反対するのは世界平和に反対するも同然である。ニダ。
0307デフォルトの名無しさん2006/05/16(火) 21:15:21
関数型とは人間にとってわかりにくい言語。
人間の頭の中は関数型ではない。
0308デフォルトの名無しさん2006/05/16(火) 21:41:32
それはそうだけど、手続き型はもっと脳の把握から遠い気がする。
0309デフォルトの名無しさん2006/05/17(水) 02:48:30
>>308
同感
0310デフォルトの名無しさん2006/05/17(水) 07:24:28
>>308
異感
0311デフォルトの名無しさん2006/05/17(水) 07:25:37
>>308
か・・快感 ♥
0312デフォルトの名無しさん2006/05/17(水) 08:14:44
人間の頭の中は人の言葉尻から自分の頭の中の
都合の良い一群の言葉引き出して口の前に置いて
いるだけで、関数型でも手続き型でもなく、
唖然、呆然、論理型だ。
0313デフォルトの名無しさん2006/05/17(水) 09:40:40
>>308　そーなの？
プログラムって処理の連続になるので手続き型のほうが自然かとおもた（というより関数型よくわかってない）んだが。
0314デフォルトの名無しさん2006/05/17(水) 10:23:18
関数的プログラミングと手続的プログラミングのどっちか片方しかできない言語はうんこ。
逆にこのふたつを十分にサポートしているならコアがどっちかとか副作用を認めるかなんてのは些細な問題だろ。
0315デフォルトの名無しさん2006/05/17(水) 12:36:53
人間の脳はニューロンの複合的な作用によるものだからそのどちらでもない
0316デフォルトの名無しさん2006/05/17(水) 12:49:20
思考には副作用があるから関数型じゃなくね?
0317デフォルトの名無しさん2006/05/17(水) 12:59:22
>>316
たとえば、表面的な作用からプログラミング言語の種類を判定できるか、君は。
0318デフォルトの名無しさん2006/05/17(水) 13:13:31
頭が悪いまま議論めいたことがしたいからって
トンデモ抽象論に走らなくていいから＞そのへんの子
0319デフォルトの名無しさん2006/05/17(水) 13:20:45
なんか同類スレに湧いてるやつがいるな
0320デフォルトの名無しさん2006/05/17(水) 14:27:42
>>308
俺は関数型のプログラムの方が読みやすくて好き。
記述がアルゴリズムの意味そのものに近いから分かりやすい。
手続き型だとアルゴリズムを構築するような感じになるから、記述と意味が離れてしまっていて
内容を理解するのに苦労する。
関数型の楽さに慣れてしまうと、手続き型には戻れなくなる。
0321デフォルトの名無しさん2006/05/17(水) 14:47:17
プログラム、と言われて、UIやらネットワークIOやらを思い浮かべるひとと、
自明でないアルゴリズムの実装を思い浮かべるひととの間で、話がかみ合ってない気がする。
0322デフォルトの名無しさん2006/05/17(水) 14:49:59
.NETばかりやってるんだが、それと絡められる関数型言語ってないでしょうか?
0323デフォルトの名無しさん2006/05/17(水) 14:54:13
>>322
よく知らんのだが、F#なんてどうよ。
0324デフォルトの名無しさん2006/05/17(水) 14:57:33
主観的な話はどうでもいいよ
0325デフォルトの名無しさん2006/05/17(水) 15:07:10
どうでもいいという主観が書くほど大事なこととは思えません ;-)
0326デフォルトの名無しさん2006/05/17(水) 15:46:42
普段は C++ と Java とアセンブラで組み込みを少し。
それ以外の言語は Emacs Lisp と PHP と Perl。
な俺が仕事抜きで関数型言語を理解したいと思って来ましたよ。
Windows で遊べる処理系ってどれ？
できればサンプルが多い処理系の方がありがたいです。
0327デフォルトの名無しさん2006/05/17(水) 16:06:48
Cygwin 入れりゃ大抵の処理系は使えると思うけど、
とりあえず GHC (Haskell) を勧めとこう。
0328デフォルトの名無しさん2006/05/17(水) 17:04:13
>>326
>それ以外の言語は Emacs Lisp と PHP と Perl。
うえ、キモい
0329デフォルトの名無しさん2006/05/17(水) 17:26:49
人は実際にやってみて手順を確認しながら自分のやってることの意味を理解するんだと思います＞＜
もしくは結果が出て初めて自分のやったことの意味を理解するんだと思います＞＜
最初に全ての意味を理解してから行動してる人なんていないと思います(>_<)
関数型言語が扱い難いのはそれなりに理由があるんだと思います＞＜
0330デフォルトの名無しさん2006/05/17(水) 17:31:09
>>328
m9(^д^)ﾌﾟｷﾞｬｰ!!
0331デフォルトの名無しさん2006/05/17(水) 17:32:26
Rの付くあの言語を入れないと、信者達に煽られちゃうよ！気をつけて！
0332デフォルトの名無しさん2006/05/17(水) 18:21:08
という、Rの付くあの言語のスレで叩かれた>>331さんのコメントでした

なんてな
0333デフォルトの名無しさん2006/05/17(水) 19:23:31
何故分かった！
0334デフォルトの名無しさん2006/05/17(水) 23:16:13
Rython
0335デフォルトの名無しさん2006/05/18(木) 01:47:20
RATFOR
0336デフォルトの名無しさん2006/05/18(木) 02:02:24
RPG
0337デフォルトの名無しさん2006/05/18(木) 03:31:05
小説全体を全部一つの文で書くのが関数型。
分かりにくいのは当然。
0338デフォルトの名無しさん2006/05/18(木) 04:21:59
【手続き型小説】

吾輩は猫である。
名前はまだ無い。
どこで生れたかとんと見当がつかぬ。
何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。
吾輩はここで始めて人間というものを見た。

【関数型小説】

人間というものを始めて見た薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶しているがどこで生まれたかとんと見当がつかず名前がまだ無い猫である吾輩。
0339デフォルトの名無しさん2006/05/18(木) 06:43:42
じゃぁ処理済のジョブをジョブ郡から削除しすべてのジョブがなくなった場合はアラーとを出す処理は、
【手続き型】
ジョブ郡から処理済を列挙
その列挙したジョブ郡をジョブリストから削除。
ジョブリストが空ならアラート。
【関数型】
アラートは、ジョブリスト(この場合のジョブ郡-それは処理済のジョブで構成される−が削除されるもの）が空なら鳴る。

ってかんじ？

0340デフォルトの名無しさん2006/05/18(木) 08:37:18
何の根拠もないのだけれど、
表層は論理型、深層は関数型のように思えるなぁ。

手続き型は資源の管理テーブルがしっかりないといけないから。
そんなもの脳の中にあるのかねぇ。
0341名無しさん＠Linuxザウルス2006/05/18(木) 08:46:01
>>340
脳の構造はEBtみたいなリンク、グラフ構造になってると思われ。
リンクの繋ぎかえがあるからその部分は副作用と言える。
0342デフォルトの名無しさん2006/05/18(木) 18:19:57
この世界は現時点の万物の状態から一瞬後の万物の状態を返す関数と言える。
0343デフォルトの名無しさん2006/05/18(木) 19:59:05
ということは、この世界を呼び出して戻り値を使うスーパー世界があるかもしれないってことか
03443392006/05/18(木) 23:02:31
すまんが、この理解であってるんでしょうか?
0345デフォルトの名無しさん2006/05/19(金) 00:46:29
関数型：C言語
手続き型：Pascal

つまり関数型が実践的で手続き型が教育向けって事です。
0346デフォルトの名無しさん2006/05/19(金) 01:12:53
C言語は関数型じゃありません。
前提からして間違っています。
0347デフォルトの名無しさん2006/05/19(金) 03:54:26
>>343
世界は再帰呼び出しだ
そのうちスタックオーバーフロｑあｓｗｒふぇｄｔｇｙふじこｌ；ｐ＠：
0348デフォルトの名無しさん2006/05/19(金) 04:17:22
末尾再帰ならちゃんと最適化されて、オーバーフローしないかもしれないよ、とか。
0349デフォルトの名無しさん2006/05/19(金) 09:23:00
そのうち例外吐きながらビッグクランチか
0350デフォルトの名無しさん2006/05/19(金) 14:29:52
>>347
アセンブラやれ
スタック分かってん野か？
0351デフォルトの名無しさん2006/05/19(金) 15:09:20
>>350
TMS9900とかNM1610とかで泣いた事あるだろ
0352デフォルトの名無しさん2006/05/19(金) 20:47:53
関数型だろうが手続き型だろうが、ある程度高級な静的型の言語は
基本的な道具としてバリアントとパターンマッチと型推論を備えるべきだと思うがどうだろう。
この三つは手続き型のプログラミングでも役に立つし、ないととても不便だ。
いまのところ手続き型言語ではNemerleやmerdあたりにしか実装されてないようだが。

このへんをちゃんと備えた手続き型言語が出てきて初めて、関数型と手続き型のまともな比較ができるような気がする。
0353デフォルトの名無しさん2006/05/19(金) 21:26:12
> このへんをちゃんと備えた手続き型言語
つ ML
0354デフォルトの名無しさん2006/05/19(金) 21:55:39
MLは変数がデフォルトで変更不可だし、goto(やreturnやbreak)がないから手続き型というのは苦しいと思うが。
しかし、手続き型と関数型という区別は余り役に立たないような気がしてきた。
問題になるのはむしろ個々の言語機能、例えばGCがあるか、クロージャがあるか、バリアントがあるか、副作用があるか…だよな。
0355デフォルトの名無しさん2006/05/19(金) 22:21:47
で、結局はいちばんつまらない「ライブラリが充実しているかどうか」に
落ち着くわけですよ。
0356デフォルトの名無しさん2006/05/19(金) 22:58:42
あと日本語（文字コード）対応な。
0357デフォルトの名無しさん2006/05/20(土) 09:27:26
そうなると関数型言語最強はErlang
0358デフォルトの名無しさん2006/05/20(土) 22:59:46
>>357
オブジェクトごとにマジで通信するってのがいい。
0359デフォルトの名無しさん2006/05/21(日) 04:12:11
ErLangとOCamlってどっちが実用的？
0360デフォルトの名無しさん2006/05/21(日) 09:12:19
用途次第
0361デフォルトの名無しさん2006/05/21(日) 13:22:38
並列計算やりたいならErlangが良いんじゃない？
型重視ならOCamlとかHaskellとかが良いと思う。
0362デフォルトの名無しさん2006/05/21(日) 17:35:47
>>352
同意。俺の場合、開発ターゲットはC/C++だけなんだが、
それ用のデータ加工ツールには好きな言語使える。
で、大抵はスクリプト言語とかを使うんだが、
最近ちょっと OCaml や Haskell をかじったもんだから
パターンマッチ使いてえ（*ﾟ∀ﾟ)=3ﾑﾊｰ 状態になったりする。
あとやっぱデータ量が増えてくると速度が欲しくなるとか。

なので、正規表現とか多言語が楽ちんに扱えた上で
静的型付け＆型推論＆パターンマッチも便利、みたいな言語があれば
結構広まるような気がする。
手続きっぽく書いてもいいけど関数型だとより記述がすっきり、
みたいに使ってる人をだんだん関数型に染めてくみたいな。
（C++だとここが逆なんだよなあ）
0363デフォルトの名無しさん2006/05/25(木) 20:29:23
関数型のスクリプト言語が切に欲しい。
Perlのように書きやすくて、Haskellのように考えやすい言語。
0364デフォルトの名無しさん2006/05/25(木) 20:30:27
scheme?
0365デフォルトの名無しさん2006/05/25(木) 20:33:15
>>364
静的な型がないと生きていかれません。
0366デフォルトの名無しさん2006/05/25(木) 20:42:34
>>365
haskellもインタプリタあるんじゃないの？
0367デフォルトの名無しさん2006/05/25(木) 20:48:19
副作用がある処理での、
関数型と手続き型のコードの違いを見てみたい。
0368デフォルトの名無しさん2006/05/25(木) 20:56:08
>>366
あるけど、余りスクリプトっぽい書きやすさを指向した言語じゃないから、面倒な事が結構ある。
ロジックを実装してるうちはいいんだけど、printfやら正規表現やらディレクトリ操作なんかを始めると
途端にJavaっぽいコードを書くはめになる。
0369デフォルトの名無しさん2006/05/25(木) 21:10:17
>>367
関数型のやりかたが知りたいなら、Monadiusのソースを見てればいいんじゃないかな
0370デフォルトの名無しさん2006/05/25(木) 21:11:37
>>367
大して違わない。
http://ja.wikipedia.org/wiki/Hello_world
0371デフォルトの名無しさん2006/05/25(木) 21:56:32
>>370
ちょっと少なすぎてよくわかんないな。
最低でも、比較、繰り返し、関数定義、関数呼び出しぐらいはほしいな。
0372デフォルトの名無しさん2006/05/25(木) 22:42:28
/* C */
# include <stdio.h>
int get_int(void) {
  int r;
  if(scanf("%d", &r) != 1)
    return -1;
  return r;
}
int main(void) {
  int i, sum = 0;
  while((i = get_int()) >= 0)
    sum += i;
  printf("sum=%d\n", sum);
  return 0;
}
-- Haskell
import System.IO.Error
getInt :: IO Int
getInt = do
  r <- try readLn -- 例外を考慮して整数を読み込む
  return (either (const (-1)) id r) -- 例外が発生したなら-1を、そうでないなら読み込んだ値をそのまま返す
main :: IO ()
main = do
  sum <- loop 0 -- whileループ部分を関数loopに切り出してある
  putStrLn ("sum=" ++ show sum)
where
  loop sum = do -- mainに局所的な関数loopの定義
    i <- getInt
    if i >= 0
      then loop (sum + i) -- ループの代わりに再帰
      else return sum
0373デフォルトの名無しさん2006/05/26(金) 00:49:38
>>372
さんくす。

あー。Haskellよくわかんねーなー。
どこで区切って見ればいんだ？
0374デフォルトの名無しさん2006/05/26(金) 00:53:28
>>367
いろんな言語の比較が見たいなら、ここ
ttp://shootout.alioth.debian.org/
とか、ここ
ttp://shinh.skr.jp/testsprite/
が参考になると思う。
0375デフォルトの名無しさん2006/05/26(金) 00:56:50
>>363
関数型言語ユーザーのブログとか見ると、Rubyを使っている人が多い気がする。
関数型じゃないけど。
0376デフォルトの名無しさん2006/05/26(金) 01:01:29
>>372 のを少し違った考え方で書いてみた。

import System.IO.Error
import Control.Monad

repeatM :: IO a -> IO [a]
repeatM mx -- 例外が発生するまでmxを繰り返し実行してその結果のリストを返す
= try mx >>= either (const $ return []) (\ i -> liftM (i:) $ repeatM mx)

getIntP :: IO Int
getIntP -- 正の整数だけを読み込む。それ以外の値だと例外発生
= do{ i <- readLn; if i < 0 then ioError (userError "negative number") else return i }

main :: IO ()
main = do{ s <- repeatM getIntP; putStrLn ("sum = " ++ show (sum s)) }
0377デフォルトの名無しさん2006/05/26(金) 01:50:46
とりあえず、普通？のインデントにしてみよう。
repeatMはよくわからんので保留
こうやって見ると、関数型の特徴がよくわからんｗ
ただのシンタックスシュガーに見える。

getIntP :: IO Int
getIntP = do{
　　i <- readLn;
　　if i < 0 then
　　　　ioError (userError "negative number")
　　else
　　　　return i
}

main :: IO ()
main = do{
　　s <- repeatM getIntP;
　　putStrLn ("sum = " ++ show (sum s))
}
0378デフォルトの名無しさん2006/05/26(金) 02:02:46
俺はつねづね、forとifを関数オブジェクトを使って実装すれば
関数型言語になると思っているんだが？
JavaScript風に書くと

function for_func(from,to,func) {
　　for(var i = from; i < to; i++) {
　　　　func(i);
　　}
}

function if_func(condition,func) {
　　if(condition) {
　　　　func();
　　}
}

って感じの関数を定義してやれば、あとは全部関数型としてかけると思う。
for_func(1,10, function (i) { print(i) })
if_func(1=1, function () { print(true) })


0379デフォルトの名無しさん2006/05/26(金) 02:08:32
>>378
ラムダ式は？
0380デフォルトの名無しさん2006/05/26(金) 02:29:20
それはただの無名関数のことだろ。
0381デフォルトの名無しさん2006/05/26(金) 07:16:08
378に従うとすると、C++も関数型言語として言える。……よな？
for_eachはあるしBoost.Lambdaもあるし。
0382デフォルトの名無しさん2006/05/26(金) 07:57:21
>>377
>こうやって見ると、関数型の特徴がよくわからんｗ
だから>>370な訳だが。
手続き型っぽくかけるようにわざわざ構文糖を用意してるんだから似てるのは当然。
0383デフォルトの名無しさん2006/05/26(金) 08:50:58
>>381
C++のその辺は、文字通り「関数型言語的に書くために生み出された道具」だと思う。
だから「378に従うとすると」という仮定は要らないんじゃないかな。

とはいえあくまでも現段階のそれらは「関数言語的に書ける」レベルであって、
細かいところではまだまだ同じようにはいかないところがあるのだろうけど。
0384デフォルトの名無しさん2006/05/26(金) 10:20:27
>>378
集合と列はどう扱うの？
0385デフォルトの名無しさん2006/05/26(金) 18:27:01
そういえば関数型言語では、

・型Tから「要素型Tのlist型」を作るtype constructorと、
・その要素を作るdata constructor（たとえば[]と:）

は代数data型の枠組みで容易に扱えるけど、

・型Tから「要素型Tの集合型」を作るtype constructor（powerset constructor）
・その要素を作るdata constructor

はどうやって扱うのが一般的なんだろう？
listと違って、data constructorが要素の値に依存する（multisetでないとして）
から話がややこしそうだ。
0386デフォルトの名無しさん2006/05/26(金) 19:18:26
>>385
HaskellやOcamlでは二分探索木を使って実装されている。
木のデータ構築子は隠し、代わりに構築用の関数(emptyとinsert)をエクスポートして、
抽象型としてアクセスさせる。
0387デフォルトの名無しさん2006/05/26(金) 20:04:06
>>386
まあそんなところか。
手続き型言語と同じってことで。

おそらくgraphも同様かな。ただgraphの場合、理論上は切断等を使って
構成的にdata型を定義できるはずだが。
0388デフォルトの名無しさん2006/05/26(金) 21:15:33
手続き型と関数型が合わさって
さらに発展したものがオブジェクト指向だな。

いまさら関数型にこだわる必要も無いだろう。
0389デフォルトの名無しさん2006/05/26(金) 21:24:45
オブジェクト指向を強制されないというだけでも関数型には価値がある。
0390デフォルトの名無しさん2006/05/26(金) 21:44:02
>>388←何も知らない馬鹿
0391デフォルトの名無しさん2006/05/26(金) 21:44:48
低学歴の香りがするよな
0392デフォルトの名無しさん2006/05/26(金) 22:24:21
馬鹿という奴が（ｒｙって奴ですねｗ
0393デフォルトの名無しさん2006/05/26(金) 22:42:10
ということにしたいのですね
0394デフォルトの名無しさん2006/05/26(金) 22:43:13
>>393
当たり前だろ、ごみ野郎
0395デフォルトの名無しさん2006/05/26(金) 23:50:07
【馬鹿という奴が馬鹿なんだ】
突きつけられた己のレベルを認めたくない人間が
現実逃避に用いるポピュラーなうっちゃり。
大抵は失敗して土俵に潰れるが、潰れたままヘラヘラ笑い続けるのが特徴。
0396デフォルトの名無しさん2006/05/29(月) 02:44:04
>395
うるさい！ばかっていうやつがばかっていうやつがばかなんだぞ！
0397デフォルトの名無しさん2006/05/29(月) 09:26:02
精神的に向上心のないものは、ばかだ
0398デフォルトの名無しさん2006/05/29(月) 10:34:42
精神的でない向上心などあるものか
0399デフォルトの名無しさん2006/05/30(火) 00:16:03
敗者とは始める前から諦めている者のことである。
0400デフォルトの名無しさん2006/05/31(水) 23:23:15
「始めたら負けかなと思ってる」
0401デフォルトの名無しさん2006/06/01(木) 21:26:15
歯医者。
0402デフォルトの名無しさん2006/06/07(水) 21:21:03
なあ思ったんだけど、
関数の記述を 関数名(引数) じゃなくて (引数)関数名 にすれば
なんか日本語にとっても近くならないか？
0403デフォルトの名無しさん2006/06/07(水) 21:36:09
マジレスすると
そんなことするよりオブジェクト指向にしちまえばいいんじゃないのか
0404デフォルトの名無しさん2006/06/08(木) 19:34:18
日本語に近付けるなら、助詞が有効に使えないとな。
0405デフォルトの名無しさん2006/06/08(木) 19:40:23
活用もできるようになるといいね。
0406デフォルトの名無しさん2006/06/08(木) 19:42:29
ボケナス乙。

１から読み始めて、３０あたりで爆笑が止まらなくなって、
スレ削除することにしました。

じゃぁなｗ
0407デフォルトの名無しさん2006/06/08(木) 19:44:02
なんとなくたかひろくさいスレだな
0408デフォルトの名無しさん2006/06/08(木) 19:45:47
_________Ｋ仲川について　Part10____________
http://pc8.2ch.net/test/read.cgi/prog/1121735183/l50

【初めて仲川勝彦（Ｋ仲川）と仕事する方へ】
http://pc8.2ch.net/test/read.cgi/prog/1149580345/l50

　　　　　　　　　　†　　　　　　　　　
http://pc8.2ch.net/test/read.cgi/prog/1111407459/l50
0409デフォルトの名無しさん2006/06/08(木) 19:52:38
C/C++＞＞＞＞(越えられない壁)＞＞＞Lisp＞＞＞＞(越えられない壁)＞＞＞Haskell
0410デフォルトの名無しさん2006/06/08(木) 20:14:06
バグの生産性
0411デフォルトの名無しさん2006/06/08(木) 20:29:32
C++ >>> Ada > PL/I
0412デフォルトの名無しさん2006/06/08(木) 21:37:34
テキストでいいからエロゲー作ってくれ
0413デフォルトの名無しさん2006/06/08(木) 23:23:52
DOS時代の探せばノベル系エロゲーあったかもしれない。
0414デフォルトの名無しさん2006/06/08(木) 23:30:05
スクリプトインタプリタは関数型言語の得意分野ということになるかな。
0415デフォルトの名無しさん2006/06/09(金) 00:07:52
いろいろ議論はあるけど、実用の際に一番ポイントになるのは↓になると思うよ


　関数型　　　：　ソースコード自体がそのプログラミング言語のデータ構造になっている。

　手続き型　　：　ソースコード自体がそのプログラミング言語のデータ構造になっていない。


　　　　　
0416太田司　2006/06/09(金) 00:12:39
[email protected]
↑僕のメアドなんで痛メでも何でも送って楽しませてください
皆のメール待ってます
0417デフォルトの名無しさん2006/06/09(金) 00:14:37
>402
func(func(func()))
（（（）関数）関数）関数

この場合、最初に入れ子の数を
予測して書かなければならない。
些細だが、気になる人は気になると思う。
0418デフォルトの名無しさん2006/06/09(金) 00:16:46
>>417
そこで助詞の出番ですよ。
0419デフォルトの名無しさん2006/06/09(金) 00:23:31
助詞表記
()を関数を関数を関数
ドット表記
().func.func.func
0420デフォルトの名無しさん2006/06/09(金) 01:06:09
$stdoutに linesを puts
0421デフォルトの名無しさん2006/06/09(金) 03:04:29
>>337-338素晴らしい。
今まで関数型志向設計の有意性と無為性を語ってきたが、これほどわかりやすく且つ特徴を捉えた例も説明も無く苦労してきた。

　　ミミ彡ﾐミﾐ彡彡ミミﾐﾐ
,,彡彡彡ミﾐﾐ彡彡彡彡彡彡
ﾐﾐ彡彡ﾞﾞﾞﾞﾞ""""""""ヾ彡彡彡
ミミ彡ﾞ　　　　　　　　　ﾐﾐ彡彡
ﾐミ彡ﾞ　＿　　　　＿ 　 ﾐﾐミ彡
ﾐミ彡 '´￣ヽ　　'´￣｀ ,|ミﾐ彡
ﾐﾐ彡　￣ﾟ￣'　〈￣ﾟ￣ .|ﾐミ彡
　彡|　　 　　|　　 　 　 |ﾐ彡
　彡|　　　´-し｀)　　／|ﾐ|ﾐ　　　／￣￣￣￣￣￣￣￣
　 ゞ|　 　　　､,!　　　　 |ソ　　＜　カンドーした！
　　　ヽ　'´￣￣￣`ﾉ /　　　　　＼＿＿＿＿＿＿＿＿
　　　 ,.|＼､　 　　' ／|､
￣￣| ｀＼.`──'´／ |￣￣｀
　　　 ＼　~＼,,／~　 /
　　　　　＼／▽＼／
0422デフォルトの名無しさん2006/06/09(金) 05:36:29
天動説、地動説。
0423デフォルトの名無しさん2006/06/09(金) 10:37:00
>>339　ｽ万が誰かこの理解が正しいのか教えてくれ
0424デフォルトの名無しさん2006/06/09(金) 10:42:03
>>423
それは単なるデータ構造の違いというだけ。
関数型・手続き型の違いとはあまり関係ない。
0425デフォルトの名無しさん2006/06/09(金) 11:05:42
>>424　よくわからんです（･ω･）
0426デフォルトの名無しさん2006/06/09(金) 11:09:36
>>425
>【手続き型】
>ジョブ郡から処理済を列挙
これは配列を使うという意味でしょう？

>【関数型】
>アラートは、ジョブリスト(この場合のジョブ郡-それは処理済のジョブで構成される−が削除されるもの）が空なら鳴る。
これはリストを使うという意味でしょう？

配列を使うかリストを使うかというだけでしかなくて、関数型か手続き型かという意味の問題ではなくなっているんだよ。
0427デフォルトの名無しさん2006/06/09(金) 11:40:54
>>【手続き型】
>>ジョブ郡から処理済を列挙
>これは配列を使うという意味でしょう？
>
>>【関数型】
>>アラートは、ジョブリスト(この場合のジョブ郡-それは処理済のジョブで構成される−が削除されるもの）が空なら鳴る。
>これはリストを使うという意味でしょう？
とてもそうは見えないのだが。
0428デフォルトの名無しさん2006/06/09(金) 11:41:57
>>426　
ん、データ構造はあまり気にしてなかったんですが。
手続き型でリストだろうが、マップだろうが。
そもそも手続き型と関数型の違いがあまり判っていないんですが、
猫であるの例を見て、それを実際の処理記述に当てはめるとこうなるのかと思って書いた次第です。
自分がここで聞きたいのは関数型での処理の記述がこんな風になるのかということですね。
0429デフォルトの名無しさん2006/06/09(金) 12:04:16
寧ろこうか?
手続き型
列挙ジョブ群 = ジョブ群.列挙(処理済)
ジョブリスト.削除(列挙ジョブ群)
if (ジョブリスト.空) アラート()

関数型
ジョブ群から処理済を列挙したジョブ群を削除したジョブリストが空なら鳴らすアラート
0430デフォルトの名無しさん2006/06/09(金) 12:14:24
>>429
概念的にはそんな感じだと思うけど、実際の関数型言語では、
両者の折衷形態で書かれるのが普通だと思う。

if(ジョブ群から処理済を列挙したジョブ群を削除したジョブリストが空)
  アラートを鳴らす。

これだと高水準な手続き型言語と区別がつかないけど。
0431デフォルトの名無しさん2006/06/09(金) 12:20:29
処理とは　アラートを鳴らす事が出来るならアラートを鳴らす
アラートを鳴らす事が出来るとは　残処理リスト が 空である
残処理リストとは　ジョブ群から 処理済みを列挙したジョブ群を 削除したものである

こうじゃないの？
0432デフォルトの名無しさん2006/06/09(金) 12:32:28
>>429

処理済みのものを求めて引くよりは、最初から未処理のものだけ列挙すりゃいいじゃん。

手続き型(というよりOOP?)
func ジョブ群.列挙(フラグ) {
　ジョブ群のうちフラグが立っている物だけを列挙して返す。
}
if (ジョブ群.列挙(未処理).空) アラート()

関数型
if (空？( 抽出(未処理？, ジョブ群) )) アラート()
ここで、抽出(f,s)はsの要素のうち判定関数fで真であるものだけを集めたもの。

0433デフォルトの名無しさん2006/06/09(金) 12:38:53
>>431
Haskellっぽく書けばそうなるな。
>>430はML風ということで。
ついでにCleanっぽいのを書いてみる。

処理後の世界とは、アラートを鳴らすことが出来るならば
処理前の世界にアラートを鳴らした後の世界であり、
そうでなければ処理前の世界と同じ世界である。
以下>>431と同様。

しかし、この手の比較が関数型言語の特徴をうまく掴んでいるとは思えないんだが。
関数型と手続き型の違いを知りたいなら、入出力の絡まない処理の方がわかりやすいと思う。

>>432
それは両方とも関数型だと思われ
0434デフォルトの名無しさん2006/06/09(金) 12:58:08
>>432
ジョブ郡から終了したものを削除する処理とアラームなる処理は別だから。
＞関数型と手続き型の違いを知りたいなら、入出力の絡まない処理の方がわかりやすいと思う。
その例を是非
0435デフォルトの名無しさん2006/06/09(金) 15:35:01
遅延評価の中の人がどうステップ踏んでるのか知りたい
やたら遅いのでなんか事故ってると思う
0436デフォルトの名無しさん2006/06/09(金) 16:10:01
>>435
Haskellスレで質問してた人？
特定のコードが遅いならあっちで晒してみるといいかと。
0437デフォルトの名無しさん2006/06/09(金) 17:31:07
>>415
おまいの脳内世界では関数型言語がLisp系しか存在しないってのがわかった
0438デフォルトの名無しさん2006/06/09(金) 18:05:42
まあ、関数も変数だからな・・
0439デフォルトの名無しさん2006/06/12(月) 11:57:01
関数型を勉強する者は蟻
手続き型で十分だと関数型を軽視する者はキリギリス
0440デフォルトの名無しさん2006/06/12(月) 12:34:07
しかし、世界はキリギリス中心に動く。
0441デフォルトの名無しさん2006/06/12(月) 13:46:29
>>440
そのフレーズいただいた
あとで俺がそのフレーズ朴った本出しても訴えるなよ
0442 ◆4.bZNjkJnA 2006/06/12(月) 13:52:41
ｓｓ
0443デフォルトの名無しさん2006/06/12(月) 19:19:40
なんつうか、アリとキリギリスが逆じゃねえ？
0444デフォルトの名無しさん2006/06/12(月) 20:30:13
確かに。 Java プログラマがキリギリスだとは思えない。
0445デフォルトの名無しさん2006/06/12(月) 21:19:27
うむ。逆だろw
0446デフォルトの名無しさん2006/06/12(月) 21:21:15
蟻でもキリギリスでもない。糞ころがしだ。
0447デフォルトの名無しさん2006/06/13(火) 00:27:13
数年前の関数型言語スレのコピペかよ。
クダラネェな。
0448デフォルトの名無しさん2006/06/13(火) 14:59:13
なに興奮してんの？ｗ
0449デフォルトの名無しさん2006/06/13(火) 23:28:19
> 2006/06/13(火) 14:59:13

　　　　　　　　　　　　↑ヒッキー発見ｗ
0450デフォルトの名無しさん2006/06/14(水) 01:03:11
？
0451デフォルトの名無しさん2006/06/14(水) 10:11:05
>>450
>449はきっと、平日昼間に書き込むのはヒッキーだと思い込みたいリアル厨かヒッキー予備軍なんだろ。
0452デフォルトの名無しさん2006/06/14(水) 10:47:16
平日昼間に余裕で書き込める窓際社員(古w)のオレが来ましたよ
0453デフォルトの名無しさん2006/06/14(水) 11:04:37
あこがれるっす
0454デフォルトの名無しさん2006/06/14(水) 23:50:29
>>452
昼食時間もまともにとれない俺様が深夜帰宅途中に携帯カキコですがなにかorz
0455デフォルトの名無しさん2006/06/15(木) 00:36:20
>>454
会社辞めさせてもらえないって本当?
0456デフォルトの名無しさん2006/06/15(木) 05:04:52
無職透明な俺が456ゲット。
0457デフォルトの名無しさん2006/06/18(日) 01:51:56
マ板でやれ
0458デフォルトの名無しさん2006/06/29(木) 21:34:54
(f (f (f x)))
(((x f) f) f)
(x f (f (f)))
(((f) f) f x)

>>417
0459デフォルトの名無しさん2006/06/29(木) 22:22:43
Smalltalkのブロックはそんな感じかも。

x ← [ [ [ ... ] value ] value ] value.
みたいな。
MacOSXで復活(?)したObjective-Cも近いんじゃないかね。
0460デフォルトの名無しさん2006/07/19(水) 20:42:18
57 名前：デフォルトの名無しさん[] 投稿日：2006/02/16(木) 10:58:30
>>56 プログラム全体にわたっての型の整合性は
コンパイルが通った時点で保証されている、と信じたいから

という発言に対し、

65 名前：デフォルトの名無しさん[] 投稿日：2006/02/16(木) 21:42:52
っていうか、>>57 みたいなこと書くやつは死ねばいいと思う。
お前みたいなド素人がプログラミングでメシ食っていこうなんて百年早い
マジ死ねよ

と返す。
これがBoostスレクオリティ。
0461デフォルトの名無しさん2006/07/19(水) 23:32:23
一応書いておくけど、その後フォロー入っているよ。
66デフォルトの名無しさんsage2006/02/16(木) 21:45:48
>>65
57の感覚自体はまともだと思うけど
0462デフォルトの名無しさん2006/07/20(木) 07:22:50
こんな関係無いスレに言いつけに来るなよ57ｗ

自分の代わりに「敵」をやっつけてくれそうな猛者でも期待したのか？
残念だったなｗ
0463デフォルトの名無しさん2006/07/20(木) 15:16:44
65乙
0464デフォルトの名無しさん2006/07/20(木) 15:28:38
こんな関係無いスレに言いつけに来るなよ57ｗ

自分の代わりに「敵」をやっつけてくれそうな猛者でも期待したのか？
残念だったなｗ
0465デフォルトの名無しさん2006/07/20(木) 15:36:12
>>460
ゴキブリはチョンＳＰさっさとゴミ箱に捨ててＮＤＳで知育ゲームでもやったら？

でないとおまえ本気で社会復帰できないよｗｗｗｗｗｗｗｗｗｗｗｗ
0466デフォルトの名無しさん2006/07/20(木) 15:41:55
　　　　　　　　　　／∧　　　 ／∧
　　　　　　　　 ／　/ λ　 　／　/λ
　　　　　　　／　　/ /λ ／　　/ /λ
　　　　　 ／　　　/ / /λ　　 / / /λ
　　　　／　　　　　　　　 ￣￣　　　 　＼
　　　/　　　　　／￣＼　　　　　／￣＼＼
　　 /　　　　　 |　　 ●| 　　　　| 　　●|　 ヽ
　　|　　　　　　 し￣ヽJ　　　　 し ￣ヽJ　 　| 　　　　　　　　―→>>463
　 ｜　　　　　　　　 　 　　'"""　　　　　　 　 |
　　 ＼　　　　　　 　丶 ＿__人＿__ノ　　　 /
　　　　＼_　　　　　　　　ヽ―／　　　__／ ＜ うぷぷぷ
　　　　　／　　　　　　　　　￣　ヽヽ　　　＼
　　　　／
0467デフォルトの名無しさん2006/07/20(木) 19:39:57
ひどいな
そんな気に障るようなレスだったのかね
0468デフォルトの名無しさん2006/07/21(金) 05:31:40
まぁ57にとっては
気に障るなんてもんじゃなかったんだろうな。
こんなとこに泣きついてくるくらいだから。
0469デフォルトの名無しさん2006/07/21(金) 14:39:22
>>468
いつまでも粘着してるお前の方がどうかと思うぞ
0470デフォルトの名無しさん2006/07/21(金) 14:51:03
>プログラム全体にわたっての型の整合性は
>コンパイルが通った時点で保証されている、と信じたいから
OCamlではこれがあるから、実行時エラーが少なくてすむ。
0471デフォルトの名無しさん2006/07/21(金) 15:20:04
いや、型周りに穴があるC++でそれを期待するのは間違いって話じゃないの？
04724712006/07/21(金) 15:31:30
見てきた。
違うみたいだな。
視野の狭い人間が偉そうにしてるって話か。
くだらん。
0473デフォルトの名無しさん2006/07/21(金) 16:22:48
>>461
否定してるだろうが
よく読め馬鹿

68 名前：デフォルトの名無しさん[] 投稿日：2006/02/16(木) 21:50:14
>>66
お前も死ねよ。ド素人が

>>472
どこをどう読めばそうなるのかなーwww
チョンは氏ね
0474デフォルトの名無しさん2006/07/22(土) 04:26:44
あーあ泣き出しちゃったｗ
0475デフォルトの名無しさん2006/07/22(土) 05:03:14
>>474
誤爆か？
04764742006/07/22(土) 05:05:46
>>475
頭がかわいそーな人ﾊｹｰﾝ
0477デフォルトの名無しさん2006/07/22(土) 05:43:46
>>476
誤爆か？
0478デフォルトの名無しさん2006/07/22(土) 21:16:57
Haskellが下火になってきたな
みんな飽きてきたらしい
0479デフォルトの名無しさん2006/07/23(日) 00:48:54
まあ、アルゴリズム関連は処理速度が遅い、GUIも苦手と来れば使い道ないもんな。
一通りのことを勉強したらそれで終わりって感じ。
0480デフォルトの名無しさん2006/07/23(日) 04:22:24
よーし、ついに Lisp 時代の到来だ
0481デフォルトの名無しさん2006/07/23(日) 05:02:47
　　(　ﾟдﾟ)　 　　　　
＿(__つ/￣￣￣/＿
　　＼/　　　　/
　　　　￣￣￣

　　( ﾟдﾟ )
＿(__つ/￣￣￣/＿
　　＼/　　　　/
　　　　￣￣￣
0482デフォルトの名無しさん2006/07/23(日) 06:44:19
もっと見てv
0483デフォルトの名無しさん2006/08/17(木) 02:38:05
　　( ﾟдﾟ )
＿(__つ/￣￣￣/＿
　　＼/　　　　/
　　　　￣￣￣

　　(　ﾟдﾟ)　 　　　　
＿(__つ/￣￣￣/＿
　　＼/　　　　/
　　　　￣￣￣
0484デフォルトの名無しさん2006/08/17(木) 04:17:25
見〜て〜よ〜ぉぉ！！！
0485デフォルトの名無しさん2006/08/30(水) 09:01:25
>>417
括弧なくせばイイんじゃね？


それなんてFO…
0486デフォルトの名無しさん2006/08/30(水) 12:08:55
>>402
BibTeX の bst ファイルは後置記法でそんな感じだなあ。
おもっくそ読みにくいよ。
0487デフォルトの名無しさん2006/09/01(金) 21:24:44
>>402 >>417 >>485-486
Haskell の $ の逆で
行始からそれまでの式を
一発で括る記法作ったらどうよ
0488デフォルトの名無しさん2006/09/08(金) 03:28:09
Dなら
arr.map((int n){return n * b;}).writefln();
とかできるが
0489デフォルトの名無しさん2006/09/11(月) 16:56:02
infixl 1 %
(%) = flip ($)
main = [1..10] % map (*5) % print
0490デフォルトの名無しさん2006/09/11(月) 18:48:12
>>488
感動した。Cもついにここまで来たか。
0491デフォルトの名無しさん2006/09/11(月) 19:19:27
だからCじゃないって。
0492デフォルトの名無しさん2006/09/11(月) 22:58:26
C -> C++ -> D
0493デフォルトの名無しさん2006/09/12(火) 07:37:27
　　　　　　　　↑いまここ
0494デフォルトの名無しさん2006/11/04(土) 13:04:31
「手続き型」も一種の「関数型」と見なしていいんですよね？
0495デフォルトの名無しさん2006/11/04(土) 16:04:24
J - C++ for Haskeller
http://d.hatena.ne.jp/w_o/20061008#p1

> C++とは、以下のような特徴を持ったプログラミング言語です
>
> 参照透明（！）
> 出現評価(occurrence evaluation) （などといういかがわしい単語をつくる）
> パターンマッチできる
> 全く直感的でない構文
> IOモナドを書くための大量のsyntax sugarがある

クソワロタ
0496デフォルトの名無しさん2006/11/04(土) 16:54:21
何が面白いんだ？

事実そのままやん
初心者には、面白く感じるんかね？
0497デフォルトの名無しさん2006/11/04(土) 17:28:00
俺も初心者だけど、ワロタｗ
0498デフォルトの名無しさん2006/11/04(土) 17:28:40
>>496
上級者はお前しかいないみたいだ。よかったな。
0499デフォルトの名無しさん2006/11/04(土) 19:06:22
笑うのは puts("hello, world") のとこだけだろ
0500デフォルトの名無しさん2006/11/04(土) 19:14:49
>>499
人に「ここで笑え」と指示するなんて、さすが上級者ですね＾＾
0501デフォルトの名無しさん2006/11/04(土) 19:37:17
連想配列のくだりで腹を抱えて笑った俺は初心者。
0502デフォルトの名無しさん2006/11/04(土) 20:10:44
>>500
存在しない「指示」を読み取っちゃうのは
コミュニケーションの初心者だな
0503デフォルトの名無しさん2006/11/04(土) 20:22:14
>>502
行間を読めない人なんですね＾＾；
0504デフォルトの名無しさん2006/11/04(土) 21:10:36
まぁ、無いものをあると言い張る時には便利な言葉だ＜行間

こうして「解釈の違い」に逃げていくのもお約束
0505デフォルトの名無しさん2006/11/05(日) 00:42:00
>>504
と言えば勝った気になれるのもお約束＾＾

そんな不毛な話がしたいの？
上級者って忍耐強くて尊敬できますよ。
0506デフォルトの名無しさん2006/11/05(日) 10:36:02
突然勝ち負けの概念を持ち出すと、
それにこだわってたのが自分だってバレちゃうよ。
0507デフォルトの名無しさん2006/11/05(日) 12:19:31
>>506
自分も持ち出してるくせに、よく言うよ。
0508デフォルトの名無しさん2006/11/06(月) 00:42:57
負け組乙
0509デフォルトの名無しさん2006/11/06(月) 01:06:29
ｵﾏｲらいい歳こいて、子供みたいな喧嘩してるなあ、あはは
0510デフォルトの名無しさん2006/11/06(月) 01:33:16
おっさん乙
0511デフォルトの名無しさん2006/11/06(月) 08:55:35
ｺﾞﾙｧ!
0512デフォルトの名無しさん2006/11/06(月) 09:38:06
年寄りは国の宝なんだから大事に扱えよ
0513デフォルトの名無しさん2006/11/06(月) 10:04:58
国のお荷物が何を言っているんだか
0514デフォルトの名無しさん2006/11/06(月) 19:49:44
お荷物はニートのお前だろｗ
0515デフォルトの名無しさん2006/11/07(火) 03:31:21
よく考えたらそうだったｗｗｗｗ
0516デフォルトの名無しさん2006/11/10(金) 16:45:11
チンボぶっ飛ばすぞお前ら。

何がモナドだ。

schemeで継続やっときゃいいんだよ。
0517デフォルトの名無しさん2006/11/11(土) 04:40:16
型のない継続なんてダメダメ
0518デフォルトの名無しさん2006/11/11(土) 11:31:25
今時LispやらSchemeやらが最高だと思ってるやつは時代遅れ
0519デフォルトの名無しさん2006/11/11(土) 12:34:31
lispやschemeが流行り廃りに左右されるものだと思ってる奴は致命的
0520デフォルトの名無しさん2006/11/11(土) 14:02:45
lispやschemeの問題点が見えないのは致命的。というか、無学。
0521デフォルトの名無しさん2006/11/11(土) 18:41:36
>>520
その問題点は言語的な方か商業や政治的な方かで話がだいぶ違うわけであるが。
0522デフォルトの名無しさん2006/11/11(土) 20:42:35
無学というからには、言語的なほうじゃないのか？

俺としては遅いぐらいしか問題点思いつかないけどな。
0523デフォルトの名無しさん2006/11/11(土) 21:05:12
M式ってなんですか？
0524デフォルトの名無しさん2006/11/11(土) 21:37:31
>>521
商業や政治的には、問題点云々以前の問題外だろｗ
0525デフォルトの名無しさん2006/11/11(土) 23:44:40
思ったよりバカが多いな。
0526デフォルトの名無しさん2006/11/11(土) 23:45:33
>>522
quote についてどう思う？
0527デフォルトの名無しさん2006/11/12(日) 13:00:32
なんで急に「わかったふり」の一行レスばっかに(^_^;
0528デフォルトの名無しさん2006/11/12(日) 13:20:19
そんなことはどうでもいい
0529デフォルトの名無しさん2006/11/12(日) 13:25:35
誰も答えられないので、Lispはクズということですか。
0530デフォルトの名無しさん2006/11/12(日) 17:25:57
そうだね、lispやschemeは結局クズっていう結論でいいと思うよ。
ハスケルとかもっとキャッチーな言語にうつつをぬかしておけばいいんじゃない？
0531デフォルトの名無しさん2006/11/12(日) 18:00:30
>>530
その言い方だと、Haskellはクズじゃないと思っているみたいだけど、
うつつを抜かす、というのはどういう意味で言っているのかな。
別に批判的な意味で質問しているのではないけど。
0532デフォルトの名無しさん2006/11/12(日) 18:04:10
>>531
俺は>>530じゃないが、たぶんお前は>>530を誤読していると思う。
もう一回読み直してみれ。
0533デフォルトの名無しさん2006/11/12(日) 23:27:55
馬鹿に向かってそういう冷静なアドバイスをすると
噛み付かれるよ
0534デフォルトの名無しさん2006/11/12(日) 23:49:36
と、すでに噛みついている狂犬くんでした
0535デフォルトの名無しさん2006/11/13(月) 02:23:58
嫌味が解らないと2chは難しい
0536デフォルトの名無しさん2006/11/13(月) 06:00:09
悪い意味でピュアな子には難しいな。
0537デフォルトの名無しさん2006/11/13(月) 18:07:10
>531
Haskellを直接クズとは書かれていないが
「うつつを抜かす」で暗に否定してるだろ
0538デフォルトの名無しさん2006/11/13(月) 18:09:56
クズな言語があるならクズじゃない言語もあるはずだが（相対的）
具体的にクズじゃない言語を言ってみて。
0539デフォルトの名無しさん2006/11/13(月) 22:52:55
Rubyとか
0540Ruby使い2006/11/14(火) 15:56:58
>539
言語の基本的なところは良いんだけど
（まー他言語の良いトコ取りで悪いのも困るが）
開発者や周辺の人達の人格がおかしすぎるのが問題
RubyスレでMLについてのレスを見ればよく判る
0541デフォルトの名無しさん2006/11/14(火) 15:59:13
まぁ、コミュニティにもともと学術関係者すくないですから。
0542デフォルトの名無しさん2006/11/14(火) 16:57:24
一番の難点は宗教が絡んでいるところ。
0543デフォルトの名無しさん2006/11/14(火) 17:09:21
>>542
は？
0544デフォルトの名無しさん2006/11/18(土) 15:57:02
PythonがあればRubyはいらない
0545デフォルトの名無しさん2006/11/18(土) 15:58:11
Pythonは現代的
Lispは時代遅れ
0546デフォルトの名無しさん2006/11/18(土) 16:00:38
Pythonは実用的
Haskellは使い物にならない
0547デフォルトの名無しさん2006/11/18(土) 22:07:51
PythonってLispのマクロに当たるもんあるの？
後遅いという話を聞いたとですが。
0548デフォルトの名無しさん2006/11/18(土) 23:00:49
ないよ
遅いよ
0549デフォルトの名無しさん2006/11/19(日) 00:15:55
んじゃ、ただの動的で使いやすい言語でしかない感じ？
0550デフォルトの名無しさん2006/11/19(日) 02:36:46
> 使いやすい言語
重要じゃないですか
0551デフォルトの名無しさん2006/11/19(日) 03:05:23
はい
0552デフォルトの名無しさん2006/11/19(日) 03:51:01
Pythonみたいな文法の言語で
Lispマクロっぽいのって
やったらすごそうだなｗ
0553デフォルトの名無しさん2006/11/19(日) 04:14:37
http://pc8.2ch.net/test/read.cgi/tech/1158259643/
0554デフォルトの名無しさん2006/11/19(日) 04:18:36
>>552
良く知らんけど、Clean はマクロあるらしいよ。
0555デフォルトの名無しさん2006/11/20(月) 18:32:14
>>542
自分の慣れ親しんだパラダイムの生産性が高く見えるというのは
確かにあるだろうな。
さらに厄介なのは、そのパラダイムがその人にとっては実際に
生産性が高い、ということがあるかも知れないという点だ。
こうなるとパラダイム間の比較はほとんど不可能だと思う。

>>554
ちょっと見た感じでは、マクロの引数から情報を取り出す手段がないので、
Lispのマクロのような使いかたはできないように感じた。
0556デフォルトの名無しさん2006/11/25(土) 12:05:11
手続き型は関数のインターフェイスと実装の結びつきが曖昧。
関数型は関数のインターフェイスがそのままアルゴリズムに直結してる。
そんな印象。
どっちが分り易いかといえば関数型なんだけど、その分りやすさを
コーディングの段階で作り出せるかっていうとそれも難しい。
難しさがそのまま関数型の言語の扱い難さに直結してる。
そんな印象。
0557デフォルトの名無しさん2006/11/25(土) 17:00:26
> 手続き型は関数のインターフェイスと実装の結びつきが曖昧。
> 関数型は関数のインターフェイスがそのままアルゴリズムに直結してる。
プログラム例を希望
0558デフォルトの名無しさん2006/12/09(土) 20:39:44
何一つ有意義な意見もなく無事終了
0559デフォルトの名無しさん2007/01/10(水) 13:36:11
図画工作発案設計工事完成論理関数手続機械
0560デフォルトの名無しさん2007/03/15(木) 23:56:22
>>458 類型。
(+ (+ (+ 0))) (+ (+ 1)) (+ 2) 3
(((0 +) +) +) ((1 +) +) (2 +) 3
(0 + (+ (+))) (1 + (+)) (2 +) 3
(((+) +) + 0) ((+) + 1) (+ 2) 3
0561デフォルトの名無しさん2007/07/21(土) 18:23:59
age age
0562デフォルトの名無しさん2007/07/22(日) 16:08:14
a = b = 1;
は、関数(b = 1)の戻り値１がaに代入されると
考えてよいだろうか。
0563デフォルトの名無しさん2007/07/22(日) 16:34:49
C++ で考えるなら、b = 1 の戻り値は b への参照だな。
0564デフォルトの名無しさん2007/07/22(日) 17:55:12
糖衣構文と割り切るか…？
0565デフォルトの名無しさん2007/08/03(金) 15:57:25
関数型を勉強したら、普通の言語でも次みたいに書くようになってしまいました。

string getCrSeparatedStr(string keyword) {
　return replaceSpaceWithCr(
　　trim(modifyConcatenatedSpacesToSingleSpace(
　　　modifySpaceWideToNarrow(
　　　　deleteSingleQuote(keyword)))));
}
0566デフォルトの名無しさん2007/08/03(金) 16:31:25
>>565
キモっ
0567デフォルトの名無しさん2007/08/03(金) 16:32:14
頼むから横幅2cm以上の関数は作ってくれるな
0568デフォルトの名無しさん2007/08/03(金) 16:53:02
>>565
C++のOven Rangeみたいな書き方お勧め。
http://p-stade.sourceforge.net/oven/doc/html/#oven.introduction
0569デフォルトの名無しさん2007/08/03(金) 17:11:51
右から読もうとして混乱した。
0570デフォルトの名無しさん2007/08/03(金) 18:33:56
>>565
Rubyやってると、むしろこうなる

def getCrSeparatedStr(keyword) do
　keword.deleteSigleQuote.modifySpaceWideToNarrow.modifyConcatenatedSpacesToSingleSpace.trim.replaceSpaceWithCr
end
0571デフォルトの名無しさん2007/08/03(金) 22:28:19
手続き型って頭悪いプログラマーを連想するな、このスレの C++ 信者とか
0572デフォルトの名無しさん2007/08/03(金) 22:34:11
そりゃ、人数が多ければ、駄目な奴もその分多めになる。
0573デフォルトの名無しさん2007/08/03(金) 22:35:09
だめな奴が居るからできる奴が輝くんじゃないか
0574デフォルトの名無しさん2007/08/04(土) 07:42:33
>>571
手続き型を使っているプログラマーが頭が悪いのではなく、
頭が悪いプログラマーが手続き型を多く使っているだけ

頭の悪い奴は、関数型は使えないｗ
0575デフォルトの名無しさん2007/08/04(土) 09:28:20
>>573
ちがう、できるやつ：だめなやつ＝２：８
0576デフォルトの名無しさん2007/08/06(月) 11:01:40
2も居るのかうらやましいな･･･('A`)
0577デフォルトの名無しさん2007/09/03(月) 13:11:19
関数型ド素人です。

友人が以前Ocamlを絶賛していたので、ちょっとかじってみようかな、と思いますが。
Ocamlって関数型としては厳格な方なんでしょうか。

あと、ここのスレ大変面白く読ませていただいてますが、自分がソースからスキルを
判断する際に基準にしているのが、

　「縦に長いソースコードを書く人間はダメ」

っていうものです。関数型使いの方々が頭が良いということと関連するのかな、とも
感じました。
0578デフォルトの名無しさん2007/09/03(月) 13:24:30
>>577　OCamlはゆるゆるです。
05795772007/09/05(水) 10:00:55
>>578
そうですか・・・。

ユルユルってことは、手続き型と同様の不具合の可能性があるということなんでしょうか。

自分の理解では、関数型は変数への破壊的代入が無いということが、手続き型で発生する問題
の大半を抑止できるということかと思ってます。手続き型はそれを防ぐために、変数のスコープを
できるだけ短くする、といった工夫が必要です。オブジェクト指向の最も重要な特徴も、データの
カプセル化なわけですが、関数型はそういった気遣いが無用ということなんでしょうか。
0580デフォルトの名無しさん2007/09/05(水) 11:56:21
>>579
MLでは変数はデフォルトで変更不可。だから
let p = 5 in (巨大な式)
とあったら、pはずっと5であることが保証される。
ただ、MLは式が副作用を持つことを認めるので、
裏でこっそりグローバルな状態を書き換える関数なんかが定義できる。
この点で、副作用を禁止するHaskellなんかと比べると厳格でない。

>関数型はそういった気遣いが無用ということなんでしょうか。
たとえreadonlyでも実装を公開したら実装に依存されてしまう。
だからカプセル化が必要になることはあるし、そのための仕組みも提供されている。
0581デフォルトの名無しさん2007/09/08(土) 10:15:35
関数型にも色々あるようなんですが、何がオススメでしょうか。
0582デフォルトの名無しさん2007/09/16(日) 21:19:01
Schemeがお勧め
0583デフォルトの名無しさん2007/09/18(火) 10:04:15
F#
0584デフォルトの名無しさん2007/11/05(月) 01:46:56
>>295
ツール不足（というか全くない）。
でも関数型CPUと言えるものは製品としてあるよ。
0585デフォルトの名無しさん2007/12/10(月) 08:13:44
志村〜日付日付!
0586デフォルトの名無しさん2008/04/10(木) 11:44:28
>>1
こういう分類をする場合は、論理型も関数型に含めていいんだろうか?
0587デフォルトの名無しさん2008/04/11(金) 01:26:05
Lispって関数型言語なのかな？
ちょっと勉強がてらに手元にあるEmacsLispを見てみよう


・・・何という手続きのかたまり
0588デフォルトの名無しさん2008/04/11(金) 02:31:16
Lisp は手続き型言語に分類するのが普通だと思う。
中でも Emacs Lisp は手続き的なコードを書くのが一般的。

論理型言語は関数型とも全然違うでしょ。
どっちにも分類できない第三の勢力だけど、マイナーだから無視される。
0589デフォルトの名無しさん2008/04/11(金) 03:49:09
論理型言語ってprologとかplannerとかその方面?
wikipediaからつながってる方向だとこういうのとプロセス代数なんかがうまく融合したら
(というかアクターとかはそっちからの考え方に近いのか?)、
テストやらモデル検査は楽になりそうだけど、なんつーか工業製品を作っているみたいな気分になってくる。
いや本来はそっちが目的なのかもしれないが。
アカデミックになると途端に専門用語が数学臭くなって、プログラミングの本来の楽しさみたいなのが消え失せるな。
プログラムではなく事象を記述するというか。まぁ数学的な面白さってのはあるんだろうけどね。

これがプログラマが理解できるまで降りてくると、コンパイラあたりで自動化されてんだろうな。
数学、コンピュータサイエンス、ソフトウェアサイエンス、ソフトウェアエンジニアリング、IT土方、
それぞれで必要になるものは変わってくるんだろうけど。

最近/.でこれみてからなんかこの辺のことを考える様になった…。
Forget Math to Become a Great Computer Scientist?
http://developers.slashdot.org/article.pl?sid=07/07/08/0547234
0590デフォルトの名無しさん2008/04/11(金) 07:52:47
>>589
つ GHC, Concurrent Prolog
0591デフォルトの名無しさん2008/04/11(金) 10:39:58
>>590
こういう気の利いた関数型はないね。
0592デフォルトの名無しさん2008/04/11(金) 12:25:08
>>587
Lispのマルチパラダイムっぷりは、他の言語でいうとC++に一番近い気がする。
0593デフォルトの名無しさん2008/04/11(金) 12:53:37
>>590
論理型っていうのは、関数型言語にちょっとだけ架構したものだが、
GHC (Guarded Horn Clauses) を見ると、
並列処理がこんなにも簡潔に表現できるものかと驚かされる。
この簡潔さばかりは関数型言語ではどう手を尽くしても届き得ない。
0594デフォルトの名無しさん2008/04/11(金) 23:17:01
副作用がなければ並列処理は余裕

そんなイメージがあります
0595デフォルトの名無しさん2008/04/12(土) 02:33:51
>>592
つうかC++のgeneric functionは、
思いっきりCLOSの影響を受けてる。
0596デフォルトの名無しさん2008/04/12(土) 02:35:50
>>593
> 論理型っていうのは、関数型言語にちょっとだけ架構したものだが、

なことはない。

>>594
論理型はホーン節が思いっきり並列構造。
ホーン節への変換がキモ。
0597デフォルトの名無しさん2008/04/15(火) 23:51:43
関数型言語が破壊的代入がないことにより、並行処理を実現するのが楽だってことを
どっかで見て、最近ちびちびと勉強している。

並行処理の肝は、並列にアクセス(破壊的変更)される状態の管理で、それ自体がない
関数型言語では、必然的に実現しやすいのだって触れ込みだったと思う。俺の妄想かも。

手続き型もとい破壊的代入による状態の管理を行う手法での並行処理が難しいことは、
いやと言うほど知っている。だからこそ、関数型言語のそれに興味がある。

実際のところどうなの？
0598デフォルトの名無しさん2008/04/16(水) 02:15:22
Software Transactional Memoryが、
二つの境界を無くそうとしています。
0599デフォルトの名無しさん2008/04/16(水) 05:58:27
関数型言語での並行処理に使われる手法は手続き型言語のものと一緒(共有メモリ、メッセージ)だから、
関数型言語だからどうということはないはず
「破壊的代入による状態の管理を行う手法」に困難を感じてるなら、古典的な共有メモリ以外の情報共有の方法
(メッセージ渡しとかSTMとか)を調べる方が、関数型言語をやるよりも有益だと思う
0600デフォルトの名無しさん2008/04/16(水) 10:42:21
>>598->>599
「プログラミングErlang」では何と言っているか確かめるのが上策。
0601デフォルトの名無しさん2008/04/16(水) 12:06:09
>>599
ではそのメッセージ渡しやstmといった手法を取り入れやすいのが、関数型言語である
というわけではないのですか？
0602デフォルトの名無しさん2008/04/16(水) 13:34:17
最近のErlang流行りは、
一昔前のデータフロー計算流行りを思い起こさせる。
Erlangがここまで生き延びるとは思わなかった。
0603デフォルトの名無しさん2008/04/16(水) 14:56:37
理屈っぽい言語が多い中で、実務的実績があることが
大きいのだろうか。ハンブルグにいる人に調べてもらったら
ドイツでも通信系の企業では使われているらしい。北欧だけ
ではない。WEBなんかで調べても全然でてこないのだけれど。
0604デフォルトの名無しさん2008/04/21(月) 07:14:27
Erlangは関数型なのに文法がPrologに似てるよね
文法に癖あるけど自分が触ってみた限りでは結構普通な感じで使いやすかったりする
0605デフォルトの名無しさん2008/04/21(月) 23:22:52
(+) 相当が fun erlang:'+'/2 とか
お前はホントに関数型言語なのかと
0606デフォルトの名無しさん2008/05/06(火) 08:51:11
多バイト文字を扱えないと、汎用言語には絶対なれないから、
どこかでErlangの方が折れて、仕様に取り込まなくてはなら
ないだろう。
0607デフォルトの名無しさん2008/05/12(月) 23:26:32
結局、手続き型言語の利点っていうのはなんなんでしょうか？
0608デフォルトの名無しさん2008/05/12(月) 23:33:22
手続きを扱うのが楽
0609デフォルトの名無しさん2008/05/13(火) 00:01:31
時間軸を記述出来るのは大きい（場合もある）
0610デフォルトの名無しさん2008/05/13(火) 04:09:01
>>607
手続きを記述できるということかな。それなら、手続きの利点はというと、
構成要素間に特に強い依存性がなくかけるということが多い。
手続き: p1;p2;p3 はp1,p2,p3のそれぞれの結果がどうであれ実行できる。
宣言型たとえばPrologだと
p :- p1,p2,p3. はp1が真かつp2が真かつp3が真の場合pが成立するというように、
各要素は手続きに較べて緊張関係にある。つまり、それぞれの出力に依存する。
手続きは遥に自由だ。
0611デフォルトの名無しさん2008/05/13(火) 04:43:28
手続き型だって p1 で例外が出れば中断して例外処理に入るんで、 p2 や p3 が実行されるとは限らない。
Prolog で手続き的な述語が fail するのって例外送出するような状況だろうし、そこは大差ないと思うけど。
0612デフォルトの名無しさん2008/05/13(火) 06:11:29
>>611
Prologの手続的解釈というのもあり、Prologは例としては適切でないのかな。
しかし、例外は例外だろうw
0613デフォルトの名無しさん2008/05/13(火) 06:20:40
個々の手続き型言語にはいろいろ利点があるだろうが、手続き型言語全体に共通する利点なんて無い気がする
手続きを記述したり、処理を並べたりするのは関数型言語でも普通にできる
0614デフォルトの名無しさん2008/05/13(火) 07:30:00
>>613
代入が機械語数ステートメントでできること、とかは?
0615デフォルトの名無しさん2008/05/13(火) 07:30:48
>>614　Monadみたいなのは普通とは言わない
0616デフォルトの名無しさん2008/05/13(火) 07:31:32
>>613　でした。逝ってくる･･･orz
0617デフォルトの名無しさん2008/05/13(火) 13:13:13
>>615
どこが普通と違う？
Haskellならdoキーワードの後に文を並べるだけじゃないか
0618デフォルトの名無しさん2008/05/13(火) 15:20:19
>>607
人口が多い。
0619デフォルトの名無しさん2008/05/13(火) 21:14:44
Haskell って変数の値を変更できる状態にする際に
元の値を壊さないようコピーが発生するもんだと思ってるけど
その理解に間違いは無いのかな？
0620デフォルトの名無しさん2008/05/13(火) 22:34:36
>>619
変数の値を変更できる状態にするって、iorefなんかのこと？
それなら、コピーは発生しないよ
iorefのじったいは、つうじょうのhaskellのデータひょうげん(もちろんこれはimmutable)をさす、mutableなポインタにすぎない
iorefにたいする代入が行われるときは、あたらしい あたいに たいおうする ひょうげんが あらたに つくられて、
ポインタが その あたらしい ひょうげんを さす ように へんこ%a
0621デフォルトの名無しさん2008/05/13(火) 23:15:50
>>619
Javaの文字列がなぜ変更できないか理解してるなら問題ない
0622デフォルトの名無しさん2008/05/14(水) 21:40:34
>>620
なるほど。毎回値を作ってそれを参照してるだけなのね。
0623デフォルトの名無しさん2008/05/19(月) 06:26:44
手続き型の利点は、ノイマン型アーキテクチャと親和性が高いこと。
0624デフォルトの名無しさん2008/05/19(月) 20:41:00
手続き脳全開の俺は手続きをそのまま書ける事自体が利点
0625デフォルトの名無しさん2008/05/19(月) 21:11:39
普通の、特にビジネス処理なんか考えるときはオブジェクト指向を含む手続き型の方が自然だよね。
0626デフォルトの名無しさん2008/05/20(火) 07:54:08
>>625
ビジネス処理で手続き型が自然というか優位な理由を
教えてください。
0627デフォルトの名無しさん2008/05/20(火) 08:00:43
お舞は何か仕事片付けるとき段取り付けてせえへんの？
0628デフォルトの名無しさん2008/05/20(火) 08:28:08
流れ作業でやるので、関数型の方が適しています。
0629デフォルトの名無しさん2008/05/20(火) 16:41:15
流れ作業「を」構築する仕事ならともかく、
（誰かが構築した）流れ作業「で」仕事をしている人間は、
関数型どころか、わずかな種類の手続きにしか慣れていない「退化した手続き型人間」だと思う。
0630デフォルトの名無しさん2008/05/20(火) 20:02:10
だから「関数型言語は逐次処理が苦手」という前提が間違ってるんだって
逐次処理が苦手な関数型言語もあるかもしれんが、主流の(MLとかHaskell)はそうじゃない
0631デフォルトの名無しさん2008/05/24(土) 18:48:21
>>630
確かにそうだけどさ。
筋の通らないことを堂々という人は
自分の側が勝って優越感味わいたいだけで
他の人の知識を吸収して和解を深めようとか
そういう気構えじゃないから完全無視でOkじゃね。
0632デフォルトの名無しさん2008/05/30(金) 15:29:50
>>631
和解金が目的なんですね、わかります。
0633デフォルトの名無しさん2008/05/30(金) 16:31:35
面白くないよ。
0634デフォルトの名無しさん2008/07/05(土) 06:21:30
>>630
また、関数型からマルチパラダイム型になったcommon lispやschemeのようなものも
あるからね。common lispでマクロの扱いまでなれ出すと、なんでもありになってしまう。

デバックをしているとね。手続き型の方が格段に面倒に思ってますね。できれば関数型
にプログラミングをしていくほうがいい。1つの関数のソースの長さが小さくできることも
利点だと思うよ。

手続き型やオブジェクト指向しいて破壊的操作が加わると、見えないところでの変化が
多すぎて、バグを見極めるのが面倒なんだよね。手続き型言語の方がREPLがより有効
そうなんだが、そうはなってないよね。
0635デフォルトの名無しさん2008/07/07(月) 11:41:23
そもそも手続きprocedure≒関数functionだろ
普通は関数型って命令型imperativeと対比させると思う
0636デフォルトの名無しさん2008/07/13(日) 22:20:05
関数型言語で自在にプログラム組めて、CPUアーキテクチャにも
そこそこ明るい人ー

関数型言語の考え方でCPU作れますか？
0637デフォルトの名無しさん2008/07/14(月) 16:17:06
すでにある
0638デフォルトの名無しさん2008/07/14(月) 16:23:27
まあ市販されてるとかそういうことじゃないが
0639デフォルトの名無しさん2008/07/14(月) 19:12:05
具体的にはどんなん？
0640デフォルトの名無しさん2008/07/14(月) 20:17:13
中央演算装置とはインタプリタのことだから・・・。
0641デフォルトの名無しさん2008/07/14(月) 20:25:13
珍しくもない
ググれば普通に見つかる
0642デフォルトの名無しさん2008/07/14(月) 20:35:35
> 関数型言語の考え方で
というのが何を意味してるかにもよるが

関数型を効率よく実行するための専用機とか
そのあたりの説明には言語のimplementationに関する知識がいる

データフロープロセッサも関数型と関連がある
いわゆる普通のCPUにも研究成果は取り入れられている
0643デフォルトの名無しさん2008/07/14(月) 22:17:41
まあ誰でも真っ先に考えるアイデアですな
0644デフォルトの名無しさん2008/07/15(火) 09:39:45
データフローマシンだけでなく、
グラフリダクションマシンってのもあったな。
0645デフォルトの名無しさん2008/07/15(火) 09:54:52
インテルでもやってるはずだ
0646デフォルトの名無しさん2008/08/16(土) 17:28:38
以下はC#で書いた、"2003/4"みたいな文字列からDateTimeに変換する関数ですが。
これを関数型言語らしく書くと、どのように書けますか？
従来の思考が抜けなくて、どうやっても関数型言語で手続きしてしまいます。

DateTime? parse1(string s)
{
　　var m = Regex.Match(s, @"^(\d+)/(\d+)$");
　　if(!m.Success)
　　　　return null;
　　var year = int.Parse(m.Groups[1].Value);
　　var month = int.Parse(m.Groups[2].Value);
　　return new DateTime(year, month, 1);
}
0647デフォルトの名無しさん2008/08/16(土) 17:41:26
>>646
そのままでいいんじゃね？
俺がHaskellで同じ関数を書くとしても多分似たようなコードになる
0648デフォルトの名無しさん2008/09/04(木) 22:26:23
Functional Java
http://functionaljava.org/
0649デフォルトの名無しさん2008/10/25(土) 21:26:14
DateTime *parse(char *p, DateTime.member *f)
{
if(!*p) {return f.parent();} else {
DateTime.member *F=isdigit(*p)?f:=f.nextMember();
*F= add(*F*10, makeInteger(*p++));
return parse(p, F);}
}
c言語風擬似コード
lispリーディングオンリーラーニングのうんこがイメージするのこんな感じ?
Fをわざわざ出してるけど、代入先変更と計算をまとめて関数化すればそれっぽくなりそうだが果たして…
DateTimeは年が終わったら次のメンバに代入してるだけ。表現をもうちょいうまく考える必要がありそう。
0650デフォルトの名無しさん2008/10/25(土) 22:21:08
ry parse(ry)
return if_func (!*p, f.parent(), parse(add(p, 1), add(mul(isdigit(*p, f, f.nextMember()), 10), makeInteger(*p)));

makeInteger(c)
return isdigit(c, sub(*p, '0'), 0);

isdigit(c, a, b)
return if_func( and('0' <= c, c <= '9'), a, b);

and(a,b)
return a&&b;

if_func(a,b,c)
return a?b:c;

add,sub,mul,div ry

上はこういう感じのことを言いたかったんだ。
でもこれってcじゃ無理だなやっぱ。
0651デフォルトの名無しさん2008/11/17(月) 01:38:45
>>646
Haskellで書いてみた。
エラー処理とか仕様とかはかなりテキトウ。

data Date = Date { dateYear :: Int, dateMonth :: Int, dateDay :: Int }

defaultDate :: Date
defaultDate = Date { dateYear = 1900, dateMonth = 1, dateDay = 1 }

breaks :: (a -> Bool) -> [a] -> [[a]]
breaks f xs = case zs of
{ [] -> [ys]
; _:zs' -> ys:(breaks f zs')
} where (ys,zs) = break f xs

parse :: String -> Date
parse str = case map read $ breaks (=='/') str of
{ [y,m] -> defaultDate { dateYear = y, dateMonth = m }
; [y,m,d] -> defaultDate { dateYear = y, dateMonth = m, dateDay = d }
; _ -> error "Illegal Format!"
}

微妙...orz
もうちっとまともにパースしたいんだったらParserCombinatorとかになるのかな？
あと最近はどんな言語にでもRegexライブラリ用意されてるからそれで一発、が実際かも...。
06526512008/11/17(月) 01:41:06
sage忘れた...。
吊ってくる。
0653デフォルトの名無しさん2008/12/31(水) 17:05:38
もしクロージャのあるなしで区別するとすれば、関数型言語は手続き型言語を包含してるでしょー。
余計なfeatureがあるかどうかくらいで、メリットデメリットというほどの違いはない。
0654デフォルトの名無しさん2008/12/31(水) 17:15:23
Lisp系みたいななんでもありの関数型言語はそうかもしれないけど、
純粋な関数型言語はどうかなー
0655デフォルトの名無しさん2008/12/31(水) 20:20:33
lispって関数型言語か？
0656デフォルトの名無しさん2009/01/03(土) 06:34:12
「なんでもありの関数型言語」
では
0657デフォルトの名無しさん2009/01/03(土) 08:14:28
手続き型言語に分類するのが普通だと思うけど。
0658デフォルトの名無しさん2009/01/03(土) 10:13:01
マルチパラダイム言語っていう言葉を使うべきだと思う
0659デフォルトの名無しさん2009/01/03(土) 16:12:48
>>658 だな
0660デフォルトの名無しさん2009/01/03(土) 17:16:39
LispはLisp以外の何者でもなくLispの前にLisp無くLispの後にLisp無し
0661デフォルトの名無しさん2009/01/03(土) 18:12:57
「それはどうかな？」




この命題はLisperが何十年に渡り挑み続け、
そして敗れていった・・・
0662デフォルトの名無しさん2009/01/04(日) 10:04:44
じゃリスト型言語ってことで
0663デフォルトの名無しさん2009/01/04(日) 21:38:18
もうリスト処理用言語でよくね？
0664デフォルトの名無しさん2009/01/04(日) 23:29:39
別にCでも関数型プログラミングすることは出来る
Cでもオブジェクト指向が出来る、という話よりもはるかに自然に書ける
でもやらない　それは人間にとって不自然な書き方だから
0665デフォルトの名無しさん2009/01/04(日) 23:37:22
クロージャが C で自然に書けるのか？
0666デフォルトの名無しさん2009/01/04(日) 23:45:36
後学のために是非その自然な書き方で書いたソースを･･･
0667デフォルトの名無しさん2009/01/05(月) 00:12:53
クロージャなんざ必要なローカル変数コピーして関数呼び出すだけじゃねえか
0668デフォルトの名無しさん2009/01/05(月) 00:33:32
それは違うw
0669デフォルトの名無しさん2009/01/05(月) 00:58:04
enum Enum{ Add, ... };

struct Closure{ Enum Enum; void* Env; };

int Add(int x, int y){ return x + y; }

struct AddEnv{ int X; int Y; }

int Result(Closure closure)
{
switch(closure.CalcEnum){
case Add:
AddEnv* env = (AddEnv*)(closure.Env);
return Add(env->X, env->Y);
case ...
}

Cの細かいことは忘れたけどまあ自然に書けるだろ
0670デフォルトの名無しさん2009/01/05(月) 01:28:04
それでできることは分かってるが、
自然か・・・と言われると微妙だな・・・。
0671デフォルトの名無しさん2009/01/05(月) 01:45:48
(let ((x X) (y Y) (z Z))
;; x y zの値変更
(let ((f #'(lambda () (+ x y)))
(g #'(lambda () (+ y z)))
(h #'(lambda () (+ z x))))
(setq x (* X (+ Y 1)))
(setq y (* Y (+ Z 1)))
(setq z (* Z (+ X 1)))
(print (f) (g) (h))
(list f g h)
))
に相当することを自然に書いてくれ。


0672デフォルトの名無しさん2009/01/05(月) 01:47:25
setq?
思いっきり副作用を用いたコーディングだな
どこが関数型なの、それ
0673デフォルトの名無しさん2009/01/05(月) 08:22:17
関数型かどうかはともかく、Lispでクロージャを使えば普通にできるとこが、
Cで自然にできるか、という話の題材としては問題ないと思うが。
0674デフォルトの名無しさん2009/01/05(月) 08:29:10
本来は"Cで自然に関数型プログラミングが書けるか"という問題だったろ
なんで変えるの？
0675デフォルトの名無しさん2009/01/05(月) 12:58:26
そんなにピュアな関数型にこだわるなら、遅延評価をやってもらおうか？
「自然に」。
0676デフォルトの名無しさん2009/01/05(月) 13:01:01
まるで子供の喧嘩だな
言語仕様として関数内関数もサポートしてないCで関数型の真似なんて
ネタもいいところなのは分かりきってるのに
そうムキになるなよ
0677デフォルトの名無しさん2009/01/05(月) 15:05:32
>>669
なんか、昔ゲーム会社でみた、タスクシステムがデジャブ・・・
0678デフォルトの名無しさん2009/01/05(月) 15:43:58
構造体中のポインタで間接呼び出ししてるだけだろ。
ごくあたりまえのテクニック。
0679デフォルトの名無しさん2009/01/05(月) 16:24:50
評価を遅延するだけなら>>669のClosureでいいし
その結果を取っときたいならキャッシュするだけだろ
何か不自然になるところがあるか？
0680デフォルトの名無しさん2009/01/05(月) 21:56:03
可能か不可能かではなく自然か不自然かだからな。
自然か不自然かは人によって判断基準の異なるいい加減なもの。
永遠に平行線だな。
0681デフォルトの名無しさん2009/01/05(月) 23:23:08
>>669
そのクロージャー、区ロージャーとして呼ぶ所が増えるたびに関数本体を修正するの?(´・ω・｀)
0682デフォルトの名無しさん2009/01/06(火) 02:05:31
関数型言語のユーザーのほとんどは
頭をひねくり回さないと書けないし理解できない言葉を使うことで
選民意識に浸っているかわいそうな人たち
必然的にそのコミュニティは宗教になる

Lispの真実
http://www.aoky.net/articles/leon_bambrick/lisp_truth.htm
0683デフォルトの名無しさん2009/01/06(火) 11:46:07
そう思う奴は永遠に機械語使ってればいいんだよ
あれほど単純でわかりやすい言語は他にない
0684デフォルトの名無しさん2009/01/06(火) 12:44:09
俺としてはlispよりhaskellの方がわかりやすいかな
lispは玄人好みすぎる…
0685デフォルトの名無しさん2009/01/06(火) 13:16:31
分かりやすいプログラムを書くために通常プログラマは以下の様なことに気をつける

1.短すぎる識別子は危険なので、どのような関数であろうと
最低限 それが属する物の名前．関数名、 といった形でアクセスされるようにする
これは言語により強制されることが多い

2.深すぎるネストは混乱の元だ
A(B(C(D,E(F))))
一目で分かる程度まで分割する必要がある

val e = E(F)
val c = C(D, e)
A(B(c))

3.再帰は分かりにくいので、再帰でなければ書けない場合以外は使用を避ける

関数型のプログラマはこういった原則を無視しがちなので
彼らのプログラムは簡単に破綻する
0686デフォルトの名無しさん2009/01/06(火) 13:22:20
>>682
仲間内では気のきいた文章ということになるのかもしれないが
こんなにくどいとユーモアの欠如を感じるな
0687デフォルトの名無しさん2009/01/06(火) 13:23:59
>>685
手続き型言語の限界ゆえに主張される「わかりやすさ」をここで主張されてもなー

だいたい、再帰がわかりにくいとか言う奴は、帰納法はわからないからループで
書けとか数学者に文句付けるのかなーとか思う。
0688デフォルトの名無しさん2009/01/06(火) 13:27:37
理屈倒れを指摘するために即席で理屈をこねる手続き型言語ユーザー
ということで
0689デフォルトの名無しさん2009/01/06(火) 13:41:02
もともと再帰的な問題は、再帰で表現するのが一番自然で分かりやすい
が、単に副作用を避けるために迂遠な方法を取っているのならば、それは
自然で分かりやすいとはいえない
0690デフォルトの名無しさん2009/01/06(火) 13:41:57
ネストが深いのが分かりにくいというのは
一文が長くなりすぎるといいたいことが分からなくなるということと同じで
単に人の脳が普遍的にもっている問題だ

再帰が分かりにくいのは処理を理解するために
もう一度同じ処理を頭の中で実行しなきゃならなくなるからだ
「この文は偽である」といったように
何度実行しても永遠に答えに辿り着かないことすらある

プログラム言語の目的は
ある処理を人間にとって分かりやすく書き下すことであり
数学的にエレガントに書き下すことではないのだ
ループで書けるものをわざわざ再帰にして
リストみたいな不合理なデータ構造をcarとかcdrするなんてのは
頭がおかしいとしかいいようがない
0691デフォルトの名無しさん2009/01/06(火) 13:47:20
lispだけが関数型じゃないよ
もっとhaskellとかMLとかにも批判くれよ
0692デフォルトの名無しさん2009/01/06(火) 13:47:37
>>685
append([],X) -> X;
append([U|R],Y) -> [U|append(R,Y)].

再帰はわかりにくい?
0693デフォルトの名無しさん2009/01/06(火) 13:54:41
>>692
分かりにくいし第一そのプログラム死ぬほど非効率だろう
0694デフォルトの名無しさん2009/01/06(火) 14:00:06
確かnilとconsとeqとnullの公理を定義すれば
そこから帰納法でだけでappendとか導き出せるんだよね
そういう背景知ってるとこれ以上はないってぐらいわかりやすいと思う
俺も洗脳されてんだろうな
0695デフォルトの名無しさん2009/01/06(火) 14:00:22
内包表記やdo-ec、foreachみたいなので書ける奴は
再帰で書くよりそっちで書いたほうが分かりやすい

あと、最適化のために末尾再帰に変形したコードは分かりにくい
0696デフォルトの名無しさん2009/01/06(火) 14:02:55
高階関数万歳
0697デフォルトの名無しさん2009/01/06(火) 14:05:41
>>694
ルールがシンプルなのがいいならforthや、それ以上にbrainf*ckがいいと
いえなければならないのでは
数字なんかもダサいので何でもチャーチ数で表現すればいいと思う

分かりやすいんだよね？それが
0698デフォルトの名無しさん2009/01/06(火) 14:11:31
common lispやhaskellは手続き的なものも意識している
関数型だけでも手続き型だけでも駄目
俗に言うマルチパラダイムというやつ？
カオスにならない程度に色々できた方がいいんだよ
0699デフォルトの名無しさん2009/01/06(火) 14:12:39
>>697
いや、そこそこ賢い人じゃないと
皮肉って痛々しいだけだから。
0700デフォルトの名無しさん2009/01/06(火) 14:15:39
C++0x(C++)
scala(Java)
Python3000
Perl6

メジャーな手続き型の言語も関数型言語の要素を取り入れて進化していきます
0701デフォルトの名無しさん2009/01/06(火) 14:16:35
>>690
> ネストが深いのが分かりにくいというのは
> 一文が長くなりすぎるといいたいことが分からなくなるということと同じで
> 単に人の脳が普遍的にもっている問題だ

手続き型でも普通にネストが深くなりますが何か？
ていうか、代入一回につき、同じ式の意味が変わるわけで
（k == 1 なら k + k == 2、k =2 すると k + k == 4）
手続き型は代入するたびに、意味的にはネストしていると
言っても過言ではない。

> 再帰が分かりにくいのは処理を理解するために
> もう一度同じ処理を頭の中で実行しなきゃならなくなるからだ
> 「この文は偽である」といったように
> 何度実行しても永遠に答えに辿り着かないことすらある

ループだって同じですね。

> プログラム言語の目的は
> ある処理を人間にとって分かりやすく書き下すことであり
> 数学的にエレガントに書き下すことではないのだ

数学的にエレガントだと分かりづらい、という偏見。

> ループで書けるものをわざわざ再帰にして
> リストみたいな不合理なデータ構造をcarとかcdrするなんてのは
> 頭がおかしいとしかいいようがない

単純な2分構造で全てが現せるリストを合理的と思えないのはどっかおかしい。
0702デフォルトの名無しさん2009/01/06(火) 14:19:36
末尾再帰化とかCPSへの変換とか
人間様がやる仕事じゃないと思う
0703デフォルトの名無しさん2009/01/06(火) 14:21:14
>>700
Python3000はPython3.0となりもうリリースされたが
Python3.0で新たに取り入れられた関数型言語の要素は
何も無いように思う

強いて言えばレキシカルクロージャから自由変数を変更できるようになったが
関数型的には関係ないよねこれ
0704デフォルトの名無しさん2009/01/06(火) 14:25:03
そうかpythonは何も知らないから適当に入れちゃったんだよごめんね
反省して鼠本買って勉強するよ
0705デフォルトの名無しさん2009/01/06(火) 14:29:25
>>691
Haskellは、インタプリタに日本語が入力できなかったので速攻で萎えました。
自分は日本人なので、日本語ぐらい普通に使えて欲しいです。
普通に日本語ぐらい使えるようになったら、使ってみたいです。

OCamlを入れてみましたが、Strライブラリが大昔のUnixのregexライブラリのように
グローバル変数に依存（非スレッドセーフ、非リエントラント）しているので
萎えました。stringがmutableで、そのくせ別にBufferみたいなのもあるのも
萎えました。あと記法がキモいです。色々と。
標準のIOの抽象度が低く、文字列ストリームすらないのも萎えました。
モジュールの品揃えには片寄りがあり、Windows環境ではサードのモジュール
を入れるのも一苦労でした。
0706デフォルトの名無しさん2009/01/06(火) 14:36:59
処理系やライブラリが未成熟なのも敬遠される要素だよなー
現状は趣味言語の域を出ないというのは信者も理解している筈
0707デフォルトの名無しさん2009/01/06(火) 14:54:14
>697
構造が単純＝わかりやすいとは限らない
forthはわかりにくい
専用スレの状態見れば「わかりやすい」
b(rは論外
0708デフォルトの名無しさん2009/01/06(火) 18:29:17
なんかキモいくらいに腐すやつと
キモいくらいに擁護するやつがいて、
総じてキモいスレ。
0709デフォルトの名無しさん2009/01/06(火) 19:16:44
実際のところ、関数型プログラミングでも自身では再帰ってそう使わない気がする、全くとは言わないが。
現実で使っていると、それよりもリストにmapとかfoldとか
高階関数を使ってあれこれできるってのが醍醐味だと感じる。
0710デフォルトの名無しさん2009/01/06(火) 19:26:03
map/reduceの類なら別にPerlだのRubyだのPythonだのでも使えるわけで
0711デフォルトの名無しさん2009/01/06(火) 19:59:37
そんなものに大した価値はないと言いつつ盗んでいく
どこかで聞いたような話だな
0712デフォルトの名無しさん2009/01/06(火) 20:09:03
でもそれらは関数型言語とは呼ばれない

ファーストクラスのレキシカルクロージャや便利な高階関数のようなものを
多くの言語がLispから盗んで普通にサポートしている中で、
それでも関数型言語の優位性を説こうというのなら、
「盗まれていない」部分の優位性を説得力を持って示せなければ意味は無いし、
誰も関数型言語を使おうとは思わないでしょう
0713デフォルトの名無しさん2009/01/06(火) 20:10:57
そんなものに大した価値はないというような手続き脳の奴は、
PerlだのRubyだのPythonだのを使っていてもmapやfoldは使(わ|え)ない。

mapやfoldは、それが無ければ再帰的に書くようなパターンを抽象化した
ものだから、まぁ自然な流れだね。
mapやfoldをPerlだのRubyだのPythonだので使うような奴は、再帰も普通に使う。
0714デフォルトの名無しさん2009/01/06(火) 20:12:48
>>713
ん？問題の焦点は「再帰」ではないでしょ？
再帰が出来なかったのなんて大昔のBASICだのCOBOLだのぐらいなもので
Cでさえ普通にできるものを「関数型言語の特徴」なんてまさか言わないよな？
0715デフォルトの名無しさん2009/01/06(火) 20:20:10
俺もOCamlの一番のキモさは
＞stringがmutableで、そのくせ別にBufferみたいなのもあるのも萎えました。
これだと思っている。stringがchar listでもなくなんか独自な型なあたりがキモいと思いました。
でもわかりやすいし、Haskellみたいなインデント依存でもカッコだらけでもないあたりは好きです。
例外を気楽に簡単に使えるあたりもいいなと思いました。

あとOCamlのオブジェクト指向部分ってみんなバリバリ使ってるの？
あれ使う場合って代入しまくり、副作用ありまくりなスタイルになるかと思うんだけどどうなの？
0716デフォルトの名無しさん2009/01/06(火) 20:22:37
あ、でもlablgtkはいいよね。
まさに手続き型だけどHaskellのgtk2hsよりはマシかな？って思ってる。
0717デフォルトの名無しさん2009/01/06(火) 20:29:19
再帰に関しては、手続き脳だろうが二分探索やクイックソートを書けと
言われたら普通再帰を使う

「再帰が理解できない」のは、手続き脳なのではなく、単にそいつが
プログラマではないというだけだ

強いて言えば、手続き脳のプログラマは、本質的なiterativeなprocess
は単にループで書き、わざわざ再帰で書こうとは考えない
0718デフォルトの名無しさん2009/01/06(火) 22:21:00
手続き脳ってなに?
ゲーム脳みたいなの?
0719デフォルトの名無しさん2009/01/06(火) 22:30:55
うん
こ
0720デフォルトの名無しさん2009/01/06(火) 22:38:19
>>709
Haskellなんかは再帰よりfoldとかmapとか無限リスト使う文化があるような
末尾再帰にしても最適化しないらしいし…
0721デフォルトの名無しさん2009/01/06(火) 23:06:56
つうか、foldとかmap自体が再起で実装されるだろ
0722デフォルトの名無しさん2009/01/06(火) 23:30:28
日常的に、lisp、arc、scheme、haskell、scala　といった言語を利用されている方にお尋ねします。
どのような問題を解決されるときにそれらの言語でコードを書かれていますか。

個人的な書き捨て用途や、趣味のプロトタイピング、仕事など。
コーディング規模は数分から数ヶ月など、いろいろあるかとおもいますが。

どのような場面、用途でご利用されているのでしょうか。
今後、使いたい用途としてはどんな分野がありますか？
0723デフォルトの名無しさん2009/01/07(水) 02:56:04
C#でもmapは使うけどfoldはあまり使わんね
式にして関数の引数に入れられるようにするより
foreachと副作用で書く

関数型のプログラマはたとえば
「預金残高が1000円減った」というような場合でも
副作用は使わずに新しくオブジェクトを作るわけ？
0724デフォルトの名無しさん2009/01/07(水) 04:35:31
>>723
個人的には、どんどんとオブジェクトを作って使い捨てていくのが
関数型言語での書き方だと思ってるよ

HaskellのStateモナドも、要するに状態オブジェクトを新しくどんどん生成して
持ち回っていって計算をするというモデルだよね
0725デフォルトの名無しさん2009/01/07(水) 06:27:40
でもHaskellで実際何か作るときは、処理効率、実際のタスクがもとからIO処理であるなどの理由より
状態を考えるとき
StateモナドではなくReaderモナドとIORefを組み合わせて副作用的なプログラミングをすることも多いと思う。
まあ「そんなの邪道」って人もいるに間違いないが。
0726デフォルトの名無しさん2009/01/07(水) 06:32:53
Haskellで実際何か書く奴なんていないだろ
0727デフォルトの名無しさん2009/01/07(水) 06:39:07
wwwww

まあそれはともかく、
＞「預金残高が1000円減った」というような場合でも
＞副作用は使わずに新しくオブジェクトを作るわけ？
その「預金残高」オブジェクトのデータ構造とか、サイズ、更新頻度とかを考えて副作用的にするか
オジェクトをコピーして持ちまわす形にするか決めるんじゃないか？
0728デフォルトの名無しさん2009/01/07(水) 07:41:14
>>727
> その「預金残高」オブジェクトのデータ構造とか、サイズ、更新頻度とかを考えて副作用的にするか
> オジェクトをコピーして持ちまわす形にするか決めるんじゃないか？

手続き型でも、別の口座への入金との一貫性を保つためにトランザクションとか
やりだしたら、単に変数を書き換えるだけじゃ済まないし。結局似たようなもんだよね。
0729デフォルトの名無しさん2009/01/07(水) 08:12:54
御舞ら的にソフトウェアトランザクショナルメモリってどうよ?
0730デフォルトの名無しさん2009/01/07(水) 21:08:47
>>721
それは関係ない
普段のコーディングではあまり手で再帰を書かない、再帰を意識しないって話だろ
0731デフォルトの名無しさん2009/01/08(木) 01:23:25
たとえばツリーについて何か処理をしようとしたら
再帰で書かないと結構厄介なことになるよねえ
0732デフォルトの名無しさん2009/01/08(木) 06:47:30
対象になるデータが再帰的構造の場合は再帰を使うね。
手続き型であまり再帰を使わないというのは、そういう
データ構造を扱うプログラミングの頻度が低いという事
もあるのではないか。
0733デフォルトの名無しさん2009/01/08(木) 08:54:26
だね。
まぁそういったトラバースも関数に落としてくので再起関数を定義すること自体は減ってくと思うけど。
0734デフォルトの名無しさん2009/01/08(木) 10:17:44
Compositeパターンで書かないと厄介なことにー
0735デフォルトの名無しさん2009/01/08(木) 10:42:15
arrowとか使えば綺麗にかけるかも
0736デフォルトの名無しさん2009/01/08(木) 12:48:54
関数型やってて仕事でもプログラマやってる人って
仕事が苦痛になったりしないですか？
仕事は仕事と割り切ってる？
0737デフォルトの名無しさん2009/01/08(木) 12:55:00
ここのところの流れ、どの主張もそんなに違和感はないんだけど、
源流になってる>>685の 3.だけは間違ってると思うね。
0738デフォルトの名無しさん2009/01/08(木) 12:55:58
>>736
仕事ってなに？
俺は研究するのが仕事なんだが。
0739デフォルトの名無しさん2009/01/08(木) 12:59:17
>>736
COBOLプログラマが家に帰ったらHaskellやってるようなケースかい?
0740デフォルトの名無しさん2009/01/08(木) 12:59:42
>>738
それなら問題はないでしょうね
>>739
そうそう
0741デフォルトの名無しさん2009/01/08(木) 13:03:42
バイトでCOBOLのプログラム書いたこともあったな・・
そんな俺はニート
0742デフォルトの名無しさん2009/01/09(金) 08:08:01
>>739
私は違うけれど、COBOLのプログラマ人口から考えると、
相当な数いるだろうね。
0743デフォルトの名無しさん2009/01/09(金) 08:26:33
>>742
300人。
「ふつうの・・・」を読んで家で勉強したCOBOLプログラマの予想数。
0744デフォルトの名無しさん2009/01/09(金) 08:36:26
仕事で使うCOBOLが嫌で趣味でprologとかlispとかやってたCOBOLerは相当居たと思う
0745デフォルトの名無しさん2009/01/09(金) 18:16:06
>>743
COBOLプログラマが日本に30万人いるとすると、1000人にひとり。
少し少なすぎる気がするが・・・。ところで「ふつうの・・・」は
何部くらい出ているんだろう。
0746デフォルトの名無しさん2009/01/10(土) 08:26:15
>>744
COBOLで書かれたPrologってないのかな。WEB検索では出てこないけど。
これがあるかないかで全く違いますね。モチベーションが。
0747デフォルトの名無しさん2009/01/10(土) 10:32:17
最初のPrologはFORTRANで書かれたという故事ならあります。
0748デフォルトの名無しさん2009/01/10(土) 10:34:48
COBOLは他の言語が作れるほど自由な言語じゃないだろ
0749デフォルトの名無しさん2009/01/10(土) 10:52:13
>>748
実行環境の縛りが尋常でないというのなら解るが、REDEFINES句　OCCURS句を
用いてデータ部にスタックを取れば、他の言語とそれほど差がないのではないか。
再帰は書けないけど。
0750デフォルトの名無しさん2009/01/10(土) 12:51:57
チューリング完全なら他の言語が書けないと言うこともないだろう
0751デフォルトの名無しさん2009/01/10(土) 12:58:54
まずprologやlispでprologからcobolのコードを吐くコンパイラを作ります
次に入力されたprologのコードをそのコンパイラに渡し、それから返ってきたコードを実行するCOBOLのプログラムを書きます
以上でprologのコードをCOBOL処理系で実行する処理系が完成されました
0752デフォルトの名無しさん2009/01/10(土) 14:21:05
>>751
> lispで

なぜw
0753デフォルトの名無しさん2009/01/10(土) 19:18:11
ACCEPT からちょっと実行したいという程度のものなら、Prologより
Lispの方がずっと簡単に実現できる。>>752へのレスではないが。
0754デフォルトの名無しさん2009/01/10(土) 19:27:38
googleでは出てこないが、
COBOLで書かれたLISP
LISPで書かれたCOBOL
これはどちらもあるだろう。
0755デフォルトの名無しさん2009/01/13(火) 18:03:25
↑↑馬鹿だろ
0756デフォルトの名無しさん2009/01/17(土) 14:27:48
関数型言語のユーザーはウインドウに描画するたびに新しいウインドウを作るわけ？
0757デフォルトの名無しさん2009/01/17(土) 15:08:01
プログラミング言語は一通りやったけど、
やっぱりHSPが一番しっくりくる。

今はOSもHSPで自作したものを使ってるし、
HSPのポテンシャルは図りしれない。
0758デフォルトの名無しさん2009/01/17(土) 15:33:18
>>756
Haskellとかはモナドに入れて遅延評価するだけだよ。
モナドがない言語なら副作用を使うかもしれないね。
0759デフォルトの名無しさん2009/01/17(土) 15:54:30
>>758
画像がアニメーションしたらその都度モナドで皮をかぶせていくわけ？
あっという間にメモリが足りなくなるだろ
0760デフォルトの名無しさん2009/01/17(土) 16:00:06
そもそも現実のモデルが副作用有りまくりなんだから。
0761デフォルトの名無しさん2009/01/17(土) 16:16:31
>>759
無限リストは無限に皮をかぶったモナドだが、なぜ無限のメモリがないのに処理できるんだ？
0762デフォルトの名無しさん2009/01/17(土) 16:17:13
遅延評価をもっと勉強して来い
0763デフォルトの名無しさん2009/01/17(土) 16:19:01
>>761
そりゃその都度値を作ってるからだ
アニメーションにおいてその都度画像を作るのでないならば
皮をかぶせるしかないだろ
0764デフォルトの名無しさん2009/01/17(土) 16:44:29
関数型言語で作られたマルチメディア系プログラムを読んでみると
副作用ばかりでがっかりするのはよくあること
0765デフォルトの名無しさん2009/01/17(土) 17:08:14
>>764
Haskell以外の言語だろ。
原始的なモナドも遅延評価もない関数型言語。
0766デフォルトの名無しさん2009/01/17(土) 17:20:25
そりゃHaskellでマルチメディア系プログラムを書くのは不可能だからな
Cleanなら出来るのか知らんが
0767デフォルトの名無しさん2009/01/17(土) 17:47:19
Haskellでマルチメディア系プログラムを出力するプログラムを書けるよ
という理屈があってだな
0768デフォルトの名無しさん2009/01/17(土) 17:58:47
汚れ仕事は素直にCで書けばいいんだよ
そういう意味では、役割分担が容易でグルーとして使いやすい言語が
実用的だと思ってる
Pythonとかな（関数型じゃないけど）
0769デフォルトの名無しさん2009/01/17(土) 18:00:24
よく知らないことについて自信満々にレスするのはやめようぜ

まず、このへんの議論に遅延評価はほとんど関係ない
IOモナドを使うことで、副作用なしに入出力を記述できるのがHaskellの特徴だけど、
同じことは正格評価の言語でもできる

>>756
そんなことはしないよ
一つのウィンドウに対して、常識的に描画命令を発行していくだけ
関数型言語だからって命令的なことができないわけじゃない

>>766
Unlambdaか何かと勘違いしてないか
0770デフォルトの名無しさん2009/01/17(土) 18:26:55
Haskellで書かれたウインドウは値を書き換えることなしに
どうやって描画命令を実行するわけ？
0771デフォルトの名無しさん2009/01/17(土) 18:33:13
>>770
ふつうにWin32APIなりXlibなりを呼ぶだけ
0772デフォルトの名無しさん2009/01/17(土) 18:33:18
ウィンドウすら扱えないようでは
Hello, world! すら作れんぞ。
0773デフォルトの名無しさん2009/01/17(土) 18:35:10
>>771
1024x768x32BPPのDIBSectionを作って
得られた配列に、1pixel単位で描画してblitしたいのですが
Haskellでどうやるのでしょうか＞＜
0774デフォルトの名無しさん2009/01/17(土) 18:37:54
Haskell は副作用のある処理を、
その処理の方法自体を戻り値とすることで、
方法は常に同じだよね、という理屈で
副作用が無いとか言ってんじゃなかったっけ。
0775デフォルトの名無しさん2009/01/17(土) 18:43:44
>>771
じゃあ質問を変えると
HaskellでWin32 APIのようなウインドウシステムを
どうやって作るわけ？
0776デフォルトの名無しさん2009/01/17(土) 18:44:33
>>773
Cでやるのと全く同じようにやればおｋ
1pixel単位での描画は、生のメモリにバイト単位で書き込む関数が用意されてるから、それを使う
Cでポインタに添字アクセスするのと同じね

>>774
そんな感じ
0777デフォルトの名無しさん2009/01/17(土) 18:44:57
Java でどうやって作るんだろう
0778デフォルトの名無しさん2009/01/17(土) 18:45:47
>>775
もうhaskell勉強してこいよ。
そのほうがいちいち質問するより早い。
0779デフォルトの名無しさん2009/01/17(土) 18:47:26
>>776
ありがとうございます

ポインタアクセスが出来るのですか？
それはすごいかも……
意外とHaskellは黒いですね＞＜
0780デフォルトの名無しさん2009/01/17(土) 18:53:19
参照されている値を書き換えたら参照透過性が崩れるだろ
書き換えた生のメモリはHaskellからは二度と参照されないわけ？
0781デフォルトの名無しさん2009/01/17(土) 18:59:36
Haskell のイメージ

const char* main() {
　return "printf(\"Hello, world!\\n\");";
}
この main 関数は副作用を持たない。

んで、Haskell のスタートアップルーチンが
eval(main());
としてる。

そんな感じ。
0782デフォルトの名無しさん2009/01/17(土) 19:03:57
>>780
まず、Haskellの変数のアドレスは取れないから、この方法で変数の値を書き換えることはできない
(処理系依存の汚い方法を使えば取れるかもしれないけど、それは無視していいよな？普通やらないし)
で、Haskellから見て生のメモリはプログラムの「外部」にあるかのように入出力扱いでアクセスされる
だから参照透過性は崩れない

そもそもどうやって参照透過なまま入出力をやってるのか、というとIOモナドを使ってる
これについて一言では説明できんので、Haskellを勉強するか、どこかうまい説明をしてるサイトでも探してくれ
0783デフォルトの名無しさん2009/01/17(土) 19:05:02
>>766
つttp://jp.youtube.com/watch?v=eLS6GHXWMpA&feature=related
つttp://jp.youtube.com/watch?v=zqFgQiPKtOI
0784デフォルトの名無しさん2009/01/17(土) 19:08:26
小細工して副作用をIOモナドに押し付けてんのかもしれないが、
結局プログラムの書き方が大きく変わるわけではないのなら、
どんな利点があるんだ？
0785デフォルトの名無しさん2009/01/17(土) 19:15:13
>>780
getCharの値は？と聞かれたらいつも「何を入力するかは人それぞれ」と答える
いつも同じ答えなので参照透明です
0786デフォルトの名無しさん2009/01/17(土) 19:22:01
>>784
コンパイラの最適化器は間違いなく大きな恩恵を受けてる
結果が使われてない式は問答無用で削除できるし、共通部分式の括り出しも自由だし、
評価順序も都合の良いように入れ替えられる

コードを書く立場からすると、評価順を気にしなくていいというのが大きいか
あとは関数が裏で変なことやってないことが保証されるとか、入力が決まれば出力も決まるのが扱いやすいとか

>結局プログラムの書き方が大きく変わるわけではないのなら、
逐次的な要素の強い処理(>>773みたいな)を書くときには手続き型っぽい書き方をするってだけで
入出力が絡まない処理だと結構書き方も変わると思う
0787デフォルトの名無しさん2009/01/17(土) 19:34:33
モナドのやってることは次の行でしか使われない変数を
次々に新しく作って返すってだけだろ

しかし画像は書き換えられなきゃならないし取っとかなきゃならないんだから
Haskellでは書けんだろ
0788デフォルトの名無しさん2009/01/17(土) 19:38:23
どうせGCが裏で副作用だらけの処理をしてるんだから
副作用を完全に隠蔽したうえで入出力を行うことは可能だろ
0789デフォルトの名無しさん2009/01/17(土) 19:39:48
>>787
全然違う

とりあえずモナドとIOモナドを区別しようぜ
どうでもいいがIO型のことをわざわざIO「モナド」と呼ぶのは紛らわしいだけだと思う
0790デフォルトの名無しさん2009/01/17(土) 19:48:40
画像を取っておくことすらできないなら
Hello, world! も作れない事に
いい加減気付いて欲しい。
Hello, world! が作れるんだから
画像を取っておくこともできてもおかしくはない。
0791デフォルトの名無しさん2009/01/17(土) 19:55:26
>>787
まあものすごく大雑把な説明をすると、
画像というデータを直接叩くわけではなくて、
「画像を操作する命令列」をいじっているだけ。
命令列自体は参照透明な値と思える、ってことだ
0792デフォルトの名無しさん2009/01/17(土) 20:01:16
なんかようわからんけど
ハスケルって使いづらいんだな
0793デフォルトの名無しさん2009/01/17(土) 20:51:53
手続き脳の俺には勉強になるなぁ
0794デフォルトの名無しさん2009/01/17(土) 20:58:37
参照透明っていっても、
HaskellでGUIのアプリとか作るときにやることは手続き型の言語と何ら変わらんよ。
純粋に関数的に使えるhaskell用のGUIツールキットとかもあるようだけど、実験的だったり普及皆無とか。
ためしにgtk2hsとかwxHaskellとか見てみればわかる。
0795デフォルトの名無しさん2009/01/17(土) 22:28:16
とりあえず、Haskellの処理系は副作用をバリバリに使うのでHaskellでは書けない
これはYes,No?
0796デフォルトの名無しさん2009/01/17(土) 22:42:23
OpenGL Tetris in Haskell
http://myawesomeblag.blogspot.com/2007/03/opengl-tetris-in-haskell.html
http://1.bp.blogspot.com/_wDxK4f5G5wA/RggslzqD0hI/AAAAAAAAAAM/gU4kJ3d7boE/s1600-h/Picture+2.png
0797デフォルトの名無しさん2009/01/17(土) 22:44:14
>>794
CだろうとなんだろうとHaskellよりはうまく出来るわ
なんたって値を書き換えられるからな
0798デフォルトの名無しさん2009/01/17(土) 22:47:12
>>796
Haskellのゲームってだけで話題になるぐらいじゃダメだと思うんだ俺は
C/C++なら当たり前すぎるわけだからさ
0799デフォルトの名無しさん2009/01/17(土) 22:47:32
>>797
じゃあこれより短いテトリスのプログラムをCで書いて。
0800デフォルトの名無しさん2009/01/17(土) 22:49:51
OpenGLならサーバにコマンドをプッシュするだけだもんね
自分で描画してないじゃんﾌﾟﾌﾟ
0801デフォルトの名無しさん2009/01/17(土) 23:12:25
>>795
釣るにももっと上手い釣り方があるだろ。

マジで言ってんなら
ghc/compiler/main/Main.hs　　　←　　ちなみに拡張子は.hsね。
みてみろwww

一部のHaskell狂信者が副作用ないからHaskellネ申とか言ってるけど副作用的にプログラミングすることは非常に多い。
0802デフォルトの名無しさん2009/01/17(土) 23:13:24
>>799
別に短くねーだろ

JavaScriptだけど
http://www.geocities.jp/nanagyou/list.html
0803デフォルトの名無しさん2009/01/17(土) 23:43:04
やっぱりCでうまく書けないんだねえ
0804デフォルトの名無しさん2009/01/17(土) 23:44:17
「Cよりは短く書ける」ことが今時自慢になるとでも思ってるのかよ……
0805デフォルトの名無しさん2009/01/17(土) 23:45:12
Cの本物のショートコーダーがどんなもんか知らんだろ
あれを短いと思ってるのが本物を知らん証拠だ
0806デフォルトの名無しさん2009/01/17(土) 23:48:21
>>801
コンパイラじゃなくて処理系だっての
とりあえず副作用のあるAPI関数をHaskellから呼び出すのはどうやるんだ？
0807デフォルトの名無しさん2009/01/17(土) 23:49:49
LispみたいにFFIを通すんでしょ
0808デフォルトの名無しさん2009/01/17(土) 23:50:43
>>806
黙ってgtk2hsのサンプルでも読めよ。
0809デフォルトの名無しさん2009/01/17(土) 23:58:19
僕のチンコもモナドの皮をかぶっててCよりも短いのですが
使いづらいですか？
0810デフォルトの名無しさん2009/01/18(日) 00:04:04
>>808
いいから教えろや
0811デフォルトの名無しさん2009/01/18(日) 00:07:46
>>810
いいから教えてもらったもの読めや
0812デフォルトの名無しさん2009/01/18(日) 00:11:45
「モナド」とか数学コンプっぽくてキモい
たかがhello worldを印字するだけのことで気取るなっつーの

んでもHaskellたんはゴム越しじゃなくて直接メモリ弄れるんですね
ちょっと見直しました
0813デフォルトの名無しさん2009/01/18(日) 00:24:28
Haskellのオブジェクトのメモリは書き換えられねえんだろ
そんなもの書き換えられるとは言わんだろ

HaskellのInt配列を画像として表示する関数をうまいこと作ったとしよう
その画像の一部を書き換えたくなったら一々新しい配列作らなきゃならんのだろ
0814デフォルトの名無しさん2009/01/18(日) 00:41:53
全然理解できてねえw
馬鹿に使えない言語w
0815デフォルトの名無しさん2009/01/18(日) 01:05:00
>>812
たかがhello worldを印字するのにも副作用なんていうキモいトリックを使わなきゃならん言語よりはマシだと思う
0816デフォルトの名無しさん2009/01/18(日) 01:12:43
いやいやキモくないでしょ
ノイマン型の計算機なんだから、メモリに書き込みたいときは正直にメモリに書き込む
言いたいことを、素直に直接的に言ってるだけ

ド汚い仕事を他人任せにして自分だけは手を汚してないフリなんかしない
0817デフォルトの名無しさん2009/01/18(日) 01:28:28
アセンブリみたいに命令の羅列なら確かに正直だけど、Cなんかは代入や関数呼び出しが式じゃん
値を計算するふりをして陰で入出力やら破壊的更新やらするのは十分キモいと思う
0818デフォルトの名無しさん2009/01/18(日) 01:32:13
なるほど、式と文をハッキリ区別してるPythonならいいわけだね
0819デフォルトの名無しさん2009/01/18(日) 01:37:24
movみたいなアセンブラのニーモニックは許せて
関数は許せないってのはよくわからん感覚だな
0820デフォルトの名無しさん2009/01/18(日) 01:46:29
>>816
だからさー、関数型言語っていうのは
関数っていう箱の中身がブラックボックスでも入力と出力の対がどうなってるのか知ってるだけで
部品として使えるのが便利なんじゃねーの。
箱の中で何やってるか考えなくてもいいのは明らかな長所だろ。
0821デフォルトの名無しさん2009/01/18(日) 01:49:04
アセンブリ…命令と計算を区別する。言語から直接使えるのは命令だけで、計算したいときは命令を組み合わせる
Haskell…命令と計算を区別する。言語から直接使えるのは計算だけで、命令が必要なら計算によって組み立てる

C, Lisp etc…命令と計算を区別しない。キモい
0822デフォルトの名無しさん2009/01/18(日) 01:58:47
>>820
いやだからさ、現実のプログラムは関数の豪勢による単なる値を計算するだけでなくて、その値を表示したり、他のものに渡したり、何らかの副作用を伴う作業を行うわけでしょ?
そこの値を計算するのに手続き型よりもすっきりかけるのはいいとしてもそのほかの部分をモナドに押しつけて僕は汚くありませんとか言っても何だかなという感じなんだが。
すまん、そこら辺勘違いしてるなら英語でもいいからここ読んどけというのを教えてたもれ
0823デフォルトの名無しさん2009/01/18(日) 02:00:54
計算をきれいに行えたとしても、それを実際の入出力に割り当てて、それをうまいこと並列化できるの?
0824デフォルトの名無しさん2009/01/18(日) 02:01:05
どこにあるとも知れぬHaskellからは参照できないビットマップを
処理系が裏でコソコソ作り出している副作用で書き換えて
「書き換えた結果はHaskellからは見えません。
どうしても見たければIOを使って読み出してください」
そんなクソ言語の分際で「画像を使うときは手続き型言語と同じだよね」って
同じなわけあるかボケが
0825デフォルトの名無しさん2009/01/18(日) 02:07:13
>>821
キモいけど、ほどほどには快適なぬるま湯。
0826デフォルトの名無しさん2009/01/18(日) 02:12:41
>>822
＞そこの値を計算するのに手続き型よりもすっきりかけるのはいいとしても
＞そのほかの部分をモナドに押しつけて僕は汚くありませんとか言っても何だかなという感じなんだが。

だからその変が嫌なら使わなきゃいいだけでしょ。
別に「Haskellは数学的にキレイだから他の低能言語とは違う」みたいに言ってるのは
ごく一部のHaskell狂信者だけだから。
ふつうの人は「ふーんこうやってモナドでくるんで使えばいいのね」みたいな感じで使ってる。
0827デフォルトの名無しさん2009/01/18(日) 09:49:25
モナド自体には副作用をどうこうする力はないだろ
「この処理には副作用がある可能性があります」というラベルを貼れるだけで
で、実際の副作用は非Haskellで作られたなんらかの処理を
処理系が呼び出して発生させる
Haskell自体には副作用がある処理を記述する能力はない
0828デフォルトの名無しさん2009/01/18(日) 13:49:27
>>827
まぁ、最終的にmain関数の返値のIOを処理するわけだからな
0829デフォルトの名無しさん2009/01/18(日) 13:57:08
>>827
くだ巻いている暇あったら、SPJの論文でも読めばいいのに。
0830デフォルトの名無しさん2009/01/18(日) 14:26:33
一見関係ありそうで関係ない論文を読まされる身にもなってみろ
0831デフォルトの名無しさん2009/01/18(日) 16:55:11
>別に「Haskellは数学的にキレイだから他の低能言語とは違う」みたいに言ってるのは
>ごく一部のHaskell狂信者だけだから。
>ふつうの人は「ふーんこうやってモナドでくるんで使えばいいのね」みたいな感じで使ってる。

Haskell ユーザなら自虐過ぎ。
「ふつう」の Haskell ユーザは、数学・計算機科学をある程度勉強して、
手続き型と違う「美しさ」に魅力を感じているからこそ Haskell を使っているんだと思うんだが。

その辺りに主義主張もなく、わざわざ Haskell なんて使っていながら
>「ふーんこうやってモナドでくるんで使えばいいのね」
というような表層だけの理解で通り過ぎる人こそ、普通じゃない

プログラム言語「マニア」

だと思うんだけど。
0832デフォルトの名無しさん2009/01/18(日) 17:41:05
「わざわざ」Haskellって……ｗ
それも十分自虐に見えるな

「単に便利な道具だから使う」という選択肢は最初から眼中にないわけね
なら、実用には使われなくて当たり前だ
0833デフォルトの名無しさん2009/01/18(日) 19:20:01
そりゃ不便だからな
ここの人なんか
ttp://www.shido.info/hs/haskell12.html

詰め碁で碁盤が書き換わるたびにIntMapを新しく作るような実装にして
「これでは遅すぎる」とか言ってるしな
あたりまえじゃねえか
0834デフォルトの名無しさん2009/01/18(日) 19:25:02
ある関数に入出力やら副作用が絡んでるかどうかが、
型を見るだけで分かるってのは、なかなか嬉しいこと
だと思うけどね。
0835デフォルトの名無しさん2009/01/18(日) 19:40:06
>>832
ん？
言語機能的にはCより遥かに便利だと思うが。
0836デフォルトの名無しさん2009/01/18(日) 19:55:15
今どきの言語でCより機能が貧弱な言語なんてねぇって
0837デフォルトの名無しさん2009/01/18(日) 20:57:09
>>831
もちろん綺麗だから使っているんだろうけど、

＞その辺りに主義主張もなく、わざわざ Haskell なんて使っていながら
＞>「ふーんこうやってモナドでくるんで使えばいいのね」
＞というような表層だけの理解で通り過ぎる人こそ、普通じゃない

こういう「表層だけの理解」とか人のことを貶している奴をHaskell狂信者って言うんだよ。
あとその主義主張をやたら大声でわめいてる奴らとか。
0838デフォルトの名無しさん2009/01/18(日) 22:18:54
まあ副作用のないMapは美しいなあとは思うよ
非効率だけど
0839デフォルトの名無しさん2009/01/18(日) 22:25:26
再代入が無ければ遅延評価でなんとかなるんじゃね
0840デフォルトの名無しさん2009/01/18(日) 23:07:42
更新するために既存の木を出来るだけ使って新しく組み立てるんだろ
良く知らんけど
俺の頭の中では一個付け加えた二分木を作るのにlogn回のノードのnewで済む
0841デフォルトの名無しさん2009/01/18(日) 23:15:07
確かに平衡化で組み替えが必要か。
0842デフォルトの名無しさん2009/01/18(日) 23:23:52
>>841
つ amortize
実際にそういうデータ構造のライブラリがある。
0843デフォルトの名無しさん2009/01/19(月) 08:43:37
>>838
効率良いぞ。
っていうか、rubyのmapと一緒にすんなｗ
0844デフォルトの名無しさん2009/01/19(月) 10:35:41
Haskellの良さはIOを完全に分離して考えれることだろ
IOに関わらない部分は頭の中で考えたロジックをほぼそのまま記述できる
でも現実的にはIO処理も大部分占めるけどHaskellでは効率も微妙だし書きづらい
まあそういうのためにFFIとかがあるわけで、要は全部Haskellで書いたり全部Cで書いたりしようとするのがナンセンス
0845デフォルトの名無しさん2009/01/19(月) 10:36:42
分離ではなく、統一なんだが。
0846デフォルトの名無しさん2009/01/19(月) 10:43:28
FFIとか泥臭い。
まぁ、HaskellのFFIはシンプルだが、それでもハイブリッドは美しくない。
0847デフォルトの名無しさん2009/01/19(月) 11:00:20
>>844
「ロジック」とか言うけど結局それってプログラムの内容によるんじゃね
「IOの関わらないピュアなロジック」なんてのがどの程度の分量あるかどうか

テキストエディタだのゲームだのWebアプリだの、典型的なプログラムはむしろ
状態とIOの塊でしょ
ピュアなロジックを綺麗に記述できることよりも、状態を上手く扱えることが
求められるケースのほうがずっと多いんじゃないの
0848デフォルトの名無しさん2009/01/19(月) 11:02:44
>>847
だから、ロジックとI/Oを分離してるんじゃなくて、統一してるんだって。
統一的に扱える枠組みとしてモナドを利用しているわけ。
0849デフォルトの名無しさん2009/01/19(月) 11:06:12
erlangなんかはpi-calculusという考え方に基づいた統一の仕方をしているね。
haskellは圏論に基づいた統一をしている。
でもCはマシン語むき出しの原始人の言語。
0850デフォルトの名無しさん2009/01/19(月) 11:26:22
>>843
mapは普通はハッシュテーブルで実装した方が速い
だがHaskellでは使えないに等しいだろ

碁盤を書き換えるなんてのは配列を使う以外考えられないケースだが
それもHaskellでは使えないに等しい
欠陥言語だな
0851デフォルトの名無しさん2009/01/19(月) 11:30:33
>>850
CでもHaskellでも、列を一つの数字として表すのが普通だと思うよ。
0852デフォルトの名無しさん2009/01/19(月) 11:32:56
Cだったら普通は碁盤を二次元配列にして
関数に入るときに碁石を置いて
関数から抜ける時に碁石を戻す
0853デフォルトの名無しさん2009/01/19(月) 11:37:07
>>852
効率が悪い。
0854デフォルトの名無しさん2009/01/19(月) 11:39:34
>>853
どこがだ
書き換えるたびに配列を一々作らなきゃならない欠陥言語と一緒にするなよ
0855デフォルトの名無しさん2009/01/19(月) 11:44:26
>>854
まず、

> 書き換えるたびに配列を一々作らなきゃならない

一体何の言語の仕様を言っているの？ｗ
0856デフォルトの名無しさん2009/01/19(月) 11:46:45
>>854
リバーシでも囲碁でもいいが、オープンソースで強いAIといわれている実装を見てみろよ。
データ構造に二次元配列を使って、一つの要素に1バイト以上も使っている実装なんて極少数だぞ。
0857デフォルトの名無しさん2009/01/19(月) 11:46:56
HaskellのArrayだな
IOが付いてない方の
0858デフォルトの名無しさん2009/01/19(月) 11:49:40
配列操作のほとんどは整数論的な最適化で実現可能。
配列が必要不可欠なアルゴリズムってほとんど思いつかないわ。
0859デフォルトの名無しさん2009/01/19(月) 11:52:17
>>856
どれの話だ
まあ二次元配列より一次元配列を二次元のように使った方が速いから
一次元配列にする方が普通だが
0860デフォルトの名無しさん2009/01/19(月) 11:53:14
>>848
IOと言ったのがまずかった
Stateを特別扱いしてる
0861デフォルトの名無しさん2009/01/19(月) 11:58:27
>>858
たとえば英文を読んでa-Zまでの文字が何回現われたか調べる
これを配列を使って実装するのと使わないで実装するのじゃ
効率が1ケタ違うだろう
0862デフォルトの名無しさん2009/01/19(月) 11:58:37
>>859
たとえばリバーシの場合、一つの石の状態を2ビットで表し、一列を16ビットであらわすんだよ。
で、状態を変化させるときは整数演算で行う。
そういう実装だよ。
0863デフォルトの名無しさん2009/01/19(月) 12:08:46
そういうハードウェアベタベタの効率化を図るなら機械語に近い処理系でやらなければ
ならないのは自明。Haskellとか使おうというのが間違い。Haskellに文句をつけるのが
お門違い。適材適所。
0864デフォルトの名無しさん2009/01/19(月) 12:21:50
>>862
Thellっていうリバーシのプログラム
http://sealsoft.jp/thell/#download
のspot/Board.hpp
というのを見れや
二次元配列になっとるぞ
0865デフォルトの名無しさん2009/01/19(月) 12:29:38
http://d.hatena.ne.jp/tosik/20071115/1195120024
0866デフォルトの名無しさん2009/01/19(月) 12:48:15
そのビットボードで強いAIってのはどこにあるんだよ
てか一気に2手以上指すわけでもなし
ビット演算するより普通に配列アクセスした方がはえーだろ
0867デフォルトの名無しさん2009/01/19(月) 12:54:48
なんだこいつら・・
調べたらすぐに分かることを調べようともせず、無知を棚に上げて相手を批判することしか考えていない
ここじゃ議論の余地はないな
0868デフォルトの名無しさん2009/01/19(月) 12:58:12
そうやって逃げてりゃ楽かも知らんけどね
関数型言語が非効率だってのは疑いようのない事実だ
連結リストや二分木がGCにどのくらい負荷をかけるか考えたことはあるかね
0869デフォルトの名無しさん2009/01/19(月) 13:00:21
少なくともOCaml最強の事実は変わらないわけだが
0870デフォルトの名無しさん2009/01/19(月) 13:04:17
OCamlでデバドラも書けるしロボットだって動かせるよ！
0871デフォルトの名無しさん2009/01/19(月) 13:04:26
>>869
どの辺が最強なの？
0872デフォルトの名無しさん2009/01/19(月) 13:04:59
>>868
だからなに？
スピード狂はGPGPUスレあたりでだんごとかいうクソコテと戯れてれば？
0873デフォルトの名無しさん2009/01/19(月) 13:10:18
http://shootout.alioth.debian.org/gp4/
このランキン見ていたら、意外とHaskell(GHC)が上位に入っていてびっくりした
0874デフォルトの名無しさん2009/01/19(月) 13:30:18
参照透明だからコンパイラが最適化しやすいんです＞＜
とか
並列計算で有利だお＞＜
とか言っても実際速くならないんじゃ意味ないよね
0875デフォルトの名無しさん2009/01/19(月) 13:38:03
>>874
まぁ、お前ら一般ユーザーはそういう理解でいいよ（笑）
0876デフォルトの名無しさん2009/01/19(月) 13:39:48
研究的価値ががあるなら研究者は集まってくるし、
研究者がいなくなるなら、それは将来的にもあまりいいものは出来そうにないってことだしな。
一般ユーザーは出来上がったものを使ってればいいよ。
10年ぐらい遅れたやつをねｗ
0877デフォルトの名無しさん2009/01/19(月) 13:41:49
キモっ
0878デフォルトの名無しさん2009/01/19(月) 17:08:31
現状だとHaskell使うのは速いからじゃなくて使いやすいからだからな
0879デフォルトの名無しさん2009/01/19(月) 17:14:58
速いぞ？>>873
0880デフォルトの名無しさん2009/01/19(月) 17:18:33
静的型言語でコンパイルして
さらに副作用まで使ってるのにこれしかいかねえんだから
全然早くねえんだよ
0881デフォルトの名無しさん2009/01/19(月) 17:21:21
最適化のために全体を書き換えられるような小さなプログラムなら結構速いな
そうじゃなくてもボトルネックが明確で、そこだけ最適化すればいいプログラムとか
広く浅くの効率化が必要だと、最適化に手間ばかりかかってHaskellの利点を殺す感じがある
0882デフォルトの名無しさん2009/01/19(月) 17:36:48
Haskellじゃ関数の奥のほうにボトルネックがあっても
そこだけ副作用使うとかそこだけCで書くとかできねえからな
どうしようもないね
0883デフォルトの名無しさん2009/01/19(月) 17:44:14
できるけど
0884デフォルトの名無しさん2009/01/19(月) 17:44:38
関数型言語の強みって、関数呼び出しのオーバヘッドが軽量ってことじゃないの？
Cなんかだと関数呼び出しが相当重いけど、関数型言語じゃ軽い軽い
0885デフォルトの名無しさん2009/01/19(月) 18:08:38
>>884
え？意味分からん。こんなコードをCとocamloptでコンパイルしてみて
tak 20 10 5とかやってみると、大差は無いがCのが速いぞ。

let rec tak x y z =
    if x <= y then y
    else tak (tak (x-1) y z) (tak (y-1) z x) (tak (z-1) x y)

let _ =
    if Array.length Sys.argv > 3 then
        Printf.printf "%d\n"
                      (tak (int_of_string Sys.argv.(1))
                           (int_of_string Sys.argv.(2))
                           (int_of_string Sys.argv.(3)))
0886デフォルトの名無しさん2009/01/21(水) 00:20:09
>>881
そんな感じだよね
いろいろ考えていじりまわそうとすると面倒な事がどんどん出てきて、
最終的に「他の言語でやるのと大差無いじゃん」という結論に至る
0887デフォルトの名無しさん2009/01/21(水) 00:54:10
>>228
魔法使いが現れた
0888デフォルトの名無しさん2009/01/21(水) 01:08:17
それ約三年前
0889デフォルトの名無しさん2009/01/31(土) 20:32:32
std::string<int> a = 3;

手続き式だと上の一文でも10個ぐらい概念が出てくるジャン
「std」 「 ::」 「string」 「<」 「 int」 「>」 「 a」 「 =」 「 3」

関数型はこれら文の意味づけを行う文法レベルで編纂していける言語っていう事かえ？
0890デフォルトの名無しさん2009/01/31(土) 20:52:09
意味が分からんけど十中八九違うよ
0891デフォルトの名無しさん2009/01/31(土) 21:40:57
面白いからコピペに使ってやんよ
0892デフォルトの名無しさん2009/02/10(火) 01:07:06
あながち間違いでもないと言えなくはない。
0893デフォルトの名無しさん2009/04/12(日) 13:04:13
ちょｗ
0894デフォルトの名無しさん2009/09/14(月) 10:29:20
ちがｗ
0895デフォルトの名無しさん2009/09/14(月) 20:54:09
>>888
つまり >>228 今 40 で、もし未だに C 未経験なら >>228 は妖精ということに…？
0896デフォルトの名無しさん2009/10/05(月) 23:29:03
>895
Cは未経験でもC++もC#もObjective Cも何でもOKの猛者だったりして。
0897デフォルトの名無しさん2009/10/08(木) 21:22:24
リアルに30杉て未経験なわけだが……
0898デフォルトの名無しさん2009/10/08(木) 21:27:41
魔法使いうらやましす
0899デフォルトの名無しさん2009/10/08(木) 21:58:34
なんでだよ。悲し杉るぞ、一生経験無いとか。
0900デフォルトの名無しさん2009/10/08(木) 22:11:59
もうとっととソープにでも行ってこい
0901デフォルトの名無しさん2009/10/08(木) 22:45:02
そういうことじゃないんだが
0902デフォルトの名無しさん2009/10/08(木) 22:55:07
はあ、もう死にたい。
関数型とか手続き型とかどうでもいいや……
0903デフォルトの名無しさん2009/11/08(日) 15:57:33
くだらねぇ
0904デフォルトの名無しさん2010/10/02(土) 22:25:56
だが、ピアノが上手い
0905デフォルトの名無しさん2011/04/15(金) 16:25:08.40
ほしゅ
0906デフォルトの名無しさん2011/04/15(金) 19:18:33.80
>>904
算術？
0907デフォルトの名無しさん2011/05/03(火) 01:57:32.75
急浮上
0908uy2011/05/11(水) 23:03:37.37
lambdaを使える言語なら関数プログラミング出来るので
わざわざ機能もライブラリも乏しい関数型言語使う意味はありません
マジで慣れれば最終的にクラスを全く使わずlambdaのみで（クラスよりも効率的に）やっていけるだろうと予想はしてるけど、
現時点、騒ぐほどすごい事はやってない
かえってオブジェクト指向に、中途半端に関数型の概念入れると
ソースがごっちゃごっちゃになる可能性もある
別にlambdaで出来る事の全てはクラスで出来るしね。効率？別に変わらない
かえって、lambda抜きで全てクラスでかいていくほうが統一性がある。やるならlambdaだけか、クラスだけか、にきっぱり分けるべき
とりあえず関数型言語の範囲の奴等が、再帰･マクロって言葉を特に頻繁に出してくるようになったら
何かが完成したと見て良い。
複数人でプログラム組むことを考えた場合、イロイロと完成していない関数型言語じゃやっていけない
OOのプログラム規則はだいぶまとまり始めているけど、関数型プログラミングにはそれが無い
自由すぎて人によってどんなコードをかいているかがわからないし、
人のレベルによって全然異質の関数型プログラミングのソースコードを書いていると思われる
だから「え？こんなのが関数プログラミング？」っていうのも関数プログラミングって呼ばれちゃうので、
関数型言語触っていない人から見ると、意味不明状態。「全然クラスでかけるじゃんｗｗｗｗ」っていう。
関数型プログラミングは、クラスではかけないソースコードのことを指すべきだということを常に思う。
似たような概念を2種類、世の中に放つ理由はないから。
つまり統一性が無さ過ぎる。その理由は、簡単。関数型プログラミングって概念が、まだ未完成の未完成。
ひとりでも、関数型プログラミングの究極にたどり着ければ、そこから一番効率のいい手法が広まっていく為、
「正しい・間違っている」を明確にできる
0909uy2011/05/11(水) 23:03:58.30

今は、きっと誰もいないか、自信を持ってる発言できる奴がいない。
未完成状態の手法を広めても意味がない

クラスで十分やっていける事を、関数型で書き直す意味もないから、lambdaのlambdaがすごい。と謳ったところで
この技術は広まりはしない。オブジェクト指向。クラスでは効率的にやっていけずに、
関数型言語でのみ効率的にやっていけるのはマクロだ。
けど完成していない。マクロの技術が完成しない限り、OO厨は関数型厨がどんなに騒ぎ立てても焦る必要は無い
どうせしょっぼいコードしか描いてないからｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ


0910デフォルトの名無しさん2011/05/11(水) 23:08:10.16
たとえ closure があっても return foo みたいに書かせる言語が
関数プログラミング出来ているとは感じられないね。

関数の返り値を使ってプログラムを構築するスタイルの言語が
関数型言語なのであって、lambda があるかどうかは二次的な話。
0911デフォルトの名無しさん2011/05/11(水) 23:23:50.62
関数型と遅延評価は別か？
0912デフォルトの名無しさん2011/05/12(木) 10:23:14.51
別。MLを関数型でないと言う奴はいないだろ。
0913デフォルトの名無しさん2011/05/12(木) 10:54:04.70
>>910
> 関数の返り値を使ってプログラムを構築するスタイルの言語が

「関数プログラミング」なら、
全ての関数がfirst class objectかどうかの方が大きいと思う。
それから無名関数の存在。

"Pure functional"となれば副作用なしのプログラミングだと思うが。


0914uy2011/05/17(火) 18:13:45.61
>>910
そんな時代遅れな関数型プログラミングやっててもしょうがないだろ
lambdaは関数型の一部としてみろよ
lambdaのない関数型言語の存在価値はゼロに等しい･･･
0915デフォルトの名無しさん2011/05/17(火) 19:22:33.67
>>911
別
純粋な関数型言語との相性が良いだけで、関数型言語に必須という訳じゃない
0916デフォルトの名無しさん2011/05/17(火) 19:27:17.53
>>910
関数を組み合わせるのであって、毎回返り値を使っている訳では無いよ
「あと一つ引数を取れば、値を返す関数」とかも普通に引数にしたり、返り値にしたりするし
0917デフォルトの名無しさん2011/05/17(火) 19:29:17.06
うん、まあ理想を言えばバカでも使える言語がいいので
uy君の意見にももっともな点がある
0918デフォルトの名無しさん2011/05/17(火) 23:17:38.00
uy君はLISP信者だから仕方ない
0919デフォルトの名無しさん2011/05/18(水) 01:06:06.72
>>910
FPｷﾀｰ
0920デフォルトの名無しさん2011/05/24(火) 20:06:48.12
MLしか知らんので、Haskellでは改善させているかもしれないが、
・丁度やりたい処理に合致した高階関数があればとても便利だが、
　なければ非常にめんどうになる。
・配列が使いにくい。もう少し糖衣構文がほしい。
・同型からなるレコードの場合は、map/foldが使いたい。
0921デフォルトの名無しさん2011/05/24(火) 20:55:43.23
>>920
haskellで改善されてたかレポート希望

0922デフォルトの名無しさん2011/05/26(木) 22:08:55.79
仮想的に時を超え将来入力されるであろう値が入ってるリストdeviceがあるとする。
このdeviceは(car (car device))というふうに関数を適用すると1つ目のデバイスから、
1回目の入力結果が得られる。(car (cdr (car device)))とすれば、2回目の入力が得られる。
このdeviceリストを1番最初に呼ばれる関数の引数に渡して処理をしていくとすると、
副作用の無い計算という事になるんだろうか？少なくとも最初の関数に渡されている時点で
値は決定されているという屁理屈なんだが。
0923デフォルトの名無しさん2011/05/26(木) 22:29:12.24
>>922
Stream I/Oというものですね。
昔のHaskellはそのやり方でした。
0924デフォルトの名無しさん2011/05/28(土) 13:51:56.48
F#って使ったことないんだけど、どんなもん？
0925デフォルトの名無しさん2011/05/28(土) 13:52:30.04
Haskellの要素をちょっと加えて.NETで味付けしたおきゃむる
0926デフォルトの名無しさん2011/05/28(土) 14:27:51.72
Haskellの要素ってComputationExpressionのこと？
0927デフォルトの名無しさん2011/05/28(土) 17:21:14.68
.NETの機能が使えるから実運用で関数型使うにはいいんだろう
その場合は言語仕様よりライブラリの充実度だから
0928デフォルトの名無しさん2011/05/28(土) 22:16:53.36
UIはC#で書いてデータモデルにはF#ってパターンはありだと思う
0929デフォルトの名無しさん2011/05/29(日) 02:28:02.09
F#でXAMLライクな定義DSL書いてやったほうが幸せになれそうな気がしてきたよ(´д｀)ﾏﾏﾝ…
0930デフォルトの名無しさん2011/05/29(日) 03:22:17.84
.netのデリゲート的な処理をどうやって副作用なしで実現するか気になる。
アレは戻り値が無いもんなぁ。
0931デフォルトの名無しさん2011/05/29(日) 09:43:36.86
イベントが上がったら、何か状態を変更したりステートメントを実行したりとかの今ポピュラーなGUIスタイルのこと?
多分その辺はRxもしくはRx的なFRPの類で副作用的なものとその依存関係を隠ぺいするって形なんだろうねー
あーほんとにF#での宣言的なXAML&MVVMLikeのフレームワークとRxLikeとかつくったらかなり幸せになりそうな気がしてきたよ。
全部F#ですっきりかけそう。
0932デフォルトの名無しさん2011/05/30(月) 01:03:06.60
まぁGUIのイベントもそうだけど、スレッドとかね。
スレッドなんて副作用無くしたら共有情報持てないんだから
どうなんのかすげぇ気になる。やっぱモナドなんかな。
0933デフォルトの名無しさん2011/05/30(月) 01:07:11.58
モナドよりもモナコがいい
0934デフォルトの名無しさん2011/05/30(月) 03:39:40.54
関数型と手続き型が合体した言語って無いの？
0935デフォルトの名無しさん2011/05/30(月) 03:58:36.66
>>934
むしろ事実上そんなのばっかじゃん
どっち寄りかってだけで
0936デフォルトの名無しさん2011/05/30(月) 09:27:52.38
>932
そのためのActorモデルでしょう。Rxとかも同様だけどね。
結局何かしらのデータやメッセージをそのコンテキストでシンクロナイズして処理すると。
STMやらなんやらよりもこのモデルのほうが可読性とかははるかに高いと思われ。FRPとも相性いいし。
0937デフォルトの名無しさん2011/05/30(月) 11:18:46.23
Actorは副作用ありまくりですけども
今でいうところの並行モバイルエージェント計算みたいなもんなんで。
0938デフォルトの名無しさん2011/05/30(月) 22:04:48.23
Erlangのreceiveがなんか関数型として納得いかん。

Process![値,値,値]　は、WinAPIのPostMessage(Process,値,値,値):みたいな感じだし、
receiveは、WndProcedureを言語機能で持ってるようなもんだし。
どこが関数的なのか教えてくれ。
0939デフォルトの名無しさん2011/05/30(月) 23:46:55.64
関数型のメリットが理解できない
状態を追い出すことが目的になってムダに難解にしてる
0940デフォルトの名無しさん2011/05/30(月) 23:59:05.32
>>939
それは手続き型に毒された視点から見てだろ。
状態自体は関数が持ってるし別に無い訳じゃない。

あと関数型は入力が同じである限り、
出力は同じ筈だ。一見入出力があるように見えても、
入出力は無い。なのでCの数学関数がOSに依存しないように
関数型の入出力を模した関数もOSや環境に(概念上)依存しない。
0941デフォルトの名無しさん2011/05/31(火) 00:01:43.49
別に副作用あっても、Cの関数はOSに依存しないだろ。
0942デフォルトの名無しさん2011/05/31(火) 00:04:56.82
>>939
自分も最初、そう思ってたから言うけど、関数型言語の方が素直に書ける場面の方が多いよ

文字数を求める関数は「どう動くべき」か？
合計を求める関数は「どう動くべき」か？

関数型言語って、そう考えて作るもの

まず、どう言う物かを定義して、まんま書くだけ

上のは再起しか使ってないけど、他の場面でも、大抵そう考えれば作れる
0943デフォルトの名無しさん2011/05/31(火) 00:12:19.70
近視眼的すぎないか
分割の概念はどうなってるの？
0944デフォルトの名無しさん2011/05/31(火) 00:14:18.17
非純粋関数型の立ち位置がわからん
0945デフォルトの名無しさん2011/05/31(火) 00:19:29.38
>>938みたいなレスあるけど結局純粋関数型だとスレッドとか非同期イベントってむりなん？
0946デフォルトの名無しさん2011/05/31(火) 00:20:48.34
>>942
> 文字数を求める関数は「どう動くべき」か？
> 合計を求める関数は「どう動くべき」か？
>
> 関数型言語って、そう考えて作るもの

それ、関数型言語以外でも同じだからｗ

0947デフォルトの名無しさん2011/05/31(火) 00:25:47.14
>>943
でも、関数型言語初心者はsumを再帰で書いて、次にfoldl or foldr書いて、さらに次にfoldl or foldrで書いて、productに進むのが良いと思う

分割？何の事だろ
分割統治方使ったクイックソートの事。。。じゃ無いか

0948デフォルトの名無しさん2011/05/31(火) 00:26:08.79
>>946
じゃなくて手続きだとどう複数の文を書くかになるだろ。
ループの抜けかたがどうのとか変数の使い方がどうのとか。
0949デフォルトの名無しさん2011/05/31(火) 00:28:54.74
>>946
再帰を使えばね
でも、手続き型だと普段は「どう動くべき」を考えたら、次に「どう実現するか」が間に入るでしょ

関数型言語にはそれが無い場面が多い
0950デフォルトの名無しさん2011/05/31(火) 00:30:23.77
再帰ってスタック浪費してる
0951デフォルトの名無しさん2011/05/31(火) 00:31:23.72
>>947
>>943
x さらに次にfoldl or foldrで書いて
o さらに次にfoldl or foldrでsum書いて
0952デフォルトの名無しさん2011/05/31(火) 00:32:59.88
関数型にヒープの概念ってあるの？
0953デフォルトの名無しさん2011/05/31(火) 00:33:26.92
>>950
組み込みのfoldl/foldrはスタック消費しないよね
でも、最初はそれでも再帰で書いた方が良いと思うんだ
0954デフォルトの名無しさん2011/05/31(火) 00:37:00.22
再帰で書いて、次に末尾再帰に直して、、、
0955デフォルトの名無しさん2011/05/31(火) 00:38:38.60
オブジェクト指向は手続き型からの正統な進化形だと思うけど
そこに関数型のメリットを追加するとすればどういう形になると思う？
0956デフォルトの名無しさん2011/05/31(火) 00:41:30.76
>>954
末尾再帰は再帰でいくつか関数を作った方が良いと思う
高階関数を含めて、関数型言語の関数の概念に慣れてもらってからだと思う
0957デフォルトの名無しさん2011/05/31(火) 00:55:39.35
>>955
高階関数
型推論(こっちは関数型言語ほど簡単にいかない気がする。動的言語には関係無いかもだけど)

でも、手続き型は高階関数を自分で作れる言語より、高階関数をライブラリに組み込む言語が主流になりそうな気がする

手続き型と配列の相性が良いように、関数型とリストは相性が良い
文字列を表現する構造が違う限り、完全に関数型言語の特徴を取り込むのは無理な気がする
0958デフォルトの名無しさん2011/05/31(火) 01:08:11.31
>>955
構造体ベースのクラスじゃなくリストベースのクラスになるかもよ。
メンバー変数(フィールド)の追加削除が自由自在。
それからパターンマッチが導入されるかもね。
オブジェクトの型じゃなく構成で呼ぶメソッドを変えられる。
0959デフォルトの名無しさん2011/05/31(火) 01:08:13.24
どっちもC/C++ならいらないなぁ
0960デフォルトの名無しさん2011/05/31(火) 01:18:39.21
今更気付いたけど、foldl/foldr/mapって、手続き型のループを抽象化してるのな
0961デフォルトの名無しさん2011/05/31(火) 01:24:11.73
偉大な構造化定理は関数型で反映されてるの？
0962デフォルトの名無しさん2011/05/31(火) 02:15:30.26
>>957 配列は関数型と相性が悪いのかもわからんね。
初期値なしfoldが配列の方が書きにくい。
val foldl1 = foldl (hd xs) f (tl xs)
val foldl1' xs f =
foldli (xs $ 0) (fn (i,a,b) => if i=0 then a else f(a,b)) xs
0963デフォルトの名無しさん2011/05/31(火) 12:05:11.61
いまある関数型ってSmalltalk的なやり過ぎ感がある
0964デフォルトの名無しさん2011/05/31(火) 12:26:54.43
最近は関数型言語発祥の機能を入れたマルチパラダイム言語が多いのでは?
有名所でもScala, Rubyなど。

狹い意味での関数型言語(>>963のいうやり過ぎ系が含まれると思われる)の
仕様、実装の数はイギリス人たちがHaskell大連合を作ったのでむしろ減ってるし、
こういうのは「やり過ぎ」じゃないと、研究する意味がない。
0965デフォルトの名無しさん2011/05/31(火) 12:35:49.68
研究用ならいいんだけどね
0966デフォルトの名無しさん2011/05/31(火) 12:36:28.59
参照透過性とか一部の数学的な性質は、ひとつでも例外があると壊れちゃうんで
Haskellがエクストリームなのはしょうがない。

>>964
Haskellがあるおかげで、研究的な別の仕様の言語とかはHaskellにはどうしても
導入できない機能の実験とかに限られてる感じだよね。
0967デフォルトの名無しさん2011/05/31(火) 12:36:49.53
>>961
反映と言うか、普通に満たしてるし、入力出力が明確な分、下手な手続き型より忠実な気がする

0968デフォルトの名無しさん2011/05/31(火) 12:41:32.17
混ぜるな危険
0969デフォルトの名無しさん2011/05/31(火) 12:42:38.40
え？
0970デフォルトの名無しさん2011/05/31(火) 12:46:31.52
最近C10K系のWebアプリが対象ドメインになっている言語で、
非同期処理の効率を追求するため、
関数型言語的要素を多く持つ言語が注目を浴びてる。(Erlang, Clojureなど)
こういうのは要求に迫られての仕様なんで仕方ない。
0971デフォルトの名無しさん2011/05/31(火) 13:00:17.58
>>963
SICPの序文によると、Pascalは宣言的過ぎるからSchemeがベターだそうだ
そういう批判に対して
「Pascalは宣言的過ぎるんじゃなくて総称型の機能が足りないだけなんだからね！」
のような反応が返ってくることは想像に難くない
0972デフォルトの名無しさん2011/05/31(火) 13:16:36.54
そこでDelphiですよ
0973デフォルトの名無しさん2011/05/31(火) 13:34:22.17
参照透過性が目的ならテンプレートプログラミングのほうがよくね？
0974デフォルトの名無しさん2011/05/31(火) 14:30:32.22
テンプレートでは実行時の参照局所性を保証できない。
0975デフォルトの名無しさん2011/05/31(火) 14:45:29.66
え？
0976デフォルトの名無しさん2011/05/31(火) 17:51:49.75
Microsoft ResearchのSimon Peyton Jones先生の
"Parallel = Functional, The way of the future"
http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/Parallel-Haskell.pdf
0977デフォルトの名無しさん2011/05/31(火) 18:38:03.64
>>972
自滅さえしなければ良い選択肢だったんだがな
0978デフォルトの名無しさん2011/05/31(火) 18:47:25.41
Simon saysっていうゲームあったよな
0979デフォルトの名無しさん2011/05/31(火) 19:08:34.51
Haskellがやり過ぎって思うのは、「純粋」「非正格」みたいな宣伝文句に騙されてるんじゃね？
実際は、いわゆる関数的な記述を強制される訳じゃなくて、破壊的操作を伴うアルゴリズムとか普通に書ける
特に「純粋」な言語であることは、使ってみると意外なほどコーディングに影響しない
0980デフォルトの名無しさん2011/05/31(火) 19:17:44.15
>>979
それは有るなー。。。
変な宣伝文句に踊らされ過ぎなんよね

普通に、そういう言語。って受け入れれば、副作用も扱えるし、正確評価も扱える

デフォルトが非性格で、副作用もおまじないが必要って思えば、関数型言語の利点を最大限生かしてるだけで、ちゃんと普通の言語だと気づく
0981デフォルトの名無しさん2011/05/31(火) 21:43:39.88
しかし、いまだに計算量の見積もりやスペースリークの回避に
悩んでしまう。
0982デフォルトの名無しさん2011/05/31(火) 23:10:13.71
どう考えても構造化された手続き言語のほうが可読性高い
0983デフォルトの名無しさん2011/05/31(火) 23:11:56.61
無理に使う必要ない。
英語読めないと>>976すら読めないんだし。
0984デフォルトの名無しさん2011/05/31(火) 23:13:00.32
effective haskellみたいな本ないの？
0985デフォルトの名無しさん2011/05/31(火) 23:41:55.94
effective haskell

第一章　メモリ管理

1項 サンクは早期に潰そう
2項 foldlの利用は避けよう
3項 使えるときは、必ずseqを使おう
0986デフォルトの名無しさん2011/06/01(水) 02:33:00.81
イベントハンドリングやろうと思ったら殆ど副作用ナシでいけるんだな。
手続きよりむしろ簡単な気がする。

(defun EventLoop(widget handler input) (EventLoop (handler (car input) ) handler (cdr input) )
(EventLoop widget (lambda (event) 色々) input)
※終了条件が無いとかwidgetがひとつとかなのは面倒なので書いてない
0987デフォルトの名無しさん2011/06/01(水) 08:50:46.56
ほとんど 気がする・・・
0988デフォルトの名無しさん2011/06/01(水) 09:05:18.46
>>985 effectiveなら末尾再帰なfoldl(foldl')では

世の中にある多くのアルゴリズムは副作用ありの擬似言語で記述されてるんで
既存資産的には手続き型有利
0989デフォルトの名無しさん2011/06/01(水) 09:13:20.15
foldr/foldl問題は、
対象とする列がリスト表現なのかどうか、
適用する演算子が右結合なのか、左結合なのか、
交換律が成りたつのかによって違い、
>>985のタイトルほど簡単には言えない。
これは関数型/手続き型関係ない。
0990デフォルトの名無しさん2011/06/01(水) 20:24:32.24
Haskellだと使うのはfoldrかfoldl'で、foldlを使うべきケースって基本的に無いよ
0991デフォルトの名無しさん2011/06/01(水) 22:28:35.84
なんで関数型風に擬似コード書かないのは何故？
0992デフォルトの名無しさん2011/06/01(水) 22:44:12.29
関数型風の疑似コードって数式の事?
0993デフォルトの名無しさん2011/06/02(木) 03:33:15.31
最近オブジェクト指向にはまってるんですけど、
関数型言語って、非オブジェクト指向ですよね？

今時、データと処理が分離してるなんて
ありえないんですけど、時代と逆行してるんですか？
0994デフォルトの名無しさん2011/06/02(木) 06:23:57.77
データ即是処理、処理即是データ。
0995デフォルトの名無しさん2011/06/02(木) 07:52:14.98
>>993
オブジェクト指向はメッセージってメソッドやら何らかの処理を
させさえすればいい。なので別にデータがオブジェクトと一体である必要は無い。
たまたまそういう実装が多いだけの話し。
海外のサイトで勉強しなおしたら？
0996デフォルトの名無しさん2011/06/02(木) 09:09:34.17
海外のサイトｗ
0997デフォルトの名無しさん2011/06/02(木) 09:37:18.77
洋モノ
0998デフォルトの名無しさん2011/06/02(木) 12:34:23.33
>>993
どっちかと言うと関数型言語はデータと手続きが高次元で融合してる
関数もデータとして扱えるのは大きい

オブジェクト志向と比べて再利用性が高いのは本当
0999デフォルトの名無しさん2011/06/02(木) 13:39:45.73
Cで関数型の機能実装してみれば組み込みでは使えないことがわかる
1000小倉優子 ◆YUKOH0W58Q 2011/06/02(木) 14:58:45.67
　　∧,,,∧　
　( 　・∀・)　1000ならジュースでも飲むか
　 (　　 　)　
　　し─J　
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。