関数型と手続き型

大きな二つの流れである関数型と手続き型について議論･学習するスレです。
両者のメリット、デメリット、得意･不得意分野などをまなびませう。

関数型なんて一部のマニアが趣味で使っているだけだろ。

手続き型は文系・原始人
関数型は理系・知的

エージェント指向

erlangは関数型だけど，実用的なものに使われてるよ。

一階述語論理は？

>>2
関数型は馬鹿を切り捨てるぶん、浸透しにくいよね。

C++はSTLのあたりから結構関数型風に傾いていないか？

C#でのdelegate、Generics,インターフェースを駆使したものでの生産性と関数型の生産性は異なるの？

>>7
教育の問題だと思う。初めてプログラミングを教えるときに使う言語をPrologとかSchemeみたいなのにすれば浸透すると思う。
私は命令型の言語よりもPrologのような論理型言語を使った方がプログラムしやすい。

>>10
Prologは言語というよりも証明支援系・・・かな？

>>11
ふつうのプログラミング言語だよ。ライブラリは少ないかもしんないけど。

手続き型→一般人
関数型→厨房・暇人

手続き型のアホに対する優しさは異常

>>8
無い。

object is poormans closer!!!!!!!!!!!!

>>14
手続き型っていうか、代入型は初心者がバグを書くのを助けてくれる。

>>15
使ってない人が反応しなくていいです(^^)

>>18
お前のことだろw

>>8
関数型というより静的(コンパイル時)に決められるものは
徹底的に静的に決めるということだな。
仮想関数はなるべく使わない。クラスを避ける。
自然と関数指向になる。

ここで手続き型と関数型の違いについて質問でてるけど、まともな答え返ってこないね。
ttp://pc8.2ch.net/test/read.cgi/tech/1140717775/

>>20
> 関数型というより静的(コンパイル時)に決められるものは
> 徹底的に静的に決めるということだな。
>仮想関数はなるべく使わない。クラスを避ける。

という説明から

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

これにはならんのだが。
関数型というものを、勘違いしている人のいうセリフだな。

手続き型と関数型の違いはプログラミングスタイルじゃないかな。

  * 手続き型

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

  * 関数型

    事実を定義し，それらの事実と事実との関係を構築しプログラムを作成。

関数型、手続き型でおのおの得意なプログラム、苦手なプログラム、出来ないプログラムってあるの？

できないプログラムはありません。実はラムダ式に帰着できちゃいます。

関数型の生産性と持続可能な発展性は美味しい

向き不向きは？
後ラムダ式に帰着できるって言うのはマシン語に帰着できるというような極論？

遅延評価があるとリアルタイム処理が難しくならない?

>向き不向きは？
あると思う。
>後ラムダ式に帰着できるって言うのはマシン語に帰着できるというような極論？
その通り。

関数型は馴染みが無いが、説明的なところを読んで解釈して書いてみる。
間違ってたらｽﾏｿ。

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

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)
}

あらゆる計算モデル、つまりチューリングマシン、帰納的関数論、またはActor理論、etc..はλ計算で表現できます。

結局さぁ・・・
普通のプログラムだと、データ受信したとか、入力があったとか何らかの起点があるよね？
そこからの流れが関数として書かれてるってこと？
状態の保持とかどうすんの？
状態持つとかだったら、オブジェクト型のほうが人の思考になじみやすいってこと？
で、どこら辺で生産性があがるのよ？

んな小難しいことしなくても

手続きっぽいの
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!"
)

あ、手続きのは"dekitayo!"とかをstringの変数に入れたほうがよかったか。
バカっぽくてごめん。

関数型には if も else も存在しない。
なぜなら状態という概念が無いから状態によって変化、分岐するということが無いから。

なぁそのコンパクトに書けるっていうのじゃなくてさぁ･･･ほらこう･･･あるだろ？
関数型がこう･･･いいって言われるものがさぁ･･･あるんだよな？

生産性は下がるんじゃねーの？関数型はマイナーなんだし。

>>35
嘘をつくな。
例えば
abs x = if x > 0 then x else -x
は数学的な意味で関数だ。

>>37
そういう次元の話じゃない。

関数っていうのは基本的には、
特定の集合に特定の一つの集合を結びつける規則という縛りしかない。

確かに馬鹿文系に無理に使わせるのは却って生産性を下げるな。
使いこなせないだろうから。

×生産性があがる
○抽象性があがる

ラムダとかクロージャとか、
最近の手続き型言語と言われてる言語にも
それなりに導入されてるしな。
直接的なものでなくとも、
言語機能を使えばそれなりに簡単に実装できる、とか。

純粋な手続き型言語ってのはそのうち死滅しそうだが、
だからといって純粋な関数型言語もずっとマイナーでいつづけるだろうな。

これが手続き型、
if( ... ) { ... } else { ... }

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

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

人間の考え方は、手続き型です。

だから手続き型の方が人間に分かりやすいのです。

>>44
if使う使わないの話は関数型，命令型に関係ない。

もともとCは関数型のスタイルでプログラミングするように設計されてない。Cで関数型プログラミングできないことはないけどやりにくい。

>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;
}

そもそも条件分岐している時点で｢状態｣が存在しているわけだから純粋な関数型じゃない。

>>47
お前が言うところの「数学的な意味での関数の書き方」て何よ

>>48
自然言語が入っちゃマズイとか、
連続していないといけないとか、
定義域が実数じゃないといけないとか、

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

関数型と数学の関数は違うんじゃないのかな。

>>47
条件分岐のどこに状態がある?値を渡す時間によって帰ってくる値が変わるっていうなら状態があるっていうけど。

もうこいつら何について話してるのかわかんね。コンテキストがあってねー。

結論：誰も分かってる奴がいない。

>>51-52
MediatorパターンとAdapterパターン使って。

>>47
数学を引き合いに出したのがまずかったなら言い直すが、
abs x = if x > 0 then x else -x
は正しいHaskellの関数定義(MLでもちょっといじれば通るはず)。

>54
そういうことでなら納得。確かに参照透過性は損なわれないわけだし。

つまり、数学のための言語であって
実用的じゃないのが関数型でいいの？

>>56
よくないです

>>56
違う。
モデル化する方法が異なるだけ。
ディジタル回路を扱うときに使う言語とアナログ回路を扱うときに使う言語の違いのようなもの。

それに実用的に使える。

ビジネスというのは最初がローコストに見えることが重要。
安く導入して保守費用で儲けたりさ。そういう観点から見ると手続き型しかありえんのだわ。

つはっかーと画家

手続き型の言語ばかりやっていると新しい言語の習得が難しくなりコストがかかる。
Schemeみたいな関数型と手続き型の両方のプログラミングスタイルが気軽に扱える言語を覚えた方がトータルで考えると低コストだと思う。

手続き型に組み込まれた関数型は実用的だけど、
純粋関数型は実用的だとは思えない。

たとえば、Javaの総称型が関数型言語の多相型を取り入れたものだということは明らかなんだけど、
元からの言語仕様に強制的にねじ込んだものだからひどく煩雑なつくりになっている。
あれなら素直に関数型言語を使ったほうが良いとさえ思う。

>>62
純粋関数型言語で作られた実用的なアプリ。

http://www.wings3d.com/

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

;; 予め言っておくが、他にはって聞かれたら、次は darcs 出すから聞くなよ。
;; 際限無いからな。

>>64
英語じゃなくて日本語のやつは無いの？

>>64　正直オブジェクト指向に頭が固まってるんだが･･･関数型だとオブジェクトとかどうとらえるの？
そうはとらえんのか？
たとえば、ブラウザ作るとして開いてるページとその中身のhtmlとかはどんな感じに保持するの？

>>66 俺も。○○指向、という点ではオブジェクト指向に
頭が固まっちゃってる。問題を解決するに当たって
どんな風にクラスにモデル化するかということばかり
考えてしまう。関数型プログラミングとオブジェクト指向
プログラミングって相性悪い？

ぜんぜん的はずしてるかもしれないけど、 Emacs Lisp
いじってるときはオブジェクト指向の頭が取れてる気がする。

で、なんで相性悪いって気になるのか
仕事中にもかかわらずぼーっと考えてみたんだけど、
オブジェクトの内部状態って関数型プログラミング
ではどうやってあらわすのよ？ってオモタ。

>>68
純粋な関数型ではないけどSchemeだったらクロージャと代入を使ってオブジェクトを作る。
純粋な関数型の場合，詳しくはないけど，クロージャとモナドを使うんじゃない?

>>69　挿すっと今度は逆にオブジェクト指向を関数型で実現するのに無理してる。最初からオブジェクト指向言語使えばいいのにって感じになるのか？

>>70
うん。オブジェクト指向で考えた方が楽なら無理して関数型を使う必要はないと思う。SmalltalkとかRubyみたいな言語を使った方がいいと思う。

>>71 それが混在してるのが悩ましいところなんだよな。

逆に手続き型の言語なのに、マシンの状態をイメージしないで
プログラミングするのはカンベンしてﾎｽｲ。人の能力に限りはあるけど、
できるだけそうするように努めるべき。

>>71　そうすると、関数型で作るときはオブジェクト的な考え方はしないの？
例であげた、ブラウザ作るときに複数ページを保持するようなものはどうするの？

つStateT

ストリームとか使うんでない?

結局状態を保存しないと無理なんじゃ

実際の動作は状態を保存するようなことになるけど、
形式的にはステップごとに状態をバケツリレーしていく感じ。

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

関数型
関数x(.. 関数2( 関数1(状態0) ) .. )

>>78　処理と処理の間に空白があるときは？たとえば入力してしばらくしてから修正するときとか。
その間はどっかに状態保持するよね？

Lispいじるときは関数＝クロージャだから
あまり「手続き型と真っ向対立」みたいなことは思わないなぁ
各関数が各環境を持っているわけで

>>79
引数として状態が渡される。
関数nは状態を変更する処理と思えばよい。
入力してしばらくしてからと言う場合はその間に状態を変更する関数が実行されていないか、
もしくは恒等関数( f(x) = x )が実行されていると考えてもよい。

>関数nは状態を変更する処理と思えばよい。
正確には関数nは状態を受け取って次の状態を返す関数。

>>81　状態を変更する処理が実行されない間は住所録？どこかに保持されるんじゃないんですか？
オブジェクト指向なら普通
class AddressBook{
void Add(Address addr);
void Delete(string key);
}
見たいなクラスでシングルトンかなんかでアクセスされてインスタンスはひとつがずっと保持されるんだが。

>>83
引数として状態が渡されて、引数はその関数を計算する間定数として保持される。

>>84　いやだから、入力処理があるよね？で削除処理があるよね？その間どこに保持されるんですか？

>>85 そういうのは副作用で系外に・・・
って、そういうのは反則？

>>83
純粋でない関数型言語の場合は、普通にローカル変数を使う。
x = add_address(empty_address_book, "a");
print(x);
// ここで何か別のことをやる。
x' = add_address(x, "b");
print(x');

純粋な関数型言語ではいろいろ妙なことをやるけど、
結果的に似たようなコードになる。
そもそも、逐次処理は手続的に書くのが最善の事が多いから、
関数型言語でも手続的に書けるようになっている。

純粋じゃない関数的プログラミングっつったら↓みたいなイメージあるけど間違ってる？

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

みたいにしていくイメージがあるけどこれでいいの？

「状態」っていうのを変数と値の組を記録したデータベースと考えて、
状態0はそれが空のものと考えると、

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

といった感じ。

リロードし忘れましたごめんなさい

>>89　結局そのいずれかの状態にあたるものはグローバル変数なり何なりアクセスできるところにおいてあるということ？

>>91
いや、その状態にアクセスする関数間を全部引数として引きまわすのが原則。

>>92　だとしたら、入力とか削除とかなにされるかわからないときはどんなコードになるんです？

>>93
>入力とか削除とかなにされるかわからない
意味が分からん。もうちょっと詳しく。

>>94　んーたとえばさっきの住所録みたいなやつ。
>>89　みたいなやつでおのおのの作業（A追加、B追加、A削除)の間にユーザーが行うまでに間がある場合

ごめん。>>92は俺の勘違い。
>>89にあるような「状態」はグローバルにあると考えていい。

オブジェクト指向だとデータとメソッドを一体化させるけど、関数型はそれをしないということ？
あと>>96のようにするならば、関数型の状態を変えないからバグが出にくいとかというのはそのばあいには適用されないということ？

混乱させてすまん。>>89の話は(俺が正しく理解してるなら)どちらかというと概念上の話
(あるいは実装の詳細)で、
「関数型言語のインタプリタを作る際にグローバルな状態を活用できる」位の意味に取ってくれればいい。
実際の関数プログラミングでは、データは全部関数間を引きまわす。

で、
>おのおのの作業（A追加、B追加、A削除)の間にユーザーが行うまでに間がある場合
だけど、>>87の説明で分からないところはあるか？

>>95
要するに並列処理の場合でしょ。
ちょいややこしいけど、処理のリストを2つ考えてそれを適当に混ぜて1つのリストにしてしまうものを考える。
処理A : abcdef
処理B : ABCDEF
混ぜたやつ : aAbBCcDdeEfF
そして混ざったやつを先頭から順に、
状態1 = a(状態0)
状態2 = A(状態1)
...
状態n = F(状態n-1)
のような感じに計算する。

>>99　>>87でわからないところは特にないです。
が、プログラム全体の構造がやっぱりいまいち理解できてないかな･･･

自分はハッカーと画家で言われてたようなLISPのきわめて高い生産性に興味があったんだがそれは>>9でいわれてるようなもので可能なものとはまったく異なるものなの？

LISPはプログラミング言語じゃありません

>>103
LISPがプログラミング言語って書いてあるのはどのへんですか？

>>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());
}

>>105　そうかくと手続き型と何もかわらんねぇ。

>>105
最後のifに対応するelseがないのはまずくない？
まぁ、 else loop(book); でもつければいいだけのことだけど。

>>66
レコード型で表現可能

関数型言語でオブジェクト指向はできるかどうか、という質問は非常に多いね。
関数型言語のスレには是非テンプレに入れておいてもらいたいな。

ステートマシンみたいな状態の保存必須の事を関数型言語でどうやって表現するの？
結局(setq hoge (func fuga))なの？

というか状態の保存って概念は関数型とか以前な話でFA?

>>109
普通に表現できる。
type StateMachine = Input -> (Output, StateMachine)
言い替えると、
「ステートマシンとは、Inputを引数に取って、Outputとステートマシンを返す関数である」
とする。

>>109
だから、チューリングマシンでできることはλ計算でできるんだって。
C言語やJavaのような代入型言語でできて関数型言語でできないことはないの。

保守性とか可読性とかまったく違うところ目指してる？

はい

関数型の利点
http://www.sampou.org/haskell/article/whyfp.html

代入型言語でプログラミングするなら、レジスタ、CPUキャッシュ、物理メモリの状態を
把握できるようになるべき。それをして初めて関数が多言語並みの厳密なプログラミングができるようになる。
代入型言語でプログラミングしてるやつはやってることがいい加減なくせにそのことにあまりにも無頓着すぎ。

>>115
> 代入型言語でプログラミングするなら、レジスタ、CPUキャッシュ、物理メモリの状態を
> 把握できるようになるべき。
それはアセンブリ言語やらC言語などの比較的低級言語の場合だけ。
高級なプログラミング言語では、そういった低レベルなことを忘れても良いように作られるべきなんだよね。

>>116
>高級なプログラミング言語では、そういった低レベルなことを忘れても良いように作られるべきなんだよね。

これはドキュンコーダー向けの愚民化コピーだろう。こんなの真に受けてどうするｗ

>>115
>関数が多言語並みの厳密なプログラミング

具体的にはどういう事?
「物理メモリの状態」というのも具体的に何を指しているの?

>>115
日本語でおｋ

http://www.sampou.org/haskell/article/whyfp.html
この文章では、説得力ゼロじゃんとか感じた無知蒙昧なオイラにだれかご教授いただけると幸いです。
ここに書いてあるメリットは、最近はC#でもJavaでもPerlでも容易かつスムーズにできると思うんですが。
high-orderはC#の匿名メソッドで。
遅延評価はデザインパターンで。
もちろん、シンタックスは、関数型のが美しいし、可読性もよいけど、
この文章からだと、そんな劇的に生産性が異なるほどとは、ぜんぜんピンときません。
自分でdynamic arrayのクラスを切って、それでLISPのmap関数やapplyに
ラムダ式を渡すような感じで匿名メソッド(クロージャっぽい機能もある)を
渡すように記述することで、極力foreachやforを使わないように書く癖がついてますし。
つまり、それらをデータ構造定義と数式で書き直したとしても、
大して違いはないようなやたらと宣言的に「見える」コーディングスタイルなわけなんですが。
状態云々とか、宗教じゃなくって、関数型言語だと、具体的に、どうしてこれよりも
ずっとソースコード量が減るのか、そこを教えて欲しいです。

>>117曰く、「俺は凄いコーダなんだぜ」

>>120
代入文って冗長でしょ？

冗長な代入文なんて、そもそも書いたりしませんよ。
LISPだって、ラムダ式が長くなりすぎなときは、
普通にdefunして、式をsymbolにbindするじゃないですか。
そういう風に式をブロック化することで可読性と再利用性と
デバッガビリティーが向上するからです。
ぼくがC#で代入文を使うときも、それとほとんど同じような感覚で使うんですよ。
つまり、長くなりすぎた式を、部分式に分割して、それに名前をつける目的で、
それを変数に代入する。
だから、結局、それをhaskellに置き換えたとしても結局、やはりその
代入文の右側にある式は、haskellの右側の式とほとんどおなじになっちゃうし、
haskellの左側にある関数名は、C#の変数宣言とほとんどおなじになってしまい、
ソースコードの見た目はほとんど変わらない。

C#とかだと変数の型宣言が必須だから、型推論してくれるHaskellと比べるとその分冗長になるとは思うが、
同じ物を同じようなやり方で書くのなら見た目がほとんど同じになるのは当然でしょう。

型推論自体は、関数型言語とは関係ないですよね。
だって、手続き型なのに型推論機能のついている言語はありますよね。
Pythonとか。
C#の次のバージョンからは、型推論機能も少しは入るらしいし。
「同じものを同じようなやり方で書く」と言っているのではなく、
「より少ないソースコード量やシンプルな表現で記述しようとするにも関わらず、
避けがたい結果として、同じようなソースコード量や表現になってしまう」
ことを問題としています。

関数型言語なら短くなる、じゃなくて、
lisp的なマクロがある言語なら短く書ける、じゃねーの？

短さならPerl最強

実感値としては、中規模以上のプログラムだと、
「短さならPerl最強」は完全に間違いだと思う。
「lisp的なマクロがある言語なら短く書ける」は結構
実質的には当たっているが、関数型言語の話とは関係ない。
だって、LISPマクロと同等の機能を手続き型言語に入れれば
それで済んじゃう話だもん。

.NETで使える関数型ってあるの？

Pythonは動的型付けであって、型推論ではないでしょ。

純粋関数型＋変数への代入機能(状態保存機能)＝手続き型
っていう認識でおｋ？

>>128
それを言っちゃおしまい。

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

でも、ほいほい何でもかんでも入れちゃうのは文法とかの整合性が取れなくなったりしてまずいと思う。

>.NETで使える関数型ってあるの？
つ http://d.hatena.ne.jp/akiramei/20040305
Haskell、もStandardMLも、LISPもありますよ。

>>131たぶんおｋ

>>134
でたらめ言うな。

関数型ってのは関数に値を渡して返ってきた値をまた他の関数へ渡す。このようなスタイルでプログラムを書いていく言語を関数型と言って，代入はあまり使われない。

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

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

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

ただ，設計の目的が異なるため関数型ように設計された言語は関数型のプログラムを書き易い。

C 言語だとカリー化とかがなぁ。
こんな風にゴリ押しできないこともないみたいだけど、
何だかなぁ。

ttp://nicosia.is.s.u-tokyo.ac.jp/pub/essay/hagiya/h/curry

ﾊｷﾞﾔ先生って今のC++についてはどう思ってるんだろ

カリー化もそうだが、ラムダはもっと深刻かも。
GCC の内部関数を利用すれば、
近い事はできなくもないが・・・。

boost:lambda も面白いな

>>136　純粋な関数がたって状態の管理どうするの？

>>141
>>110みたいにするのでは？

>>141　んー代入と何が違うのかわからん･･･orz

すべての処理を const への参照を取って const への参照を返す
って書き方にしたら、関数型言語っぽくなる？

状態を扱うときに代入スタイルと大差なくなるのは自然じゃないか？

>>145は>>143へのレス

>>144
「ほとんどすべての変数を const」 にすると相当それっぽくなる。

>>147
関数内部の一時的な自動変数もだめ？
もちろん副作用は起こさないようにして。

処理速度は関数型の方が速いの？
代入行わないからなんとなく速そうなんだけど。

>>149
の真ん中あたり
ttp://www.unixuser.org/~euske/doc/python/python-lisp-j.html

>>148
お遊びだから自分が満足できるだけやればいいんじゃない？
とりあえず for (int i = 0; i < 10; ++i) が禁止になるだけでも結構楽しいよ。

>>148
>関数内部の一時的な自動変数もだめ？
関数型の特徴(利点・欠点)はそういう小規模なレベルで特に顕著だと思う。

>>151
それくらいだと、末尾再帰の最適化を期待して書くのと
あんまり変わらないかな

(define true (lambda (x y) x)))
(define false (lambda (x y) y)))
(define if (lambda (x y z) (x y z)))

>>154
はいはい、λ式があれば条件分岐もできるってことね。

Smalltalkもifがないよね。

参照透明性(同じのを渡せばいつも同じ答えが返ってくる性質)が保たれていると，コンパイル時の最適化がしやすいから，速くできる。

その分，代入があるといつも同じ状況に応じ答えが違うから，コンパイル時にコードを書き換えたりするような最適化がしにくい。あまり速くできない。

巨大配列を扱うような数値計算って
純粋関数型で扱えるの？

>>158
苦手かもしれないけど、出来ないことはない。
基本的に、手続き型言語で表現できることは
(破壊的代入も含めて)純粋関数型言語でも表現できる。
例えばHaskellでは、普段使う変数は変更不可だし、普段使う関数に副作用はないけど、
効率よく変更可能な「変数もどき」や副作用つきの「関数もどき」がある。

>>159
なるほど。
やっぱそのあたりは
如何に純粋関数型言語と言えども
使えるようにはなってるんだ。
ただ、一工夫してあるということやね？

>>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を２次元化してください。

>>161
ttp://pggirls.asukaze.net/index.php?%B2%E8%C1%FC%2FHaskell%A4%BF%A4%F3

神さまありがとう
ぼくに友達をくれて

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

ありがとうぼくの友達
Haskell に会わせてくれて

Haskellたんはツンデレですか？

Haskell で射精した。

>>163
元ネタの悪党が友達ってのもすげぇ詩だよな

保守の都合でここにカメムシ置いときますね
　　　　　　 ,.
.._ 　 　　 / 　ﾌﾟ〜ﾝ
　 ＼　__,!
　　　 〕-`ｰ;、
　 」`;{ヾ￣.} l'_
　 _/~|　＼l　}=､
　　　<ヽ/ `i/　 ＼._
　　　 _)

何でカメムシなんだよ？

カメムシってなんとなくラムダに見えなくない？

岩手の喧嘩祭といえば、六尺褌一丁の男達が、神輿を担いでぶつかり合う、
勇壮な祭として、この地方に知られている。
祭のあと、男達は集会所に集まり、普段着に着替え、飲み合う。
六尺は、激しい祭でドロドロボロボロになるから、使い捨てで、ゴミとして出される。
俺はいつもそれが狙いだ。
捨てられている六尺の、できるだけ汚れてる奴を10数本ほど、
こっそりさらって家に持ち帰る。
そして、深夜、俺一人の祭が始まる。
俺はもう一度汚れた六尺のみ身に付け、部屋中にかっさらってきた六尺をばら撒き、
ウォーッと叫びながら、六尺の海の中を転げ回る。
汚れた六尺は、雄の臭いがムンムン強烈で、俺の性感を刺激する。
前袋の中のマラは、もうすでに痛いほど勃起している。
六尺の中に顔を埋める。臭ぇ。
汗臭、アンモニア臭や、股ぐら独特の酸っぱい臭を、胸一杯に吸い込む。溜まんねえ。
臭ぇぜ、ワッショイ！　雄野郎ワッショイ！と叫びながら、前袋ごとマラを扱く。
嗅ぎ比べ、一番雄臭がキツイやつを主食に選ぶ。
その六尺には、我慢汁の染みまでくっきりとあり、ツーンと臭って臭って堪らない。
その六尺を締めてた奴は、祭で一番威勢が良かった、五分刈りで髭の、40代の、
ガチムチ野郎だろうと、勝手に想像して、鼻と口に一番臭い部分を押し当て、
思いきり嗅ぎながら、ガチムチ野郎臭ぇぜ！俺が行かせてやるぜ！と絶叫し、
マラをいっそう激しく扱く。
他の六尺は、ミイラのように頭や身体に巻き付け、
ガチムチ野郎の六尺を口に銜えながら、ウオッ！ウオッ！と唸りながらマラを扱きまくる。
そろそろ限界だ。
俺は前袋からマラを引き出し、ガチムチ野郎の六尺の中に、思いっきり種付けする。
どうだ！気持良いか！俺も良いぜ！と叫びながら発射し続ける。
本当にガチムチ野郎を犯してる気分で、ムチャクチャ気持ち良い。
ガチムチ野郎の六尺は、俺の雄汁でベトベトに汚される。
ガチムチ野郎、貴様はもう俺のもんだぜ！
俺の祭が済んだあと、他の六尺とまとめて、ビニール袋に入れ押し入れにしまい込む。
また来年、祭で六尺を手に入れるまで、オカズに使う。
押し入れにはそんなビニール袋がいくつも仕舞ってあるんだぜ。

(´・ω・｀)誤爆


(´・ω・｀)ぶち殺すぞ

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　,,､ - ｰ― ｰ- ､
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ､- ' ~:::::::::　　　　;;;;;;;;　~''-､
　　　　　　　　　おいお前！　　　　　　　　　　　　　　　　　 , ''~;　; ;;;;;;;::::::::::::::::::::::;;;;;;;;;;;;　 ;;;;ヽ
　　　　　　　　　　　　　　　　　　　　　　　　 ,､　　　　　　　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､::,,,:::::;>'";;;;;::::: /､､;;;;／::￣::::::::::::::~":::ヽ''〈::/ ''" ,/　　　 /; |

今、lispを少し勉強したけど、たいして違いがわからん。
関数形式で表すだけで、やっていることは同じように感じる。

>>173
ははは、奇遇だな
俺もFortranとCの違いがわからないんだよー

俺もvbとjavaの違いが分からん

おらはC#とJavaの違いがわからん

俺はひまわりとなでしこの違いが分からん。

>>173
Common Lisp はマルチパラダイムな言語だからね。
違いを感じたいなら Scheme やった方が良いかと。

ネスカフェとマキシムの違いが分からんが、言語は処理系の違いにもうるさい（やかましいだけ）

もしかして、何を皮肉ってるか理解されてない？

>>180
もしかして、何を皮肉ってるか理解されてない？

みんな、きもちいいことしてる？

まあ、俺が言いたいことはだな、Python最高

Python は関数型と手続き型のいいとこ取り？

>>184
全然違う

>>185
お前が全然違う

pythonはなにげにぼくらの期待の星

ここで空気を読まずにHSP!HSP!HSP!

戯言を皮肉とは言いませんね。

関数型言語はたしかにアルゴリズムを簡潔に表現できる。
が、パフォーマンスを気にしてチューニングすると
プログラムが手続き型言語っぽくなってしまう。
機械語自体が手続き型言語だから。
ならはじめから手続き型言語でいいじゃんって思う今日このごろ。

ラムダ計算を効率よくできるラムダコンピュータを作ってください

>>190
それって disassemble とかして検証してるの?

完璧な処理系が作れることを前提とした言語

>>191
関数型言語の歴史＝如何にλ式を現行マシンで効果的にコンパイルするか

じゃないの。

>>194
関数型言語の歴史
ではなくて、
関数型言語の実装の歴史
でしょ。

>>184
それはRubyの話。

>>178
Schemeですか。
了解。

純粋じゃない関数的プログラミングについて書いてるいい本って何かない？
とりあえず onlisp は読んだ。

関数型言語と関数言語ってくべつして呼称すべきですよね？

>関数言語
はつみみです

関数言語って何ですか？

俺が最初にC言語の勉強をしたとき(もう15年以上前だけど)

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

と説明してあった本がありました。

>>202
晒しキボン

その基準で言うと、Haskellみたいなのが「関数言語」っつー事？

「C言語」と言ってる時点で駄目本決定。

>>202
つーことは関数型言語には現在の時刻を返す関数はないんだな？

確かに昔はそんな本がゴロゴロしていたな。

さすがに今はそんな本は見かけなくなった。
google で検索をかければ、それが嘘か本当かすぐ分かるもんな。
いい時代になったもんだ。

あるよ。
f(x) = x

>>205
void乙

作って分かるCプログラミングは隠れた名著

なんで「C言語」と言ったらダメなのか分からんのだが。

>>210
ほんとに隠れてるよな

>>211
BASIC言語
C#言語
C++言語
Pascal言語
Java言語
Javascript言語
FORTRAN言語
Perl言語
Ruby言語
Python言語
Lisp言語
OCaml言語
Haskell言語
Prolog言語

>>213
それと同じことだろ？
多少不恰好なだけであって、
そんなんでダメと言い切る理由が無い。

隠れて分かるCプログラミング

http://homepage3.nifty.com/catfood/up/src/up4748.txt
http://www.google.com/Top/Computers/Programming/Languages/

ここに出ている言語を、関数型と、手続き型に分類してください

>>216
「論理型」とかはどうすんのさ？

>216
一通り読んで言語名でないものは取り除けよ。
マークアップ言語もな。

>>214
誰も言ったらダメなんて言ってないんだが。

>>219 >>205
"C"だと短くて日本語の語感としてあわないからなんだろうな。

C言語って全く違和感がない。
当方、38歳。

私も違和感ない。
当方、21歳。

同じく違和感ない。
当方、27歳。

for文に違和感あり。
当方、20歳

さらにボケて

高子さん、晩ご飯はまだかいの

さきほどお召しになりましたでしょ。

Cってまだ経験無い
当方、37歳。

Cに満たない人も多いので油断は禁物でーす

中括弧{}だらけに違和感あり。
当方、32歳。

Lisper?

Delphian?

Haskeller?

実はコボラーだったりして。

こぼちゃんは手続き型？

世代が違うので分からん

コボルはデータ指向型という感じだなぁ。

>>236
データ指向型って何ですか？

ん〜なかなかイメージ湧きません。

SQLとか

>>238
データの集合に対する関係を構築してプログラムを作成するって感じ？

C#でのカリー化って、こんな感じでOK?
List<int> l1 = getList();
int x = calcX();
List<int> l2 = l1.map(delegate(int y){add(x,y);});
移植性もあるし、そんな複雑にもなってないというか。

>>240
言いたいことは分かるが、それを指してカリー化と言うのは誤用じゃないだろうか。

説明不足だな。
add(x)(y)という形でaddを使えるように定義するのがカリー化で、
>>240みたいなのは「関数の部分適用」というはず。

>>206
ねーよｗｗ

Concurrent Cleanにはあるが。

カリー化のカリーはハスケル・カリーのカリー
だからみんなHaskellをやるんだ！

とん汁作ってたら味付けが変になったんで
適当に香りの強めの香辛料がばがば入れてったら
カリー化した

ＶＢプログラマ　Ｃプログラマのお仕事
http://www.vb-c.net/

>>243
^^;

カリー化使ったコードは遅い。
スピードが要求されるアルゴリズムの計算では避けるのが普通。
カリー化とはそういうもの。
わざわざHaskellに乗り換えてまで使うほどの価値はない。

カリー化でうれしいのは

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

でスピード要求せずにコードの美しさを追求するならいいかもね。

Haskellって人にやさしいんじゃなくてコンパイラにやさしい言語なんじゃないかっておもた。

Haskellってほんとに使う人のことを考えて設計されてんのかな?
変数の名前付けとかインタプリタの対話性の難しさはきつい

せめてラムダ計算の何たるかを知ってから、関数型言語を語ってくれ。

>>252
λ計算が分からないと関数型言語を使っちゃいけないと?

使ってもいいけど語っちゃいかんだろな。

>>254
λ計算まじめにやってないから資格ないかぁ。
全ての計算がλ式で表わせるってのがλ計算?

まぁλ計算って何だといわれて答えられないから簡潔に教えてください。λ計算って何?

>>251
コンパイラにやさしいって事は無いんじゃないの。
コンパイル遅いらしいし、文法もかなり人間向きな感じ。

遅レスだが、ＣをＣ言語って呼ぶのは検索し辛いからだと思ってた…
考えてみりゃＣってWeb普及前からあるんだっけ。

お前が生まれる前からあるよ

>>255
・変数はλ式
・M,Nがそれぞれλ式なら(MN)もλ式
・xが変数でMがλ式なら(λx.M)もλ式

まぁ、興味があったら以下の本も読んでおくと良いよ（難易度は上から順、重要度は下から順）
・コンピュータサイエンス入門-論理とプログラム意味論
・計算論-計算可能性とラムダ計算
・The Lambda Calculus: Its Syntax and Semantics

アマ向きだなハスケルは
速度はまあいいから簡単にスッキリ記述できてバグも高度に少なく
保守も容易で持続可能な発展を見込める
ただし、言語自体理解するのに高度な知能を要求されるという矛盾も秘めている
頭はいいけど資産が無い奴向きかな？

使う分には知識はそんなに要らないよ。
使うための環境をそろえている、まさにその段階が現状なんだから、もう少し待たないとね。

　　　　　 　　　,､=＝-,.､ -- ､.. -- ､
　　　　　 　 　 　 ／　__／-‐｀:.:.:`~:.:.:.:.‐:｀ヽ
　　　　　　　　　 　,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| =＝､　ﾊ　　 |

λは単に基礎
ジェネリックを使ってどのように全体を構築するか考える方が大事

>>260
> まぁ、興味があったら以下の本も読んでおくと良いよ（難易度は上から順、重要度は下から順）
Barendregtが一番易しいということ？
あの電話帳を全部読むのはかなりの高難易度だと思うが。飛躍は少ないけど。

>>265
難易度は上から順　って言ったら、一番上に書いてあるのが一番易しいってことだろ・・

>>266
こういう場合高い方が上じゃね？

>>267
逆だとおも

「以下は、難度について昇順、重要度について降順」
これが言いたかった事か？

難易度順と言うと簡単な方から難しい方へ、
重要度順と言うと重要な方から重要じゃない方へ、
というイメージがある。

まぁ、そんなことはどうでもいいことだ。

>260は「重要度は下から順」を「一番下が一番重要」という意味で使っている。
これに基づけば、「難易度は上から順」は「一番上が一番難易」と解釈できる。

「一番難易」を「一番難」とみなすか「一番易」とみなすかが意見のわかれる
ところだな。

まあ、紛らわしい表現なのは確かだな。
長くなっても、曖昧さを無くした表現を採るべきだな。

自然言語だし、いいんじゃない？

コミュニケーションがとれればいいけどね。
とれてない以上、何とかした方が良さげ。

たとえば、時計回りを物理学では右回りというが、生物学では左回りだという。
常識的には時計回りは右回りだと思っている人が大半だろう。
新聞のような文章でも時計回りと右回りは同じ意味で使っているし、自然言語では社会通念としての「常識」というのが重要なのだろうね。
論文でもない限り、そんなに厳密にしなくてもいいじゃない。
どうでもいいけど。

で、その社会通念としての「常識」は
今回の場合存在するのか？

どうでもいいらしいのでスルー。

>>277
ムきになるなよ＾＾；

本題からそれるのが好きな方が多いみたいだね。

>>280
ムきになるなよ＾＾；

>>272
ああ何となくわかる、
おいらは話の流れ的に260が言わんとすることを「基礎を大事に考えてくれ」と言う前提があるものと解釈したので難易度が上からってのを
「難しく専門向けであり、興味を持つのはよいがあまりその立ち位置じゃ重要視しないでよいよ」の意味にとってしまったのだな。

うむ、ニュアンスが伝わりにくい文字だけの会話って難しいね。

こういうときこそ、仕様記述言語Zの出番だろ。

>>249
カリー化すると遅くなるのって、関数をコール回数が増えるから?
素人質問でｽﾏｿ。

もっと議論したまえ

　 　 　 　　　　　　,:::-､ 　 　 　　__
　　　　　　,,r 　　〈:::::::::） 　　　ｨ::::::ヽ
　 　 　　〃 　　,::::;r‐'´ 　 　 　 ヽ::ノ
　　　　,'::;' 　　/::/ 　__
　 　 　l:::l 　　ｌ::::ｌ　/:::::) 　 ,:::::､ 　ｊi
　　　　|::::ヽ　ｊ::::ｌ、ゝ‐′ 　ﾞ:;;:ﾉ　,j:l
　　　　}:::::::ヽ!::::::::ゝ、 <:::.ｧ ＿_ノ::;! 　
.　 　　{::::::::::::::::::::::::::::`='=‐'´:::::::::/
　　　　';::::::::::::ﾄ､::::::::::::::i＾i::::::::::::/
　 　 　 ｀ｰ--'　ヽ:::::::::::ｌ l;;;;::::ノ
　　　　　　　　　　`ｰ-"

【ラッキーコアラ】
このレスを見た人はコピペでもいいので
10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ
出世しまくるわ体の悪い所全部治るわでえらい事です。

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バイト。

他スレで、手続き型の言語が全てだと思い込んで○○言語最高とか偉そうに語っている
椰子を見ると、さぶいなと感じる今日このごろ。
たくさんの言語をマスターしているつもりなら、Schemeぐらいは勉強してほしい。

ラムダ計算ＡＢＣ
http://members.at.infoseek.co.jp/nbz/ref/lambda.html
を読んでみて思った素朴な疑問
足し算、かけ算みたいなfのネストを増やす方向の演算が出来るのはわかるけど、
引き算みたいなfのネストを減らす方向の演算はどうやってやるんだろう。

他にもやりかたはあるかもしれないけど、俺が知ってるのは以下のもの。

まず、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が計算できる。

>>289
Church numeric?

>>290
なるほど、cons,car,cdrを使うようなイメージか。
たしかにそれならできそう。
いきなり疑問が解決したよ、感謝！
>>291
だね。こういうのをチャーチ数っていうんだってはじめて知ったよ。

関数型ってλがらみの話をすることしかできない言語？
言語を使って何かをしようって感じがまったく感じられず
ひたすら式について語っているのしかみたことないんだけど。

>>293
こういうことをしてる人もいる。
ttp://www.geocities.jp/takascience/haskell/monadius_ja.html

現在の最新、最高の技術を使って、関数型(Lispとはいわない)マシンを
作ると、何か問題点があるのだろうか。

>>293
どんな言語も計算をするために使うものですよ。

ひたすらオブジェクトについて語っているだけの人も多いなあ。

Rのつくアレかな

関数型に理解を示せない奴はプログラマとして正味期限が来ている
アセンブリしかできないプログラマが今受けている視線と同じような物を
近い将来浴びる事になるだろう

>>294
＞Haskellでもどうにかゲームは作れるぞということは示せましたが、 実行してたら遅くなるとかいった、Haskellの仕組みをよく知らないと分からない問題はお手上げです。 もっともっとゲームを作りやすくする方法があるはず。 つぎは、みんなにまかせた！
とか書いてある、やはりリアルタイム応答の分野(ゲームぢゃないぞ)には向かないのかねぇ。

コンパイラの性能の問題じゃないの？
複数の演算装置を持つような構成に最適化するとなると関数型の方が楽になるかもよ

PS3の方向が成功すれば関数型でなけりゃゲームには無理とか言われるかもね

>>299
アセンブラ馬鹿にすんな

まぁその都度言語覚えればいいだろな。

言語習得難しくないし

>>302
しかできない事を馬鹿にしたのだが
アセンブリは馬鹿にしてないよ

自分に向けられた刃を、他の「大物」に向けられたものであるかのように
無理矢理ねじ曲げて解釈し、そこから相手をドン・キホーテ的に捉えてみせるのは
割とポピュラーな逃亡術の一つです :-)

example:○国人

ウリの主張に反対するのは世界平和に反対するも同然である。ニダ。

関数型とは人間にとってわかりにくい言語。
人間の頭の中は関数型ではない。

それはそうだけど、手続き型はもっと脳の把握から遠い気がする。

>>308
同感

>>308
異感

>>308
か・・快感 ♥

人間の頭の中は人の言葉尻から自分の頭の中の
都合の良い一群の言葉引き出して口の前に置いて
いるだけで、関数型でも手続き型でもなく、
唖然、呆然、論理型だ。

>>308　そーなの？
プログラムって処理の連続になるので手続き型のほうが自然かとおもた（というより関数型よくわかってない）んだが。

関数的プログラミングと手続的プログラミングのどっちか片方しかできない言語はうんこ。
逆にこのふたつを十分にサポートしているならコアがどっちかとか副作用を認めるかなんてのは些細な問題だろ。

人間の脳はニューロンの複合的な作用によるものだからそのどちらでもない

思考には副作用があるから関数型じゃなくね?

>>316
たとえば、表面的な作用からプログラミング言語の種類を判定できるか、君は。

頭が悪いまま議論めいたことがしたいからって
トンデモ抽象論に走らなくていいから＞そのへんの子

なんか同類スレに湧いてるやつがいるな

>>308
俺は関数型のプログラムの方が読みやすくて好き。
記述がアルゴリズムの意味そのものに近いから分かりやすい。
手続き型だとアルゴリズムを構築するような感じになるから、記述と意味が離れてしまっていて
内容を理解するのに苦労する。
関数型の楽さに慣れてしまうと、手続き型には戻れなくなる。

プログラム、と言われて、UIやらネットワークIOやらを思い浮かべるひとと、
自明でないアルゴリズムの実装を思い浮かべるひととの間で、話がかみ合ってない気がする。

.NETばかりやってるんだが、それと絡められる関数型言語ってないでしょうか?

>>322
よく知らんのだが、F#なんてどうよ。

主観的な話はどうでもいいよ

どうでもいいという主観が書くほど大事なこととは思えません ;-)

普段は C++ と Java とアセンブラで組み込みを少し。
それ以外の言語は Emacs Lisp と PHP と Perl。
な俺が仕事抜きで関数型言語を理解したいと思って来ましたよ。
Windows で遊べる処理系ってどれ？
できればサンプルが多い処理系の方がありがたいです。

Cygwin 入れりゃ大抵の処理系は使えると思うけど、
とりあえず GHC (Haskell) を勧めとこう。

>>326
>それ以外の言語は Emacs Lisp と PHP と Perl。
うえ、キモい

人は実際にやってみて手順を確認しながら自分のやってることの意味を理解するんだと思います＞＜
もしくは結果が出て初めて自分のやったことの意味を理解するんだと思います＞＜
最初に全ての意味を理解してから行動してる人なんていないと思います(>_<)
関数型言語が扱い難いのはそれなりに理由があるんだと思います＞＜

>>328
m9(^д^)ﾌﾟｷﾞｬｰ!!

Rの付くあの言語を入れないと、信者達に煽られちゃうよ！気をつけて！

という、Rの付くあの言語のスレで叩かれた>>331さんのコメントでした

なんてな

何故分かった！

Rython

RATFOR

RPG

小説全体を全部一つの文で書くのが関数型。
分かりにくいのは当然。

【手続き型小説】

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

【関数型小説】

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

じゃぁ処理済のジョブをジョブ郡から削除しすべてのジョブがなくなった場合はアラーとを出す処理は、
【手続き型】
ジョブ郡から処理済を列挙
その列挙したジョブ郡をジョブリストから削除。
ジョブリストが空ならアラート。
【関数型】
アラートは、ジョブリスト(この場合のジョブ郡-それは処理済のジョブで構成される−が削除されるもの）が空なら鳴る。

ってかんじ？

何の根拠もないのだけれど、
表層は論理型、深層は関数型のように思えるなぁ。

手続き型は資源の管理テーブルがしっかりないといけないから。
そんなもの脳の中にあるのかねぇ。

>>340
脳の構造はEBtみたいなリンク、グラフ構造になってると思われ。
リンクの繋ぎかえがあるからその部分は副作用と言える。

この世界は現時点の万物の状態から一瞬後の万物の状態を返す関数と言える。

ということは、この世界を呼び出して戻り値を使うスーパー世界があるかもしれないってことか

すまんが、この理解であってるんでしょうか?

関数型：C言語
手続き型：Pascal

つまり関数型が実践的で手続き型が教育向けって事です。

C言語は関数型じゃありません。
前提からして間違っています。

>>343
世界は再帰呼び出しだ
そのうちスタックオーバーフロｑあｓｗｒふぇｄｔｇｙふじこｌ；ｐ＠：

末尾再帰ならちゃんと最適化されて、オーバーフローしないかもしれないよ、とか。

そのうち例外吐きながらビッグクランチか

>>347
アセンブラやれ
スタック分かってん野か？

>>350
TMS9900とかNM1610とかで泣いた事あるだろ

関数型だろうが手続き型だろうが、ある程度高級な静的型の言語は
基本的な道具としてバリアントとパターンマッチと型推論を備えるべきだと思うがどうだろう。
この三つは手続き型のプログラミングでも役に立つし、ないととても不便だ。
いまのところ手続き型言語ではNemerleやmerdあたりにしか実装されてないようだが。

このへんをちゃんと備えた手続き型言語が出てきて初めて、関数型と手続き型のまともな比較ができるような気がする。

> このへんをちゃんと備えた手続き型言語
つ ML

MLは変数がデフォルトで変更不可だし、goto(やreturnやbreak)がないから手続き型というのは苦しいと思うが。
しかし、手続き型と関数型という区別は余り役に立たないような気がしてきた。
問題になるのはむしろ個々の言語機能、例えばGCがあるか、クロージャがあるか、バリアントがあるか、副作用があるか…だよな。

で、結局はいちばんつまらない「ライブラリが充実しているかどうか」に
落ち着くわけですよ。

あと日本語（文字コード）対応な。

そうなると関数型言語最強はErlang

>>357
オブジェクトごとにマジで通信するってのがいい。

ErLangとOCamlってどっちが実用的？

用途次第

並列計算やりたいならErlangが良いんじゃない？
型重視ならOCamlとかHaskellとかが良いと思う。

>>352
同意。俺の場合、開発ターゲットはC/C++だけなんだが、
それ用のデータ加工ツールには好きな言語使える。
で、大抵はスクリプト言語とかを使うんだが、
最近ちょっと OCaml や Haskell をかじったもんだから
パターンマッチ使いてえ（*ﾟ∀ﾟ)=3ﾑﾊｰ 状態になったりする。
あとやっぱデータ量が増えてくると速度が欲しくなるとか。

なので、正規表現とか多言語が楽ちんに扱えた上で
静的型付け＆型推論＆パターンマッチも便利、みたいな言語があれば
結構広まるような気がする。
手続きっぽく書いてもいいけど関数型だとより記述がすっきり、
みたいに使ってる人をだんだん関数型に染めてくみたいな。
（C++だとここが逆なんだよなあ）

関数型のスクリプト言語が切に欲しい。
Perlのように書きやすくて、Haskellのように考えやすい言語。

scheme?

>>364
静的な型がないと生きていかれません。

>>365
haskellもインタプリタあるんじゃないの？

副作用がある処理での、
関数型と手続き型のコードの違いを見てみたい。

>>366
あるけど、余りスクリプトっぽい書きやすさを指向した言語じゃないから、面倒な事が結構ある。
ロジックを実装してるうちはいいんだけど、printfやら正規表現やらディレクトリ操作なんかを始めると
途端にJavaっぽいコードを書くはめになる。

>>367
関数型のやりかたが知りたいなら、Monadiusのソースを見てればいいんじゃないかな

>>367
大して違わない。
http://ja.wikipedia.org/wiki/Hello_world

>>370
ちょっと少なすぎてよくわかんないな。
最低でも、比較、繰り返し、関数定義、関数呼び出しぐらいはほしいな。

/* 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

>>372
さんくす。

あー。Haskellよくわかんねーなー。
どこで区切って見ればいんだ？

>>367
いろんな言語の比較が見たいなら、ここ
ttp://shootout.alioth.debian.org/
とか、ここ
ttp://shinh.skr.jp/testsprite/
が参考になると思う。

>>363
関数型言語ユーザーのブログとか見ると、Rubyを使っている人が多い気がする。
関数型じゃないけど。

>>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)) }

とりあえず、普通？のインデントにしてみよう。
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))
}

俺はつねづね、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) })

>>378
ラムダ式は？

それはただの無名関数のことだろ。

378に従うとすると、C++も関数型言語として言える。……よな？
for_eachはあるしBoost.Lambdaもあるし。

>>377
>こうやって見ると、関数型の特徴がよくわからんｗ
だから>>370な訳だが。
手続き型っぽくかけるようにわざわざ構文糖を用意してるんだから似てるのは当然。

>>381
C++のその辺は、文字通り「関数型言語的に書くために生み出された道具」だと思う。
だから「378に従うとすると」という仮定は要らないんじゃないかな。

とはいえあくまでも現段階のそれらは「関数言語的に書ける」レベルであって、
細かいところではまだまだ同じようにはいかないところがあるのだろうけど。

>>378
集合と列はどう扱うの？

そういえば関数型言語では、

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

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

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

はどうやって扱うのが一般的なんだろう？
listと違って、data constructorが要素の値に依存する（multisetでないとして）
から話がややこしそうだ。

>>385
HaskellやOcamlでは二分探索木を使って実装されている。
木のデータ構築子は隠し、代わりに構築用の関数(emptyとinsert)をエクスポートして、
抽象型としてアクセスさせる。

>>386
まあそんなところか。
手続き型言語と同じってことで。

おそらくgraphも同様かな。ただgraphの場合、理論上は切断等を使って
構成的にdata型を定義できるはずだが。

手続き型と関数型が合わさって
さらに発展したものがオブジェクト指向だな。

いまさら関数型にこだわる必要も無いだろう。

オブジェクト指向を強制されないというだけでも関数型には価値がある。

>>388←何も知らない馬鹿

低学歴の香りがするよな

馬鹿という奴が（ｒｙって奴ですねｗ

ということにしたいのですね

>>393
当たり前だろ、ごみ野郎

【馬鹿という奴が馬鹿なんだ】
突きつけられた己のレベルを認めたくない人間が
現実逃避に用いるポピュラーなうっちゃり。
大抵は失敗して土俵に潰れるが、潰れたままヘラヘラ笑い続けるのが特徴。

>395
うるさい！ばかっていうやつがばかっていうやつがばかなんだぞ！

精神的に向上心のないものは、ばかだ

精神的でない向上心などあるものか

敗者とは始める前から諦めている者のことである。

「始めたら負けかなと思ってる」

歯医者。

なあ思ったんだけど、
関数の記述を 関数名(引数) じゃなくて (引数)関数名 にすれば
なんか日本語にとっても近くならないか？

マジレスすると
そんなことするよりオブジェクト指向にしちまえばいいんじゃないのか

日本語に近付けるなら、助詞が有効に使えないとな。

活用もできるようになるといいね。

ボケナス乙。

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

じゃぁなｗ

なんとなくたかひろくさいスレだな

_________Ｋ仲川について　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

C/C++＞＞＞＞(越えられない壁)＞＞＞Lisp＞＞＞＞(越えられない壁)＞＞＞Haskell

バグの生産性

C++ >>> Ada > PL/I

テキストでいいからエロゲー作ってくれ

DOS時代の探せばノベル系エロゲーあったかもしれない。

スクリプトインタプリタは関数型言語の得意分野ということになるかな。

いろいろ議論はあるけど、実用の際に一番ポイントになるのは↓になると思うよ


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

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


　　　　　

[email protected]
↑僕のメアドなんで痛メでも何でも送って楽しませてください
皆のメール待ってます

>402
func(func(func()))
（（（）関数）関数）関数

この場合、最初に入れ子の数を
予測して書かなければならない。
些細だが、気になる人は気になると思う。

>>417
そこで助詞の出番ですよ。

助詞表記
()を関数を関数を関数
ドット表記
().func.func.func

$stdoutに linesを puts

>>337-338素晴らしい。
今まで関数型志向設計の有意性と無為性を語ってきたが、これほどわかりやすく且つ特徴を捉えた例も説明も無く苦労してきた。

　　ミミ彡ﾐミﾐ彡彡ミミﾐﾐ
,,彡彡彡ミﾐﾐ彡彡彡彡彡彡
ﾐﾐ彡彡ﾞﾞﾞﾞﾞ""""""""ヾ彡彡彡
ミミ彡ﾞ　　　　　　　　　ﾐﾐ彡彡
ﾐミ彡ﾞ　＿　　　　＿ 　 ﾐﾐミ彡
ﾐミ彡 '´￣ヽ　　'´￣｀ ,|ミﾐ彡
ﾐﾐ彡　￣ﾟ￣'　〈￣ﾟ￣ .|ﾐミ彡
　彡|　　 　　|　　 　 　 |ﾐ彡
　彡|　　　´-し｀)　　／|ﾐ|ﾐ　　　／￣￣￣￣￣￣￣￣
　 ゞ|　 　　　､,!　　　　 |ソ　　＜　カンドーした！
　　　ヽ　'´￣￣￣`ﾉ /　　　　　＼＿＿＿＿＿＿＿＿
　　　 ,.|＼､　 　　' ／|､
￣￣| ｀＼.`──'´／ |￣￣｀
　　　 ＼　~＼,,／~　 /
　　　　　＼／▽＼／

天動説、地動説。

>>339　ｽ万が誰かこの理解が正しいのか教えてくれ

>>423
それは単なるデータ構造の違いというだけ。
関数型・手続き型の違いとはあまり関係ない。

>>424　よくわからんです（･ω･）

>>425
>【手続き型】
>ジョブ郡から処理済を列挙
これは配列を使うという意味でしょう？

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

配列を使うかリストを使うかというだけでしかなくて、関数型か手続き型かという意味の問題ではなくなっているんだよ。

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

>>426　
ん、データ構造はあまり気にしてなかったんですが。
手続き型でリストだろうが、マップだろうが。
そもそも手続き型と関数型の違いがあまり判っていないんですが、
猫であるの例を見て、それを実際の処理記述に当てはめるとこうなるのかと思って書いた次第です。
自分がここで聞きたいのは関数型での処理の記述がこんな風になるのかということですね。

寧ろこうか?
手続き型
列挙ジョブ群 = ジョブ群.列挙(処理済)
ジョブリスト.削除(列挙ジョブ群)
if (ジョブリスト.空) アラート()

関数型
ジョブ群から処理済を列挙したジョブ群を削除したジョブリストが空なら鳴らすアラート

>>429
概念的にはそんな感じだと思うけど、実際の関数型言語では、
両者の折衷形態で書かれるのが普通だと思う。

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

これだと高水準な手続き型言語と区別がつかないけど。

処理とは　アラートを鳴らす事が出来るならアラートを鳴らす
アラートを鳴らす事が出来るとは　残処理リスト が 空である
残処理リストとは　ジョブ群から 処理済みを列挙したジョブ群を 削除したものである

こうじゃないの？

>>429

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

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

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

>>431
Haskellっぽく書けばそうなるな。
>>430はML風ということで。
ついでにCleanっぽいのを書いてみる。

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

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

>>432
それは両方とも関数型だと思われ

>>432
ジョブ郡から終了したものを削除する処理とアラームなる処理は別だから。
＞関数型と手続き型の違いを知りたいなら、入出力の絡まない処理の方がわかりやすいと思う。
その例を是非

遅延評価の中の人がどうステップ踏んでるのか知りたい
やたら遅いのでなんか事故ってると思う

>>435
Haskellスレで質問してた人？
特定のコードが遅いならあっちで晒してみるといいかと。

>>415
おまいの脳内世界では関数型言語がLisp系しか存在しないってのがわかった

まあ、関数も変数だからな・・

関数型を勉強する者は蟻
手続き型で十分だと関数型を軽視する者はキリギリス

しかし、世界はキリギリス中心に動く。

>>440
そのフレーズいただいた
あとで俺がそのフレーズ朴った本出しても訴えるなよ

ｓｓ

なんつうか、アリとキリギリスが逆じゃねえ？

確かに。 Java プログラマがキリギリスだとは思えない。

うむ。逆だろw

蟻でもキリギリスでもない。糞ころがしだ。

数年前の関数型言語スレのコピペかよ。
クダラネェな。

なに興奮してんの？ｗ

> 2006/06/13(火) 14:59:13

　　　　　　　　　　　　↑ヒッキー発見ｗ

？

>>450
>449はきっと、平日昼間に書き込むのはヒッキーだと思い込みたいリアル厨かヒッキー予備軍なんだろ。

平日昼間に余裕で書き込める窓際社員(古w)のオレが来ましたよ

あこがれるっす

>>452
昼食時間もまともにとれない俺様が深夜帰宅途中に携帯カキコですがなにかorz

>>454
会社辞めさせてもらえないって本当?

無職透明な俺が456ゲット。

マ板でやれ

(f (f (f x)))
(((x f) f) f)
(x f (f (f)))
(((f) f) f x)

>>417

Smalltalkのブロックはそんな感じかも。

x ← [ [ [ ... ] value ] value ] value.
みたいな。
MacOSXで復活(?)したObjective-Cも近いんじゃないかね。

57 名前：デフォルトの名無しさん[] 投稿日：2006/02/16(木) 10:58:30
>>56 プログラム全体にわたっての型の整合性は
コンパイルが通った時点で保証されている、と信じたいから

という発言に対し、

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

と返す。
これがBoostスレクオリティ。

一応書いておくけど、その後フォロー入っているよ。
66デフォルトの名無しさんsage2006/02/16(木) 21:45:48
>>65
57の感覚自体はまともだと思うけど

こんな関係無いスレに言いつけに来るなよ57ｗ

自分の代わりに「敵」をやっつけてくれそうな猛者でも期待したのか？
残念だったなｗ

65乙

こんな関係無いスレに言いつけに来るなよ57ｗ

自分の代わりに「敵」をやっつけてくれそうな猛者でも期待したのか？
残念だったなｗ

>>460
ゴキブリはチョンＳＰさっさとゴミ箱に捨ててＮＤＳで知育ゲームでもやったら？

でないとおまえ本気で社会復帰できないよｗｗｗｗｗｗｗｗｗｗｗｗ

　　　　　　　　　　／∧　　　 ／∧
　　　　　　　　 ／　/ λ　 　／　/λ
　　　　　　　／　　/ /λ ／　　/ /λ
　　　　　 ／　　　/ / /λ　　 / / /λ
　　　　／　　　　　　　　 ￣￣　　　 　＼
　　　/　　　　　／￣＼　　　　　／￣＼＼
　　 /　　　　　 |　　 ●| 　　　　| 　　●|　 ヽ
　　|　　　　　　 し￣ヽJ　　　　 し ￣ヽJ　 　| 　　　　　　　　―→>>463
　 ｜　　　　　　　　 　 　　'"""　　　　　　 　 |
　　 ＼　　　　　　 　丶 ＿__人＿__ノ　　　 /
　　　　＼_　　　　　　　　ヽ―／　　　__／ ＜ うぷぷぷ
　　　　　／　　　　　　　　　￣　ヽヽ　　　＼
　　　　／

ひどいな
そんな気に障るようなレスだったのかね

まぁ57にとっては
気に障るなんてもんじゃなかったんだろうな。
こんなとこに泣きついてくるくらいだから。

>>468
いつまでも粘着してるお前の方がどうかと思うぞ

>プログラム全体にわたっての型の整合性は
>コンパイルが通った時点で保証されている、と信じたいから
OCamlではこれがあるから、実行時エラーが少なくてすむ。

いや、型周りに穴があるC++でそれを期待するのは間違いって話じゃないの？

見てきた。
違うみたいだな。
視野の狭い人間が偉そうにしてるって話か。
くだらん。

>>461
否定してるだろうが
よく読め馬鹿

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

>>472
どこをどう読めばそうなるのかなーwww
チョンは氏ね

あーあ泣き出しちゃったｗ

>>474
誤爆か？

>>475
頭がかわいそーな人ﾊｹｰﾝ

>>476
誤爆か？

Haskellが下火になってきたな
みんな飽きてきたらしい

まあ、アルゴリズム関連は処理速度が遅い、GUIも苦手と来れば使い道ないもんな。
一通りのことを勉強したらそれで終わりって感じ。

よーし、ついに Lisp 時代の到来だ

　　(　ﾟдﾟ)　 　　　　
＿(__つ/￣￣￣/＿
　　＼/　　　　/
　　　　￣￣￣

　　( ﾟдﾟ )
＿(__つ/￣￣￣/＿
　　＼/　　　　/
　　　　￣￣￣

もっと見てv

　　( ﾟдﾟ )
＿(__つ/￣￣￣/＿
　　＼/　　　　/
　　　　￣￣￣

　　(　ﾟдﾟ)　 　　　　
＿(__つ/￣￣￣/＿
　　＼/　　　　/
　　　　￣￣￣

見〜て〜よ〜ぉぉ！！！

>>417
括弧なくせばイイんじゃね？


それなんてFO…

>>402
BibTeX の bst ファイルは後置記法でそんな感じだなあ。
おもっくそ読みにくいよ。

>>402 >>417 >>485-486
Haskell の $ の逆で
行始からそれまでの式を
一発で括る記法作ったらどうよ

Dなら
arr.map((int n){return n * b;}).writefln();
とかできるが

infixl 1 %
(%) = flip ($)
main = [1..10] % map (*5) % print

>>488
感動した。Cもついにここまで来たか。

だからCじゃないって。

C -> C++ -> D

　　　　　　　　↑いまここ

「手続き型」も一種の「関数型」と見なしていいんですよね？

J - C++ for Haskeller
http://d.hatena.ne.jp/w_o/20061008#p1

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

クソワロタ

何が面白いんだ？

事実そのままやん
初心者には、面白く感じるんかね？

俺も初心者だけど、ワロタｗ

>>496
上級者はお前しかいないみたいだ。よかったな。

笑うのは puts("hello, world") のとこだけだろ

>>499
人に「ここで笑え」と指示するなんて、さすが上級者ですね＾＾

連想配列のくだりで腹を抱えて笑った俺は初心者。

>>500
存在しない「指示」を読み取っちゃうのは
コミュニケーションの初心者だな

>>502
行間を読めない人なんですね＾＾；

まぁ、無いものをあると言い張る時には便利な言葉だ＜行間

こうして「解釈の違い」に逃げていくのもお約束

>>504
と言えば勝った気になれるのもお約束＾＾

そんな不毛な話がしたいの？
上級者って忍耐強くて尊敬できますよ。

突然勝ち負けの概念を持ち出すと、
それにこだわってたのが自分だってバレちゃうよ。

>>506
自分も持ち出してるくせに、よく言うよ。

負け組乙

ｵﾏｲらいい歳こいて、子供みたいな喧嘩してるなあ、あはは

おっさん乙

ｺﾞﾙｧ!

年寄りは国の宝なんだから大事に扱えよ

国のお荷物が何を言っているんだか

お荷物はニートのお前だろｗ

よく考えたらそうだったｗｗｗｗ

チンボぶっ飛ばすぞお前ら。

何がモナドだ。

schemeで継続やっときゃいいんだよ。

型のない継続なんてダメダメ

今時LispやらSchemeやらが最高だと思ってるやつは時代遅れ

lispやschemeが流行り廃りに左右されるものだと思ってる奴は致命的

lispやschemeの問題点が見えないのは致命的。というか、無学。

>>520
その問題点は言語的な方か商業や政治的な方かで話がだいぶ違うわけであるが。

無学というからには、言語的なほうじゃないのか？

俺としては遅いぐらいしか問題点思いつかないけどな。

M式ってなんですか？

>>521
商業や政治的には、問題点云々以前の問題外だろｗ

思ったよりバカが多いな。

>>522
quote についてどう思う？

なんで急に「わかったふり」の一行レスばっかに(^_^;

そんなことはどうでもいい

誰も答えられないので、Lispはクズということですか。

そうだね、lispやschemeは結局クズっていう結論でいいと思うよ。
ハスケルとかもっとキャッチーな言語にうつつをぬかしておけばいいんじゃない？

>>530
その言い方だと、Haskellはクズじゃないと思っているみたいだけど、
うつつを抜かす、というのはどういう意味で言っているのかな。
別に批判的な意味で質問しているのではないけど。

>>531
俺は>>530じゃないが、たぶんお前は>>530を誤読していると思う。
もう一回読み直してみれ。

馬鹿に向かってそういう冷静なアドバイスをすると
噛み付かれるよ

と、すでに噛みついている狂犬くんでした

嫌味が解らないと2chは難しい

悪い意味でピュアな子には難しいな。

>531
Haskellを直接クズとは書かれていないが
「うつつを抜かす」で暗に否定してるだろ

クズな言語があるならクズじゃない言語もあるはずだが（相対的）
具体的にクズじゃない言語を言ってみて。

Rubyとか

>539
言語の基本的なところは良いんだけど
（まー他言語の良いトコ取りで悪いのも困るが）
開発者や周辺の人達の人格がおかしすぎるのが問題
RubyスレでMLについてのレスを見ればよく判る

まぁ、コミュニティにもともと学術関係者すくないですから。

一番の難点は宗教が絡んでいるところ。

>>542
は？

PythonがあればRubyはいらない

Pythonは現代的
Lispは時代遅れ

Pythonは実用的
Haskellは使い物にならない

PythonってLispのマクロに当たるもんあるの？
後遅いという話を聞いたとですが。

ないよ
遅いよ

んじゃ、ただの動的で使いやすい言語でしかない感じ？

> 使いやすい言語
重要じゃないですか

はい

Pythonみたいな文法の言語で
Lispマクロっぽいのって
やったらすごそうだなｗ

http://pc8.2ch.net/test/read.cgi/tech/1158259643/

>>552
良く知らんけど、Clean はマクロあるらしいよ。

>>542
自分の慣れ親しんだパラダイムの生産性が高く見えるというのは
確かにあるだろうな。
さらに厄介なのは、そのパラダイムがその人にとっては実際に
生産性が高い、ということがあるかも知れないという点だ。
こうなるとパラダイム間の比較はほとんど不可能だと思う。

>>554
ちょっと見た感じでは、マクロの引数から情報を取り出す手段がないので、
Lispのマクロのような使いかたはできないように感じた。

手続き型は関数のインターフェイスと実装の結びつきが曖昧。
関数型は関数のインターフェイスがそのままアルゴリズムに直結してる。
そんな印象。
どっちが分り易いかといえば関数型なんだけど、その分りやすさを
コーディングの段階で作り出せるかっていうとそれも難しい。
難しさがそのまま関数型の言語の扱い難さに直結してる。
そんな印象。

> 手続き型は関数のインターフェイスと実装の結びつきが曖昧。
> 関数型は関数のインターフェイスがそのままアルゴリズムに直結してる。
プログラム例を希望

何一つ有意義な意見もなく無事終了

図画工作発案設計工事完成論理関数手続機械

>>458 類型。
(+ (+ (+ 0))) (+ (+ 1)) (+ 2) 3
(((0 +) +) +) ((1 +) +) (2 +) 3
(0 + (+ (+))) (1 + (+)) (2 +) 3
(((+) +) + 0) ((+) + 1) (+ 2) 3

age age

a = b = 1;
は、関数(b = 1)の戻り値１がaに代入されると
考えてよいだろうか。

C++ で考えるなら、b = 1 の戻り値は b への参照だな。

糖衣構文と割り切るか…？

関数型を勉強したら、普通の言語でも次みたいに書くようになってしまいました。

string getCrSeparatedStr(string keyword) {
　return replaceSpaceWithCr(
　　trim(modifyConcatenatedSpacesToSingleSpace(
　　　modifySpaceWideToNarrow(
　　　　deleteSingleQuote(keyword)))));
}

>>565
キモっ

頼むから横幅2cm以上の関数は作ってくれるな

>>565
C++のOven Rangeみたいな書き方お勧め。
http://p-stade.sourceforge.net/oven/doc/html/#oven.introduction

右から読もうとして混乱した。

>>565
Rubyやってると、むしろこうなる

def getCrSeparatedStr(keyword) do
　keword.deleteSigleQuote.modifySpaceWideToNarrow.modifyConcatenatedSpacesToSingleSpace.trim.replaceSpaceWithCr
end

手続き型って頭悪いプログラマーを連想するな、このスレの C++ 信者とか

そりゃ、人数が多ければ、駄目な奴もその分多めになる。

だめな奴が居るからできる奴が輝くんじゃないか

>>571
手続き型を使っているプログラマーが頭が悪いのではなく、
頭が悪いプログラマーが手続き型を多く使っているだけ

頭の悪い奴は、関数型は使えないｗ

>>573
ちがう、できるやつ：だめなやつ＝２：８

2も居るのかうらやましいな･･･('A`)

関数型ド素人です。

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

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

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

っていうものです。関数型使いの方々が頭が良いということと関連するのかな、とも
感じました。

>>577　OCamlはゆるゆるです。

>>578
そうですか・・・。

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

自分の理解では、関数型は変数への破壊的代入が無いということが、手続き型で発生する問題
の大半を抑止できるということかと思ってます。手続き型はそれを防ぐために、変数のスコープを
できるだけ短くする、といった工夫が必要です。オブジェクト指向の最も重要な特徴も、データの
カプセル化なわけですが、関数型はそういった気遣いが無用ということなんでしょうか。

>>579
MLでは変数はデフォルトで変更不可。だから
let p = 5 in (巨大な式)
とあったら、pはずっと5であることが保証される。
ただ、MLは式が副作用を持つことを認めるので、
裏でこっそりグローバルな状態を書き換える関数なんかが定義できる。
この点で、副作用を禁止するHaskellなんかと比べると厳格でない。

>関数型はそういった気遣いが無用ということなんでしょうか。
たとえreadonlyでも実装を公開したら実装に依存されてしまう。
だからカプセル化が必要になることはあるし、そのための仕組みも提供されている。

関数型にも色々あるようなんですが、何がオススメでしょうか。

Schemeがお勧め

F#

>>295
ツール不足（というか全くない）。
でも関数型CPUと言えるものは製品としてあるよ。

志村〜日付日付!

>>1
こういう分類をする場合は、論理型も関数型に含めていいんだろうか?

Lispって関数型言語なのかな？
ちょっと勉強がてらに手元にあるEmacsLispを見てみよう


・・・何という手続きのかたまり

Lisp は手続き型言語に分類するのが普通だと思う。
中でも Emacs Lisp は手続き的なコードを書くのが一般的。

論理型言語は関数型とも全然違うでしょ。
どっちにも分類できない第三の勢力だけど、マイナーだから無視される。

論理型言語ってprologとかplannerとかその方面?
wikipediaからつながってる方向だとこういうのとプロセス代数なんかがうまく融合したら
(というかアクターとかはそっちからの考え方に近いのか?)、
テストやらモデル検査は楽になりそうだけど、なんつーか工業製品を作っているみたいな気分になってくる。
いや本来はそっちが目的なのかもしれないが。
アカデミックになると途端に専門用語が数学臭くなって、プログラミングの本来の楽しさみたいなのが消え失せるな。
プログラムではなく事象を記述するというか。まぁ数学的な面白さってのはあるんだろうけどね。

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

最近/.でこれみてからなんかこの辺のことを考える様になった…。
Forget Math to Become a Great Computer Scientist?
http://developers.slashdot.org/article.pl?sid=07/07/08/0547234

>>589
つ GHC, Concurrent Prolog

>>590
こういう気の利いた関数型はないね。

>>587
Lispのマルチパラダイムっぷりは、他の言語でいうとC++に一番近い気がする。

>>590
論理型っていうのは、関数型言語にちょっとだけ架構したものだが、
GHC (Guarded Horn Clauses) を見ると、
並列処理がこんなにも簡潔に表現できるものかと驚かされる。
この簡潔さばかりは関数型言語ではどう手を尽くしても届き得ない。

副作用がなければ並列処理は余裕

そんなイメージがあります

>>592
つうかC++のgeneric functionは、
思いっきりCLOSの影響を受けてる。

>>593
> 論理型っていうのは、関数型言語にちょっとだけ架構したものだが、

なことはない。

>>594
論理型はホーン節が思いっきり並列構造。
ホーン節への変換がキモ。

関数型言語が破壊的代入がないことにより、並行処理を実現するのが楽だってことを
どっかで見て、最近ちびちびと勉強している。

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

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

実際のところどうなの？

Software Transactional Memoryが、
二つの境界を無くそうとしています。

関数型言語での並行処理に使われる手法は手続き型言語のものと一緒(共有メモリ、メッセージ)だから、
関数型言語だからどうということはないはず
「破壊的代入による状態の管理を行う手法」に困難を感じてるなら、古典的な共有メモリ以外の情報共有の方法
(メッセージ渡しとかSTMとか)を調べる方が、関数型言語をやるよりも有益だと思う

>>598->>599
「プログラミングErlang」では何と言っているか確かめるのが上策。

>>599
ではそのメッセージ渡しやstmといった手法を取り入れやすいのが、関数型言語である
というわけではないのですか？

最近のErlang流行りは、
一昔前のデータフロー計算流行りを思い起こさせる。
Erlangがここまで生き延びるとは思わなかった。

理屈っぽい言語が多い中で、実務的実績があることが
大きいのだろうか。ハンブルグにいる人に調べてもらったら
ドイツでも通信系の企業では使われているらしい。北欧だけ
ではない。WEBなんかで調べても全然でてこないのだけれど。

Erlangは関数型なのに文法がPrologに似てるよね
文法に癖あるけど自分が触ってみた限りでは結構普通な感じで使いやすかったりする

(+) 相当が fun erlang:'+'/2 とか
お前はホントに関数型言語なのかと

多バイト文字を扱えないと、汎用言語には絶対なれないから、
どこかでErlangの方が折れて、仕様に取り込まなくてはなら
ないだろう。

結局、手続き型言語の利点っていうのはなんなんでしょうか？

手続きを扱うのが楽

時間軸を記述出来るのは大きい（場合もある）

>>607
手続きを記述できるということかな。それなら、手続きの利点はというと、
構成要素間に特に強い依存性がなくかけるということが多い。
手続き: p1;p2;p3 はp1,p2,p3のそれぞれの結果がどうであれ実行できる。
宣言型たとえばPrologだと
p :- p1,p2,p3. はp1が真かつp2が真かつp3が真の場合pが成立するというように、
各要素は手続きに較べて緊張関係にある。つまり、それぞれの出力に依存する。
手続きは遥に自由だ。

手続き型だって p1 で例外が出れば中断して例外処理に入るんで、 p2 や p3 が実行されるとは限らない。
Prolog で手続き的な述語が fail するのって例外送出するような状況だろうし、そこは大差ないと思うけど。

>>611
Prologの手続的解釈というのもあり、Prologは例としては適切でないのかな。
しかし、例外は例外だろうw

個々の手続き型言語にはいろいろ利点があるだろうが、手続き型言語全体に共通する利点なんて無い気がする
手続きを記述したり、処理を並べたりするのは関数型言語でも普通にできる

>>613
代入が機械語数ステートメントでできること、とかは?

>>614　Monadみたいなのは普通とは言わない

>>613　でした。逝ってくる･･･orz

>>615
どこが普通と違う？
Haskellならdoキーワードの後に文を並べるだけじゃないか

>>607
人口が多い。

Haskell って変数の値を変更できる状態にする際に
元の値を壊さないようコピーが発生するもんだと思ってるけど
その理解に間違いは無いのかな？

>>619
変数の値を変更できる状態にするって、iorefなんかのこと？
それなら、コピーは発生しないよ
iorefのじったいは、つうじょうのhaskellのデータひょうげん(もちろんこれはimmutable)をさす、mutableなポインタにすぎない
iorefにたいする代入が行われるときは、あたらしい あたいに たいおうする ひょうげんが あらたに つくられて、
ポインタが その あたらしい ひょうげんを さす ように へんこ?%a

>>619
Javaの文字列がなぜ変更できないか理解してるなら問題ない

>>620
なるほど。毎回値を作ってそれを参照してるだけなのね。

手続き型の利点は、ノイマン型アーキテクチャと親和性が高いこと。

手続き脳全開の俺は手続きをそのまま書ける事自体が利点

普通の、特にビジネス処理なんか考えるときはオブジェクト指向を含む手続き型の方が自然だよね。

>>625
ビジネス処理で手続き型が自然というか優位な理由を
教えてください。

お舞は何か仕事片付けるとき段取り付けてせえへんの？

流れ作業でやるので、関数型の方が適しています。

流れ作業「を」構築する仕事ならともかく、
（誰かが構築した）流れ作業「で」仕事をしている人間は、
関数型どころか、わずかな種類の手続きにしか慣れていない「退化した手続き型人間」だと思う。

だから「関数型言語は逐次処理が苦手」という前提が間違ってるんだって
逐次処理が苦手な関数型言語もあるかもしれんが、主流の(MLとかHaskell)はそうじゃない

>>630
確かにそうだけどさ。
筋の通らないことを堂々という人は
自分の側が勝って優越感味わいたいだけで
他の人の知識を吸収して和解を深めようとか
そういう気構えじゃないから完全無視でOkじゃね。

>>631
和解金が目的なんですね、わかります。

面白くないよ。

>>630
また、関数型からマルチパラダイム型になったcommon lispやschemeのようなものも
あるからね。common lispでマクロの扱いまでなれ出すと、なんでもありになってしまう。

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

手続き型やオブジェクト指向しいて破壊的操作が加わると、見えないところでの変化が
多すぎて、バグを見極めるのが面倒なんだよね。手続き型言語の方がREPLがより有効
そうなんだが、そうはなってないよね。

そもそも手続きprocedure≒関数functionだろ
普通は関数型って命令型imperativeと対比させると思う

関数型言語で自在にプログラム組めて、CPUアーキテクチャにも
そこそこ明るい人ー

関数型言語の考え方でCPU作れますか？

すでにある

まあ市販されてるとかそういうことじゃないが

具体的にはどんなん？

中央演算装置とはインタプリタのことだから・・・。

珍しくもない
ググれば普通に見つかる

> 関数型言語の考え方で
というのが何を意味してるかにもよるが

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

データフロープロセッサも関数型と関連がある
いわゆる普通のCPUにも研究成果は取り入れられている

まあ誰でも真っ先に考えるアイデアですな

データフローマシンだけでなく、
グラフリダクションマシンってのもあったな。

インテルでもやってるはずだ

以下は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);
}

>>646
そのままでいいんじゃね？
俺がHaskellで同じ関数を書くとしても多分似たようなコードになる

Functional Java
http://functionaljava.org/

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は年が終わったら次のメンバに代入してるだけ。表現をもうちょいうまく考える必要がありそう。

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じゃ無理だなやっぱ。

>>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ライブラリ用意されてるからそれで一発、が実際かも...。

sage忘れた...。
吊ってくる。

もしクロージャのあるなしで区別するとすれば、関数型言語は手続き型言語を包含してるでしょー。
余計なfeatureがあるかどうかくらいで、メリットデメリットというほどの違いはない。

Lisp系みたいななんでもありの関数型言語はそうかもしれないけど、
純粋な関数型言語はどうかなー

lispって関数型言語か？

「なんでもありの関数型言語」
では

手続き型言語に分類するのが普通だと思うけど。

マルチパラダイム言語っていう言葉を使うべきだと思う

>>658 だな

LispはLisp以外の何者でもなくLispの前にLisp無くLispの後にLisp無し

「それはどうかな？」




この命題はLisperが何十年に渡り挑み続け、
そして敗れていった・・・

じゃリスト型言語ってことで

もうリスト処理用言語でよくね？

別にCでも関数型プログラミングすることは出来る
Cでもオブジェクト指向が出来る、という話よりもはるかに自然に書ける
でもやらない　それは人間にとって不自然な書き方だから

クロージャが C で自然に書けるのか？

後学のために是非その自然な書き方で書いたソースを･･･

クロージャなんざ必要なローカル変数コピーして関数呼び出すだけじゃねえか

それは違うw

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の細かいことは忘れたけどまあ自然に書けるだろ

それでできることは分かってるが、
自然か・・・と言われると微妙だな・・・。

(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)
))
に相当することを自然に書いてくれ。

setq?
思いっきり副作用を用いたコーディングだな
どこが関数型なの、それ

関数型かどうかはともかく、Lispでクロージャを使えば普通にできるとこが、
Cで自然にできるか、という話の題材としては問題ないと思うが。

本来は"Cで自然に関数型プログラミングが書けるか"という問題だったろ
なんで変えるの？

そんなにピュアな関数型にこだわるなら、遅延評価をやってもらおうか？
「自然に」。

まるで子供の喧嘩だな
言語仕様として関数内関数もサポートしてないCで関数型の真似なんて
ネタもいいところなのは分かりきってるのに
そうムキになるなよ

>>669
なんか、昔ゲーム会社でみた、タスクシステムがデジャブ・・・

構造体中のポインタで間接呼び出ししてるだけだろ。
ごくあたりまえのテクニック。

評価を遅延するだけなら>>669のClosureでいいし
その結果を取っときたいならキャッシュするだけだろ
何か不自然になるところがあるか？

可能か不可能かではなく自然か不自然かだからな。
自然か不自然かは人によって判断基準の異なるいい加減なもの。
永遠に平行線だな。

>>669
そのクロージャー、区ロージャーとして呼ぶ所が増えるたびに関数本体を修正するの?(´・ω・｀)

関数型言語のユーザーのほとんどは
頭をひねくり回さないと書けないし理解できない言葉を使うことで
選民意識に浸っているかわいそうな人たち
必然的にそのコミュニティは宗教になる

Lispの真実
http://www.aoky.net/articles/leon_bambrick/lisp_truth.htm

そう思う奴は永遠に機械語使ってればいいんだよ
あれほど単純でわかりやすい言語は他にない

俺としてはlispよりhaskellの方がわかりやすいかな
lispは玄人好みすぎる…

分かりやすいプログラムを書くために通常プログラマは以下の様なことに気をつける

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

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

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

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

関数型のプログラマはこういった原則を無視しがちなので
彼らのプログラムは簡単に破綻する

>>682
仲間内では気のきいた文章ということになるのかもしれないが
こんなにくどいとユーモアの欠如を感じるな

>>685
手続き型言語の限界ゆえに主張される「わかりやすさ」をここで主張されてもなー

だいたい、再帰がわかりにくいとか言う奴は、帰納法はわからないからループで
書けとか数学者に文句付けるのかなーとか思う。

理屈倒れを指摘するために即席で理屈をこねる手続き型言語ユーザー
ということで

もともと再帰的な問題は、再帰で表現するのが一番自然で分かりやすい
が、単に副作用を避けるために迂遠な方法を取っているのならば、それは
自然で分かりやすいとはいえない

ネストが深いのが分かりにくいというのは
一文が長くなりすぎるといいたいことが分からなくなるということと同じで
単に人の脳が普遍的にもっている問題だ

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

プログラム言語の目的は
ある処理を人間にとって分かりやすく書き下すことであり
数学的にエレガントに書き下すことではないのだ
ループで書けるものをわざわざ再帰にして
リストみたいな不合理なデータ構造をcarとかcdrするなんてのは
頭がおかしいとしかいいようがない

lispだけが関数型じゃないよ
もっとhaskellとかMLとかにも批判くれよ

>>685
append([],X) -> X;
append([U|R],Y) -> [U|append(R,Y)].

再帰はわかりにくい?

>>692
分かりにくいし第一そのプログラム死ぬほど非効率だろう

確かnilとconsとeqとnullの公理を定義すれば
そこから帰納法でだけでappendとか導き出せるんだよね
そういう背景知ってるとこれ以上はないってぐらいわかりやすいと思う
俺も洗脳されてんだろうな

内包表記やdo-ec、foreachみたいなので書ける奴は
再帰で書くよりそっちで書いたほうが分かりやすい

あと、最適化のために末尾再帰に変形したコードは分かりにくい

高階関数万歳

>>694
ルールがシンプルなのがいいならforthや、それ以上にbrainf*ckがいいと
いえなければならないのでは
数字なんかもダサいので何でもチャーチ数で表現すればいいと思う

分かりやすいんだよね？それが

common lispやhaskellは手続き的なものも意識している
関数型だけでも手続き型だけでも駄目
俗に言うマルチパラダイムというやつ？
カオスにならない程度に色々できた方がいいんだよ

>>697
いや、そこそこ賢い人じゃないと
皮肉って痛々しいだけだから。

C++0x(C++)
scala(Java)
Python3000
Perl6

メジャーな手続き型の言語も関数型言語の要素を取り入れて進化していきます

>>690
> ネストが深いのが分かりにくいというのは
> 一文が長くなりすぎるといいたいことが分からなくなるということと同じで
> 単に人の脳が普遍的にもっている問題だ

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

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

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

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

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

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

単純な2分構造で全てが現せるリストを合理的と思えないのはどっかおかしい。

末尾再帰化とかCPSへの変換とか
人間様がやる仕事じゃないと思う

>>700
Python3000はPython3.0となりもうリリースされたが
Python3.0で新たに取り入れられた関数型言語の要素は
何も無いように思う

強いて言えばレキシカルクロージャから自由変数を変更できるようになったが
関数型的には関係ないよねこれ

そうかpythonは何も知らないから適当に入れちゃったんだよごめんね
反省して鼠本買って勉強するよ

>>691
Haskellは、インタプリタに日本語が入力できなかったので速攻で萎えました。
自分は日本人なので、日本語ぐらい普通に使えて欲しいです。
普通に日本語ぐらい使えるようになったら、使ってみたいです。

OCamlを入れてみましたが、Strライブラリが大昔のUnixのregexライブラリのように
グローバル変数に依存（非スレッドセーフ、非リエントラント）しているので
萎えました。stringがmutableで、そのくせ別にBufferみたいなのもあるのも
萎えました。あと記法がキモいです。色々と。
標準のIOの抽象度が低く、文字列ストリームすらないのも萎えました。
モジュールの品揃えには片寄りがあり、Windows環境ではサードのモジュール
を入れるのも一苦労でした。

処理系やライブラリが未成熟なのも敬遠される要素だよなー
現状は趣味言語の域を出ないというのは信者も理解している筈

>697
構造が単純＝わかりやすいとは限らない
forthはわかりにくい
専用スレの状態見れば「わかりやすい」
b(rは論外

なんかキモいくらいに腐すやつと
キモいくらいに擁護するやつがいて、
総じてキモいスレ。

実際のところ、関数型プログラミングでも自身では再帰ってそう使わない気がする、全くとは言わないが。
現実で使っていると、それよりもリストにmapとかfoldとか
高階関数を使ってあれこれできるってのが醍醐味だと感じる。

map/reduceの類なら別にPerlだのRubyだのPythonだのでも使えるわけで

そんなものに大した価値はないと言いつつ盗んでいく
どこかで聞いたような話だな

でもそれらは関数型言語とは呼ばれない

ファーストクラスのレキシカルクロージャや便利な高階関数のようなものを
多くの言語がLispから盗んで普通にサポートしている中で、
それでも関数型言語の優位性を説こうというのなら、
「盗まれていない」部分の優位性を説得力を持って示せなければ意味は無いし、
誰も関数型言語を使おうとは思わないでしょう

そんなものに大した価値はないというような手続き脳の奴は、
PerlだのRubyだのPythonだのを使っていてもmapやfoldは使(わ|え)ない。

mapやfoldは、それが無ければ再帰的に書くようなパターンを抽象化した
ものだから、まぁ自然な流れだね。
mapやfoldをPerlだのRubyだのPythonだので使うような奴は、再帰も普通に使う。

>>713
ん？問題の焦点は「再帰」ではないでしょ？
再帰が出来なかったのなんて大昔のBASICだのCOBOLだのぐらいなもので
Cでさえ普通にできるものを「関数型言語の特徴」なんてまさか言わないよな？

俺もOCamlの一番のキモさは
＞stringがmutableで、そのくせ別にBufferみたいなのもあるのも萎えました。
これだと思っている。stringがchar listでもなくなんか独自な型なあたりがキモいと思いました。
でもわかりやすいし、Haskellみたいなインデント依存でもカッコだらけでもないあたりは好きです。
例外を気楽に簡単に使えるあたりもいいなと思いました。

あとOCamlのオブジェクト指向部分ってみんなバリバリ使ってるの？
あれ使う場合って代入しまくり、副作用ありまくりなスタイルになるかと思うんだけどどうなの？

あ、でもlablgtkはいいよね。
まさに手続き型だけどHaskellのgtk2hsよりはマシかな？って思ってる。

再帰に関しては、手続き脳だろうが二分探索やクイックソートを書けと
言われたら普通再帰を使う

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

強いて言えば、手続き脳のプログラマは、本質的なiterativeなprocess
は単にループで書き、わざわざ再帰で書こうとは考えない

手続き脳ってなに?
ゲーム脳みたいなの?

うん
こ

>>709
Haskellなんかは再帰よりfoldとかmapとか無限リスト使う文化があるような
末尾再帰にしても最適化しないらしいし…

つうか、foldとかmap自体が再起で実装されるだろ

日常的に、lisp、arc、scheme、haskell、scala　といった言語を利用されている方にお尋ねします。
どのような問題を解決されるときにそれらの言語でコードを書かれていますか。

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

どのような場面、用途でご利用されているのでしょうか。
今後、使いたい用途としてはどんな分野がありますか？

C#でもmapは使うけどfoldはあまり使わんね
式にして関数の引数に入れられるようにするより
foreachと副作用で書く

関数型のプログラマはたとえば
「預金残高が1000円減った」というような場合でも
副作用は使わずに新しくオブジェクトを作るわけ？

>>723
個人的には、どんどんとオブジェクトを作って使い捨てていくのが
関数型言語での書き方だと思ってるよ

HaskellのStateモナドも、要するに状態オブジェクトを新しくどんどん生成して
持ち回っていって計算をするというモデルだよね

でもHaskellで実際何か作るときは、処理効率、実際のタスクがもとからIO処理であるなどの理由より
状態を考えるとき
StateモナドではなくReaderモナドとIORefを組み合わせて副作用的なプログラミングをすることも多いと思う。
まあ「そんなの邪道」って人もいるに間違いないが。

Haskellで実際何か書く奴なんていないだろ

wwwww

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

>>727
> その「預金残高」オブジェクトのデータ構造とか、サイズ、更新頻度とかを考えて副作用的にするか
> オジェクトをコピーして持ちまわす形にするか決めるんじゃないか？

手続き型でも、別の口座への入金との一貫性を保つためにトランザクションとか
やりだしたら、単に変数を書き換えるだけじゃ済まないし。結局似たようなもんだよね。

御舞ら的にソフトウェアトランザクショナルメモリってどうよ?

>>721
それは関係ない
普段のコーディングではあまり手で再帰を書かない、再帰を意識しないって話だろ

たとえばツリーについて何か処理をしようとしたら
再帰で書かないと結構厄介なことになるよねえ

対象になるデータが再帰的構造の場合は再帰を使うね。
手続き型であまり再帰を使わないというのは、そういう
データ構造を扱うプログラミングの頻度が低いという事
もあるのではないか。

だね。
まぁそういったトラバースも関数に落としてくので再起関数を定義すること自体は減ってくと思うけど。

Compositeパターンで書かないと厄介なことにー

arrowとか使えば綺麗にかけるかも

関数型やってて仕事でもプログラマやってる人って
仕事が苦痛になったりしないですか？
仕事は仕事と割り切ってる？

ここのところの流れ、どの主張もそんなに違和感はないんだけど、
源流になってる>>685の 3.だけは間違ってると思うね。

>>736
仕事ってなに？
俺は研究するのが仕事なんだが。

>>736
COBOLプログラマが家に帰ったらHaskellやってるようなケースかい?

>>738
それなら問題はないでしょうね
>>739
そうそう

バイトでCOBOLのプログラム書いたこともあったな・・
そんな俺はニート

>>739
私は違うけれど、COBOLのプログラマ人口から考えると、
相当な数いるだろうね。

>>742
300人。
「ふつうの・・・」を読んで家で勉強したCOBOLプログラマの予想数。

仕事で使うCOBOLが嫌で趣味でprologとかlispとかやってたCOBOLerは相当居たと思う

>>743
COBOLプログラマが日本に30万人いるとすると、1000人にひとり。
少し少なすぎる気がするが・・・。ところで「ふつうの・・・」は
何部くらい出ているんだろう。

>>744
COBOLで書かれたPrologってないのかな。WEB検索では出てこないけど。
これがあるかないかで全く違いますね。モチベーションが。

最初のPrologはFORTRANで書かれたという故事ならあります。

COBOLは他の言語が作れるほど自由な言語じゃないだろ

>>748
実行環境の縛りが尋常でないというのなら解るが、REDEFINES句　OCCURS句を
用いてデータ部にスタックを取れば、他の言語とそれほど差がないのではないか。
再帰は書けないけど。

チューリング完全なら他の言語が書けないと言うこともないだろう

まずprologやlispでprologからcobolのコードを吐くコンパイラを作ります
次に入力されたprologのコードをそのコンパイラに渡し、それから返ってきたコードを実行するCOBOLのプログラムを書きます
以上でprologのコードをCOBOL処理系で実行する処理系が完成されました

>>751
> lispで

なぜw

ACCEPT からちょっと実行したいという程度のものなら、Prologより
Lispの方がずっと簡単に実現できる。>>752へのレスではないが。

googleでは出てこないが、
COBOLで書かれたLISP
LISPで書かれたCOBOL
これはどちらもあるだろう。

↑↑馬鹿だろ

関数型言語のユーザーはウインドウに描画するたびに新しいウインドウを作るわけ？

プログラミング言語は一通りやったけど、
やっぱりHSPが一番しっくりくる。

今はOSもHSPで自作したものを使ってるし、
HSPのポテンシャルは図りしれない。

>>756
Haskellとかはモナドに入れて遅延評価するだけだよ。
モナドがない言語なら副作用を使うかもしれないね。

>>758
画像がアニメーションしたらその都度モナドで皮をかぶせていくわけ？
あっという間にメモリが足りなくなるだろ

そもそも現実のモデルが副作用有りまくりなんだから。

>>759
無限リストは無限に皮をかぶったモナドだが、なぜ無限のメモリがないのに処理できるんだ？

遅延評価をもっと勉強して来い

>>761
そりゃその都度値を作ってるからだ
アニメーションにおいてその都度画像を作るのでないならば
皮をかぶせるしかないだろ

関数型言語で作られたマルチメディア系プログラムを読んでみると
副作用ばかりでがっかりするのはよくあること

>>764
Haskell以外の言語だろ。
原始的なモナドも遅延評価もない関数型言語。

そりゃHaskellでマルチメディア系プログラムを書くのは不可能だからな
Cleanなら出来るのか知らんが

Haskellでマルチメディア系プログラムを出力するプログラムを書けるよ
という理屈があってだな

汚れ仕事は素直にCで書けばいいんだよ
そういう意味では、役割分担が容易でグルーとして使いやすい言語が
実用的だと思ってる
Pythonとかな（関数型じゃないけど）

よく知らないことについて自信満々にレスするのはやめようぜ

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

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

>>766
Unlambdaか何かと勘違いしてないか

Haskellで書かれたウインドウは値を書き換えることなしに
どうやって描画命令を実行するわけ？

>>770
ふつうにWin32APIなりXlibなりを呼ぶだけ

ウィンドウすら扱えないようでは
Hello, world! すら作れんぞ。

>>771
1024x768x32BPPのDIBSectionを作って
得られた配列に、1pixel単位で描画してblitしたいのですが
Haskellでどうやるのでしょうか＞＜

Haskell は副作用のある処理を、
その処理の方法自体を戻り値とすることで、
方法は常に同じだよね、という理屈で
副作用が無いとか言ってんじゃなかったっけ。

>>771
じゃあ質問を変えると
HaskellでWin32 APIのようなウインドウシステムを
どうやって作るわけ？

>>773
Cでやるのと全く同じようにやればおｋ
1pixel単位での描画は、生のメモリにバイト単位で書き込む関数が用意されてるから、それを使う
Cでポインタに添字アクセスするのと同じね

>>774
そんな感じ

Java でどうやって作るんだろう

>>775
もうhaskell勉強してこいよ。
そのほうがいちいち質問するより早い。

>>776
ありがとうございます

ポインタアクセスが出来るのですか？
それはすごいかも……
意外とHaskellは黒いですね＞＜

参照されている値を書き換えたら参照透過性が崩れるだろ
書き換えた生のメモリはHaskellからは二度と参照されないわけ？

Haskell のイメージ

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

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

そんな感じ。

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

そもそもどうやって参照透過なまま入出力をやってるのか、というとIOモナドを使ってる
これについて一言では説明できんので、Haskellを勉強するか、どこかうまい説明をしてるサイトでも探してくれ

>>766
つttp://jp.youtube.com/watch?v=eLS6GHXWMpA&feature=related
つttp://jp.youtube.com/watch?v=zqFgQiPKtOI

小細工して副作用をIOモナドに押し付けてんのかもしれないが、
結局プログラムの書き方が大きく変わるわけではないのなら、
どんな利点があるんだ？

>>780
getCharの値は？と聞かれたらいつも「何を入力するかは人それぞれ」と答える
いつも同じ答えなので参照透明です

>>784
コンパイラの最適化器は間違いなく大きな恩恵を受けてる
結果が使われてない式は問答無用で削除できるし、共通部分式の括り出しも自由だし、
評価順序も都合の良いように入れ替えられる

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

>結局プログラムの書き方が大きく変わるわけではないのなら、
逐次的な要素の強い処理(>>773みたいな)を書くときには手続き型っぽい書き方をするってだけで
入出力が絡まない処理だと結構書き方も変わると思う

モナドのやってることは次の行でしか使われない変数を
次々に新しく作って返すってだけだろ

しかし画像は書き換えられなきゃならないし取っとかなきゃならないんだから
Haskellでは書けんだろ

どうせGCが裏で副作用だらけの処理をしてるんだから
副作用を完全に隠蔽したうえで入出力を行うことは可能だろ

>>787
全然違う

とりあえずモナドとIOモナドを区別しようぜ
どうでもいいがIO型のことをわざわざIO「モナド」と呼ぶのは紛らわしいだけだと思う

画像を取っておくことすらできないなら
Hello, world! も作れない事に
いい加減気付いて欲しい。
Hello, world! が作れるんだから
画像を取っておくこともできてもおかしくはない。

>>787
まあものすごく大雑把な説明をすると、
画像というデータを直接叩くわけではなくて、
「画像を操作する命令列」をいじっているだけ。
命令列自体は参照透明な値と思える、ってことだ

なんかようわからんけど
ハスケルって使いづらいんだな

手続き脳の俺には勉強になるなぁ

参照透明っていっても、
HaskellでGUIのアプリとか作るときにやることは手続き型の言語と何ら変わらんよ。
純粋に関数的に使えるhaskell用のGUIツールキットとかもあるようだけど、実験的だったり普及皆無とか。
ためしにgtk2hsとかwxHaskellとか見てみればわかる。

とりあえず、Haskellの処理系は副作用をバリバリに使うのでHaskellでは書けない
これはYes,No?

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

>>794
CだろうとなんだろうとHaskellよりはうまく出来るわ
なんたって値を書き換えられるからな

>>796
Haskellのゲームってだけで話題になるぐらいじゃダメだと思うんだ俺は
C/C++なら当たり前すぎるわけだからさ

>>797
じゃあこれより短いテトリスのプログラムをCで書いて。

OpenGLならサーバにコマンドをプッシュするだけだもんね
自分で描画してないじゃんﾌﾟﾌﾟ

>>795
釣るにももっと上手い釣り方があるだろ。

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

一部のHaskell狂信者が副作用ないからHaskellネ申とか言ってるけど副作用的にプログラミングすることは非常に多い。

>>799
別に短くねーだろ

JavaScriptだけど
http://www.geocities.jp/nanagyou/list.html

やっぱりCでうまく書けないんだねえ

「Cよりは短く書ける」ことが今時自慢になるとでも思ってるのかよ……

Cの本物のショートコーダーがどんなもんか知らんだろ
あれを短いと思ってるのが本物を知らん証拠だ

>>801
コンパイラじゃなくて処理系だっての
とりあえず副作用のあるAPI関数をHaskellから呼び出すのはどうやるんだ？

LispみたいにFFIを通すんでしょ

>>806
黙ってgtk2hsのサンプルでも読めよ。

僕のチンコもモナドの皮をかぶっててCよりも短いのですが
使いづらいですか？

>>808
いいから教えろや

>>810
いいから教えてもらったもの読めや

「モナド」とか数学コンプっぽくてキモい
たかがhello worldを印字するだけのことで気取るなっつーの

んでもHaskellたんはゴム越しじゃなくて直接メモリ弄れるんですね
ちょっと見直しました

Haskellのオブジェクトのメモリは書き換えられねえんだろ
そんなもの書き換えられるとは言わんだろ

HaskellのInt配列を画像として表示する関数をうまいこと作ったとしよう
その画像の一部を書き換えたくなったら一々新しい配列作らなきゃならんのだろ

全然理解できてねえw
馬鹿に使えない言語w

>>812
たかがhello worldを印字するのにも副作用なんていうキモいトリックを使わなきゃならん言語よりはマシだと思う

いやいやキモくないでしょ
ノイマン型の計算機なんだから、メモリに書き込みたいときは正直にメモリに書き込む
言いたいことを、素直に直接的に言ってるだけ

ド汚い仕事を他人任せにして自分だけは手を汚してないフリなんかしない

アセンブリみたいに命令の羅列なら確かに正直だけど、Cなんかは代入や関数呼び出しが式じゃん
値を計算するふりをして陰で入出力やら破壊的更新やらするのは十分キモいと思う

なるほど、式と文をハッキリ区別してるPythonならいいわけだね

movみたいなアセンブラのニーモニックは許せて
関数は許せないってのはよくわからん感覚だな

>>816
だからさー、関数型言語っていうのは
関数っていう箱の中身がブラックボックスでも入力と出力の対がどうなってるのか知ってるだけで
部品として使えるのが便利なんじゃねーの。
箱の中で何やってるか考えなくてもいいのは明らかな長所だろ。

アセンブリ…命令と計算を区別する。言語から直接使えるのは命令だけで、計算したいときは命令を組み合わせる
Haskell…命令と計算を区別する。言語から直接使えるのは計算だけで、命令が必要なら計算によって組み立てる

C, Lisp etc…命令と計算を区別しない。キモい

>>820
いやだからさ、現実のプログラムは関数の豪勢による単なる値を計算するだけでなくて、その値を表示したり、他のものに渡したり、何らかの副作用を伴う作業を行うわけでしょ?
そこの値を計算するのに手続き型よりもすっきりかけるのはいいとしてもそのほかの部分をモナドに押しつけて僕は汚くありませんとか言っても何だかなという感じなんだが。
すまん、そこら辺勘違いしてるなら英語でもいいからここ読んどけというのを教えてたもれ

計算をきれいに行えたとしても、それを実際の入出力に割り当てて、それをうまいこと並列化できるの?

どこにあるとも知れぬHaskellからは参照できないビットマップを
処理系が裏でコソコソ作り出している副作用で書き換えて
「書き換えた結果はHaskellからは見えません。
どうしても見たければIOを使って読み出してください」
そんなクソ言語の分際で「画像を使うときは手続き型言語と同じだよね」って
同じなわけあるかボケが

>>821
キモいけど、ほどほどには快適なぬるま湯。

>>822
＞そこの値を計算するのに手続き型よりもすっきりかけるのはいいとしても
＞そのほかの部分をモナドに押しつけて僕は汚くありませんとか言っても何だかなという感じなんだが。

だからその変が嫌なら使わなきゃいいだけでしょ。
別に「Haskellは数学的にキレイだから他の低能言語とは違う」みたいに言ってるのは
ごく一部のHaskell狂信者だけだから。
ふつうの人は「ふーんこうやってモナドでくるんで使えばいいのね」みたいな感じで使ってる。

モナド自体には副作用をどうこうする力はないだろ
「この処理には副作用がある可能性があります」というラベルを貼れるだけで
で、実際の副作用は非Haskellで作られたなんらかの処理を
処理系が呼び出して発生させる
Haskell自体には副作用がある処理を記述する能力はない

>>827
まぁ、最終的にmain関数の返値のIOを処理するわけだからな

>>827
くだ巻いている暇あったら、SPJの論文でも読めばいいのに。

一見関係ありそうで関係ない論文を読まされる身にもなってみろ

>別に「Haskellは数学的にキレイだから他の低能言語とは違う」みたいに言ってるのは
>ごく一部のHaskell狂信者だけだから。
>ふつうの人は「ふーんこうやってモナドでくるんで使えばいいのね」みたいな感じで使ってる。

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

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

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

だと思うんだけど。

「わざわざ」Haskellって……ｗ
それも十分自虐に見えるな

「単に便利な道具だから使う」という選択肢は最初から眼中にないわけね
なら、実用には使われなくて当たり前だ

そりゃ不便だからな
ここの人なんか
ttp://www.shido.info/hs/haskell12.html

詰め碁で碁盤が書き換わるたびにIntMapを新しく作るような実装にして
「これでは遅すぎる」とか言ってるしな
あたりまえじゃねえか

ある関数に入出力やら副作用が絡んでるかどうかが、
型を見るだけで分かるってのは、なかなか嬉しいこと
だと思うけどね。

>>832
ん？
言語機能的にはCより遥かに便利だと思うが。

今どきの言語でCより機能が貧弱な言語なんてねぇって

>>831
もちろん綺麗だから使っているんだろうけど、

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

こういう「表層だけの理解」とか人のことを貶している奴をHaskell狂信者って言うんだよ。
あとその主義主張をやたら大声でわめいてる奴らとか。

まあ副作用のないMapは美しいなあとは思うよ
非効率だけど

再代入が無ければ遅延評価でなんとかなるんじゃね

更新するために既存の木を出来るだけ使って新しく組み立てるんだろ
良く知らんけど
俺の頭の中では一個付け加えた二分木を作るのにlogn回のノードのnewで済む

確かに平衡化で組み替えが必要か。

>>841
つ amortize
実際にそういうデータ構造のライブラリがある。

>>838
効率良いぞ。
っていうか、rubyのmapと一緒にすんなｗ

Haskellの良さはIOを完全に分離して考えれることだろ
IOに関わらない部分は頭の中で考えたロジックをほぼそのまま記述できる
でも現実的にはIO処理も大部分占めるけどHaskellでは効率も微妙だし書きづらい
まあそういうのためにFFIとかがあるわけで、要は全部Haskellで書いたり全部Cで書いたりしようとするのがナンセンス

分離ではなく、統一なんだが。

FFIとか泥臭い。
まぁ、HaskellのFFIはシンプルだが、それでもハイブリッドは美しくない。

>>844
「ロジック」とか言うけど結局それってプログラムの内容によるんじゃね
「IOの関わらないピュアなロジック」なんてのがどの程度の分量あるかどうか

テキストエディタだのゲームだのWebアプリだの、典型的なプログラムはむしろ
状態とIOの塊でしょ
ピュアなロジックを綺麗に記述できることよりも、状態を上手く扱えることが
求められるケースのほうがずっと多いんじゃないの

>>847
だから、ロジックとI/Oを分離してるんじゃなくて、統一してるんだって。
統一的に扱える枠組みとしてモナドを利用しているわけ。

erlangなんかはpi-calculusという考え方に基づいた統一の仕方をしているね。
haskellは圏論に基づいた統一をしている。
でもCはマシン語むき出しの原始人の言語。

>>843
mapは普通はハッシュテーブルで実装した方が速い
だがHaskellでは使えないに等しいだろ

碁盤を書き換えるなんてのは配列を使う以外考えられないケースだが
それもHaskellでは使えないに等しい
欠陥言語だな

>>850
CでもHaskellでも、列を一つの数字として表すのが普通だと思うよ。

Cだったら普通は碁盤を二次元配列にして
関数に入るときに碁石を置いて
関数から抜ける時に碁石を戻す

>>852
効率が悪い。

>>853
どこがだ
書き換えるたびに配列を一々作らなきゃならない欠陥言語と一緒にするなよ

>>854
まず、

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

一体何の言語の仕様を言っているの？ｗ

>>854
リバーシでも囲碁でもいいが、オープンソースで強いAIといわれている実装を見てみろよ。
データ構造に二次元配列を使って、一つの要素に1バイト以上も使っている実装なんて極少数だぞ。

HaskellのArrayだな
IOが付いてない方の

配列操作のほとんどは整数論的な最適化で実現可能。
配列が必要不可欠なアルゴリズムってほとんど思いつかないわ。

>>856
どれの話だ
まあ二次元配列より一次元配列を二次元のように使った方が速いから
一次元配列にする方が普通だが

>>848
IOと言ったのがまずかった
Stateを特別扱いしてる

>>858
たとえば英文を読んでa-Zまでの文字が何回現われたか調べる
これを配列を使って実装するのと使わないで実装するのじゃ
効率が1ケタ違うだろう

>>859
たとえばリバーシの場合、一つの石の状態を2ビットで表し、一列を16ビットであらわすんだよ。
で、状態を変化させるときは整数演算で行う。
そういう実装だよ。

そういうハードウェアベタベタの効率化を図るなら機械語に近い処理系でやらなければ
ならないのは自明。Haskellとか使おうというのが間違い。Haskellに文句をつけるのが
お門違い。適材適所。

>>862
Thellっていうリバーシのプログラム
http://sealsoft.jp/thell/#download
のspot/Board.hpp
というのを見れや
二次元配列になっとるぞ

http://d.hatena.ne.jp/tosik/20071115/1195120024

そのビットボードで強いAIってのはどこにあるんだよ
てか一気に2手以上指すわけでもなし
ビット演算するより普通に配列アクセスした方がはえーだろ

なんだこいつら・・
調べたらすぐに分かることを調べようともせず、無知を棚に上げて相手を批判することしか考えていない
ここじゃ議論の余地はないな

そうやって逃げてりゃ楽かも知らんけどね
関数型言語が非効率だってのは疑いようのない事実だ
連結リストや二分木がGCにどのくらい負荷をかけるか考えたことはあるかね

少なくともOCaml最強の事実は変わらないわけだが

OCamlでデバドラも書けるしロボットだって動かせるよ！

>>869
どの辺が最強なの？

>>868
だからなに？
スピード狂はGPGPUスレあたりでだんごとかいうクソコテと戯れてれば？

http://shootout.alioth.debian.org/gp4/
このランキン見ていたら、意外とHaskell(GHC)が上位に入っていてびっくりした

参照透明だからコンパイラが最適化しやすいんです＞＜
とか
並列計算で有利だお＞＜
とか言っても実際速くならないんじゃ意味ないよね

>>874
まぁ、お前ら一般ユーザーはそういう理解でいいよ（笑）

研究的価値ががあるなら研究者は集まってくるし、
研究者がいなくなるなら、それは将来的にもあまりいいものは出来そうにないってことだしな。
一般ユーザーは出来上がったものを使ってればいいよ。
10年ぐらい遅れたやつをねｗ

キモっ

現状だとHaskell使うのは速いからじゃなくて使いやすいからだからな

速いぞ？>>873

静的型言語でコンパイルして
さらに副作用まで使ってるのにこれしかいかねえんだから
全然早くねえんだよ

最適化のために全体を書き換えられるような小さなプログラムなら結構速いな
そうじゃなくてもボトルネックが明確で、そこだけ最適化すればいいプログラムとか
広く浅くの効率化が必要だと、最適化に手間ばかりかかってHaskellの利点を殺す感じがある

Haskellじゃ関数の奥のほうにボトルネックがあっても
そこだけ副作用使うとかそこだけCで書くとかできねえからな
どうしようもないね

できるけど

関数型言語の強みって、関数呼び出しのオーバヘッドが軽量ってことじゃないの？
Cなんかだと関数呼び出しが相当重いけど、関数型言語じゃ軽い軽い

>>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)))

>>881
そんな感じだよね
いろいろ考えていじりまわそうとすると面倒な事がどんどん出てきて、
最終的に「他の言語でやるのと大差無いじゃん」という結論に至る

>>228
魔法使いが現れた

それ約三年前

std::string<int> a = 3;

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

関数型はこれら文の意味づけを行う文法レベルで編纂していける言語っていう事かえ？

意味が分からんけど十中八九違うよ

面白いからコピペに使ってやんよ

あながち間違いでもないと言えなくはない。

ちょｗ

ちがｗ

>>888
つまり >>228 今 40 で、もし未だに C 未経験なら >>228 は妖精ということに…？

>895
Cは未経験でもC++もC#もObjective Cも何でもOKの猛者だったりして。

リアルに30杉て未経験なわけだが……

魔法使いうらやましす

なんでだよ。悲し杉るぞ、一生経験無いとか。

もうとっととソープにでも行ってこい

そういうことじゃないんだが

はあ、もう死にたい。
関数型とか手続き型とかどうでもいいや……

くだらねぇ

だが、ピアノが上手い

ほしゅ

>>904
算術？

急浮上

lambdaを使える言語なら関数プログラミング出来るので
わざわざ機能もライブラリも乏しい関数型言語使う意味はありません
マジで慣れれば最終的にクラスを全く使わずlambdaのみで（クラスよりも効率的に）やっていけるだろうと予想はしてるけど、
現時点、騒ぐほどすごい事はやってない
かえってオブジェクト指向に、中途半端に関数型の概念入れると
ソースがごっちゃごっちゃになる可能性もある
別にlambdaで出来る事の全てはクラスで出来るしね。効率？別に変わらない
かえって、lambda抜きで全てクラスでかいていくほうが統一性がある。やるならlambdaだけか、クラスだけか、にきっぱり分けるべき
とりあえず関数型言語の範囲の奴等が、再帰･マクロって言葉を特に頻繁に出してくるようになったら
何かが完成したと見て良い。
複数人でプログラム組むことを考えた場合、イロイロと完成していない関数型言語じゃやっていけない
OOのプログラム規則はだいぶまとまり始めているけど、関数型プログラミングにはそれが無い
自由すぎて人によってどんなコードをかいているかがわからないし、
人のレベルによって全然異質の関数型プログラミングのソースコードを書いていると思われる
だから「え？こんなのが関数プログラミング？」っていうのも関数プログラミングって呼ばれちゃうので、
関数型言語触っていない人から見ると、意味不明状態。「全然クラスでかけるじゃんｗｗｗｗ」っていう。
関数型プログラミングは、クラスではかけないソースコードのことを指すべきだということを常に思う。
似たような概念を2種類、世の中に放つ理由はないから。
つまり統一性が無さ過ぎる。その理由は、簡単。関数型プログラミングって概念が、まだ未完成の未完成。
ひとりでも、関数型プログラミングの究極にたどり着ければ、そこから一番効率のいい手法が広まっていく為、
「正しい・間違っている」を明確にできる

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

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

たとえ closure があっても return foo みたいに書かせる言語が
関数プログラミング出来ているとは感じられないね。

関数の返り値を使ってプログラムを構築するスタイルの言語が
関数型言語なのであって、lambda があるかどうかは二次的な話。

関数型と遅延評価は別か？

別。MLを関数型でないと言う奴はいないだろ。

>>910
> 関数の返り値を使ってプログラムを構築するスタイルの言語が

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

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

>>910
そんな時代遅れな関数型プログラミングやっててもしょうがないだろ
lambdaは関数型の一部としてみろよ
lambdaのない関数型言語の存在価値はゼロに等しい･･･

>>911
別
純粋な関数型言語との相性が良いだけで、関数型言語に必須という訳じゃない

>>910
関数を組み合わせるのであって、毎回返り値を使っている訳では無いよ
「あと一つ引数を取れば、値を返す関数」とかも普通に引数にしたり、返り値にしたりするし

うん、まあ理想を言えばバカでも使える言語がいいので
uy君の意見にももっともな点がある

uy君はLISP信者だから仕方ない

>>910
FPｷﾀｰ

MLしか知らんので、Haskellでは改善させているかもしれないが、
・丁度やりたい処理に合致した高階関数があればとても便利だが、
　なければ非常にめんどうになる。
・配列が使いにくい。もう少し糖衣構文がほしい。
・同型からなるレコードの場合は、map/foldが使いたい。

>>920
haskellで改善されてたかレポート希望

仮想的に時を超え将来入力されるであろう値が入ってるリストdeviceがあるとする。
このdeviceは(car (car device))というふうに関数を適用すると1つ目のデバイスから、
1回目の入力結果が得られる。(car (cdr (car device)))とすれば、2回目の入力が得られる。
このdeviceリストを1番最初に呼ばれる関数の引数に渡して処理をしていくとすると、
副作用の無い計算という事になるんだろうか？少なくとも最初の関数に渡されている時点で
値は決定されているという屁理屈なんだが。

>>922
Stream I/Oというものですね。
昔のHaskellはそのやり方でした。

F#って使ったことないんだけど、どんなもん？

Haskellの要素をちょっと加えて.NETで味付けしたおきゃむる

Haskellの要素ってComputationExpressionのこと？

.NETの機能が使えるから実運用で関数型使うにはいいんだろう
その場合は言語仕様よりライブラリの充実度だから

UIはC#で書いてデータモデルにはF#ってパターンはありだと思う

F#でXAMLライクな定義DSL書いてやったほうが幸せになれそうな気がしてきたよ(´д｀)ﾏﾏﾝ…

.netのデリゲート的な処理をどうやって副作用なしで実現するか気になる。
アレは戻り値が無いもんなぁ。

イベントが上がったら、何か状態を変更したりステートメントを実行したりとかの今ポピュラーなGUIスタイルのこと?
多分その辺はRxもしくはRx的なFRPの類で副作用的なものとその依存関係を隠ぺいするって形なんだろうねー
あーほんとにF#での宣言的なXAML&MVVMLikeのフレームワークとRxLikeとかつくったらかなり幸せになりそうな気がしてきたよ。
全部F#ですっきりかけそう。

まぁGUIのイベントもそうだけど、スレッドとかね。
スレッドなんて副作用無くしたら共有情報持てないんだから
どうなんのかすげぇ気になる。やっぱモナドなんかな。

モナドよりもモナコがいい

関数型と手続き型が合体した言語って無いの？

>>934
むしろ事実上そんなのばっかじゃん
どっち寄りかってだけで

>932
そのためのActorモデルでしょう。Rxとかも同様だけどね。
結局何かしらのデータやメッセージをそのコンテキストでシンクロナイズして処理すると。
STMやらなんやらよりもこのモデルのほうが可読性とかははるかに高いと思われ。FRPとも相性いいし。

Actorは副作用ありまくりですけども
今でいうところの並行モバイルエージェント計算みたいなもんなんで。

Erlangのreceiveがなんか関数型として納得いかん。

Process![値,値,値]　は、WinAPIのPostMessage(Process,値,値,値):みたいな感じだし、
receiveは、WndProcedureを言語機能で持ってるようなもんだし。
どこが関数的なのか教えてくれ。

関数型のメリットが理解できない
状態を追い出すことが目的になってムダに難解にしてる

>>939
それは手続き型に毒された視点から見てだろ。
状態自体は関数が持ってるし別に無い訳じゃない。

あと関数型は入力が同じである限り、
出力は同じ筈だ。一見入出力があるように見えても、
入出力は無い。なのでCの数学関数がOSに依存しないように
関数型の入出力を模した関数もOSや環境に(概念上)依存しない。

別に副作用あっても、Cの関数はOSに依存しないだろ。

>>939
自分も最初、そう思ってたから言うけど、関数型言語の方が素直に書ける場面の方が多いよ

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

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

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

上のは再起しか使ってないけど、他の場面でも、大抵そう考えれば作れる

近視眼的すぎないか
分割の概念はどうなってるの？

非純粋関数型の立ち位置がわからん

>>938みたいなレスあるけど結局純粋関数型だとスレッドとか非同期イベントってむりなん？

>>942
> 文字数を求める関数は「どう動くべき」か？
> 合計を求める関数は「どう動くべき」か？
>
> 関数型言語って、そう考えて作るもの

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

>>943
でも、関数型言語初心者はsumを再帰で書いて、次にfoldl or foldr書いて、さらに次にfoldl or foldrで書いて、productに進むのが良いと思う

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

>>946
じゃなくて手続きだとどう複数の文を書くかになるだろ。
ループの抜けかたがどうのとか変数の使い方がどうのとか。

>>946
再帰を使えばね
でも、手続き型だと普段は「どう動くべき」を考えたら、次に「どう実現するか」が間に入るでしょ

関数型言語にはそれが無い場面が多い

再帰ってスタック浪費してる

>>947
>>943
x さらに次にfoldl or foldrで書いて
o さらに次にfoldl or foldrでsum書いて

関数型にヒープの概念ってあるの？

>>950
組み込みのfoldl/foldrはスタック消費しないよね
でも、最初はそれでも再帰で書いた方が良いと思うんだ

再帰で書いて、次に末尾再帰に直して、、、

オブジェクト指向は手続き型からの正統な進化形だと思うけど
そこに関数型のメリットを追加するとすればどういう形になると思う？

>>954
末尾再帰は再帰でいくつか関数を作った方が良いと思う
高階関数を含めて、関数型言語の関数の概念に慣れてもらってからだと思う

>>955
高階関数
型推論(こっちは関数型言語ほど簡単にいかない気がする。動的言語には関係無いかもだけど)

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

手続き型と配列の相性が良いように、関数型とリストは相性が良い
文字列を表現する構造が違う限り、完全に関数型言語の特徴を取り込むのは無理な気がする

>>955
構造体ベースのクラスじゃなくリストベースのクラスになるかもよ。
メンバー変数(フィールド)の追加削除が自由自在。
それからパターンマッチが導入されるかもね。
オブジェクトの型じゃなく構成で呼ぶメソッドを変えられる。

どっちもC/C++ならいらないなぁ

今更気付いたけど、foldl/foldr/mapって、手続き型のループを抽象化してるのな

偉大な構造化定理は関数型で反映されてるの？

>>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

いまある関数型ってSmalltalk的なやり過ぎ感がある

最近は関数型言語発祥の機能を入れたマルチパラダイム言語が多いのでは?
有名所でもScala, Rubyなど。

狹い意味での関数型言語(>>963のいうやり過ぎ系が含まれると思われる)の
仕様、実装の数はイギリス人たちがHaskell大連合を作ったのでむしろ減ってるし、
こういうのは「やり過ぎ」じゃないと、研究する意味がない。

研究用ならいいんだけどね

参照透過性とか一部の数学的な性質は、ひとつでも例外があると壊れちゃうんで
Haskellがエクストリームなのはしょうがない。

>>964
Haskellがあるおかげで、研究的な別の仕様の言語とかはHaskellにはどうしても
導入できない機能の実験とかに限られてる感じだよね。

>>961
反映と言うか、普通に満たしてるし、入力出力が明確な分、下手な手続き型より忠実な気がする

混ぜるな危険

え？

最近C10K系のWebアプリが対象ドメインになっている言語で、
非同期処理の効率を追求するため、
関数型言語的要素を多く持つ言語が注目を浴びてる。(Erlang, Clojureなど)
こういうのは要求に迫られての仕様なんで仕方ない。

>>963
SICPの序文によると、Pascalは宣言的過ぎるからSchemeがベターだそうだ
そういう批判に対して
「Pascalは宣言的過ぎるんじゃなくて総称型の機能が足りないだけなんだからね！」
のような反応が返ってくることは想像に難くない

そこでDelphiですよ

参照透過性が目的ならテンプレートプログラミングのほうがよくね？

テンプレートでは実行時の参照局所性を保証できない。

え？

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

>>972
自滅さえしなければ良い選択肢だったんだがな

Simon saysっていうゲームあったよな

Haskellがやり過ぎって思うのは、「純粋」「非正格」みたいな宣伝文句に騙されてるんじゃね？
実際は、いわゆる関数的な記述を強制される訳じゃなくて、破壊的操作を伴うアルゴリズムとか普通に書ける
特に「純粋」な言語であることは、使ってみると意外なほどコーディングに影響しない

>>979
それは有るなー。。。
変な宣伝文句に踊らされ過ぎなんよね

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

デフォルトが非性格で、副作用もおまじないが必要って思えば、関数型言語の利点を最大限生かしてるだけで、ちゃんと普通の言語だと気づく

しかし、いまだに計算量の見積もりやスペースリークの回避に
悩んでしまう。

どう考えても構造化された手続き言語のほうが可読性高い

無理に使う必要ない。
英語読めないと>>976すら読めないんだし。

effective haskellみたいな本ないの？

effective haskell

第一章　メモリ管理

1項 サンクは早期に潰そう
2項 foldlの利用は避けよう
3項 使えるときは、必ずseqを使おう

イベントハンドリングやろうと思ったら殆ど副作用ナシでいけるんだな。
手続きよりむしろ簡単な気がする。

(defun EventLoop(widget handler input) (EventLoop (handler (car input) ) handler (cdr input) )
(EventLoop widget (lambda (event) 色々) input)
※終了条件が無いとかwidgetがひとつとかなのは面倒なので書いてない

ほとんど 気がする・・・

>>985 effectiveなら末尾再帰なfoldl(foldl')では

世の中にある多くのアルゴリズムは副作用ありの擬似言語で記述されてるんで
既存資産的には手続き型有利

foldr/foldl問題は、
対象とする列がリスト表現なのかどうか、
適用する演算子が右結合なのか、左結合なのか、
交換律が成りたつのかによって違い、
>>985のタイトルほど簡単には言えない。
これは関数型/手続き型関係ない。

Haskellだと使うのはfoldrかfoldl'で、foldlを使うべきケースって基本的に無いよ

なんで関数型風に擬似コード書かないのは何故？

関数型風の疑似コードって数式の事?

最近オブジェクト指向にはまってるんですけど、
関数型言語って、非オブジェクト指向ですよね？

今時、データと処理が分離してるなんて
ありえないんですけど、時代と逆行してるんですか？

データ即是処理、処理即是データ。

>>993
オブジェクト指向はメッセージってメソッドやら何らかの処理を
させさえすればいい。なので別にデータがオブジェクトと一体である必要は無い。
たまたまそういう実装が多いだけの話し。
海外のサイトで勉強しなおしたら？

海外のサイトｗ

洋モノ

>>993
どっちかと言うと関数型言語はデータと手続きが高次元で融合してる
関数もデータとして扱えるのは大きい

オブジェクト志向と比べて再利用性が高いのは本当

Cで関数型の機能実装してみれば組み込みでは使えないことがわかる

　　∧,,,∧　
　( 　・∀・)　1000ならジュースでも飲むか
　 (　　 　)　
　　し─J　

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。