関数型言語Part2

前スレ
http://pc.2ch.net/test/read.cgi/tech/987954395/

このスレッドの趣旨は
「関数型言語からRubyへステップアップ」
です。よろしくお願いします。

関連スレ

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

ＭＬ！！！！！！
http://pc.2ch.net/test/read.cgi/tech/1002111468/

LISP Scheme Part2
http://pc.2ch.net/test/read.cgi/tech/1002584344/

Emacs Lisp
http://pc.2ch.net/test/read.cgi/tech/1004551074/

再帰
http://pc.2ch.net/test/read.cgi/tech/992241842/

死んでください

つーか、おれにできるのはここまでだょ。
勝手にスレ立てしてごめんょ。魔が差したんだょ。
あとは任せたょ。

だからlispは関数型じゃねーって。

えっ？
一応はしりだろ。

このスレッドの趣旨は
「関数型言語からRubyへステップアップ」
です。よろしくお願いします。

恐らく流れはこんな感じだろ。

lispは破壊的なリスト操作をしなくてもプログラムが書ける。
↓
代入が無ければ見通しがいいかも。
↓
変数なんて捨てちまえ。
↓
ついでに副作用なんて捨てちまえ。
↓
作用的評価順序なんて捨てちまえ。
↓
最近カレーがﾝまい！
↓
haskellの誕生。

―――――このスレで一番痛いところは、
関数型をほんとに理解してるやつが居るのかどうか
怪しいという点だ(おれも含めて)―――――

>>6

ttp://www.cs.nott.ac.uk/~gmh/faq.html
comp.lang.functional FAQを読むと、SchemeやMLは一応「副作用も許す
のでpureではない関数型言語」という扱いになっている。Lispは論外だ
ね(副作用なしではループも書けないから)。

ところで、FAQだとHaskellも「広い意味での純関数型言語」となってい
る。I/Oがpureとは言いきれないから、らしい。

>I/Oがpureとは言いきれないから、らしい。
これはどこに書いてある？

Haskellは完全にpureだろ。

関数型言語の有用性は、関数型言語のプログラミング作法を、関数型でない言語で試してみるとよくわかるよね。
余計な一時変数を作らないようにしたり、再帰でプログラミングしたりといったことは、関数型言語でなくてもできる（速度的に不利だとしても、ボトルネックだとわかるまではそのままにしておける）。
やってみればデバッグが楽になることがわかるし、その問題への本質的な理解が深まることがわかるよな。

>>12-13
http://www.cs.nott.ac.uk/~gmh/faq.html#purity

＞Sometimes, the term "purely functional" is also used in
＞a broader sense to mean languages that might incorporate
＞computational effects, but without altering the notion of `function'

ここ訳してお願い

>>15
そこにはHaskellのI/Oメカニズムでは実行と評価が分かれてる
と書かれてると思うが、pureとはいい切れないなんて意味じゃな
いだろ？

＞Sometimes, the term "purely functional" is also used in
＞a broader sense to mean languages that might incorporate
＞computational effects, but without altering the notion of `function'

(直訳)
「関数」の概念は変えないが計算的な作用を組み入れた言語まで意味するよう
なもう少し広義で"純関数型"という用語を使うことがある。

(意訳)
「参照透明性」は壊さないまま、いわゆる副作用も扱える言語まで含めるよう
に、「純関数型」という用語を拡大解釈することがある。

(そういう拡大解釈をしなければHaskellは「純関数型」に含まれない。)

>>18
意訳のほうがめちゃめちゃ作為的にみえるんだけど。

In article >>16, 16 デフォルトの名無しさん wrote:
> > Sometimes, the term "purely functional" is also used in
> > a broader sense to mean languages that might incorporate
> > computational effects, but without altering the notion of `function'
> ここ訳してお願い

自動翻訳だと

「一般的な言語では"purely functional"という用語は計算結果を含む
より広義にも用いられる場合もある。」

ですね。

meanを動詞と解釈するのもWebにはあるけど、
ほんとのところはどうなんでしょ?
(「卑劣な, 下品な, さもしい, あさましい」だったり:)

（意訳）
一般には副作用と捕らえる事柄を、作用の概念のみを用いて表せるように
した言語を純関数型ということがある。

（Haskellは一般には副作用となるような言語すら副作用ではなく扱える
完全に純粋な関数型である）

>>21
それはコンピュータのアクションを扱わない言語が狭義の純関数型で
コンピュータのアクションも扱って、しかもそれが副作用では無い
言語が広義の純関数型と言ってるだけじゃないの？

それによるとHaskellは広義の純関数型だけど、完全に純粋ではない
と言うネガティブな意味ではなくて、純粋なくせに他より強力な
機能を持ってると言うポジティブな意味だと思う。

>「一般的な言語では"purely functional"という用語は計算結果を含む
>より広義にも用いられる場合もある。」

まあ良いけど「一般的な言語では」ってどうやったらそうなるのよ。

>meanを動詞と解釈するのもWebにはあるけど、
sense to mean を不定詞以外にどう解釈するんだ。

>一般には副作用と捕らえる事柄を、作用の概念のみを用いて表せるように
>した言語を純関数型ということがある。

「一般には」ってどっから湧いて出た？
effectって言葉は原文に1つしかないぞ？

>（Haskellは一般には副作用となるような言語すら副作用ではなく扱える
>完全に純粋な関数型である）

自動翻訳か？ 「言語すら扱える」って（藁

>>23
> まあ良いけど「一般的な言語では」ってどうやったらそうなるのよ。

Computatinal effectsって「一般的な」言語では副作用でしょ？

>>24
レスの仕方を間違えた。

> 「一般には」ってどっから湧いて出た？
> effectって言葉は原文に1つしかないぞ？

Computatinal effectsって「一般的な」言語では副作用でしょ？
「functionの意味を変えずに＝作用のみを用いて」でしょう。

>>22
Monadic I/O以前のHaskellはI/Oを扱っていたが狭義の
純関数型言語だったんじゃないか？
だからその「狭義」の解釈は違っている。

Hudak先生のお言葉:
Haskell -> lazy but pure
SML/NJ -> eager but dirty!

いつになったら抽象論から外れるんだろうか。

>>28
おまえに任せた

関数型言語の世界じゃ、識別子は短めがナウなヤングにバカウケなの？

不必要に具象的な識別子をつけるのは流行らないね。
抽象化できるかぎり抽象化するのが通のやり方。

数学界の悪しき慣習だね

why?

抽象化された関数を利用するときに具象的な実引数を渡せば良いだけではないの？
つまり、関数を利用する側では、具象的な識別子を使えばいいんだよ。
関数を定義するときはできるだけ抽象的な識別子を使う。
それが通の使い分け。

いみふめsage
f(g(Kusakabe_Yokaichi ))

>>33
通でもなんでもないだろ

少なくともJavaみたいのが良いとは､誰も思わないだろ?

　

識別子は長くも短くもできるんだからどうでもいいだろ。
つまらない議論ばかりだな。

どうでもいいか？
可読性からいっても、結構重要なことだと思うぞ。
実際JAVAなんて、打ち込んでるだけで嫌になるしな。

エディタに補完があればどうでもい

なければどうなんだ？

そういう環境・コーダはいずれ絶滅します

なくてもどうでもいい
コピペすれば？

俺は補完＋コピペ使用でも鬱になるが･･･

38の意見なんてどうでもいい

ﾊｧ?
お前らなんか勘違いしているようだが
俺たちに生産性やそれを左右する
開発手法・コーディングスタイルなんて関係がないのさ

なんで?

残り関数型言語使い 0人

俺たちの目標は単位を取ることであって
なにかを生産・開発することではない
それにコードも長くて１００行程度だから
手法やスタイルは一切不要なのだ
おわかりか？

「一文字変数なんか使う奴は氏ね」と言われて育った漏れには、
一文字変数使いまくりのHaskellの大胆さに失禁気味です。

ようは程度問題だろ
JavaやHaskellみたいに極端なのは外基地

ネーミングは難しい。簡潔なのがベストだが、センスのない人間が
わかりやすくしようとすると、ダラダラ長くなる。結局長すぎて見
通しが悪くなり、かえってわかりにくくなる。

っつーか、
Javaみたいなinclusion polymorphismな言語では長い名前のほうが合ってるけど
関数型言語みたいなparametric polymorphismな言語では長くしようがないと思われ。
「hd x = ...のxをx以外にどう言えってんだ」って。

Javaのスタイルに合わせると鬱になる

Java = 鬱そのもの

Javaが饒舌なのは、書いてる本人に自信が無い事の現れです。
今日のラッキーアイテムはedlin。

>>39
だから、長くしようと思えば、Haskellで長くすることもできるし、
Javaで短くしようと思えばすることもできるじゃない。

verificationが出来る方がいい

関数の識別子はともかく、
関数の中での変数名は一文字でもいいだろ。

データに実世界のオブジェクトを表すような名前が必要かどうか。
現実的なプログラムって全然汎用的じゃなくてある決まった処理を
するために作られることがおおい。だから変数名は端的かつ分かりやすい
方がいい。そのために自然言語の意味の借用もありでしょ。
だけど関数型言語のやり方にケチつけてる必要もない。
かれらが表現したいのは個物から離れたものだから。

未だにPVSマンセーな俺は逝ってよしか？

関数型と手続き型では変数の担う役割が違うし
手続き型での常識を持ち込まれても…。

JAVAのﾗｲﾌﾞﾗﾘ使ってみろ。
どうやって短くすんだ?

>>63
ライブラリに頼るのは厨房

ｵｲｵｲ、JavaからLibraryとったらなにも残らないよ>64

ネーミングは簡潔にって事だ

>>61
pvsﾏﾝｾｰ!!!

　　　　　　　　　　　　　逝って来ます．．．

実用されてないオナニー言語系の人達の言うことは違うねえ。

pvsは実用されてますが何か？

関数型言語（lisp）ってあまり実用的でないかもしれないけど影響力は凄いよね。

>>70
たとえば？

>>70
lispは関数型ではないって話のながれだったのでは…

研究分野で広く使われていることは実用的とは言わないのか。

>>73
ここの多くのプログラマは、
学生が業務系システムについて何も知らないことをバカにする割りには、
自分らが研究分野について無知なことには無頓着なのでれす。

俺は業務系。研究分野なんて何も知らん。だから何も言わないｗ

>>74
ハハハ，鋭い．それでもって，研究動向に無知なことを指摘されると，
「それ(研究)じゃ給料は稼げない」とか言うわけね．

喰えるか喰えないか、それが問題だ。

生き延びる人

重要なのは、それで遊べるかどうかだ。
食える言語は他にいくらでもある。

OOと関数型は相容れません

OOとの違いはよく分かんないけど、
関数型の言語って静的にプログラムの内容を
検証しやすいとかってメリットはあるの？

副作用が無ければその通りだ。

>>79
OOを実現した関数型言語はいくらでもある。

概要は？

というか
・手続き型
・オブジェクト指向型
・関数型
・論理型
という2種的(ｗ)なカテゴリーに分けることが
既に現実からはなれてしまっているような気がするが。

全ての言語は、次の2つに分ける事が出来る。
・実務型
・オナニー型

言うまでもなく、所謂関数型はことごとく後者だ。

彼女も認めるほどのオナニストですが何か？>85

>86
こすり過ぎて、関数型言語でショッピングサイトを作ろうなんて
暴挙に出るなよ。

>>87
ことごとくライバルを打ち負かしてしまい、オナニーに拍車がかかるからな。

>>85
前者には APL と PL/I と COBOL と VB と C と C++ しかないようですが？

ADAはぁ？

このスレ内容濃くて(特に前スレの前半)自分の無知を思い知らされるわ

前スレがこともあろうにHaskellマンセーで終わっている…！！！！

>>92
だめなの？

>>85
gcc は実務に使えないと？

?

やっぱりS式がいいなぁ、ﾎﾞｿ

>>65

んなことないべ。

>>75

OCamlは？使ったことないんだけど。

>>95
gcc は一旦プロセッサに依存しないツリーを作って、それをプロセッサ依存のコードに展開する方式を
採用している。でプロセッサ依存部分の記述だけど、ソースを見れば分かるように、独自の関数型言
語で書いてある。(see config/i386/i386.md)

あとはデータファイルが関数型言語っぽいデータ構造になってる CAD なんかも、わりとよく見かける
ね。

>>98
かっこがたくさんあるからって関数型って呼んでたら
関数型やってるひとが怒るぞ。

>>99
どっちの話？

たぶんgccの話でしょ。
関数型言語的というよりLisp的だから。
EmacsのStallmanが作ったcompilerだし。

関数型言語ってシステムの記述に使われたりしてるの？

>>102
Lispマシンとか(藁

>>102
SMLもHaskellもコンパイラを書いたりするのに使われているよ．

それから，CMUのFOXプロジェクトではSMLでネットワーク周りのコードを
書きまくってる．

あと，電話交換機のコードで実際に使われていた関数型言語って何だったっけ？

Erlangだっけな? Ericssonの交換機。(purely functionalではない)
後、オランダでは、運河の排水制御をやっていた。

このスレで、キャッシュとか部分計算とかいったら、怒る？

>>106
そんなのは明示的に書かなくても処理系が見抜いてくれることを希望。

>>106
意味論中立な処理系実装技術、ってことでOKなんじゃないの？
"Partial Evaluation and Automatic Program Generation"も
ほとんど関数型言語の話だよね。

Stateless な Webアプリケーションって、関数プログラミングに似ているかなっと。

でも、ユーザ・インターフェース上の要求や、パフォーマンス向上を考慮すると、
セッション管理や、各種キャッシング技法や、DBによる状態保存が必要になる。


で、上記のうちの「キャッシング」の記述技法の提供が、「オブジェクト指向」の使命
(の１つ)かな、と言いたかったんですが、、、、

(例: EJB の　SessionBean, EntityBean, エクステント管理)

関数型でキャッシングすれば良いだけの話じゃない？

理屈(意味論限定)ではそう。

でも実際、セッションや処理コンテキストに応じた、精度の高いキャッシングは、
処理系(HTTPキャッシュや、RDBの結果キャッシュ、Webアプリケーション・サーバ)
では面倒みてくれないから、手書きするのが普通。
んで、局所情報に依存した粒度の細かいキャッシング処理を、アプリ作成者に近い側で記述するには、
オブジェクト指向(やDOA)がよろしいんではないかと。

＃関数言語によるWeb構築って(きちんとウォッチしていないからなんだけど)、
＃LispでWebアプリ構築っていう話と、OcamlのMooしか知らない。

関数型言語ではアルゴリズムの記述に注力して、
処理系への設定ファイルのようなものでそういった
細かい問題（であるがとても大事）は片付けられる
ようにならないか？こういったもの誰か作らないかな。

"Separation of Concerns"で、関数型とキャッシュ管理を分離記述できないのかな？

＃徹夜明け＆携帯書き込みなんで、ちょっと用語遣いが変 >111
＃
＃逝ってくる。

苫米地さんとこのWebサーバーはどういった感じなんだろう。
apacheの数倍速いらしいけど。

>>114　苫米地さんとこのWebサーバー
＃fj.comp.lang.functional で「有名」だった方ですね。

詳細は知らないけれど多分、マルチスレッド
を使って、単一プロセス内でWebサーバとアプリサーバとWebアプ
リを動かして、コンテキスト・スイッチングを最小限に抑えて高性
能を実現、っといった話のような気がする。所詮、実装技術か？

>>108 さんくす。
出直してくる。

>>115
苫米地さんとこは別スレで既存の処理系を使ってると書いてあった。
本当はこういった話は言語レベルで解決すべきではない、という
やり方が関数型言語らしいような気もするけどね。
でもそんなことしていたら実務レベルで使える処理系がいつ出てくることやら。

λがわかりまくる本ってどれ？

知りません。

>>118
やはりλ教の聖書と呼ばれるBarendregt…　といいたいけどやはり
大変なので福音書と呼ばれるHindley&Seldinの本あたりでしょうか．
日本語なら高橋正子先生の本でしょう．

高橋さんの本はちょっと前にアマゾンで注文したところです。

いま新しいプログラミングパラダイム 井田 哲雄
を読んでます。

２章 λ計算と高階プログラミング 横内 寛文
を毎日ちょっとずつ読んでます。
わりと平易に書いてあるけどつらい。。。

>>118
古い本ですが、私はこの本が面白かったです.

「プログラミング言語の新潮流」　井田哲雄 (共立出版, 1988)

Lisp と Schema の処理系をかじって、次に 型推論って何？
という疑問をもった時に、本書後半の HOPE の説明を読んで、
わかったような気分にひたっていました.

関数プログラミング 読み始めた。
ってことでageる。

前スレから
http://pc.2ch.net/test/read.cgi/tech/987954395/968-981

>やはり言語は実用されているものを例とすべきだ。
>Eiffel等という正直に言って普及しているとは言いがたい言語を例とするのは、
>例示としては頂けない。
>現在の普及率などから考えて、C++やJavaなどを例示とすべきだ。
>その手の議論は言語的な広がりがなくなる。

OO の議論に Smalltalk と Eiffel は欠かせない。

別に Eiffel じゃなくても属性と方法を区別しない OOPL はいろいろある。
Delphi, C#, Ruby, Satherとか。

属性と方法を区別すると再利用しにくいので
OOPL として欠陥だと思う。

>>124 方法って、メソッドのことか。一瞬ﾜｶﾗﾅｶﾀ
Javaもあとからそれに気づいたのか
Beanの規約で属性を表にさらさずにアクセサ方法(Wで
方法のほうに統一しようとしてるし。
すれ違いｽﾏｿ

>>124
2つ質問がある。

>OO の議論に Smalltalk と Eiffel は欠かせない。

なぜ？

それから、Object Pascalがどのような点において
区別していないと言ってるんですか？


なお、方法と属性の弁別について取り上げたのはクラス設計に関連してだ。
言語の完成度は論点ではない。
つまり、クラス設計をする際には、
ある事象とでも言うべきものを抽象化しクラスとするわけだが、
その抽象化は方法と属性と言う観点に注目して行う。
それは関数型言語とはある意味逆なのではないかと言うことだ。
話を俺の論点からずらして反論するのは止めろ。

>>126
124じゃないけど、論点がわからんなあ。
関数型のように、属性と方法を区別しないのは、OOの設計と反対であるから
区別しないことはOOに向いてないと言いたいのではないのかな？
その点を踏まえて、OOPLにおいて、属性と方法を区別した方が良いと
124は言ってると思うのだが。
なにが論点？

>>126
>>OO の議論に Smalltalk と Eiffel は欠かせない。
>なぜ？

純粋なオブジェクト指向言語で対照的だから。
Smalltalk は動的型付け、動的リンク。
Eiffel は静的型付け、静的リンク。
Scheme と Haskell みたいな感じかなあ ...

>それから、Object Pascalがどのような点において
>区別していないと言ってるんですか？

Delphi には C#のプロパティと delegate のもとになった機能がある。

>クラス設計をする際には、
>ある事象とでも言うべきものを抽象化しクラスとするわけだが、
>その抽象化は方法と属性と言う観点に注目して行う。

クラス設計をする際には、
インターフェースと(属性とメソッドの)実装に分ける。
だから抽象データ型と呼ぶ。

話は変わるが、

「命題＝型、証明＝プログラム」な「構成的ブログラミング」
って、今どーなっているのかな？

型推論と逆の話になると思うが。

>>127
>関数型のように、属性と方法を区別しないのは、
>OOの設計と反対であるから
>区別しないことはOOに向いてないと言いたいのではないのかな？

それはむしろ俺が言いたいことの方に近いのでは？
相手方は、属性と方法を区別するのは
むしろOOPLにとって不完全だといっている。

>>127
>純粋なオブジェクト指向言語で対照的だから。

これは理由にならない。
何度も言うが、言語の完成度なり純粋性は俺の話の反論にはならない。
俺が言っているのは、何度も言うが、クラス設計に関するものだ。
個人的には、C++かJavaが適切だと思ったのは、広く使用されているので、
話が周知されると思ったからだ。
まあしかし、私の話の趣旨からするならば、UML等をいうべきだったかもしれない。

>Delphi には C#のプロパティと delegate のもとになった機能がある。

関数ポインタはOOの場合主としてポリモルフィズムとの関連で言われることが多いし、
実際にそれに向けられている。
高階関数による表現力の増大とは性質が違うのではないだろうか。

またプロパティはここでは関係がない。
と言うより、どう関わってくるのかが
俺には今一つ分からんので説明してください。

>クラス設計をする際には、
>インターフェースと(属性とメソッドの)実装に分ける。
>だから抽象データ型と呼ぶ。

それが俺の話の反論になるとは思えないのだが。
結局、属性とメソッドで分けているのだから。
インターフェースによって隠蔽されていると言うのは
話が違う。
高階関数の場合それ自体がオブジェクトだ。

>>127
>純粋なオブジェクト指向言語で対照的だから。

↓

>>128
>同上

>>130 は、もしかすると、属性抜きのOOと、関数言語を関連付けようとしているの？

関数型でない普通のOOでは、高階関数なんて使わないと思うが。
実現可能か、と問われれば、1.実行時情報として関数の型を参照できて、2.任意の引き数を扱う事ができて、3.高階関数用プリミティブを用意できれば、可能だと思うが。

高階関数って何？
高階導関数なら分かるが

こうかいかんすう【後悔関数】
（名）関数型言語を学んだことを、あとになって悔やむこと。

>>133
関数をデータとして扱う(引数として取ったり、値として返す)関数のこと。
述語に関する述語(notとか)を高階述語というのと同じこと。

なるほど汎関数や超関数の事か

>>130
前スレが読めんのじゃが、もう少し、分かり易く、例を交えて、説明して下さらんかのう。

ちなみに、ワシの記憶によれば、LISPのClosureこそ、OOのインスタンスなんじゃが。

関数型言語でもOOPできるし、
OOPLでも関数型プログラミングできる。
OOPLでは高階関数が使えないと決まっているわけでもない。
正直、何を議論してるのかわからない。

話の筋道は、
誰かが関数型の特徴とは何か？と聞いていたので、
他の誰かがその回答を色々言っていた。
それで俺としては、高階関数がその特徴なのではないか、
そして、それはある意味OOPLとは逆なのではないか、
と言うことを述べたら、
>>124が、属性と方法を区別するのは
むしろOOPLとしては不完全であるとして、
EiffelやSmallTalk等を例として持ち出してきた。
そこで俺は、126,130のように反論している。

>>133,134
とりあえず、技術的な話をするつもりがないなら来るな、といっておこう。

>>136 物理や数値解析系では、そーとも言う。
　　分野によって、訳語や用語が違うので、この手の疑問は普通に発生する。

　　俺は、数式処理系(Macsyma〜Mathematica) と 命題処理系(ML?)に
　　類似性を感じて、興味を持っていたので、乱入大歓迎。

　　

関数型言語（型なし）のエッセンス
構文：
M ::= x | (λx.M) | (M M)

意味：
E[x]ρ = ρ[x]
E[(λx.M)]ρ = cls(x,M,ρ)
E[(M M')]ρ = if E[M]ρ=cls(x,M'',ρ') then E[M'']ρ'{E[M']ρ/x} else ⊥

このくらい簡単にOOPLのエッセンスは書けないものだろうか？
継承とか考えなければやはりアクター計算なのかなあ。

>>141
では議論を盛り上げるべく、
属性と方法を区別するOOPLが不完全であるかどうかについて、
貴方なりの考えを聞かせてください。

いや、正確には、高階関数が関数型の特徴といえるかでしたね。
すいません。

漏れは、OOPLに　属性とメソッドの区別があっても良い、と思う。
というか、属性とメソッドの区別、というのはシンタックス・シュガー上の問題でしかない、と思う。

>>145
なるほど、
では、UMLには、Class Diagramと言うのがありますよね？
あの図では、attributeとoperationというものを区別しています。
見ればすぐに分かりますが、
あの図にとってはその区別は重要な一部です。
そのような区別も貴方の言う所では、
シンタックスシュガー（？）になるんですかね？

Cardelli達がやっていたOOPLの意味論では，オブジェクトはレコー
ドとして表現されていて，属性（インスタンス変数）とメソッドの本
質的な区別は無かったと思います．メソッドというのはインスタンス
変数（この意味論ではレコード要素）にたまたま関数が入ったもので
した．

>>146
Cardelliの意味論の立場ではその通りで，メソッドと属性は単なる
便宜上の区別でしかないわけですね．この方が理論が整理されて綺麗
では？

UMLは、オブジェクト指向(OO)というデータ分析方法(DOA)の、記述規約。

オブジェクト指向分析(OOA)では、DOA由来のデータ抽出に加えて、
メソッド抽出も重要なので、アドホックに operation が加わった、という気がする。

DOA/OOA では、多分「状態遷移」みたいな事柄を中心に考えていて、
　　　DOA　　　状態 (attribute) を重視、遷移 (operation) を軽視.
　　　OOA　　　状態 (attribute) だけでなく、遷移 (operation) も重視.

なのかな、と今思いつきで書いたが、間違っていたらスマソ。

>148 理論のきれいさ、という点では、メソッドと属性の区別が無い方が、便利だと思う。
　　　所詮、属性って (最下位レベルでは)getter と setter がないと、アクセスできないわけだし。

１２９です。

「命題＝型、証明＝プログラム」な「構成的ブログラミング」
って、今どーなっているのか、誰か教えて！

(型推論と逆の話になると思う... )

言語の話と分析・設計手法（とそのモデル）の話は分けませんか？

>>151
型推論と逆っていうけど，どういう意味で逆なの？

みんな言葉をいいかげんに使いすぎ！

>>153
うまい説明をするために、しばし考えさせて (泣)

なるほど、
つまり、属性と方法の区別がないほうがOOPLとしては優れていると。
つまり、Class Diagramでの区別はシンタックスシュガーであると。
俺はそんなことは思ったことがなかったんだが、
そう言う考えのほうがむしろ完全であると言う視点は勉強になった。
その方は分かったんだが、
もう一つの俺の本体の論点たる、
高階関数が関数型の特徴であるかどうかについてはどうでしょうかね？

>>155
（区別が無いほうが）優れているとは誰もいってないのでは？
関数型言語とオブジェクト指向型言語それぞれの本質的な特徴を
とらえるには，それぞれのモデルとして理論的にできるだけ単純
なものを考えたほうがいいわけで，そのためにメソッドと属性の
区別をわざわざつけないという主張があるわけだ．

個人的にはOOPLの最大の特徴は非同期メッセージパッシングであ
り（現時点でこれをきちんと実現している言語はほとんどないが），
クラスや継承はオマケという気もする．:-)

>>156

>>124
>別に Eiffel じゃなくても属性と方法を区別しない OOPL はいろいろある。
>Delphi, C#, Ruby, Satherとか。

>属性と方法を区別すると再利用しにくいので
>OOPL として欠陥だと思う。

ある種の高階関数はCでもかける。qsortとかね。
本質的なのは関数型変数に対して呼び出しと代入しかできないのが普通の言語で、
引数を１つ埋めたり合成したりして新しい関数を作ったり出来るようになっているのが
関数型だと思う。

でも突き詰めればそれはPerlなどのevalを持つ言語でも出来ることだから
「関数型は動的である」と言ってるに過ぎないような。

>>156
アクターっすね。

SMTPとかの非同期通信経路を使った、分散オブジェクト とか SOAP で実現されつつあるような…

>>158
高階関数は関数型の特徴ではないと言うことかな？

OOPの特徴は何かの話は止めてくれ。
それをしだすと話が大幅にずれるし、スレタイトルとも異なってくる。
俺が属性と方法の区別を言い出したのは、
高階関数との絡みでだ。
話すなら関数型に関連付けて話してくれ。

>>160
関数型「だけ」の特徴ではなくて動的な言語の特徴だと思う

>>162
それは要するに特徴ではないと言うことを言いたいのか？
他にもあるから。

>>163
うーん。
高階関数とは何かと考えると、
１・関数を変数として扱える。
２・新しい関数を定義できる。
になると思うのだが、１はCでさえ実現できてしまい、２を考えると「動的である」と
同値になってしまう。
「int型があるのはJavaの特徴か？」ときかれているような気がする。
特徴の一つではあるが、関数型を他から隔てているものではないと思う。

>>158
eval等のメタ機能で動的に関数を作れることと，計算モデルに最初
からファーストクラスの関数が入ってることは区別してほしいな．

Perlのevalで「動的に」関数を作れるといってるのは，Cでsystem
を使ってコンパイラを呼び出し，コンパイル結果を動的リンクして
「ほら関数が動的に作れたよ」といっているのと一緒．

関数型言語の本質的な特徴は，(1)リダクションにもとづく意味論と
(2)高階関数になるのでは．(1)だけだと項書換え系一般になっちゃう
けど，(2)を入れることで関数型を特徴付けられる．

このスレで困るのは，「他のパラダイムにおいて高階関数を表現でき
るので，高階関数は関数型を特徴付けるものではない」という不思議
な議論をする人がいること．関数型と他のパラダイムは必ずしも対立
するものではない（特にオブジェクト指向とは直交しているといって
もよい）ことに注意してほしいな．

>>164 付けたし
高階関数は関数型の必要条件だが十分条件ではない。
これが一番簡潔な言い方か。

>>164
Cだとclosureというか、環境とか実現できんぞ。

もう少し整理してみる．関数型言語（プログラミングパラダイム）
を特徴づけるのは
　(1)(高階)関数による情報の表現と，
　(2)リダクションによる計算の実行
を主な基盤としていること．これは理論的には(1)(2)だけで全て
（チューリング等価な世界を）表現できるというところから出発して
いるが，実際の処理系ではそれ以外に不純なものも混じっている．

他のパラダイムで(1)(2)に相当することを表現できるが，それは
そのパラダイムが関数パラダイムを内包していることをいっている．
それをイイ悪いの議論に持っていく人もいるのが2chの面白いところ．
でもそれは技術的な議論にはならない．

関数型の面白いところは，(1)(2)だけで世界が表現できることを
示して，現在の計算機アーキテクチャ上でそれなりに効率的な実行
ができることを体現しているところにある．

>>162 >>163
他のパラダイムから隔てている特徴は，「基本的に上の(1)(2)だけで
世界を表現すること」では駄目か？　高階関数もリダクションも他の
パラダイムでなんとか表現できるが，それらだけを純粋に取り出した
のが関数型．（現実の処理系に副作用があるのは目をつぶる）

プログラミング言語研究の道具としてこれだけ関数型がメジャーなの
は，手続き型やそれをベースとしたOOなどのパラダイムが関数型を内
包しているから．つまり関数型が提供している計算モデルはそれだけ
普遍的だということができる．

違う体系(公理系)を計算可能性が等価だからと言って
内包とはいわんだろ。

>>165
>eval等のメタ機能で動的に関数を作れることと，計算モデルに最初
>からファーストクラスの関数が入ってることは区別してほしいな．
これを区別するのは賛成だが、どちらも高階関数であることには違わない。
もしCの言語仕様にevalがあるのなら「Cでは高階関数がかける」というだろう。
その機能が明白に意味付けできるかどうかは別の議論だ。
・数学的にきちんと意味を定義出来る高階関数が関数型の特徴だ
というのは納得するが。

計算可能性の話でなく，関数型で書かれた記述を比較的自然に（イン
タプリタなどを書かなくても）他のパラダイムでコーディングできる
ということをいったつもり．きちんと定義するのはちょっと難しい．

なんでsageで書くの？ >170,171

>>164
しかし、高階関数は関数型の中にあってこそ、
始めてその表現力の飛躍的増大を図ることができる。
つまり、imperativeとは異なり、
プログラムがコマンドの羅列ではなく関数の集合になっている
関数型であってこそ、
高階関数は表現力増大の為に生きてくると思うが。
従って、高階関数が関数型の特徴であると言う時、
それは「int型があるのはJavaの特徴か？」と言うのとは異質だろう。

>>174
まあそうなんだけど、int型だって
「int型は細かく型チェックするタイプの言語にあってこそ有効だ。VBみたいなバリアント型
がある言語ではその力を十分に生かしきれない。」
とも言えると思うぞ。
俺も高階関数は関数型の中心的な要素だと思う。でももうちょっと考えてみるとそれ
は高階関数と言う概念よりも他の概念のほうがしっくり来るような気がしたのでつい
反論したくなっただけだ。

関数型プログラミングって、代入がバグの温床だってところから
スタートしたもんだと思ってたんだけど、それは違うの？
高階関数が関数型プログラミングで重要な概念だってことは認め
るけど（高階関数なしに関数型プログラミングするのは効率悪い
からな）、

１）高階関数をサポートしないが、代入を排除しているプログラミング

２）高階関数をサポートしているが、代入を排除しないプログラミング

を比較すると、１の方が関数型プログラミングになっている気
がするんだけど。

その比較に意味はあるの？>176

>177

たとえばJavaあたりで代入を使わずにプログラミングしたら、
それは関数型プログラミングになってるって感触があるし、
Lisp系でグローバルオブジェクトをあちこちから操作しまく
ると高階関数を上手に使っていても関数型プログラミングに
なってない（バグがとりにくい）って思うから。

>>130
>>純粋なオブジェクト指向言語で対称的(訂正)だから。
>これは理由にならない。
>何度も言うが、言語の完成度なり純粋性は俺の話の反論にはならない。

反論ではありません。ＯＯの議論になぜ欠かせないか答えただけです。

>またプロパティはここでは関係がない。
>と言うより、どう関わってくるのかが
>俺には今一つ分からんので説明してください

属性のアクセスを抽象化できる。

関数型とＯＯがある意味逆というのは
関数型はデータ抽象化しないってこと？

>>179
>関数型とＯＯがある意味逆というのは
>関数型はデータ抽象化しないってこと？

↑
前スレコピペ

>OO言語では、その機能を十全たるものにするためには
>しっかりしたクラス設計が欠かせないとされている。
>そして、その際には、属性と方法を適切に弁別する作業が欠かせない。
>つまり、「良い」OOからしてみると、
>属性と方法が渾然一体となってしまうような状態は好ましいとはいえない。
>一方で、関数型は、OO的に言うところの方法が
>同時に属性でもあり得ることを奨励し、
>そのことによってより抽象的なアルゴリズムを構築でき、
>表現力が高まるとしている。
>その意味においては、
>両者は理想とする方向が逆なのではないかと思った。

>そして、その際には、属性と方法を適切に弁別する作業が欠かせない。

本当に？
まあ、不必要に属性を公開すべきでないってことなら賛成だけど。
メッセージパッシングとネームスペースを同じドット記法で
書くから混乱しているだけってことかも知れないけれど。

でも、値を利用する立場からすれば、それが式であることには
代わりはないんで、別にどうでも良い気がするんだけどな。

>>181

>>143
>属性と方法を区別するOOPLが不完全であるかどうかについて、
>貴方なりの考えを聞かせてください。

関数型ってのはクラス化しないという意味？

私は割りと好きな手法だ
というのは私はアセンブリ思考の高級言語プログラマーなので
人間側はプログラミング言語よりも仕様書メインで
プログラムは最終的にCPUからみて考えるので
当然goto文相当のものも多く使う、がある程度分離させている。
クラス化(OOP)なものも使うができるだけポインタ渡しの関数を使うようにしている。
その最大の理由は改良や互換性において相互依存度が大きくならないことと
プログラム内に不必要なインスタンスが多数出現するのがいやなため。

これの例で具体的にはOpenGL　V.S. DirectXがあると思う

OpenGLはWin95時からずっと同じOpenGL32．dllであり関数型
おんなじかんすうだが実はデバドラのほうへの橋渡しなので
デバドラが新しい関数を提供してくれたら
従来のルーチンに上乗せする形でそれが使える。

一方のDirectXはOOPである。
OOPだから基本クラスを改良すると一から全部やり直し
それでも一応下位互換ルーチンを残しているからいいけれど
新しいインターフェースで作ったプログラムは選択の余地なく
新しいDirectXを入れていないパソコンでは初期化すらできない。

資源の再利用とかはあまり興味ないけれど、環境の変化に対してOOPは弱いのでは？

>>183はｱﾌｫ

>>183
全然違う
逝け

>>183
関数型は名前の通り関数(写像)で記述(モデル化)するって事だな。

副作用のない関数型の世界だと、属性ってただの定数では？

副作用のある不純関数型言語だと、高階関数(実装的にはclosure)
ってJavaのインスタンスとほとんど等価だよね(既出だが)。
で、属性の読み出しは引数のないメソッドとみなせるし、属性の
更新も1引数のメソッドと見なせる。

逆に、SmalltalkやJavaのインスタンスは高階関数のようにも使える。

高階関数とか属性はFPLとOOPLとを弁別するキーには全くならんと
思うが。

>>187
そんなこと言ったらCで関数ポインタを含む構造体のインスタンスは
javaのクラスインスタンスと等価とか言えるんじゃないの？
キリないよ。
結局字面の問題でしょ。

>>187
それを言いだすと、
ほとんどの言語は関数型言語をエミュレートすることで
高階関数を扱える、とか言っちゃったりするわけで...
字面の問題とまでは言わないけど、
言語自体が「高階関数」という概念を提供しているかどうかは
大きな違いがあると思う。

VBって関数のポインタ取れなかったよね？VB5以降

>>187
>副作用のある不純関数型言語だと、高階関数(実装的にはclosure)
>ってJavaのインスタンスとほとんど等価だよね(既出だが)。
>で、属性の読み出しは引数のないメソッドとみなせるし、属性の
>更新も1引数のメソッドと見なせる。

>逆に、SmalltalkやJavaのインスタンスは高階関数のようにも使える。

>高階関数とか属性はFPLとOOPLとを弁別するキーには全くならんと
>思うが。

↑

>>174
>しかし、高階関数は関数型の中にあってこそ、
>始めてその表現力の飛躍的増大を図ることができる。
>つまり、imperativeとは異なり、
>プログラムがコマンドの羅列ではなく関数の集合になっている
>関数型であってこそ、
>高階関数は表現力増大の為に生きてくると思うが。

187> 高階関数(実装的にはclosure) ってJavaのインスタンスとほとんど等価だよね(既出だが)。

何故、高階関数(実装的にはclosure)なのか、教えて下さい。

またここでも用語の混乱が起きてる様だね

多分動的束縛のLispで、関数を返す関数を作ると、
closureが返るから、高階関数＝closure と解釈した
のかな？

Lisp系の言語でOOPするときは、
クロージャに関数スロットと属性スロットをカプセル化する。
それを見て、高階関数＝クロージャと解釈したのかも知れないけど、
高階関数の典型的な使い方からは外れているよね。

対照的であってたみたいね。

>クラス設計をする際には、
>インターフェースと(属性とメソッドの)実装に分ける。
は正確ではないので
　クラス設計をする際には、
　インターフェースと実装に分ける。
に訂正します。

>>126
「属性とメソッドを弁別して抽象化する」というのに反論したんです。
この表現はクラス設計のとき属性とメソッドを区別して設計するみたいです。
これはＣ言語はグローバル変数とグローバル関数を区別して
設計すると言ってるみたいなものです。
こんな表現は奇妙です。

言ってることは分かったので主張そのもに反論はありません。

>>196
>「属性とメソッドを弁別して抽象化する」というのに反論したんです。

どこで言っていた？
ちゃんと摘示しろ。


それから、ObjectとClosureとについて
変な文を見つけたのでコピペする。
まあ、どうでもｲｲかもしれないが。

An object is a piece of data with procedures attached to it...
A closure is a procedure with a piece of data attached to it.

天才Steeleの"Lambda: the Ultimate Imperative"を読みなさい。
ついでに"Lambda: the Ultimate Declarative"モナー
Actors ≡ Closures (mod Syntax)
という章に、ObjectとClosureがなぜ等価であるのかちゃんと書いてある。

ははん、なるほど。
OOPは「メッセージパッシング」のメタファで抽象データ型をサポートするけど、
FPはクロージャでそれを実現するし、本質的にそれらは等価だってことか。

[aReciver Message] = (aClosure Proc)

みたいな理解でいい？

論点をまとめます。

関数型とＯＯが逆というのは高階関数とクラスは違うということらしい。

高階関数とクラスが違うというのは同意。

しっかりしたクラス設計とは
インターフェースと実装を適切に弁別することであって
属性とメソッドを弁別することではない。

>>197 >>180です。

方向性が逆、という話はあまりしっくり来ないな。
OOPにおけるクラス設計も、より抽象的で本質的なクラスを、
より具象的なクラスから抽出してスーパークラスにまとめて
いく分析・設計プロセスがあるよね。デザインパターンにも
よく出てくる。具象的なクラスばかり作っていてもコードの
共有が進まないからだな。

関数型プログラミングも、共有コードを増やしたいと願って
いることには違いがないから、結局、より抽象的でより本質
的な関数を抽出しようとする。やっていることは同じじゃな
いかと思う。

# というより、デザインパターンの研究は、関数型プログラ
# ミングの研究成果からのフィードバックが大きいと思われ。

>>198,199
真面目な質問なんだが、
（本質的に）等価であるとは一体全体どのような意味だ？
そして、それは、
そのビヘイビアにおいて同形であるということと
どのように関わって来るんだ？

>>201
>デザインパターンの研究は、関数型プログラ
>ミングの研究成果からのフィードバックが大きいと思われ。

それはどうかな。
なんともいえないと思いますが。

>>200
>しっかりしたクラス設計とは
>インターフェースと実装を適切に弁別することであって
>属性とメソッドを弁別することではない。

しっかりしたクラス設計　＝ インターフェースと実装を適切に弁別すること。
　　　　　　　　　　　　　　　≠　属性とメソッドを弁別すること。

>>180
>しっかりしたクラス設計が欠かせないとされている。
>そして、その際には、属性と方法を適切に弁別する作業が欠かせない。

この文は、
しっかりしたクラス設計　=　属性と方法を適切に弁別すること
なのか？

それよりもさ、君>>200の場合、
属性と方法を区別するOOPLが欠陥があるといえるならば、
Class diagramでの属性とオペレーションの区別が
どのような意味を持つかについて答えてよ。
やはりシンタックスシュガー或は便宜的区別なのか？

今更だがsageる。

>>201
>OOPにおけるクラス設計も、より抽象的で本質的なクラスを、
>より具象的なクラスから抽出してスーパークラスにまとめて
>いく分析・設計プロセスがあるよね。デザインパターンにも
>よく出てくる。具象的なクラスばかり作っていてもコードの
>共有が進まないからだな。

>関数型プログラミングも、共有コードを増やしたいと願って
>いることには違いがないから、結局、より抽象的でより本質
>的な関数を抽出しようとする。やっていることは同じじゃな
>いかと思う。

質問です。
考えてみると、この発言の趣旨が分かりません。
結局何がいいたいんでしょう？
共有を進めるためのおよそ全てのより本質的な抽象化への努力は
皆お友達だと言いたいのでしょうか？

Schemeのように、コンパイル時の型チェックがなく、
リストのような単純なデータ構造を基盤とする言語の場合はともかく。

強く型付けされた関数型言語の場合、
ある関数の適用範囲は厳密に、揺るぎなく、決定されている（シグニチャ
等を利用してポリモーフィズムを実現したとしても、適用範囲が静的に
決定できることには変わりがない）。
それは、OOPにおいて、クラスの中にメソッドがカプセル化されている
状態と本質的には同じことだと思う。

>>204
145 です。このスレの行き先が心配になってきたもので...


1. 「属性とメソッドの区別はシンタックスシュガー」というのは、
　オブジェクト指向言語を「関数モデル」から見た場合の話です。(>>145,前レス109のFP)

2.オブジェクト指向言語を、DOA や OOA の観点から見る場合は、
　　　・属性とメソッドの区別 (>>149)や、
　　　・インターフェース(分析モデル) と 実装 を分ける事(>>128)は、
　重要だと思います。

上記二つの解釈の違いは、議論のベースとなる「計算モデル」の違いです。


オブジェクト指向と、ラムダ計算のクロージャ(?) との類似性は、
比較的古い ('80s) 議論だと思いますが、何か新しい要素はあるのでしょうか？

私としては、「オブジェクト指向言語意味論を、関数モデルでいかに解釈するか？」
といったあたり (>>148-149 のCardelli) に関心を持っているのですが。

論点を決めないディスカッションは混乱をもたらすのみだな。

このスレの主旨： 「関数型言語からRubyへステップアップ」 >>2 :-P

疑問点：オブジェクト指向言語意味論を、関数モデルで記述しようとする試みの
　　　　メリット／デメリットは何か？

>>209
ここでの論点は、俺的には、

高階関数は関数型の特徴と言えるか？　これは概ね話がついた。

属性と方法の区別のあるOOPLは不完全或は欠陥があるのか？　未決

もし不完全でないとするならば、
高階関数を特徴とする関数型は属性と方法を区別するOOPとは
理想とする方向性がある意味逆と言えるか？　未決

ObjectとClosureが等価であるとは一体どのような意味か？
それは、そのビヘイビアにおいて同形であるということとは
どのような関係にあるのか？　不明

こんな感じだろ。

その209の論点は、とりあえずのところは今のトピックではない。
論点自体は至ってまともだが。

まあ、Rubyなんて低レベルなアマチュア言語の話をする気はさらさら無いけどね。

>>204
>しっかりしたクラス設計　＝ インターフェースと実装を適切に弁別すること。
>　　　　　　　　　　　　　　　≠　属性とメソッドを弁別すること。

わかりやすい！

>属性と方法を区別するOOPLが欠陥があるといえるならば、
>Class diagramでの属性とオペレーションの区別が
>どのような意味を持つかについて答えてよ。
>やはりシンタックスシュガー或は便宜的区別なのか？

>>149から
>オブジェクト指向分析(OOA)では、DOA由来のデータ抽出に加えて、
>メソッド抽出も重要なので、アドホックに operation が加わった、という気がする。

属性とメソッドを区別しない　≠　属性とメソッドは同じ概念

属性とメソッドは異なる概念です。(念のため)
区別しないというのは同じように扱うという意味です。

>>210
>属性と方法の区別のあるOOPLは不完全或は欠陥があるのか？

この問題は 関数型オブジェクト指向言語 と 手続き型オブジェクト指向言語 を
比較する方がいいと思います。

関数型オブジェクト指向言語 は
メソッドを高階関数で定義できる点で、手続き型オブジェクト指向言語 と異なります。
また、メソッドを引数として渡すと高階関数が Closure になります。
その他の点はほぼ同じです。(CLOSの多重ディスパッチのような反論はやめてください)

議論の混乱は 関数型言語 と 手続き型オブジェクト指向言語 を
比較したことが原因です。

関数型とＯＯの比較は
関数型言語 と 関数型オブジェクト指向言語 を比較する方がいいと思います。

>>212
クロージャと高階関数がまざってないかい？
「メソッドを引数として渡すと高階関数がClosureになります。」
がなんだか意味不明。

「Closureを引数または返値とするメソッドは
高階関数の実装として扱うこともできる」
とは言えると思うが、どうよ？

>>209
オブジェクト指向言語の型システムを形式化することで
異なる静的型オブジェクト指向言語間でオブジェクトを共有する際の
型検査/型推論のための参照基準ができる。
例えば永続オブジェクトの動的型を表現する時などには
Cardelliの型システムが役立つと思われ。

>>198,199
Actors ≡ Closures　(mod syntax)
というのは、そのまま読むと、
ActorsとClosuresはSyntaxを法として合同であるということになる。
そして、そのような場合においては、知られているように、
ActorsとClosuresは「同値」関係にある。
つまり、Actors is equivalent to Closuresということになる。
これは残念だが、等価であるとはいわない。
等価であるというと意味が変わってしまう。

Actors are 〜　だった。
間違えた。

言語に特化すると議論しにくいので訂正します。

>>210
>属性と方法の区別のあるOOPLは不完全或は欠陥があるのか？
>もし不完全でないとするならば、
>高階関数を特徴とする関数型は属性と方法を区別するOOPとは
>理想とする方向性がある意味逆と言えるか？

この問題は 関数型オブジェクト指向 と 手続き型オブジェクト指向 を
比較する方がいいと思います。

関数型オブジェクト指向 は
メソッドを高階関数で定義できる点で、手続き型オブジェクト指向 と異なります。
また、高階関数の Closure を使える点でも異なります。
その他はほぼ同じです。

議論の混乱は 関数型 と 手続き型オブジェクト指向 を比較したことが原因です。

関数型とＯＯの比較は
関数型 と 関数型オブジェクト指向 を比較する方がいいと思います。

>>213
>「Closureを引数または返値とするメソッドは
>高階関数の実装として扱うこともできる」
>とは言えると思うが、どうよ？

いえない。

オブジェクト
関数オブジェクト
クロージャ
高階関数
オブジェクト指向
関数型オブジェクト指向
関数型言語
オブジェクト指向言語

だれか説明して！

ただのクロージャと、レキシカルクロージャって何が違うの？

187辺りからわけわからん話題になってるyo！

>>217
>メソッドを高階関数で定義
定義した時点でクロージャになると思うがどうよ？

クロージャはオブジェクト指向で言うところのインスタンス。
関数に属性を持たせる概念がクロージャ。
関数（高階関数含む）自体も属性の１つ。

振り出しに戻る

クロージャは、関数と環境のセット。
環境っつーのは、ものすご乱暴に言うと、関数が呼び出されようとしている
瞬間の引数や関数から参照される関数の外にある変数の一覧。
スナップショットみたいなもん。
っていうふうに、俺は理解してるんだが。
どーでしょか？＞議論中の方

だから、インスタンスのように振舞うこともあるって感じですかね。

関数オブジェクトは、そのまんま、関数をオブジェクトとして、
あっちこっちもって歩けるようにしたもの。
高階関数は、関数オブジェクトを引数にとる関数。
あ、関数オブジェクトを返すのもそーですっけ？

一部勘違いしてる人がいた様だけど、
関数型言語とevalはまったく関係ないよ。
(C言語でeval実装〜とか言っていた人がいるので念のため。)
'eval'つーのはLISPで動的にリスト（データ）を評価する手段ってだけ。
不要なevalはなるべく使わないで書くのが良いスタイル。
Schemeの規格でも最近までevalは含まれなかったし。

evalは反則

「無限と連続」遠山啓著　岩波新書アンコール復刊　1952年
を読んだが、関数言語と妙にシンクロする。

第３章「もの」と｢働き」より
「…群論が現れるまで数学者の考える対象は数か図形に限ら
れていた。…
現代の数学でとくにいちじるしい対立をなしているのは
「もの」の概念と「働き」の概念である。もちろん、一つの
文章はすでに「何かのものが何かの働きをする」という形を
とっているのと同じく、数学のなかにもこの二つが対立して
いることは当然であろう。ガロアの輝かしい功績は、この
｢働き」をきわめて明瞭な姿で数学のなかに持ちこみ…」

オブジェクトとか高階関数の話と似てるような気しない？

つか、オブジェクト志向が目指す方向が、そっちにあるって感じ。

数学っていってんだから関数型なんだろ？>229

>>228
数学的記述を目指して開発されたのが
関数型であることを考えるならば、
それはごく当然だろう。
指摘するまでもないことのように思うが。

>>225
カリー化された関数（'a -> 'b -> 'c)なんかも高階関数と呼ばれるよね。

>>217
ハア？じゃあ、メソッドは関数の実装といえると思うが、どうよ？

まあ、計算幾科学の世界では、
計算機科学は「いかにして」の概念を精密に扱う枠組を
提供しようとするものだとされており、
それに対して、数学は「なんである」の概念を
精密に扱う枠組を提供するものとされている。
というか、SICPにはそうある。

しかし、群論などでわかることは、
その「いかにして」を扱うことが
現代数学の主要な特徴になっているということだ。

その意味である種の重なりのようなものを見るのは
いたって自然なことなのかもしれない。

>>215
Actors ≡ Closures　(mod syntax)

Guy Steeleが著者の一人にもなっているHackers' Dictionaryの
moduloの項目を見ろ。(今ならJargon Fileとしてwebで読める。)

Lisp Hacker用語ではmoduloはexceptと読むのだ。

つまり、上は、
「Actorsは(見かけの違いを除けば)Closureとおんなじ」
という意味なのだよ。

「メソッド」って、ポリモルフィズム無しにはありえないと思ってるんだけど。
おれの感覚おかしい？

>>233
板違いだけど、群論入門の良書って何。教えて。
HaskellのMonadなんかも半群うんぬんの話がでてきた。
群論って少しは知ってた方がよさそう。

おれが持っている唯一の数学本。
『数学小事典』 ブルーバックス P.148より

【群】
一般に、集合Gにおいて、Gの任意の元a,bに対し、
Gのある元a・bが対応して、次の1〜3の公理をみたすときに、
集合Gは群と呼ばれる。

公理1　（結合法則）
Gの任意の三つの元a,b,cに対して
　　([a]・[b])・[c] = [a]・([b]・[c])
が成り立つ。

公理2　（単位元の存在）
Gの任意の元aに対して
　　[e]・[a] = [a] = [a]・[e]
となるようなGの元eが存在する。

公理3　（逆元の存在）
Gの任意の元aに対して
　　[a]^{-1}・[a] = [e] = [a]・[a]^{-1}
となるGの元a^{-1}が存在する。


誰か簡単な説明と表記の間違い指摘を頼む（ｗ

(a*b)*c = a*(b*c)
1*a = a = a*1
(1/x)*x = 1 = x*(1/x)

(a+b)+c = a+(b+c)
0+a = a = a+0
(-x)+x = 0 = x+(-x)

>>234
そうなのか、なんか笑っちゃうね。
最初からそんな風に書かなければいいと思うが、
その定義はあとづけだな。要するに。
それを天才というべきなのかは議論の余地があるな。
個人的には、"isomorphic in their behavior"に
説得的なものを感じていただけに、少し残念だ。

>>236
まあ、群論というか、代数学は基本的には、
計算機に大きく関係する方だと思うよ。
数を扱っているからね。

>>239
つーか、言葉遊びでそ

>>236
数学処女は日本評論社の本辺りから始めるのが良いでしょう。

数学板の集合論スレや基礎論スレを見てると、
なんか果てしない泥沼にはまりそうで怖くなるね。
短い人生をああいうものに賭けるのは漢だ！ｗ

>>241
俺にはActors≡Closures(mod Syntax)が
言葉遊びには見えないんだがな。
ActorsとClosuresは、Syntax、
つまり、言葉なり記号なりの配置の仕方
と言う観点からみると、同様の役割・機能・振る舞いのようなものを
持っていると、そういうことを言いたいのではないかと思った。
それを別の言い方で言うと、振る舞いにおいて同形であると、
そういうことなのではないだろうか。
そう考えた方が整合的だと思うが。
それをJargon等を読むような連中には同形の意味がわからんので、
modはexceptなんだといっているのではないだろうか。
言葉遊びと言うにはいささかお粗末だしな。
まあ、俺がいったようなこともある意味言葉遊びだが、
それでもそちらの方が整合的だ。

>>242
どう公理系を構築すれば大体の場合において支障をきたさずに済むか、だからね。
どんな論もある前提において成り立つにすぎない。
ユークリッド幾何学しか知らない中学生がヒルベルト空間をどう思うか。

age

>>213 >>221
手続き型ＯＯのClosureを引数または返値とするメソッドは
高階関数とは少し違うような気がします。

正確に知ってる人がいたら教えてください。

>>232
>ハア？じゃあ、メソッドは関数の実装といえると思うが、どうよ？

メソッドの定義は関数の実装といえるという意味なら同意。

>>246
>高階関数とは少し違うような気がします。
そうだね。
戻値として返される関数は、そのメソッドが所持してる変数などを
「知っている」場合があるし。
関数の振る舞いはメソッドの中身と密接に関わっている。

>>237
とりあえず、「群（グループ）」についてそれでは意味がわからんので、
計算機科学的に引き直して言っておくと、
なんかしらのassociation（メソッド、関数、演算等）が定義されている
メンバ（属性、変数、数値、文字等々）の集まりだ。
それで、そのassociationがその規則を満たすというものだ。
あくまでも計算機科学的引きなおしだから、
参考程度にとどめて置くように。

誤解のないように言っておくが、
その結合は、勿論メンバの中に含まれている。
つまり、結合もメンバだ。

>>249
428には「結合」という単語は使われていないようだけど、
「その結合」って何のこと？

>>250
ん？
associationだけど、なんか変か？
まあ、というか、ある種の働きと言うか
関係と言うかそういうもんなんだが。

>誤解のないように言っておくが、
>その結合は、勿論メンバの中に含まれている。
>つまり、結合もメンバだ。

なんか意味不明な表現になってしまっていて
申し訳ないが、
結合（働き、関係）もメンバ（要素、元）になり得ると言うことだ。

どうでもいいかもしれんが、
一応これから出かけるんで、
質問などにはしばらくは答えられない。

>>251
もう結合は終わりましたか？

>>243
Jargon Fileを読んで面白く感じないなら
LispもSchemeも面白いと思わないだろうな...

それはどうでも良いが、Steeleの文章はこの手の言葉遊びばっかりだよ。
RMSらとともにLisp hackerdomの中心にいた人だしね。

moduloをexecpt (for)と読むのが後付けなわけがない。
Imperative論文はjargon-1より後だもの。

自分の勝手な解釈を後付けで補強しようとしてないか?

＞自分の勝手な解釈を後付けで補強しようとしてないか?
ｵﾏｴﾓﾅｰ

スチールです。
moduloは「except for」と読みますが何か？

>>253
ちょっと聞きたいんだが、
もしexceptならば、
その除外されるSyntaxとは何だ？
また、≡とはJargon的にはどのような意味だ？

>>253
というか、moduloがexcept forだなんて、
言葉遊びでもなんでもないぞ。
どうしてこれが言葉遊びになるのか…
ただの間違いだ。それも初歩的な。
それを「言葉遊びだ」なんて言われて、
「はいそうですか」とか真に受けるなんて、
お前は「馬鹿」ではないのか？

しっかし、どうしてもそんな数学的に
粗雑な話をするとは思えないな。
お前はそれで幸せなのかもしれんが。
それは具体的にJargon Fileのどこに書いてあるんだ？
本当に「その部分」の作成に関わったのか？

>>257
俺はimperativeは読んでないが…

＞それは具体的にJargon Fileのどこに書いてあるんだ？
http://www.tuxedo.org/~esr/jargon/html/entry/modulo.html
ミラーも山のようにあるからすぐ見つかるはずだが。

別に粗雑とは思えん。（なんか意地になってる？）

＞本当に「その部分」の作成に関わったのか？
http://www.tuxedo.org/~esr/jargon/html/Revision-History.html
を見るとほとんどの版の出版に関与してるね。俺もSteele-1983版は読んだ。
その項目を最初に書いたかどうかはしらんが関わったのは確かだろう。

>>258

>(4 = 22 mod 9).

なんだこれは
なんで、≡ではなく＝なんだ？

>別に粗雑とは思えん。

では、説明して欲しい。
その除外されるSyntaxとは何なのか？
そして、そうすると、≡とは一体いかなる意味になるのか？


確かに意地にはなっているが、
それはActors≡Closures(except for Syntax)
と、文中にあったisomorphismが繋がらないからだ。
それともこのSyntaxにもなんか特別な意味があるのか？

＞なんで、≡ではなく＝なんだ？
そりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。

＞では、説明して欲しい。
＞その除外されるSyntaxとは何なのか？

Actors ≡ Closures (mod Syntax)とかisomorphismとか、
シャレで疑似数学風に書いてはあるけど、言いたいことは要するに、
"Actors are just closures (except for slight syntax difference)."
ってことでしょ。

「Actors ≡ Closures (mod Syntax difference)」
じゃ数式風の形じゃないから面白くないじゃない。

（ここまでシャレを説明しなきゃなんないってのも
興ざめっつーか萎えるっつーか）

>>259
> なんで、≡ではなく＝なんだ？

ﾜﾗﾀ
'＝'じゃなくて'='な。

>>260
> "Actors are just closures (except for slight syntax difference)."

closure "with proper tail recursion"と書いておかないと絡まれるかも〜。

>>260
>＞なんで、≡ではなく＝なんだ？
>そりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。

ほう、それでこの時代になっても全く変えていないのか。

>Actors ≡ Closures (mod Syntax)とかisomorphismとか、
>シャレで疑似数学風に書いてはあるけど、言いたいことは要するに、
>"Actors are just closures (except for slight syntax difference)."
>ってことでしょ。
>「Actors ≡ Closures (mod Syntax difference)」
>じゃ数式風の形じゃないから面白くないじゃない。
>（ここまでシャレを説明しなきゃなんないってのも
>興ざめっつーか萎えるっつーか）

分からないに決まっているだろ。
数学的に間違いがあるんだから。
学のない人間にこそ通じる洒落に過ぎない。

俺としては、Schemeとかは他の言語に比べて
数学の諸成果を積極的に取りこんでいる言語だと思っていたので、
数学の記法というかそう言うものに関しては
ちゃんとしていると言うか、一目置いているというかそう思っていたんだ。
まあ別にそういうことならそうでもいい。

それからいっておくと、isomorphicというのは"Actors are just closures"
ではない。これはお前の間違いだ。
というか文脈から言っても違う。
また、≡も「同じ」ではない、一応言っておく。
おそらく「合同」という意味そのままだろう。

>>261
一応≡と統一しようと思っただけで他意はない。

＞>＞なんで、≡ではなく＝なんだ？
＞>そりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。
＞
＞ほう、それでこの時代になっても全く変えていないのか。

なんというか、集合論を知らないとそういう固定観念が
生まれるのか

あのなー、congruenceとisomorphismとequivalenceの
違いぐらい知ってるっつーの。

で、あの論文の中に出てきたisomorphism(って書いてあっただろヴォケ)が、
本当に数学的に厳密な意味での同型性だと思ってるのか？
ただ「それっぽく」シャレで書いてあるだけだろが。

だいたい、ASCII(でもLatin-1でも良いが、DOSでもUnixでもTTYでも
使えるくらいメジャーなcharacter set)で≡をどう書けっつうんだよアフォが。

ほんまにシャレのわからんヤツやのー。Phil Wadlerの爪の垢でも飲め。

つーか、題名だけじゃなくて中身を読んでみれば良いんでは？
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-379.pdf

件の章を読むと、ちゃんとした数学の話でないことは一目瞭然だね。

まあ、「Actorなんてただのlambdaじゃん」と言ったら角が立つだろう
からねえ。HewittってSussmanの同僚でしょ？ だからisomorphism
などとオブラートにくるんで言ったのでは。

>>265
>で、あの論文の中に出てきたisomorphism(って書いてあっただろヴォケ)が、
>本当に数学的に厳密な意味での同型性だと思ってるのか？

そんなことは言っていない。
っていうか、お前は真の馬鹿者だな。
そして、どう考えてみても、ボケはお前の方だ。
「同じ」ではない、といっているんだ。
どうしたら厳密に数学的なisomorphicだと俺が言っているんだ？

>ほんまにシャレのわからんヤツやのー。

だ・か・ら、「一般的な意味では」、modはexcept forではない。
modがexcept forであるかどうかの区別も分からん奴には、
洒落になるといっているんだ。
本当に学のない奴だ。

>>264
>＞>＞なんで、≡ではなく＝なんだ？
>＞>そりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。
>＞
>＞ほう、それでこの時代になっても全く変えていないのか。

>なんというか、集合論を知らないとそういう固定観念が
>生まれるのか

少し意味がわかりませんが、もう少し詳細に説明してください。
そしてあなたのご高説を聞かせてください。

言葉は悪いですが、少なくとも私には265の
>だいたい、ASCII(でもLatin-1でも良いが、DOSでもUnixでもTTYでも
>使えるくらいメジャーなcharacter set)で≡をどう書けっつうんだよアフォが。
の方が意味がわかるんですが。

同値関係を示す記号が何であってもその定義が
明示されていれば問題になることはない。
ということだろう。
よく使う記号は＝≡〜⇔とかだね。

>>267
> だ・か・ら、「一般的な意味では」、modはexcept forではない。
> modがexcept forであるかどうかの区別も分からん奴には、
> 洒落になるといっているんだ。

仲間内での言葉遊びはどんどん逸脱していくものだということを理解して欲しい。
駄洒落等が差異を楽しむ遊びであることを理解すれば納得できると思う。
moduloとexcept forに何の関連も見出せない人がいる、
そのくらい逸脱して初めて大いに盛り上がることが出来るのだ。
仲間内では基本パターンはやり尽くしているからね。

君はこの他愛もない言葉遊びからは仲間外れだが、
君の無理解、不寛容自体も仲間の笑いの対象だ。違うことは面白いのだ。

んで、>>254-270 は、関数型言語と関係あるの？

>>267 はほんとに文脈を理解しない愚か者だな。
「Steeleの論文では」moduloはexcept forだ、
というのは、はっきりしてるだろうに。

だれも「一般の」moduloの話なんかしてないってのに。
よい恥さらしだな。

   hoge
hoge

>>269
=というのは、恒等関係を表すものだ。
同値関係には使用しない。
もちろん恒等関係は同値関係の中に含まれるが、
だからといって、単に同値なものを恒等と言ったりはしない。
それでは記法としては話にならない。
というか、264は、「集合論を知らないと・・・」といっている。
集合論を知らないと生まれる固定観念とは
ここでは何をさしているんだ？
そして、集合論を知っていると生まれる正確な観念とは
それから比較するとどのようなものだ？
俺はそれを聞きたいんだよ。

>>270
おまえさ、俺がsteeleの話が数学的に厳密な同型性だと
どこでいっていたのかを指摘しろ。

実際には、お前の方が遙かに無理解だ。

>君はこの他愛もない言葉遊びからは仲間外れだが、
>君の無理解、不寛容自体も仲間の笑いの対象だ。

他愛がないというより有害だ。
世界はおそらくお前が思っているより広い。
その中で一意に伝達するためには、
しっかりした定義付けや記法が必要だ。
形式化の努力にはそういった意義もあるはずだ。
確かに無理解だが、それは「有害な」言葉遊びのためだ。

>>274
>その中で一意に伝達するためには、
>しっかりした定義付けや記法が必要だ。

同意。
が、ワインバーグの「ライトついてますか？」に登場する警句をひとつ。

「ユーモアを解さない人のために問題を解いてはならない」

>>272
貴方に聞きたいんだが、
この論文は、LISPコミュニティのようなものに
向けて書かれたものなのか、
それとも広く計算機科学に関わる人々に
向けて書かれたものなのか？

>>275
>「ユーモアを解さない人のために問題を解いてはならない」

ここではこういうべきだろう。
「間違いをユーモアと言う人のために問題を解いてはならない。」

>>276
272じゃないけど、件のpaperは
MIT AI Memo 379
となっているから、AIラボのメンバーが想定読者と思われ。

>>277
読んでから反論しようね。

>>278
ああ、なるほど。

>>279
は？

粘着ウザイ
おまえが冗談を解しないのはわかったから
いつまでも必死に力説してないで話戻せよ

えー、君は>>215かな?
別に君が間違ってるわけでなく、
steele が内輪しか通じない用語を使い
外部の人間を勘違いさせるようなことしたのがいけない
ってことにしといて、そろそろやめようよ。

最後に一つ

>>281
粘着ウザイ
おまえが数学を解しないのはわかったから
いつまでも必死に力説してないで話戻せよ

　　　　　　　　 　／￣￣￣￣￣￣￣￣￣￣￣￣
　　 ∧,,∧　　＜ 来週のこの時間は、
　　ミ*^ーﾟ彡日＼＿「Curry-Howard対応」デスマッチをお送りする予定です.＿＿＿＿＿＿＿＿＿＿＿
　　ﾐつ　 つ======
　ξ　ﾐ　 ﾐ ﾐ
　ξ,,U,,U,,ﾐ

「Curry-Howard対応」デスマッチのリファレンス:

ttp://research.microsoft.com/Users/luca/Drawings/CurryHoward/CurryHoward.pdf

みんな元気だねー
こんなこと書いてるひまがあったらPPL2002にでも投稿しておくれよ
温泉行こうぜ！

>>274
おいおい同値関係以上の何かを
含む｢恒等関係｣などという関係は無いぞ。
もし代数的な同値関係をそう呼んでいるとして
"="をそれ専用の記号と考えているとしたらそれは誤りだ。

計算機科学では"="は問題空間内の定義に依存するんではないのか？

ま、「学の無いやつ」なんて、学のあるやつ（本当の意味で学のあるやつなんて、どのくらいいるんだ？）の言う事じゃないと思うな。

つか、勝手に勘違いして勝手に「間違ってる」と決めつけて
勝手にスティールのせいにした「外部の人間」がひとりいるだけだろ？

バカは無視してさっさと次の話題に行こうよ。

次の話題つか、なんの話をしてたんだっけ？？

そうだ、話題についていけなくて、クロージャって何？って質問してたんだった。
あと、「メソッド」についても、厳密な定義が欲しかったんだ。
どーなの？

>>287
は？
ウルトラ馬鹿だなおまえは。
おまえ本当にそんなこと思っているのか？

>>290
>つか、勝手に勘違いして勝手に「間違ってる」と決めつけて
>勝手にスティールのせいにした「外部の人間」がひとりいるだけだろ？
>バカは無視してさっさと次の話題に行こうよ。

スティールのせいにしているとどうして読めるんですか？

>>290
>勝手にスティールのせいにした「外部の人間」がひとりいるだけだろ

それはすこし世界が狭すぎるとおもう。

>>288

>>263
>俺としては、Schemeとかは他の言語に比べて
>数学の諸成果を積極的に取りこんでいる言語だと思っていたので、
>数学の記法というかそう言うものに関しては
>ちゃんとしていると言うか、一目置いているというかそう思っていたんだ。

>>289
>本当の意味で

どんな意味ですか？

単に「そういう言葉遊びだったのか。誤解してたよ。」と言えば
すむことなのに、言葉遊びの方を「有害」な言葉遊びだとか、
学のない奴にしか分からない言葉遊びだとか、
いちゃもんをつけるのは醜いよ。自称「外部」の人よ。

>>296
おまえこそ話をそらすな。
馬鹿が。

>自称「外部」の人よ。

は？

｢おまえこそ｣というか、
「おまえは」だな。

>>296
>単に「そういう言葉遊びだったのか。誤解してたよ。」と言えば

>>263
>俺としては、Schemeとかは他の言語に比べて
>数学の諸成果を積極的に取りこんでいる言語だと思っていたので、
>数学の記法というかそう言うものに関しては
>ちゃんとしていると言うか、一目置いているというかそう思っていたんだ。
>まあ別にそういうことならそうでもいい。

というかな、
Actors≡Closures(mod Syntax)
は言葉遊びとして理解できるが、
modがexcept forだというのは言葉遊びではない。

どうでもいいよ。
互いにアホは放置ってことにしとけ。
もうこだわるな。

>>293
なるほど数学を知らん奴はそういう反応をしめすのか。

>>302
いや数学を知っていてもそうだと思うよ。

恒等関係ってなに？
恒等式の間違いじゃないのか？

>>274
3≡5(mod 2)が恒等ではないとでも言うのかねぇ
それとも3=5(mod 2)と書くべきだと言ってるのかな
あほか

昔、数学を知ってるけど、計算機のこと全然知らないやつがいて、数学から一歩も外に出られないでかわいそうだったなぁage

でもまあ数学と計算機科学のどちらが難しいか聞かれたら数学って答えるな。
比較するようなもんでもないけど

多分こいつら同値類別しても同じクラスに属するな。。。

>>308
３個セットギコ付きで４０００円（わんふぇす価格）

同じと同型については、なんともいえないけど、
恒等と同型（同値かどうかは知らない）ということなら、たぶん違うと思うよ。
SCIPの1.3.1をみてみると、

aからbまでの整数の和を計算する手続、
与えられた範囲の整数の三乗の和を計算する手続、
級数の項の並びを計算する手続

の3つを比較して、そこに共通する関数sumを作ってる。

(define (sum term a next b)
　(if (> a b)
　　　0
　　　(+ (term a)
　　　　　(sum term (next a) next b))))

これが同型写像とか言われるものじゃないかと思う。たぶん。
そんで、恒等写像として、identityを定義している。

(define (identity x) x)

この2つが同じもの、というか、おんなじ役割を持つものかといわれると
やはり違うんじゃないだろうか。
ここから考えると、
同型というものと恒等というものは違うんじゃないだろうかとも思う。

>SCIPの1.3.1をみてみると

SICPだった。間違えた。

別にsageるつもりはなかった。

もちろん恒等写像と同型写像は違う概念だが
何の話をしているんだ？>>310

いや、なんか、
Actors≡Closure(mod Syntax)
に関して、それは同じだといっている人と
同型だといっている人がいたんで、
そんで、isomorphismとかいう概念があって、
それをスティールという人が言っていたとあるので、
まあ、同型なんじゃないかなと。
同じという意味ではないのではないかと。

なんの話をしているのか、判りやすく解説きぼーん

｢関係(aRb)｣と｢写像(f:a->b)｣が混乱してるんじゃない？

>>305
x^p-1≡1(mod p)
（ただし、pは素数で、xはpで割り切れない任意の整数）

は恒等ではないがな。

>>317
なんのこっちゃい？
恒等式と方程式(不能も含む)は違うぞ？

>>318
すまん、何がいいたいのかわからん。
分かりやすく説明してくれ。

なんでこんなに判りにくいのか謎。
＞Actors≡Closure(mod Syntax)
これが出てきてからついて行けなくなりました。＞このスレ
なんの話をしてるんだよ。

>>319
分からんのはこちらだが？
方程式は当然(ほとんどの場合)恒等式ではないが
それがどうした？

>>315
んー、クロージャとオブジェクトの関係について、
スティールっていう人が、Actors≡Closures(mod Syntax)
って言ってるらしいんだよ。これが。
その解釈について、一方の人は、等価であるとか、
"Actors are just closures (except for slight syntax difference)."
であるとか、言っているんだよ。
それに対して、別の人は、それはisomorphicの別の言い方であって、
同型だとか、同値だとか、合同だとか言っているんだな。
それで、そのスティールと言う人はまた別のところで、
isomorphismとか言っているらしい。
だから、前者の人は、isomorphismは
"要するに同じ"って意味だと言っているんだと思う。
ただ、SICPを見ると、同型と恒等は
ちゃんと区別されているような感じだったし、
そこから考えると、等価（たぶん同じってことだと思う）と言うよりも
同型って言った方が正解なんじゃないかなって思った。

結局、
ActorsとClosureとをちゃんとお勉強して、どういうふうに「同じ」なのか、各自判断せよ。
で、ええのんか？

>>321

>>274
>3≡5(mod 2)が恒等ではないとでも言うのかねぇ

こう言っていたもんで、
まあそういう式が恒等でない場合を示してみたんだが。
従って、＝と≡は違うと。
3≡5(mod 2)はやはり「記法として」、
3=5(mod 2)と書くべきではないと。

というか、274が恒等であるならばこの場合でも=とすべきだと言っていると
305がなぜ思っているのかがよく分からんのだが。今更だが。

>>>274
>>3≡5(mod 2)が恒等ではないとでも言うのかねぇ

>>305
>3≡5(mod 2)が恒等ではないとでも言うのかねぇ

すまん、こうだった。

オレは数学の授業をサボっていたので良くわからんが。

同型というならせめてActors→Closureとなる写像
（トランスレータプログラム？）を示してもらいたい。。。

3≡5(mod 2)？同値類？普通はＧの正規部分群Ｈが見つかって
Ｇ／Ｈが再び群になるような構造が存在するから価値がある
のであってこの議論自体は糞ですね。。。

>>326
>同型というならせめてActors→Closureとなる写像
>（トランスレータプログラム？）を示してもらいたい。。。

それはMr.Steeleにやってもらうしかないですね。

というか、元々そんな厳密な話ではないでしょう。
この同型性も一種のアナロジーだと思いますよ。
ただだからといって、同じってことでいいじゃないかと言うと、
やはり意味のずれが生じると思います。
日常生活の中であっても、同じと同型は普通は意味が違うでしょう。
たぶんですが。
それにやはり技術的な話は
より正確に意味を伝えられる表現を採用すべきだと思います。
下らないかもしれませんが、そのようなより正確な表現の積み重ねなくして
正確な意味の伝達もあり得ないわけですから、
技術者としてやっていく以上
そういうことはとりあえずちゃんとしておいたほうがいいと思いますが。

「あなたとわたしのにほんご、ちょとちがいます、おー、ずいぶんちがうです。」
って言ってるわけか？こいつら。

つか、どっかほかでやってくれよ、いいかげんよ。

327>>
抽象と矮小の違いには気をつけるべきってことだね？
＃まぁその場の雰囲気っちゅうのもあるでしょうが。。。

>>324
すると
x^2-2x+1=0などの方程式は
x^2-2x+1≡0と記述するべきだと？
どこからそんなわけの分からん事を思いついたんだ？

同型というのは写像に関して言う言葉では？
ある元とある元が同型などという表現は聞いた事がありません。

変数が入った恒等式は、やっぱり変数がすべての値の
時に成り立たなくちゃだめだんですよね？

なんかごちゃごちゃくだらねーなー．

Hewittのアクターモデルに対してSteeleがλクロージャを持ち出したんだけど，
これはアクター本来の非同期性については何も言えてなかったんだよ．結局アク
ターモデルの形式化は米澤やAghaの仕事までできなかった．Steeleの仕事自体
はアクターの形式化を離れてそれ自身非常にいいものになったんだけどね．

>>330
なんでそうなるんですか？
なるわけないだろう。

>>333
私はそのあたりの歴史を知らないんですが、
そのあなたの言っている話からすると、
ultimate declarativeの
アクターとクロージャの関係についての話は、
結局現代においても妥当性を持つ話なの？
アクターの形式化を離れない場合。

>>334
そりゃわざわざ記号を区別する必要は全然ない
でも>>324はそう書くと思い込んでいる

>>331
それについては、Steeleさんに聞いてみてください。
私からはなんとも・・・

>>336
a ≡ b (mod c)
の場合は、≡を使うべきだといっているだけでは？
というか、ここで=を使うと、
つまり、a=b(mod c)とすると、
話が合わなくなる場合があるっていってるんじゃないの？
x^2-2x+1=0は関係ない話のような気がするけど。
というかこれって、x=1ってことじゃないの？

>>324は恒等式でないならば=を使うべきではない。と
解釈できてイミフメイ

＞x^2-2x+1=0
は当然恒等式ではなく（全てのxで成立することはない）
方程式だから>>324に従えば≡を使うことになる

＞3≡5(mod 2)
これは当然恒等式。>>324に従えば
3=5(mod 2)と書くほうが妥当かな

＞x≡5(mod 2)
これなら方程式だね

とりあえず>>324は何か重大な勘違いをしているようだ

>>339

>>324の
>というか、274が恒等であるならばこの場合でも=とすべきだと言っていると
>305がなぜ思っているのかがよく分からんのだが。今更だが。

これとの関係は？

Actors って何ですか?

俳優です。

>>340
これじゃん？
はっきり言って何が書いてあるのか分からんが
恒等関係ってなに？

>>274
＞=というのは、恒等関係を表すものだ。
＞同値関係には使用しない。
＞もちろん恒等関係は同値関係の中に含まれるが、
＞だからといって、単に同値なものを恒等と言ったりはしない。
＞それでは記法としては話にならない。

≡は合同っていうよね普通。

はなしずれまくり。しょうじき、よそでやってほしい。

>>343
うーん、つーか、よく分からんけど、
俺としても、恒等ならば=にしろとは書いてないような気もするけど。
単に同値なだけの時には=にするなといってるだけのような。

恒等関係がなにかは説明できないけど、
等しいということじゃないの？
俺は確かそういう言葉を数学関係の本で見たことあるけど。
何の本でかは忘れたけど。

いいかげん、関数型言語の話しろや(ﾟДﾟ)y─┛~~

sodesune

>>346
googleで恒等関係を調べるとどうも
経済学で平衡になる二量の関係のことを
まれにそう言うだけのようだ。
いわゆる同値関係や順序関係の類の数学用語にはなさそうだ。
上にもあるように恒等式のことだろう。

私としてはむしろ除余による同値関係は
a^{p-1}=_{p}1などと単に下付きで書くと美しいと思う
\equivでもいいけどごたごたしていて好きじゃない

>>347
ねたふりなよ

じゃあネタを振ろう。
関数型言語があるとどうしてそれをOOにしようとする奴が現れるのか？
CommonLisp(関数型？？) -> CLOS
ML -> Ocaml
Haskell -> OHaskell
「状態」を捨てるために関数型にしたのに「状態」の塊なオブジェクト指向を
しようって言うのは本末転倒というか、関数型に喧嘩売ってるような・・・・
理由説明を求む。

関数型でOOというのがよくわからん。
簡単な概要を教えて。

・ＯＯに対する羨望／あこがれ／幻想を持つ人間が多過ぎるから
・ＯＯを冠する製品を作ると商売になると誤解している人が多過ぎるから
・ＯＯをやっていると自己満足できる人が多過ぎるから
・ＯＯが何であるか本当のところは分かっていない人が多過ぎるから
つまりＯＯとはソフト産業における壮大なマスターベーションネタなんですな(w

＞「状態」の塊なオブジェクト指向
そりゃ、へたくそが書いたらそーなるだけだろ。

>>349
一応部屋の掃除ついでに
恒等関係が載ってる数学関係の本を見つけたんで、
報告する。

「無限と連続」岩波新書　遠山啓　著　1952年出版

ロングセラーの本だから今でも手に入るはずだと思うけど。
ここにこうある。

「この同値律を満たすものの中には恒等関係a=bがあることはいうまでもない。
それは最も厳しい同値関係であり、また反対に一般の同値関係は
恒等関係のゆるめられたものであると言える。」

一応報告までに。話の腰を折るつもりはないから。

遠山啓という人はどんな人かについて、
http://www.google.com/search?q=%89%93%8ER%8C%5B&hl=ja&lr=
等を参照。

>>350
1.関数型言語だと、実用的なプログラミングを行うのに不便だから。
2.OOを形式化する事で、例えばデザイン・パターンとか、テンプレートについて、
　客観的な評価をしたいから。

>>354
遠山啓は(日本で)数学を勉強した人なら誰でも
知っているような有名人だよ。
結局その用法が広まることはなかったようだね。
今現在の数学体系の集合論的定義からすると
何かが｢特別｣な概念であるとか｢厳しい｣条件である
ということ自体古臭い言い回しになってしまってる感が
(私には)ある。

OHaskell？
Haskellの何処をいじったら、オブジェクト指向になるんだろう？
いまいち想像出来ないな。

>>356
>結局その用法が広まることはなかったようだね

なかった？
もう2002年になろうという現在においてさえも
絶版ではなく売れているらしいがな。

というかな、この本は、「数学への招待」として書かれた本なんだよ。
厳密に何かを語ると言うよりも、
多くの人に平易に数学の概念を教えようとしている本だと思うがね。
お前はどうやら遠山が数学教育に力を入れていたことは知らないようだな。

>今現在の数学体系の集合論的定義からすると
>何かが｢特別｣な概念であるとか｢厳しい｣条件である
>ということ自体古臭い言い回しになってしまってる感が
>(私には)ある。

こういう下らんことを言うな。
それも出版年は1952だ。時代を考えろ、ボケ。

というか
「カントールの集合論が破壊しつくした廃墟の上に、「結合」
という一つの新しい相互関係を打ち立てるのが新しい代数学
である。」　「無限と連続」遠山啓著　より

昭和20年代の本だけど、数学の入門書でこれよりおもしろい
のないね。
　

>>358
＞>結局その用法が広まることはなかったようだね
＞
＞なかった？
＞もう2002年になろうという現在においてさえも
＞絶版ではなく売れているらしいがな。
実際に使われていないな

＞それも出版年は1952だ。時代を考えろ、ボケ。
？

>>360
＞＞それも出版年は1952だ。時代を考えろ、ボケ。
＞？
？


君は結構もぐりだね。
その「無限と連続」を知らないなんて。

ｱﾌｫが１匹おるよ。ｱﾌｫが。

＞君は結構もぐりだね。
＞その「無限と連続」を知らないなんて。
？

>>363
＞＞君は結構もぐりだね。
＞＞その「無限と連続」を知らないなんて。
＞？
？

じゃあ、知ってたし読んだ事もあるってこと？
？だけじゃ駄目だと思うよ。
どのような点がどういう風に分からないのかを明らかにしないと。
それができなければ来ない方がいいと思うよ。
もう恒等関係の話も止めるべきだと思うし。

>>364
この話にどう関係があるんだ？

>>353
例えばCLOSでそうじゃないOOをどうしろと言うのかね。
メンバ変数が状態以外の何を保持すると言うのかね。
へたくそとか言う問題じゃなかろ。
「状態」の塊だからこそGUIの構築がOOでやりやすいわけだし。
「状態」の塊でないコードへのポインタを切にキボンヌ。

>>355
2は同意ですね。なにもHaskell使わんでもとおもいますけど。
1は不同意。GUIとかいいだしたらどうにもならないけど、
そうでないなら別に問題無いとおもいます。
しばらく前に、10個ぐらい関数があって、それの合成の順序を総当たりして(nPn個)
それに無限数列食わせてドウコウってことをやる必要があったんですが、
Haskellだとすぐでした。CやFORTRANでやれと言われたら泣きます。
ま、私にとっては無いと困る「実用的」プログラムだったわけです。
なんかGUIがいるなら別の言語でそれだけすりゃいいんですし。
たしかにMLやHaskellでオフィススイート書けとかいわれたら首吊りたいかも。

>>366
Smalltalkのクラスのソースでも読んでみろ。

なんか話が関数型の話に回帰して来ていい感じ。
恒等関係ねぇ。任意の同値関係が成り立つ関係でいいんだよね。
ああ、ばかばかしい。＝を一般の同値関係に使わないってのはデマだよね。
誤解が生じなければ混用していいし、されてるんだけどね。
なんか元の話の流れから馬鹿みたいにずれててウザイ。
ただのアナロジーを遊び心で記号使って表現しただけでこんなになるとはね。
Actorsとclosureの実質的な内容に話を戻すか350からのネタを引っ張るかに
しようという方向で逝きましょう。

>>368
それは何か違う気が。いや、366への答えにはなってるけど。
Smalltalkのクラスはそれ自体オブジェクトだからなぁ。
ここで366が問題にしてるのはクラスとオブジェクトを峻別するタイプの
OOPLのことなんだろうな。そういう言語で実行時に作られるオブジェクトが状態の塊なのは
事実でしょ。
まあ、だとするとCLOSは例としては間違いなんだけどさ。

>>366
＞「状態」の塊だからこそGUIの構築がOOでやりやすいわけだし。
ＧＵＩが状態の塊だってだけだろ、でＯＯはそれ「も」扱いやすい。
まぁ、「メンバ変数」とかのたまってるってことは、Ｃ＋＋とかＪａｖａくらいしか頭に無いんだろう。
いや、もしかしたら>>366が言っているのは、逐次実行型のマシンが、そもそも状態の塊だというのかもしれん。
それなら理解はできる。
SmalltalkはＯＯとしては、すでに１世代以上前ってきがするから、最近のＯＯの代表にはならないかもしれないが、
インスタンス変数にcontents以外を持たないクラスってのは、結構多かった気がする。
それでも、たとえば、Collectionクラスが#(1 2 3 4 5)っていうのを持っていて、それが「状態」だというなら、
オブジェクトすなはち状態、という意見として聞いておいてもいいがろう。
納得はしないけど。

>>370
ＯＯの「使いドコロ」としてＧＵＩが挙げられる事が多いけど、それがそもそもＯＯの誤解への第１歩って思う。

内部状態のないオブジェクトなんか役に立つのか？

>>373
内部状態のあるオブジェクトの例をなにかあげて欲しい。

関数型からOOに話がずれてるな。350のねたに話を戻そうYO

あ、まさか「内部状態のあるオブジェクトなんかあるのか？」っていう意味じゃない。
内部状態のあるオブジェクトがＯＯであるがゆえに内部状態を持たなくちゃ行けない、
しかし、関数型言語で同じ事をしようとした場合、内部状態を取り去ることが出来るっていう
例があるなら、知りたい。

>>374
ほとんど全てのオブジェクト。
最も簡単なのは1ビットのメモリ。
カウンタなんかよく例に使う。

>>377
ほうほう、じゃぁ、カウンタを例にとって、関数型言語では、どーするの？

>>376
あるわけがない。

>>378
カウンタに相当するものは(副作用のない)関数型にはない。
同じ機能を全く違う方法で実現するだけ。

>>365
つまり、数学知ってそうなのに
恒等関係という言葉を知らない人がいて、
ただそれはその本見れば載っているわけで、
更にいうと、その本は結構有名な本なわけで、
だからもぐりなのかなと。
ただそれだけのことなんだけど。
恒等関係の意味が判らんって言ってた人がいたような気がしたんで。

この発言はそのまま通りすぎてください。

>>378
こういう質問が出るってことはおまえさん関数型使わない方？
いや、OOは構わんが関数型も宜しくね。
GUIじゃないOOといえば、培風館のLispの本に例があったなぁ。

つまりだ、ＯＯが状態の塊なんじゃなくて、状態の塊のようなＧＵＩみたいなサービスを提供するのに
比較的向いているってことだろ。
（副作用の無い）関数型言語はそれには向いていない。
だから、ＯＯが向いている分野のために、関数型言語にＯＯを取りいれてみる実験は、アリだとおもうが。
どーだろう？　>>350の答えになってるだろうか？

>>381
恒等関係という言葉は多くの本に載っていないから
一般的な言葉ではないだろう。遠山啓の創作か？
どうでもいいが。

＞任意の同値関係が成り立つ関係
この定義は分かりやすくていいね。

>>371=383
うまくまとまった感じかな？
でも関数型言語の利点は副作用が無いことだけじゃなくて、
数学的な感覚をそのまま持ち込めるところなんじゃないのかともおもったり。
367なんかはそういう意味での関数型の恩恵をもろに受けたってことだろうか。
とするとだ、関数型言語にOOを採り入れると言うよりOOを関数型でやってみる
実験って事だな。だとすれば面白いかも知れないな。副作用を許すと言う妥協をしなければだが。

>>382
関数型言語は、実際に仕事で使う場面はあんまりないです。
ただ、その前段階の調査とか、検算とか、そういうときにたまにつかいます。

微妙にネタ切れか？
むぅ。関数型は学生とか言語理論とかやってると絶対使うよな。
仕事(アプリケーションソフトのプログラマ？)とかでは確かに使いがたいんだろう。
新人教育するのにコストかかりすぎるだろうし。Schemeは構文覚えんのは簡単だけど使いこなすのは
とても難しいよな。Haskellなんか覚えんのも使うのも難しいし。大体、入出力があんな
有り様じゃ確かに普通は使いたくなかろう。そこに萌えるのが学生たるゆえ。
Haskellがメジャーに成る日を夢見て今日もλ式。

>Haskellがメジャーに成る日を夢見て今日もλ式。

なんかカワイくてウケたのでage

関数型言語で直接プログラミングする機会がどれだけあるかは疑問でも、
JavaやRubyなんかで関数型プログラミングを併用するのはデバッグ効率
が向上するのでステキだよ。

# 無用な代入を避けたり、メソッドオブジェクトを引数に渡したりね。

まあ、関数プログラミング、というかプログラミング言語理論に関して
一通り勉強した人間なら、
≡とでたら、同値、
isomorphismと出たら、同型、
とまずは訳してみるよな。
いきなり「同じ」とは訳さないよな。
まあ、全部読めば要するに同じってことかと
思えてくるのかもしれないけど。

つーかレコード型のポインタ渡しが理解できない人が余りに多かったから
発生したんじゃないのか？OO

逆にOOでオブジェクトを構築しておいてそのポインタを渡してやる関数ってのは
関数志向でもありOO志向でもあると思うのだが

出来上がったプログラムの動きを考える場合ooだとプログラム自体の複製が
複数できるので非効率という気がする。
仮想関数関係も関数自体のポインタで切り替えたりできるわけだから
結局は個人の好みとせいのうじゃないの？

oo否定派だけど低レベルとのクッションとして4世代くらいの継承までは
まぁ許容かなってかんがえている。
もっともそうでないとCOMとかも使えないし

＞つーかレコード型のポインタ渡しが理解できない人が余りに多かったから
＞発生したんじゃないのか？OO
こういうのって、どの人のＯＯの捉え方を反映してて、おもしろいよね。

＞ＯＯ志向
オブジェクト指向志向？

どの人→その人

>>384
そう言うことじゃなくて、
やっぱりどの分野にも良書といわれるものがあって、
それを読んでいないで何かをいうのはどうかなって。
つまり、良書とされているものを読まずに
一般的でないとかいうことで知らないことが免責されるかのようなことは、
どうかなと思ったんですよ。
だからもぐりって言ってみたんです。

>>395
そうは言えある本を必ず学び準拠するべき｢良書｣と
決めてしまうのは単なる権威主義とでもいうべきものであって、
過去の業績を踏襲しつつも常に反省を忘れないことが重要な
学問にあってそれは望ましいことではない。
それぞれ多種多様な方法で学んだ者々がそろって
時には相対する立場にたって議論をすることが学問の進展や、
個人の理解の促進に貢献すると思われる。ある一つの本を読んでおらず、
そしてそれ故その本における定義や方法を知らないという理由で
議論を拒み非難の対象とするのはいかにも｢幼稚｣であり、また
｢非学術的｣な行いではないだろうか。これが個人に対してでなく
派閥間で生じれば互いに意思疎通のない｢宗教｣とでもいうものにでも
発展しよう。第一そのような事を行えば、どちらが｢優れて｣いるかなど
永遠に知りえない。常に相手の考えを理性的に判断する態度が
学問には必要だろう。

また、常に進展してゆく学問においてその書物の蓄積は膨大になる。
幸いなことに科学的学問はその結論に一定の収束を見せ、
誰が語ったかは問題にならない。その結果、過去の良書のエッセンスを
取り入れつつ更に改良をほどこし時には新しい結果を盛り込んだ
書物が次々と出版されている。よって過去に良書であった本に
大きく捕われる事はあるまい。ユークリッドの原論は今でも良書と
呼ばれはするがその業績は多くの本に取り入れられており、
我々が顧みることはあまりない。時代の変遷、多種多様な環境の中様々な
方法で勉強するものがおろう。己のたどった過程を相手も
たどるとは限るまい。そのような人々を｢もぐり｣と言ってしまうのは
いかにも度量が小さいといえよう。また相手もそう思っているやも知れぬ。

2001年糞スレプログラミング言語部門にノミネートされました。

>>391
>逆にOOでオブジェクトを構築しておいてそのポインタを渡してやる関数ってのは
>関数志向でもありOO志向でもあると思うのだが

値同値と参照同値の問題はどうなるの？
参照透過性を失ってしまえばもはや関数型とは呼べないような・・・・
「-3」を表現するのに整数クラスのインスタンス「-3」を一意に作って
それへのポインタを使うだけにすると言うなら参照同値＝値同値と言うことになるのかな？

関数言語処理系の作成者とかなら必要なんだろうけど、普通のプログラミング
の時にそんな事はしてられないんじゃ？ というか、Cで関数指向するくらいならさっさとMLなり
Haskellなりを使うほうがストレスに成らないような。

遠山先生もいいけど、N.Bourbakiでそ

>>377
immutableなオブジェクトを作ったり使ったりしたことない人？

>399
激しく同意。ブルバキだよな、やっぱり。
あ、でも基礎論の当たりちょこっとうさん臭かったりするんだよな。
正則性公理のあたりとか。
つうか、最近の学生は遠山先生の本なんかよんでないだろ。

＞つうか、最近の学生は遠山先生の本なんかよんでないだろ。
ブルバキはもっとだろ。

ブルバキの本を最近の学生が読むなんて一言も書いてないけど(爆
いや、良書なのになぁ。
でも、ずっと上のほうにあるような言われ方する程遠山センセの本が読まれているわけもなく。

>>396
つか、そんな大仰な話をしているのではなくて、
なんというか、恒等関係なんて言葉はないというようなことを
言っている人がいたので、
そのことでなんと言うかあげつらっている人がいたようにも見えたので、
ただまあそう言ってみたんだけど。
例えば、関数型言語では、武市さんの本なんかは、
必読とまでは言わないような気もするけど、
やっぱ一通り読んでおかないと議論に参加するのはどうかなとも思うし。
まあそんなようなことを言いたいんだけど。

もうこの話題止めて398からの話題をひっぱりましょうね。
得るものが少なすぎます。

議論の相手を選ぶ基準は色々あるだろうが
本を読んだかどうかで決めるなら、スレタイトルは
｢武市ってどうよ？｣とかにするべきだな。

OO＝クラス型≠非関数型　って認識じゃないのか？

折がいいたいのは
クラス型＝クラス変数文メンバー関数の本体をメモリに展開する
関数型＝作成済み関数のポインタのみを扱う
というのがコンパイラ自体の違いだから使いどころとしてクラス型を使っても
全体的に関数型にできるということ。
あとローテクでいうならば関数型とOOの違いは関数に対してBレジスタなりが
スタックフレームになっているかなっていないかということなんじゃないの？

あとOOじゃないと保持状態が作れないというけれど
レコード型変数で保持してポインタ渡しにするならば
関数自体はコンパイル時に直接生成されるけれど変数は動的に作れるから
プログラムはOOではないけれど機能的には同じで多分実行時メモリは小さい。

これは少なくとも>>376への答えにはなると思う。
例えば>>378はカウンタを例に出しているが

カウンタ値は変数なりファイルなり、あるいは名称や最終更新時間をもったレコードだとして
それがデータベースやファイル、変数やリストになっているとすれば
関数型で先頭アドレスと処理内容を渡してやれば作業はできるし
コードも複雑化しない
OOの場合は実装コードもクラスに記述するか継承するので
パラメータ無しのメンバー関数が作られるが実質的にはスタックフレームが暗黙的に形成されていて

Windowsの場合コントロールごとのステータスと挙動をOOで記述するとわかりやすい気がするが
レコード型の記述と関数型のほうが効率は良い。
実際OOでもソースの中低レベルはそうなっているはず(Ex.DirectXのEnum関係とか)

ということでどう？

>>398 特定の学会に属していなければ関係ないんじゃないの？---参照透過性
できるのとやらないのは違うと思う。
別にレコード参照型で新しいレコードを生成するならば
学者さんいわくところの”関数型”になると思う。
ポインタは保存場所なんだから
プログラマーが節約のために同じところにするかどうかというだけの話

とりあえず折がいっているのはOOに対する関数型
どうしてもProcedure型の関数がいやだというなせば
関数の返り値が新しいレコードのインデックスかポインタになれば
へっぽこがくしゃさんでも気が済むでしょう。
ようは元を残してコピーを作るか、上書きするかってことだと思うよ。−−参照透過性

極端をいうならばアキュームレータの中身はかわるよね。
AccA＋AccBをコンピューターでやる場合
結果はAccAに入る
この大原則がある上で参照透過性うんぬんというのは単なる無知とはいえないか？

言語というからには”翻訳”や”変換”があるわけで
卓上でぐだぐだいって単位が取れたり本をだせたとしても
翻訳結果や変換結果を無視してたら意味がない

>>406
なんていうか、そういうことを言いたいんじゃないんだよね。
恒等関係を知らないなら知らないと言えばいい訳で、
そんな言葉はないとかいうのはおかしいなって思っただけなんだけど。
知ったかぶりはよくないんじゃないかって思うんだよね。
その知らないことについて議論に参加するのも何だか滑稽だし。

>>408
>極端をいうならばアキュームレータの中身はかわるよね。
>AccA＋AccBをコンピューターでやる場合
>結果はAccAに入る
>この大原則がある上で参照透過性うんぬんというのは単なる無知とはいえないか？

>言語というからには”翻訳”や”変換”があるわけで
>卓上でぐだぐだいって単位が取れたり本をだせたとしても
>翻訳結果や変換結果を無視してたら意味がない

それは、ひとつの見識として納得のいくものですけど。
でも、高級言語の価値は低水準の実装を隠すところにありますよね？
関数型言語の良さっていうのは、手続き型高級言語がなんだかんだ言っ
てアセンブラにおける常套句を言語構造に翻案したに過ぎないところ
とは別次元のものだと思うんですよね。
手続き型高級言語がメモリやI/Oのアクセスと制御構造によって成り
立っているのに対して、関数型言語は意味を定義する。その違いは
syntax sugarではないと思うんだけどね。

>>407
「OOじゃないと保持状態が作れないというけれど」
え、誰が言ったの、そんな事。　（驚愕

>>408
参照の透明性は
「変数の上書きをしない」ってことよりも、
「同一表現式は同一の値を表す」ことのほうが本質だと思うが。
つまり、同じ変数は常に同じ値を表すだけでなく、
同じ関数に同じ引数を与えてやると、同じ返り値が返ってくるってことが大事。

>>409
ある用語が正しいか或いは正しい用法かどうかなど
個々の信念の問題であって知識の問題ではあるまい。
もちろん正しい用法においてその言葉は｢ある｣のであって
そうでなければ｢ない｣言葉を使っていることになる。
流行語などに対して文句を付けるのをたまに聞くだろう？
｢ない｣という主張が｢おかしい｣などということは全くない。
そしてこれは概念を理解しているかどうか、すなわちその事を
知っているかどうかとはまた別問題だ。その点で
｢知ったかぶり｣という言葉で表される事態では全くない。

この｢恒等関係｣にしてもその内容からすれば｢汎同値関係｣とでも
名づけたほうがよっぽどましだろう(と私は思う)。あなたは
そのような言葉は｢ない｣と主張するかも知れないが。

専門用語でこの様なことはよく起こる。それは研究者同士の
交流が希薄だったり或いは稀に対立したりするからだ。
その場合相手の用法を全く知らないことが多い。
それは｢知らないならば議論に参加する資格がない｣などと
済まされる問題ではなく、一々確認を必要とする。
最終的な用語についても歩み寄りがない場合もある。
2chでの様に喧嘩腰の人はまずいないが。

>>413
４０９が問題にしているのは用語の正誤じゃないでしょ。
はっきりいって、「そのような用語はない」はすごく強い言明だよ。
よっぽど確信がないかぎり、使うべきものじゃないと思うが。

まあ、２ｃｈみたいな場で
「これを読んでない奴は議論に参加するな」ってのも
ちょっと乱暴だと思うけど。

答えになってなさそうです。
そもそもＣＰＵに近いところでの動作の話になると、たいていの言語は、
コンパイル後のコードやＶＭの動作の話になって、その言語の持つ特徴
が、どっかいっちゃうから。

＞あとOOじゃないと保持状態が作れないというけれど
おれは>>376ではそんなこと書いてない。
ＯＯであるがゆえに状態を持っている→関数型で書きなおすと状態がなくなってすっきり
っていう例があるのか？って書いたんだ。>>411には通じてるね。
だから答えにはなってないんだよ。

俺があと言いたい事は>>410が書いてるのとだいたい一緒。

376>>407=>>408　（あとで自分で見る時用））

>>414
＞「そのような用語はない」
これは用例がないことを意味するのではなく
それを誤りであるとする言明。用例があるのは
用例に対する応答である以上当然ある。この発言が
発言者の言語に関する正誤感覚に基づいているのは
言うまでもない。この点においてもちろん｢すごく強い言明｣で
あり、強い信念を感じとれる。この時どの程度多数の支持が
あるかは(発言者に影響しはするが)、特に妥当性に関しての信念ならば
多くの発言者は別問題と考えるだろう。

>>414
んー、議論に参加するなって言うか、
知ったかで参加するなって言うことなんだけど。
知らないということを前提にして
聞く意味も込めて参加するということならば
２chを問わずかまわないと思ってるけど。

どれが知ったかなのかをどいつが決めるんだ？
>>418か？おまえは神か？

知ったかの本人が気を付ければいい。

「無知の知」を他人に要求するとはすごいね。

別にすごくもないと思うが。
ある程度は誰でもやってる。

あーあ、こうやって粘着君がいるとせっかくのスレが台無しだよな。
わかった、わかった、知ったかは良くないよ。それは事実だよ。
あなたの主張は認めるよ。
だから関数型言語の理解・研究・発展に貢献する発言をしてください。
あるいは関数型言語のここがダメとかさ。

>>423
君もね

>>419
言うことが大げさ

http://www.dream-fact.com/lovers/
http://anny.kir.jp/bbs-a/imgboard.cgi
モロダシ画像、チャイルドポルノ、バンバンアップ！！
おめ＠丸見え！！
他では有料のアノ画像常時アップ！！

前にもどこかで書いたんだけど、関数型言語を使っているときはUnitTestとか
要らない印象があるのね。手続き型言語だと、UnitTestを使って定義域での動
作と定義域外での動作をきちんと検証しないと気が済まない（テスト中毒って
奴ですか）。だけど、Schemeとか使っているときは、テストとプログラミング
が一体化しているというか、わざわざテスト用のコードを書いたりしないな。
まだ経験が浅いからかしら。それとも関数型言語だからかしら。

>427
テストが問題になるような規模のコードを書かない/書けないから

＞UnitTestを使って定義域での動作と定義域外での動作をきちんと検証しないと気が済まない（テスト中毒って奴ですか）。
きちんと検証するのが、ごくごくあたりまえです。
むしろ、きちんと検証しないとあとがたいへん。
でもしない人も結構多くて、そういうやつがプロジェクトの足を引っ張るんだよなぁ…

武市先生の訳は巧いと思ふ今日この頃。

って武市正人(翻訳)「関数プログラミング」ですか？

本屋で見比べて、萩谷昌巳 著「関数プログラミング」
買っちゃいました!

どの言語が一番おすすめ？

Prolog

>>428
>テストが問題になるような規模
ってどれぐらい？

>>432-433 ってなんだー！Prologは一階述語論理に基づく論理型言語。
　　　　　宣言的プログラミングが良く似合う。

　　　　　ところでどっかに書いてあったProlog++, Mercury てナニ？

>>435
Prolog スレにでてたね。

Mercury は
http://www.cs.mu.oz.au/research/mercury/
> Mercury is a new logic/functional programming language
ということで (FAQ for comp.lang.functional にも載ってるし)
このスレ向きですかね。

http://pc.2ch.net/test/read.cgi/tech/1008220265/n170-171
俺も訊きたい。

>>434
>>テストが問題になるような規模
>ってどれぐらい？
関数言語厨房が書ける最大の行数+1

>>438
おいおい、一行か?

禿しく一行！

>>427

Hoare Logic とか Curry-Howard isomorphism のあたりかな？
プログラム検証を支援する仕組みとして、
・型システムの導入とか、
・事前条件/事後条件の記述(Eiffel)とか、
・形式的仕様記述言語による仕様記述とか、
いろいろありますよね。

関数型言語だと、どうして「検証するまでもなく」って感じるのかな？
副作用が少なくて、見通しがよいからかな？

>>435-437 ぁ誤爆してる...

高階関数 と 高階論理 の (類似性) を
誰か教えて頂けないでしょうか？

あとついでに、本ｽﾚの流れでいうと、
リフレクション(特にjava.lang.reflect) と 高階関数 って、
何か関係あるんでしょうか、教えて下さい.

>>442
>高階関数 と 高階論理 の (類似性) を誰か教えて頂けないでしょうか？
はぁ？ちゃんとわかるように質問しろよ。

>リフレクション(特にjava.lang.reflect) と 高階関数 って、
関係無い。

>>443 話をスムーズに進めるために、後者の件から片付けておきます。

>>442
＞2.リフレクション(特にjava.lang.reflect) と 高階関数 って、
＞　何か関係あるんでしょうか、教えて下さい.


Javaで高階関数を作れないか、という話題がありました。この話題を考えるに、
Javaでは、メソッドの引数や戻り値に、メソッドを指定する事ができないので、
　　(1)Javaのリフレクション機能(java.lang.reflect.*)を使って、Methodクラスを返すとか、
　　(2)事前に定義済みの内部クラス・インスタンスを返すとか、
　　(3)動的にクラスを生成する拡張機能(jakarta.apache.org/bcel や Java上の言語処理系)を使う、
といった答えしか思いつきませんでした.


ラムダ計算やコンビネータ論理が、プログラムの形式的モデルとして有効であるならば、
高階関数ってのは、オブジェクト指向言語実装系において、どのような意味を持つのでしょうか、
あるいは、オブジェクト指向言語を、ラムダ計算やコンビネータ論理でモデル化するのは
適切なのでしょうか？


かなりいい加減に、

　　実は「リフレクション」あたりに対応させる事ができるのではないだろーか、

と思いつき、先の質問2. をｶｷｺいたしました。

http://www.research.avayalabs.com/user/wadler/pizza/Docs/Tutorial/week3/week3.html#firstclass

pizzaでfirst-class functionsだべさ
参考にするべさ

これはinner classとしてJavaにあるということになっとるべさ

>>445 お、これまたずいぶん関数言語っぽいJavaの拡張ですね。>>piza
＃　　(Generic Java や、JCP14: Adding Generic Types to the Java の祖先ですか.)

結局、この問題は、
「Javaでは first-class functionsの代わりに inner classが実装されているから、
　それを使えば高階関数を作れる」
という回答でよろしいでしょうか？

＃　　オブジェクト指向の形式モデルなんて言い出したのヴァカみたい>>俺

プロジェクト・リーダーの役割とは何か？
お教え下さい。

>>447 すいません、また誤爆しちまったよ.

また、ってあーた、前科あり？

>>442
>高階関数 と 高階論理 の (類似性) を

高階論理では述語だけでなく、述語に関する述語や、さらにその上の述語...
などが記述できます。さて、集合A上の述語PというのはPの特性関数
X_P:A->boolと同一視できるので、A上の述語の述語が書けるというのは
(A->bool)->boolという高階関数が書けると言いかえられます。

というように結びつけられると思われ。

プログラムの検証理論に関して何かよいお手本はないでしょうか？

プログラム検証ツールは前スレにも出ていたPVS
http://pvs.csl.sri.com/
の他にどのようなものがあるのでしょうか？
ちなみにPVSはマスターするのに最低6ヵ月必要らしいの
ですが、他のものもやはりそれぐらいかかるものですか？

こっちにも貼っておかなければ…

"Why Functional Programming Matters"の日本語訳
http://www.sampou.org/haskell/article/whyfp.html

>>452
検証とは違うけどCafeOBJも面白いよ。

>>453
それなかなかいいね。

lispコミュニティにも当てはまるかも…
http://www.towelrecords.com/varitext/001.html

有名な関数型って、
Haskell、ML,LISP,Scheme,Emacs Lisp
ぐらいですか？

APL と BackusのFP 辺りも、歴史的には重要鴨。

>457
http://pc.2ch.net/test/read.cgi/tech/1010157331/l50
のスレの>167さん?

age

.NETの関数型言語はどれだけ使えてる？
知りたいのであげ

>>457

MLが抜けてます〜

http://jbbs.shitaraba.com/study/bbs/read.cgi?BBS=18&KEY=1009968275

>>462
what?

mercuryとはいかなる言語？
なんかえらいでかいパッケージなんだけどよ。

>>465
「おいオメー　さっきから　うるせえぞ
『知りません』『知りません』ってよォーーーー
『知りません』・・・そんな言葉は使う必要がねーんだ
なぜなら　オレやオレたちの仲間は　その言葉を頭に浮かべた時には！
既にGoogleや書籍で調べがついちまって　もうすでに『知っている』からだッ！
だから　使った事がねェーーーッ
『知っている』なら　使ってもいいッ！」

プログラマは知らねど安請け合い

>>466
>>465 は英語読めないんじゃねえの?
mercury って日本語の情報ほとんどないし。

mercuryのチュートリアルを読んでみた。
論理プログラミングをサポートするMLみたいな感じだね。
現実的な感じがするところが、使えそうな・面白くなさそううな。

>>466
「気に入らない事でもあったのですか、何か？」

>>469
ＭＬが論理プログラミングをサポートすると、どうして
＞現実的な感じがするところが、使えそうな
なんでしょうか？
そうかなあ？

いや、MLが論理プログラミングをサポートすると現実的になるんじゃなくて、
論理プログラミングをML的にやると現実的になるって印象を
述べております。はい。

>>472
論理プログラミング言語をつかう人が聞いたら怒りそうだ（笑

ところでみなさん、どのような言語をお使い・・というか使えると言うか、
そういう状態なのですか？

DrSchemeは、電卓代わりにいつも立ちあがってます、Win98です。

Emacs(Meadow)の*scrach*バッファが俺の電卓だなあ。

仕事はRubyだけど、難しくなりそうなプログラムはSchemeで書いて
「本質」に迫ろうとしたり。Rubyで書くと、ad hocなコードで動か
しちゃうことになりがちなので、Schemeでプロトタイピングするこ
とによってそれを避けてます。

つまりみなさんLisp以外は使っておらんと言うことですか？

んなわけねーよ

>>476ad hocなコードって何？

ここの皆さんの仕事用言語は何ですか？

COBOLです。

>>481
ネタじゃないですよね？
とかいいながらおれも
ポストコボルみたいな
Javaだったりするから
人のこと言えないかｗ。

>>479
ad hocは普通に辞書に載っている普通の言葉だが。
「特別な」「一度限りの」という意味。
つまり、ここでは、現在解こうとしている問題に
特化したコードを書いてしまうことを指している。
再利用などまったく考えていないコードのことだ
な。Rubyはスクリプト言語だからad hocなコー
ドを書きやすい。Schemeはそうじゃないってこ
と。

>>483
後付けの、みたいな感じじゃないの？

スタブを先に作っておいて
中身を後から書いたりすることだと
思ってたが、俺、間違ってる？

483が正解だと思う

勉強になりました（485）

>>483
ad hocな理論、とか言うよね？
あれは「後付け」では？

http://dictionary.goo.ne.jp/cgi-bin/ej-more_print.cgi?MT=ad+hoc&ID=EJ-003580.txt&sw=0
http://www.dictionary.com/cgi-bin/dict.pl?term=ad+hoc&db=*

ad hocってのはあれだよな、
国際機関が常設されていない場合なんかを言うと思ったが。
つまり問題が起きるたびに機関を立ち上げて、
終わると閉鎖するって奴。

>>488
違う、「場当たり的な」と言う意味。その問題にしか適用できないような、
いわば理論とは呼べない程度の理論のこと。

>>491
ありがとう。

気持ち的には正しい意味で使ってた。
日本語にしようとは思わなかっただけで。

Excelでマクロも循環参照も使わない場合、関数型言語に似ているといえないでしょうか。

eval がないのが惜しい。

>>493
>eval がないのが惜しい。
evalって、ＬＩＳＰだけじゃないっすか。
関数型言語とevalは関係ないでしょ。

Ｅｘｃｅｌって再帰できるの？

>493
Excelに限らず、任意の言語で関数型プログラミングの手法を
使うことはできるよね。FORTRANではさすがにきついが。

>>495
このあたりどうなのでしょう。
他の言語で関数風にかくことってどの程度可能なのでしょう？

再帰のできない言語では、全然ダメですし、
Ｊａｖａだってコウカイ関数が使えないのであんまり生かせませんし、

たとえばＣの文字列操作のような、関数のような形式で扱えないものも
関数的には扱えないですよね。

>496
なんで他の言語で関数風に書こうとするんだ？
そんなこと考える時間割くぐらいなら関数型言語でもやってみたら？

ＭＬスレッドにレスしようと思ったが（そのような書きこみが多くあるため）
ＭＬに限らないので、やや不便ながらこちらに書きこみます。

お初に書きこみます。
私はＭＬは嫌いではありません。
そういう上で思っていることです。

数学的背景があるからＭＬ（など）は別格であるという見方はちょっとどうかと
思います。
私もＭＬは面白いなとおもうのですが、ＭＬが好きなほかの人の話を聞くと
ときどきやりきれなくなります。

関数型言語が数学的にサポートされているというのは、単に関数型言語が
「ある」数学的視点にとって都合の良い言語というだけであって、それ以上でも
それ以下でもないはずです。
それは言語が優れているということ（この命題はそもそもきちんと定義できて
いませんが）とはイコールではないと思います。
数学的な援軍を得やすいということだけだと思うのです。

たとえば同じ働きをプログラムをどれだけトータルで経済的に開発できるか、
という基準で考えたり、
同じものをどれだけ解りやすく（つまり低い理解力で）作り出せるかといった
風に考えた場合どうでしょう。
数学的な望ましい性質は、単なる手段に過ぎないと思います。
手段と目的がひっくり返っていませんか？

実際、ＭＬは「使えますか？
どなたかがＭＬスレで書いていましたが、ＭＬには今世の中で多いであろう
要求にたいしてまとまったライブラリがほとんどないと思うのです。
ＭＬを使っている人は一体何をしているのでしょう？言語と戯れているだけで
実際に使おうとしないのですか？実際に使おうとすると自然にいろいろな資
産が残るとおもうのですが。

個人的には関数型には非常な可能性を感じます。
ぜひ、仕様の口上じゃなくて「実績」で他の言語を蹴散らしてください。

>>498
つーか、この板でつかってるやついるのか？実は498だけだったりしないか？

>>498
ていうか、実際ML使ってる人なんてほとんどいないと思うけど、
その使ってる人の中には、その数学的な特徴が一番重要で、
それゆえ「自分にとって」別格であると思ってる人がいるん
じゃないかな。
その人がそう思ってることをあなたが否定するのこそ
間違ってることだと思うよ。

>>499-500
>>498さんは「使う」人にもっと話して欲しくて煽っているんじゃないかな。

>>498

数学的背景がある、というのは言語の設計哲学とか設計上の方法論というべき
ものではないでしょうか。そもそも関数型言語には他にも目を向けるべき重要
なセールスポイントがいくつもあります。型推論、型チェック、ポリモルフィ
ズム、モジュールなどがそうであり、それらは生産性とか可読性を向上させる
目的で実装されています。

足回りが貧弱な感は否めません。ライブラリがないから誰も使わないのか、誰
も使わないからライブラリが放置されているのか...悪循環。

数学に対するコンプレックスがあることは否めません。
それはまともなプログラマであれば全ての人が抱くことです。
まずは自分の心に正直になりましょうｗ。

で、話は変わりますが、
言語として優れていても凡人にとっつきにくいのは
やはり実用的な意味ではゼロに近いです。ですが残り僅かな
ところでかなり有用なのではないでしょうか？
クリティカルなプログラムがCで組まれているのは、
生産性という点から見てもあまり誉められたものではありません。
関数型言語の特性としてプログラムの検証を行えるというのが
強みなのですから、そこをもっと前面に出していってもいいのでは？

既存の言語で既に実現できていることを関数型言語でもやってみろ
という煽りは、2ch的に見ても低レベルだと思います。

私自身は、プログラム検証には興味がありそれ、
それが実在するツールではどの程度実現できているのか、
そんなところが知りたくて今、Haskellを勉強しています。

ＭＬはとっつにくくないと思います。
Ｃ++なんかのほうがよっぽど難しいと思います。

難しいという印象がついているのは、関数型言語と世間との接点にいる人が
数学とかラムダ算法とか理論とか、そういう後光を知らずか知ってか、ちらつ
かせながら、良い言語ですよと言ってしまっている事に原因があると思う。
＃強迫神経症のような括弧の嵐、人工知能用の難しい特殊言語という先入観の
＃付いてしまったＬＩＳＰも同様に不幸ですね。

実際、ＭＬの基礎的なことは割とすぐにおぼえられると思います。
大学の講義でＭＬが使われているところのカリキュラムを見てもそれはわかります。

で、たぶん問題はそのあとで、色々なことをしてみようと思ったとたんに、
こういう時にはこういう風に組む、という情報が少ない。（本もソースも）
Ｃ言語などからの「発想転換」が必要なところはなおさら。
そして、ＭＬ風をやっと掴んできたところで、ライブラリが何も無いので、
覚えたけど使えない。中級者手前で脱落。

他の言語でできることができないなんて、とんでもないと思います。
Ｃでウインドウシステムを組むのだって、よく考えればかなり無理をしています。
それがわからないのはライブラリがあるからです。
ウインドウシステムやソケット、データベースなどを、なんらかの関数型に合っ
た流儀でつかえるようなライブラリがあったら、つかると思いますけどね。

検証はたしかにものすごい強みですが、そのためだけに不踏の大地たるＭＬ
に踏み込むコストと、検証に向かない言語を検証ツールでがんばって検証
することと比較してどうかと思います。検証がどうしても必要となるようなプロ
ジェクトではお金もかけられるだろうし。
普通に使えるようになったＭＬで検証が可能だったら人々は中毒になることでしょうが。

MacOSXがもう少し安かったら、
開発用に使ってもいいんだけどな。
Webアプリ限定だけど。

要するにライブラリが無いことに文句が言いたいんでしょ？
「C++にはVisualC++があるのに、なんでMLには無いんだ！ﾌﾟﾝﾌﾟﾝ」
マイナーな言語何だから仕方ないだろというしかないですなあ。（ﾜﾗ

.NETもしくはmono
これで言い訳は通用しません。
ガチンコです。

別に各人使いたい言語使ってればいいだけの話で、
他言語との勝負などはム板の掃き溜めである
撲滅スレの住人がやってればよろしい。
まあ、.NETで色々できるようになるんなら良いことじゃないの？

.NET上の言語って単に各言語の特徴を無くして.NETに乗せてるだけなんだけど。

.NET批判じゃないよ。現実的な話

でも上に書いてあるプログラム検証という意味では
同じ土俵に乗ったといえるんじゃないの？

飛べる力があるのに、どうして飛ぼうとしない。
起きろ！
・・という真摯な内部批判だと思うので、言語の無駄論議といっしょにするのは
どうかと思われ。

.ＮＥＴは全然解決じゃないですよ。
今だって、やろうと思えばウインドウシステムもつくれないことはない。
機能が無いのではありません。
そこに大地が無いのではなくて、どういうわけか未踏の大地のままなのです。

たぶん、こういうことじゃないかな。

同じようなこと、一度や二度感じたことのある人は沢山いると
思うんだ。実際、俺も思ったよ。でもって、ちょっと取り組ん
でみたこともある。

でも、実際にやりはじめてみると、CならCですでに実用化され
ている機能を「作り直す」という行為に終始することになるん
だよね。それって、ひどく退屈な上に、実りのなさそうな作業
なんだよね。

だったら、他の言語のライブラリにアクセスする仕組みや、別
のプロセスと通信する仕組みがあればいいってことになりがち
なんだよ。で、そういう機能は関数型言語にもある場合が多い
わけ。

それに気付いた瞬間、萎えちゃうんだよね。
少なくとも俺は萎えた。

あるものを使えばいいじゃん、って思っちゃうんだよ。
だって、使えるんだから。
それがないとどうしても困るってもんじゃないとな。

……というのが、俺の体験談ね。
でも、それでも頑張ってみるのも良いかも知れない。
SML/NJあたりだと、しばらくSML'97が健在っぽいし、日本語で
読める文献もあるわけだし、ライブラリを作ると、使ってくれる
人もいるかも、だしな。

>>513
出来たライブラリの使い勝手が C と大して変わらないとかなら
あまり欲しくないよね。
でも関数型言語用なわけだし、抽象度が高く柔軟に使えるようなものなら
作る価値があるような気がするし、
そういう方向性で作るならあなたの云うようにならなかったりしないのかな?

>>514
我輩Ｈａｓｋｅｌｌはたしなまむのではっきりとはわからないが、
Ｈａｓｋｅｌの公式サイトの
http://haskell.org/libraries/#guigs
を見てください。

>>513　の言っているのは、ＧＴＫをまんまくっつけただけなどの「望ましくな
い、抽象度の低い」ライブラリに相当すると思います。
オブジェクト指向のそれのように、関数型に即した抽象化の行われたライブ
ラリがあってしかるべきだと思います。

すでにあるじゃない、という意見なら未来永劫Ｃを使うということになりませ
んか？なんか、ダメなＣＯＢＯＬ使いの意見みたいです。
リナックスとかリナックスのウインドウシステム作ってる人みたいに、
作ること自体をたのしんでできないかな、とも思うし。


ただ、問題なのは「関数型のための抽象化」の良い案が凡人には思いつか
ないということでしょう。
どこかの研究者か天才プログラマーか、思いついてプロジェクトを始めて
欲しいなと。

まー、みなさんの言うことはおっしゃるとおりなんですが。

俺もチャレンジしないと言ってるんじゃなくって、過去の挫
折体験をカミングアウトしただけなんだけどなー。

>>516は>>513だよね?
ついでに age

Haskell少々Schemeｻﾊﾟｰﾘな人間の質問です。
Schemeでcurry化って概念はあるのでしょうか?

たとえば、リストの先頭要素とそれ以降のリストの要素の大小を比較し、
小さい要素だけのリストを返す関数を、Schemeのfilter関数(非標準?)を
用いて実現したいわけです。
ちなみに、Haskellなら以下のようになります。

lessThan :: (Num a, Ord a) => a -> a -> Bool
lessThan a b
| a > b = True
| otherwise = False

lessList :: (Num a, Ord a) => [a] -> [a]
lessList ls = filter (lessThan (head ls)) ls

これをSchemeで書くとき、filter関数の(a -> Bool)部分をどう書けば
美しくまとめることができるのか、少々悩んでいます。
filter関数を使わなければ簡単なんですけど、どうせなら使いたい。

>>518
Scheme少々Haskellｻﾊﾟｰﾘな人間の回答です。

curry 化というのはわからないけど
リストの先頭要素とそれ以降のリストの要素の大小を比較し、
小さい要素だけのリストを返す関数は以下のように書けます。

(define (rm-if-not p lst)
　;; Common-Lisp の remove-if-not 相当
　(let loop ((lst lst) (r '()))
　　(if (null? lst) (reverse r)
　　　　(loop (cdr lst) (if (p (car lst)) (cons (car lst) r) r)))))
(define (less-list lst)
　(rm-if-not (lambda (x) (< x (car lst))) (cdr lst)))

(less-list '(4 3 5 2 4 6 3))
　==> (3 2 3)

>>519 さん
ありがとうございます。
ちなみにcurry化というのは…正確な定義は忘れてしまいました。

lessThan :: (Num a, Ord a) => a -> a -> Bool
これが型の定義なのですが、 a -> a -> Bool が引数と返り値に相当します。
aに相当する数字二つを引数とするとBoolが返るのはOKとして、
もし引数が一つだけだとしたら、上の定義は右結合なので、
a -> (a -> Bool) となり、aを入力したらBoolが返る式が返り値になる、
というのがcurry化です。
Haskellでのfilter関数の定義が,
filter :: (a -> Bool) -> [a] -> [a]
のように、最初に評価式を必要とするので、curry化を用いると
具合が良かったわけです。
詳しい説明がsampou.orgにあったはずですが、これまた忘れてしまいました…。

>>520
(define (less-than a b)
　(if (a > b) #t #f))

(less-than 4) ==> Error: 引数が足らん

となるのでそういうことはできない気がします。
Scheme だと

(lambda (x) (less-than 4 x))

みたいにその場で名前なしの手続きを
つくるのが普通じゃないかな?

>>521
ごめん間違えた
(define (less-than a b)
　(if (> a b) #t #f))

強引に curry っぽいことはできるけど普通に呼ぶときに
面倒になるね

(define (less-than a)
　(lambda (b)
　　(if (> a b) #t #f)))

((less-than 4) 1)
　=> #t

全部一変数引数の関数にしておくのね。

＃教科書に載ってた、true, false, if-then-else, inc, dec, 自然数,…を表すλ式を
＃scheme処理系に入力して遊んだときのことを思い出したよ。

こうすべきだった。 lessList (l:ls) = filter (lessThan l) ls

最初に書いたやつだと先頭要素同士を
比較しちゃうからですね。
空リスト以外はコロン使った方が好みです。

#もばいるしてたら電車逃した(w

>>518
lessThan の定義ってこれじゃいかんのですか?
lessThan :: (Num a, Ord a) => a -> a -> Bool
lessThan a b = a > b
そもそも定義しなくても
lessList (l:ls) = filter (l >) ls
でいいんじゃないのですか?

>>526
それで十分なんですよね。
電車に乗ってから気がつきました。
まぁ、Schemeでcurry化ってあるの?という疑問から
色々迷走してしまったということで許してください。

Clean 使ってる人いる?
やっぱ、スレなんて立てたら即過去スレ逝きですかね?(w

過去スレじゃなく過去ログだよ…
使ってる人いないのかな…

ついでに。
http://members.tripod.co.jp/nbz/ref/lambda.html

>>530
此の範囲だと、正に Lisp だね。
括弧を補うと直ぐに分かる(w

lambda age
http://wwwfun.kurims.kyoto-u.ac.jp/MtLambda.html

ff

関数型言語を記事にしたような雑誌はなんでないんでしょうか？
というかプログラミング雑誌らしいものがCマガしかない現状は
ちと恥かしいです。他はライブラリの使い方とかそんなんばっかだし。

どうでしょうか？
2chでもおれのようなDQNが関心もつぐらいだからある程度は売れると
思うんだけど。

実際には使用人口それ程多くないだろう
やっぱり雑誌になるのは、C/C++、Java、VB、
かろうじてC#、Pascalだろう。

DDJみたいな雑誌があってもいいかなと。
bitが潰れたぐらいだから半分趣味、半分学術
なんていう雑誌は売れないのかな？

ごめん、文章ﾒﾁｬｸﾁｬ

>>534
> 2chでもおれのようなDQNが関心もつぐらいだからある程度は売れると
> 思うんだけど。
2chだからこそこれ程盛り上がって、それでわたしや貴方のようなDQN（？）が興味を持つようになるんだと思う。

http://www.dcs.gla.ac.uk/jfp/

>>539
素晴らしいです！
ありがとうございます。

>>518-527
scheamでもカリー化みたいなことは、できるみたいです。
クロージャを使ってね。

ttp://srfi.schemers.org/srfi-26/srfi-26.html

>>541
Haskell とかのやつより柔軟そうですね。

プログラミング言語における「型」ってなんなんでしょうか？
ラッセルの理論からもらってきた概念という知識しかありません。
（これすらも間違ってるかもｗ）

こういった疑問を解消するためにはどんな勉強をしたらいいのでしょうか？
数学的な理論も必要かもしれませんが、抽象的な話は理解に時間がかかるので
実際に使われている言語を使って説明したような本あれば嬉しいです。
よろしくお願いします。

>>543
MLの教科書でいいんじゃない？
あるいは、もうちょっとformalなほうが良ければ
http://www.cis.upenn.edu/~bcpierce/tapl/index.html
とか。
> The approach is pragmatic and operational;
> each new concept is motivated by programming examples
> and the more theoretical sections are driven by the needs of implementations.
なので、そんなに「抽象的」じゃないし。

>>543
昔読んだ「データ型序説」って本はよかったよ。

>>542
そうでもないよ。
このクロージャによるカリー化を処理系が
自動的にやってくれてるだけだし。
Schemeは、弱い型付けの言語だから柔軟だということかな？

>>543
> プログラミング言語における「型」ってなんなんでしょうか？

プログラム断片の性質の一つ。型だけ特別な訳じゃなくて、
同じフレームワークで型推論、データフロー解析、strictness解析が扱える。

関数型言語で考えるのが一番理解しやすい。
Abstract Interpretationとか意味論の本を読むのが一番いいのだが...

>>544 >>545 >>547
ありがとうございます。
個人的に納得がいかないのが
（それが型と関係あるのかは別としても）
変数の型と、関数の値域の違いです。
両者は関係ありそうななさそうな・・・
んー、難しいです。

こういった疑問は函数型言語を勉強すると
解消するものなんでしょうか？
お勧めの書籍をいっぱい教えてもらったので
それ読んでからまたきます。

>>548
あと、英語でよければ、
http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.A4.pdf
はいいペーパーだよ。型に興味があるのなら必読。

>>549
どうもです、早速熟読します。

わざわざCardelliのものを読まなくても、
プログラミング言語の諸概念について一通り説明してあるような本なら、
型の意義等について載っているだろう。
そういう本は余り日本語では出てないと思うが、
英語では結構ある。

>>551
たしかに読み砕くのは大変かもしれないけど、
それに値するペーパーだと思う。
Cardelliのよりも簡潔で読みやすく、あれだけ包括的かつ深さがある
ペーパーがあったらぜひ教えてほしい。
（煽りじゃなく、ほんとにそう思う）

>>550
いきなり全部を理解しようとすると結構大変だと思う。
まずは全体を流して読んで、それから興味ある部分から
熟読していけば、きっと得るものがあると思うよ。
特にsubtypesとquantified typesあたり。

「型って何？」という疑問はかなり根本的で、専門家でも大議論になる。
前に型理論メーリングリストでも盛り上がった。
(http://www.cis.upenn.edu/~bcpierce/types/archives/current/msg00271.html)

で、以下は俺の理解。

古典的な意味での型は「値の集まり」。（値の「集合」って書かないのは、ちょっと理論的な理由。
無限に続くかもしれない計算を表すのに極限の概念が必要で、ただの集合じゃなくて、位相が入ってないといけないので。）
「int」は「整数の集まり」だし、MLとかの「string -> bool」は「文字列を受け取って論理値を返す関数の集まり」。

ただ、最近は型の概念も進化してて、それだけではくくれない。抽象型とか。
だから、現代的な意味での型は、「値に対して*どのような操作が可能か*を表す式」ってとこかと。
抽象型だったらインターフェースを経由した操作しかできないし、
（ちょっと専門的だけど）線形型だったら「一回しか使っちゃだめ」ってことを表す。

で、>>548でいってる「変数の型と、関数の値域の違い」ってのはよくわからないけど、
もし「変数の型」と「関数の値域の型」（t1 -> t2のt2）のことをいってるなら、
「型である」という点では別に違わない、ってのが俺の答えなんだが、どうよ。
そもそもたとえばMLの型tは、t ::= int | bool | t1 -> t2 | ...みたく
再帰的に定義されてて、任意の型が、関数の値域の型(t2)になりうるし。

長文＆わかりにくくてスマソ

もはや誰も読んでないかもしれんが、補足。

上の見方にしたがえば、「変数xが型tを持つ」ってのは、
「実行時に変数xがとりうる値は、型tの表す集まりに入っている（ないしは型tの表す操作が可能である）」
ってこと。「式eが型tを持つ」とか「関数の値域の型がtである」も同様。
だから「型が（変数や式や関数の）値域」ってのはあながち間違いではないと思われ。

>>553
読んでますよ！

今pdfファイルをせっせと読んでいる最中なので
何も書き込むことはありません。
だけど一言お礼だけは述べたいと思います。
ありがとうございます。

>>539>>540
そのJournal of Functional Programmingって
ばりばりの研究者用ジャーナルだけど、ネタ?^^;
Functional Pearlのコーナーは研究者じゃなくても
理解できる＆おもしろいかもしれんが。

雑誌といったらそのくらいというお話

age

月刊「型技術」（日刊工業新聞社）
http://pub.nikkan.co.jp/mgz/kata/index.html

ワラ

日経関数プログラミング

行政改革、参照の透明化

保守age

>>549
その論文は昔、修論の構想を教官（応用数学系）に説明するときと
最後にまとめるときに重宝しました。ホント。

正直な話、Cardelliの話は古すぎる。

functional age
ぼけーっと考えていたんだけど、分散処理って
'(+ 1 2) を他マシンに投げる、という発想から始まったのかな?
下調べまったく無しの書き込みスマソ。

>>566 シミュレーションとか、エージェントとか、アクターっぽい視点ですね。
　コネクション・マシンあたりは、物理シミュレーションが目的かと。

>>564 恥かしながら知りませんでした。有名なものなのでしょうか？

>>565 今はどのあたりがホットなのでしょうか？　

Connection Machine Lisp萌え

VAXはいいマシンだった、という話を聞いたのですが、
実際触ったことがある方居られますか?

VAXはとーてもおーそいー♪（ダースベーダーのテーマで）

という歌は聞いたことあります。

>>569
板違いだろ。Ultrix上のFranz Lisp使ったことあるぞ。
4.2BSDは使ったことないな。

関数型言語はgc使うの？

関数型言語は来年滅びます。

今日麩の大王でもくるの？

サイヤ人の来襲があります

そりゃあいちだいじ。
ピッコロ大魔王か孫悟空を探さなきゃ。

ハァァァァァァァァァァァッァァァァ

ドドンパァァァァァァ

荒れて来たか・・・

('-`)。o○（春だし…）

('-`)。o○（春休みかぁ。いいなぁ。。。）

>>553
位相とか無限とか濃度とか考えなきゃいけないのかな？
コンピュータでは、普通無限を扱わないようなきが。。。

普段から、自然数や無限大は扱ってるような気が…

あーぁ最近メインの研究を疎かに，ラムダラムダ言っているような気がするなぁ

>>581
測度と重さもね。

>>582
コンピュータで無限大を？
オーバーフロー アンダーフローじゃなくて？

正格とか非正格って、無限の概念と関係あるかな？

>>586
関係なし
最外簡約と最内簡約は実行する順番が違う
解析木を上から攻めるか、下から攻めるかの違い

Lazy Evaluationで無限リストを処理、とか考えてしまった〜

無限リストの実現は、遅延評価に拠っている。
その意味では関係あるといえる。

最内簡約だと無限リストは永久ループになっちゃうかなねー

関数型言語ではリストの要素に自分自身を入れることは出来るんですか？

出来ますよ、っていうか、関数型でなくても出来る言語ありますよ。

出来ない言語ってあるかな?
non-strict関数型言語の場合、letrecが強力にサポートするから、宣言型風に書ける。

letrec x = 1:2:3:x; // 1:2:3:1:2:3:1:2:3:1:2...

�x00b;

>>592
自分自身を入れると倫理的におかしくなりませんか？

再帰だから問題なし？

int x[] =
┌────┐
│　　　 1│
├────┤
│　　　 2│
├────┤
│　　　 3│
├────┤
│ (int)&x│
└────┘

わざわざ表にするほどの…

>>591
強い型付けをもつものだとだめだと思ふ。
>>593
これは、自分自身が要素になっているわけではないと思ふ。

厨房ですが600頂きます、失礼しますた

>>599
CommonLispに関してはどうでしょうか？できますか？

>>601
当然です。Scheme最強です

ここも春厨だらけ

>>581
再帰があれば「無限に続く計算」は表せるでしょ。
さらにlazinessがあれば「無限に長いリスト」も定義できるし。
そういうのの意味論に極限(つーか不動点)が出てくる。

>>595
倫理的…(ぼそ)
ocamlならこんな感じ。破壊的代入とかは使ってないよ。
要するに再帰的な値の定義さえできれば良いわけだ。
強い型付けでも、再帰型があればノープロブレム。

# type t = T of t list | I of int ;;
type t = T of t list | I of int
# let rec x = [I 1; I 2; T x] ;;
val x : t list = [I 1; I 2; T [I 1; I 2; T [I 1; I 2; T (以下略)

>>604
こんなのもあるYO!

> ocaml -rectypes
Objective Caml version 3.01

# let rec x = [x] ;;
val x : 'a list as 'a =
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[.]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
#

再帰と極限と不動点にどういう関係があるんだ、とか思った奴のために。
長文なので興味がない人は無視してけろ。非ドキュソ大の数学科や情報科学科なら
そういう授業があると思うが、みんな興味を持たないので人気がない…

まずは高校数学の復習(?)から。

　　　　a_{n+1} = 0.5 a_n + 1

という漸化式を考える。_nとか_{n+1}とかは下付きの添字ね。
a_nのn→∞での極限は2になるんだが、これは

　　　　f(x) = 0.5 x + 1

なる関数fの不動点なんだ。いいかえると、

　　　　x = 0.5 x + 1

って方程式の解が極限になってる。
直観的には「数列が収束するあたりでは値が一定になる」って感じ。

さて、じゃあ再帰的関数の例として、

　　　　fact(i) = if i <= 2 then 1 else i * fact(i-1)

なる関数factを考える。このfactはどんな関数なんだ？って知りたかったら、

fact(i) = if i <= 2 then 1 else i * fact(i-1)
　　　　= if i <= 2 then 1 else i * (if i-1 <= 2 then 1 else (i-1) * fact(i-2))
　　　　= if i <= 2 then 1 else i * (if i-1 <= 2 then 1 else (i-1) * (if i-2 <= 2 then 1 else (i-2) * fact(i-3)))
　　　　= ...

みたく、再帰的定義をどんどん展開してみればいいわけだ。
こうやって展開した極限が、factの意味になる。
再帰的定義を展開していった極限を考えているのでであって、
fact(i)のi→∞での極限とは違うので、混同しないように注意。

だから、factって再帰的関数は、

　　　　f_n(i) = if i <= 2 then 1 else i * f_{n-1}(i-1)

みたいな漸化式で定義される関数列f_nの、n→∞での極限になるわけだ。
ただし初項f_0(i)は常にエラーを返すってことにしておく。

いいかえると、

　　　　F(f) = if i <= 2 then 1 else i * f(i-1)

なる作用素Fの不動点がfactなんだ。以上。

って、こんな説明じゃ元から知ってる人しかわからないか…

>>606
>直観的には「数列が収束するあたりでは値が一定になる」って感じ。
ループ(再帰)の終了条件(不動点)で良いのでは？
『計算機プログラムの構造と解釈』SICPにも載ってるね

あとは、位相と濃度と測度かよ。
面倒な宿題だなあ・・・

濃度：関数言語やってる人は濃い
測度：関数言語やってる人は逝くのが速い
位相：関数言語やってる人がこのスレにはイパーイ居そう...

＃ふぅ、完了

>>607
ループの終了条件と不変条件は別と思われ。
>>581>>608
位相はともかく、濃度とか測度とかも関数型言語の意味論に必要なの？
まあユーザとして使うだけなら、どれも要らなさそうだが(笑)

>>608
ﾜﾗﾀage

お前ら位相とか不動点とか言いたいだけちゃんかと小一時間（以下略）
なんかプログラム板っつーより数学板みたくなってきたな:-)

言語自体が理論で固めて作られてるちゃんうかと。
むしろ理論なしに関数型言語をどうやって語るのかと小一時間（以下略）

と、門外漢は思ったりするのでした。
個別の言語仕様は別スレあるしいいんでないの？

数学板なんてあったのか。
いままで知らんかった！

>613
相当古くからあるよ。確か99年にはもうあった。

>606
漏れ、今から細かぁ〜い三村マサカズ風ツッコミするで。
> factって再帰的関数は、
> 　　　　f_n(i) = if i <= 2 then 1 else i * f_{n-1}(i-1)
> みたいな漸化式で定義される関数列f_nの、n→∞での極限になるわけだ。

関数列f_nの極限かいっ！
関数列f_nのunionの極限だろ。

http://pc.2ch.net/linux/index.html#2

関数型最強の言語は？

APL

最強とか言いだすと荒れそうだが、俺が好きなのは scheme
というか他を知らないとも言う。

既出ですか?
http://www.yfcbookshelf.com/ml_lisp_scheme.htm
ML / Lisp / Scheme

The Little Schemer ついに注文してしまった。

>>621
これも面白いよ。

「関数プログラミング」　萩谷　昌己　著　日本評論社
ISBN4-535-60817-2

前書きより一部引用
引用始め
本書は一般教養としてのプログラミングの教科書である。
欲をいうならば、高校生に読んでもらったり、高等学校で
使ってもらったりすれば大変な幸せである。、、、省略、、、
BASICやFORTRANやPascalやＣ言語やC++やJavaの経験
は反面教師としてのみ有効である。
引用終わり

配列をうまく扱える関数型言語って何がある？
SISALとか使っている奴はいるんだろうか。

;; I-structureはなしね

関数型言語は状態変化が記述しずらいので 一般受けしないらしい。

>>623
J言語。

>>615
すげえ、誰もわかんないだろうと思って誤魔化したのに、しっかりばれてる…

>>623
だから APL だって…げ、>>625 さんきゅ！
そんなのがあったとは知らなんだ

APLを普通のキーボードで打てるようにしたのがJ言語です。
APLは事実上、APLマシンでしか使えませんが、J言語は普通のPCで使えます。

ここの言語研究のプロの方の考えを聞きたいところなのですが、
反復的なインクリメンタル開発ということに適した言語とは何でしょうか？

RUPの開発の主軸に、ユースケース駆動、アーキテクチャ中心、反復的かつ
インクリメンタルな開発というものがあります。
先の二点からはOOPLという解がある程度適しているとは思いますが、
最後の反復的な開発スタイルにはOOPLではどうも上手く行かないような気がします。
RUPは基本的にはソフトウェアはコンポーネント指向であるべきと考えているよう
なので、その中身のパーツたるコードまでOOである必要はないと思うのです。
というと何かOOPL信者さんに喧嘩を売っているようにも読めてしまいますが、
私はそういったことではなくて、あくまで「現場」という効率がのみが重視されるところに
おける最適解について個人的に考えたいと思っています。
現場では様々な要素が関係してくるので、方法論一般として何かを書くのは
難しいと思いますが、ここは2chということで主観的な考えを聞かせて頂けたらな、
と思います。

なお関数型言語に関する知識はlispをかじった程度の知識しかありません。
よろしくお願いします。

>>629
CLOS

>>629
現場の最適解って言ったら、プログラマのレベルを設定しないと。
COBOLしかできないプログラマにはどんな開発でもCOBOLが最適解。
勉強してからやらせるとしても、
例えばML勉強させても悲鳴をあげないくらいのプログラマが
そこそこいる「現場」ってのは俺には想像できないけどな。

ML勉強させても悲鳴をあげないくらいのプログラマが複数いたら、
ばらして、別々の現場担当させるな、おれだったら。
だから、１箇所に「そこそこ」な人数は集まらないと思う。

>>632
MLって勉強しやすくないですか？むしろ。

LISPとSCHEMEってなにが違うの？よくSCHEMEはLISPの方言っていうけど
何が違うかさぱーり。コードみても同じっぽいし。というか
理解してないから同じに見えるんだけど。名前違うとかじゃなくて
何が違うのかおせーて、神よ。

Lispには方言がたくさんあったので、Common Lispという仕様がまとめられま
した。Lispと言ったら代表的なのはこれです。

Scheme はその方言のひとつです。特徴としては、レキシカルスコープ、末尾
再帰、継続などのサポートが挙げられます。仕様は必要最小限の機能だけを盛
り込んだとても小さなものです。

勉強するなら個人的にはSchemeをお勧めします。ちなみに私は勉強中なもので
上に書いたことは不正確かもしれませんが、それにはこれからえらい人がツッ
コミをいれてくれるでしょう。

何を言ってるかわからなかったら自分で調べてみてくださいな。Lisp/Scheme
スレの頭に参考ページがいろいろあるので見てみませう。

>>633
「現場」には、COBOL以外全ての言語が勉強しにくいと感じるプログラマーや
VB以外は全く頭に入らないプログラマーがたくさんいます。
ごくわずかな例外がマ板やム板を覗き、その中のごく少数がこのスレを見てます。
>>634のような者でも「現場」の中ではエリート中のエリートなのです。

>>634

勉強するならSchemeがおすすめ。
小さいのと、高階関数の取り扱いがすっきりしてる。
小さいけどパワフル。
Guy Steele も言っているよ。

Small is beautiful.
Small is powerful.
Small is easy to understand.
I like Scheme programming language because it is small.
It packs a large number of ideas into a small number of features.

Scheme and the Art of programming
MIT press
from Foreword

>>637
その代わり、ライブラリ関係で苦しむかもね。
SLIB とか SRFI の実装とかあるけども。

用途にもよるけど、Scheme だったら Python が良いと思うよ。
手続き型にもオブジェクト指向にも関数型にも書けるし、ライブラリも充実してる。
Windows でも Mac でも Unix でも問題なく使えるし、Scheme に比べてかなり
とっつき易いという事もある。

Scheme が悪いとは言ってないよ。私も Scheme 勉強中だし。
Unix 限定のプロダクトなら Guile で良いとも思うし。

何か日本語変だし・・・（鬱

　みなさん再帰と言えばGEBを読んだ世代ですか？

教えてクンだが、なぜsｃhemeやMLや関数型言語なの？
CやJAVAやってきて本屋でふと関数型言語、SCHEMEの本みたら
なんだこれ？ってかんじだったんだけど。
すでに語られてると思うが関数型の実用的なメリットって
なに？教えてくれ。

>>641
世代なんてあるのか?
俺は少し前に買ってきたけどまだ読んでいない…。

>>642
http://www.sampou.org/haskell/article/whyfp.html
でも、この文書は関数型言語をすでにかじってる人じゃないと
あまりピンとこない気もする…。

RUPが必要なプロジェクトにおいて関数型言語が使われたことってあるのかな？

>>642

こんなの読んでみたら。

bit　１９９９．3月号　特集いま欲しいブレークスルー　
「関数プログラミング」　武市正人　著　
共立出版


ACMチューリング賞記念講演集　
１９７７　Turing Award Lecture
「プログラミングはフォン．ノイマン．スタイルから解放されうるか？
関数型プログラミング．スタイルとそのプログラム代数」　　
ジョン．バッカス　　共立出版
　　　　　　　
　　　　　　　　　　　　　　　

XMLのXSLTとか関数型プログラミングに近いのかな？

>>642

もし、古本屋でみつかったら。

「ソフトウェア考現学　基礎概念への最新おもしろガイド」
萩谷　昌己　著　CQ出版
４．新しいプログラミング．スタイルに向かって

昭和６０年の本です。
萩谷先生によれば関数プログラミングは
変数、代入、GOTOと真っ向から戦い続けている老戦士なんだって。

「関数がなく GOTO だらけ」から「構造化プログラミング」へのベクトルの
延長線上に「関数型プログラミング」がある気がする。

http://research.microsoft.com/projects/clrgen/
正直これに期待。

プログラミング言語の研究とそれの実装技術は分野として別なんでしょうか？
学術的なカテゴリーとしては。

>>650
プログラミング言語の研究⊃実装技術の研究
実装技術の研究≠実装してみました

さっそく関数プログラムを本屋で買ってきます。
ばりばり勉強だぜぃ

http://research.microsoft.com/projects/sml.net/
はいつでるんだろう・・・

>>649
それのタイトルはCOM+2.0･･･
.NETってCOMになんか依存してるの？

>>642
関数型言語の良い点？
一杯あるぞ。
ここや「LISP Scheme」板
「関数型プログラミング言語Haskell」板
「関数型プログラミング言語ML」板
などで外出なネタだ。
過去ログ見てみたら？

ちなみに俺が思う手続き型言語に比べて関数型言語の利点は
普通にプログラムを書いても１関数１状態なる点だと思う。
手続き型言語は、状態が入り乱れた理解しずいらいソースになりやすい。　

スレを板と呼ぶ…

ム板は、メタ板？

http://jp.franz.com/jlug/ja/resources/implementations.html

Common Lispの処理系でおすすめなのってどれ？
Win2000, Linux で動くフリーのやつ。

>>658
こっちのスレ逝ったほうがいいんでねぇの。
http://pc.2ch.net/test/read.cgi/tech/1016211619/l50

関数型言語の普及にとって最大の障壁は
人は思考形態の変化を簡単には受け入れ
られないってことでは？

clispにキマッテルだろ

ttp://www.franz.com/downloads/#acl

ttp://www.xanalys.com/software_tools/products/lww.html

>>660
それなりの能力を持ったプログラマなら何の問題もないと思うけど。
それよりもライブラリが充実していないのがまずい気が。

>>660
そうでもないぞ
１０代の人なら数ヶ月で新しい語順に対応できると思う
２０代以降の人も、半年ぐらいで慣れると思う。

>>663
禿同
IO+GUI+TCP/IPのライブラリ付きの良い処理系ができるといいねー
ところで関数型言語にスレッドのライブラリって要るんやろか？
マルチスレッド無くても継続やlambdaでやってしまうことが多いから。
どなんだろう？

>>664
継続切り替えのスレッドは協調型でしょ。
lambdaでやる、ってなに？
どのみちプリエンティブなやつはOSの助けが要る。
実装はgcまわりが大変かも。

>>663
>>664
柔軟な頭脳、若い頭脳のノイマンからの脱出に期待。

>>666
ノイマン型って、そんなに悪いもんか？
そんなに悪いものじゃないと俺は思うけど。
他に良いものある？

悪くは無いけど、もう発展しなそう。今だって大昔の理論がハードの
発展で実用化してるだけで、何も目新しい理論無いだろ？

所詮コンピュータなんて、正しく早く計算してくれる機械なんだから。
それに実用化されているっていうのは結構重要だと思う。
利点も欠点も判ってるっていうことだから。

米軍が量子型の開発をしているそうだけど、
「わたしたちにとって」実用的になることは……ね。

DNAコンピュータとかもあるね。
計算(パターンマッチ)は速いけど、一杯ある計算結果から
正しい結果を取り出すのが大変らしい。
実用的になるんだろうか？

まあ
暗号化・認証の方向ではそこそこいける鴨

DNAコンピューターって名前かっこいい

はぎゃー先生マンセー

核酸計算機って呼ぼうぜ。

sage

脱線しすぎage

量子コンピュータといえば、Haskellのlist monadみたいなノリで
量子計算を定式化した計算体系があったような。関数型言語のチャンス？(w
実用化しなきゃ無意味だけど…

age

XSLTマンセー

Why did you MANSEI about XSLT ?

XDuceまんせー
http://xduce.sourceforge.net/

>>681
http://www.topxml.com/xsl/articles/fp/

何となくは感じていたことだが、
タグがいかにも面倒。

>>684
S式だと親近感が沸かない人が沢山いるらしいので･･･

>>685
Haskellと比較しているけど・・・

>>684
えーと…気分転換に括弧を<>に買えてみるとか
<list 'a 'b 'e>
=><a b e>
なんとなくXMLっぽいかな。

>>687
なんとなくﾁｮﾝっぽい。

藁藁

＞えーと…気分転換に括弧を<>に買えてみるとか
（´ー｀）
↓
<｀∀´>

超先生…

お前ら、形式的仕様記述スレの回し者でございますか…？

99 ：98 ：02/05/02 13:12
∀といってもこういうの↓じゃないぞ

(・∀・)

100 ：デフォルトの名無しさん ：02/05/02 13:17
>>98
最近それに見えてしまって困ってるんです（まじ深刻

101 ：デフォルトの名無しさん ：02/05/02 13:19
(・∀・)　(・∃・)　(・∧・)　(・∨・)

102 ：デフォルトの名無しさん ：02/05/02 13:20
(゜¬゜)

103 ：デフォルトの名無しさん ：02/05/02 13:44
>>101-102
やめてくれ、これからそういう記号を扱う講義があるんだから…（笑）

職業プログラマだから日々の仕事においてCやC++で仕事をする上で必要な
ことを勉強するわけだけど、それとは別に学問としてのプログラミングも
勉強したい。つまり言語の理論的な根拠とかね。

関数型言語はそういったことを求めるプログラマの期待には応えてくれるもの？
数学の知識（代数、基礎論）はほんの僅かですがあります。

>>693
http://www.amazon.co.jp/exec/obidos/ASIN/4000050060/qid=1020731621/sr=1-3/ref=sr_1_2_3/250-3651387-8720210
http://www.amazon.co.jp/exec/obidos/ASIN/4000061909/qid=1020731621/sr=1-4/ref=sr_1_2_4/250-3651387-8720210
http://www.md.chalmers.se/~rjmh/tutorials.html
でどうよ?

>>694
ありがとうございます。
とりあえず、「論理とプログラム意味論」を注文しました。
とうちゃっくが楽しみです。

>>693
http://www.amazon.co.jp/exec/obidos/ASIN/489471163X/ref=sr_aps_d_1_1/250-9503446-8059411
おすすめ。

>>694
あ、いい忘れたけど、上の二つはどちらもλ計算バリバリです。
MLも登場します。

ちょっと希望とは違ったかも〜、って時もまた相談してね。

副作用のないage

>>691
＜ ｀ш´＞ < 角張った顔が超先生に見えるかニダーに見えるか。それが君の人生を表している。
>>698
上手い。

頭の中がオブジェクト指向な人は関数型言語を受け入れにくい，
なんてことを言われたのですが，そういうもんですかねぇ

>>700
そりゃオブジェクト指向は副作用が(ほぼ)必須だから。
オブジェクトって状態のカタマリじゃん。

関数型にも副作用はありますよ
必須ですよ、ええ

>>702 は何のことを言ってるかわからんけど(実装の話?)、
OOだと＊プログラマにとって＊副作用を使いまくるスタイルが自然だろう。
「メッセージを受け取ると内部状態が変わる」というのが
ありがちなOOの計算モデルだから。

結局、副作用を使わないと何も出来ないということでいいですか？

参照透明性が確保できれば副作用ありまくりでも、
関数プログラミングとしては何の問題もないような気が・・・

>>705
どういうこと？
局所的な副作用を含むコードということ？
例を示してみよ。

>>705
例えばファイルとかにはバンバン書き込むけど
そのファイルを参照(読み出し)できなければ
プログラムの参照透明性は確保できるとか？

>>707
それは意味がわからない。

>>707
っていうか、子ね

>>707の脳は腐っている。不純度100%。

>>707の脳は透明です

ﾏｼﾞﾚｽしておくと、
　http://www.dcs.ed.ac.uk/home/jrl/
の
　"When is a functional program not a functional program?"
に、「副作用を使ってても参照透明になるのは、どういう場合か？」
みたいな論文も一応はある。

ﾏｼﾞﾚｽすると
　http://www.dcs.ed.ac.uk/home/jrl/
にある
　"When is a functional program not a functional program?"
は「副作用を使用してる関数が参照透明になるのはどういう場合か」
みたいな論文。そういう研究も一応は存在する。

なんか凍ったので再投稿してるんだが、二重ｶｷｺになったらすまん。

>>711
どうして透明なんだ？
空っぽという意味で透明ということならば納得できるが。

>>714
もちろん空っぽという意味
ﾈﾀに解説、カコワルイ>漏れ

>>707
Concurrent Clean のユニークタイプがそんな感じじゃない?
Concurrent Clean に詳しい方いませんか?

>>716
CLEAN LANGUAGE REPORT VERSION 2.0 Section 9.1: Basic Idea Behind Uniqueness Typingより
> It is guaranteed by the type system that fwritec has private access to the file such that overwriting the file can be done
> without violating the functional semantics of the program. The resulting file is unique as well and can therefore be passed
> as continuation to another call of e.g. fwritec to make further writing possible.

脳ミソが透明だったのは707ではなく
>>708-711 >>714-715 だったようだな。(禿藁

>>717
訳してくれ。
おれには無理なのでよろしく。

>>707と>>717の内容がどう一致するのか誰か説明してくれ。

ていうか、例え707が間違ってるとしてもいきなり
連続で罵倒される発言には見えんが。
不自然すぎる。

>>720=707
ちゃんと説明しる！

>>721
俺は707じゃないが、707の言ってることぐらい説明しなくても
わかるだろ。（ﾜﾗ
ファイルを書き込む副作用があっても、参照しないから透明性は
確保されるってことだろ？

>>720
っつーかさ、最近特に煽りオンリーなアフォが増えてないか？

>>722
それは何か意味あんのか？

全く読み出さないというのは極論だが、
ファイルの同一位置に対して
読み → 書き → 読み の順序はダメだが
読み → 書き とか
書き → 読み といった
パターンのアクセスだけであることを保証できれば
参照透明性は確保されてるだろ？

>>724
意味が無いから問題なんだろ。
意味が無くなってしまうのに>>705はなぜ問題が無いのか、
意味がある別の状況だとしたらどういうことなのか。
こういうことを聞いてるんだろう。

実際的な意味としては「副作用ありまくり」でも
参照透明に解釈できれば問題ない、ってことでわ。

たとえばモナドやCleanのunique typeはそんな枠組みだな。

>>723
つーかさ、意味わかってないのに煽り入れて、後で自爆するやつ、増えてる気がする。

723=728は自作自演か？とかいってみる。

>>729
ちがうよ

unique typeって何よ？
マイナーな理論出すならちゃんと説明してくれ

>>731
データオブジェクトへの参照が1つであることが保証された型。
2つの変数から同時に参照しようとするとコンパイラがエラーを出す。
uniqueなベクタなら、破壊的に書き換える実装でも参照透明性は崩れない。

ESP処理系の「1ビットリファレンスカウンタ」とか、linear logicとか
も似てるね。

>>731
マイナーか？

>>733
マイナー中のマイナーの、どマイナーです。

>>732
説明ありがとう。
>uniqueなベクタなら、破壊的に書き換える実装でも参照透明性は崩れない。
これどういうこと？
vectorの状態は変わるんでしょ？

例えば
let (new_vector, old_value) = set_vector(vector, index, new_value)
in <body>
とする。

<body>のなかでvectorはもう参照できない(参照したらエラー)

set_vectorは、概念的には「vectorのうち、index番目だけを
new_valueに書き換えた新たなベクター(と、index番目に入っ
ていた元の値の組)を返す」わけだが、実装としては上書きし
ちゃってもだれも気が付かない。

>>736
monadの方が、言語の意味論を拡張しないですむので良いかも。

>>736
ああ、言わんとする事がわかりました。

噛み砕いて考えると、他に参照が無ければ関数の値渡し引数を参照渡しに
していいってことかな。

>>739
意味不明。

>>740
つまりだ、
func_a(structure a) {
　func_b(a);
　print a.value;
}
とかだとfuncは値渡ししないと後のprintで結果が変わる可能性があるけど、
func_a(structure a) {
　print a.value;
　func_b(a);
}
ならfunc_bには参照渡ししても値の変化を気にする必要が無い、
ということを言いたかったの。
これでもだめ？

さらに言うと、>>741の後者は末尾呼び出しなので、
末尾呼び出しは自然とこの性質を持ってることになるよ、ね？
func_aの最初〜func_b呼び出しまでの間なら、
破壊活動を行っても参照透過性は保てると。

ナンカズレテルキガスル

そういう順序依存のプログラムで参照透明性を気にするんなら
もともとモナドとか使うしかないよね。

それと、参照透明な言語では引数をコピーしてもしなくても
意味は変わらないので、値渡し／参照渡しという区別を言語は
しないと思う。まあ実装としては「ポインタの値渡し」が普通
だろうけど。

モナドおいしそう

unique typeは、linear typeのバリアントのようなものだよ。

というか、俺はそういうことが言いたかったんじゃなくて、
関数プログラミングでは、副作用があっては行けない
というようなことが言われていたような感じだったので、
別に参照透明性が確保できれば、副作用の有無は
関数プログラミングにとってはさほどの
問題ではないのではないかと、
実際モナドは、破壊的変更と参照透明性の両立を
目的とした技術であると言えるわけだし。
だから、707のような、
どのような場合に関数は参照透明であり得るかと言う議論は、
微妙に話がずれているのではないかと言うことだよ。
とまあ、思ったわけだ。

unique typeがマイナーとかいう奴は、
モナドやlinear typeがマイナーだと言っているようなもんだと思うが。
やはりストリームベースが本流か？環境渡し技術なんて邪道か？
それこそ頭空っぽだな。逝って来い。

>>747
頭がMirandaで止まってる人もいるのですよ。

>>731が鞭なだけ。

つーか、uniqueness typingのことをunique typeっていわれても
何のことかわからない人が多かったと思われ…

>>737 736からするに、言語のOperational Semanticsは変えずに、構文的に
uniqe typeの型チェックができればいいだけでは?

まとめると、モナドは型システムも変更しないで参照透明性が実現
できるが、unique typeだと、型システムは変更するが(Hindley-Milner
からは少しずれるが)、意味論は変えずに参照透明性が実現できる、
ということでよろしいか?

間違っていたらｽﾏｿ

>>750
それは駄目だよ〜ん

>>750
なんじゃそら…

unique typeを使う型付け体系がuniqueness typingだろ。表裏一体。

>>751-752
typing systemが違えば当然セマンティクスは違ってくると思うのだが。

あと、参照がuniqueかどうかのチェックは構文的な（文脈自由な）チェッ
クじゃ無理だよ。

>>752
hindley-milner?

つか、違いは、モナドが黙示的な環境渡し機構なのに対して、
unique type attributeを持つオブジェクトは、
明示的に渡されるっつーことだよ。

>>755
>あと、参照がuniqueかどうかのチェックは構文的な（文脈自由な）チェッ
>クじゃ無理だよ。

よほど簡単な型システムじゃないかぎり、型がつくプログラムの集合自身
文脈自由じゃないと思われ。心配するな。

>>752
hindley-milnerではなく、mycroft-milnerを拡張してるんだよ。
似てはいるけど、linear typeそのものではなく、いくつか違う点があるよ。

む、ほんとだ…。俺が無知でしたｺﾞﾒﾝ

CleanのObject I/O LibraryをHaskellに移植するというものを
ちょっと見てみた。
Linear typeのようなものを導入するのかと思いきや、
モナドを使っていた。
正直な話、若干無理がある気がしないでもない。

まあ、無理をしてみて、どんな具合いか調べるわけでしょ?

モナドはお菓子のホームラン王です

調べるっつーか、継続するんだとよ。
個人的には、ライブラリそのものの移植はできるとおもうよ。
それはさほど難しくないと思う。
俺が言っているのはそのことではなくて、
Cleanと同様の表現力を持って使えるとは思えないということだよ。

だから、何が足りなくて、同じ表現力にならないのか研究するわけでしょ?

表現力というと書きやすさとかそういった主観的な話なのかな。
in-placeで部分書き換えが可能なデータとかならmonadでできる
ように思うのだけど。

書き易さは主観的な問題なのか？

表現力というのは、ここでは
参照透明性を壊さない限りでの、
より制限のないオブジェクトへのアクセスということだよ。
そのことは、より高い表現力を担保し得ると思うんだが。
モナドは、正直な話、入出力リソースに対する制限が強すぎる上に、
その制限は、純粋関数型言語にとって
甘受しなければならないものとは思えない。
つまり、制限対利益のバランスが取れてないと言いたいんだが。

質問!!
member関数を､第２引数のリストの深いレベルまで
第１引数を探索して取り除くように拡張した関数はどうやって
作ればいいんですか?
あと､二重以上のリストを第一引数として受け取り､
深さ１のリストとして返す関数はどうすればいいんですか?
動作例）（makeflat '(a(b c)((d(e)f)g)h))　　
　　　　→(a b c d e f g)

>>768
まあ、宿題がんばってくれ。心の中で応援してるぞ (藁

>>768
宿題は自分でやりましょう。

>>768
flattenで検索すれ

OcamlとF#誰か日本語化してくれ。

>>772
F#についてはそのうち俺がやってやろう
期待しないで待っておれ

comp.lang.functionalより

Apparently, Simon Peyton-Jones asked them to add a tail-call primitive in the virtual
machine language, somehing absolutely necessary for getting an efficient
implementation of any functional languages.
In fact, the many projects that tried to compile an FP to the JVM failed because of the inability to
optimise tail-calls (something your average C-compiler doesn't even do
right) - there were other reasons why the JVM is not an ideal VM for FPs,
but this is a critical issue.

>>774
糞サンのＪＶＭは末尾再起しないが、
ＩＢＭは末尾再起（ＭＳも）する。

ＩＢＭを使えばいいのだ。

javacはともかくとして。

Java VM でtail recursion optimizeできないって、どおゆーこと？
詳しく教えて

よく意味がわからないので、確認してみる。

単純な末尾再帰最適化って、
(1)終了条件満たしてなかったら
(2)引数スタック書き換えて
(3)関数の先頭付近にジャンプ!
だよね。JavaVMでできそう。

JAVAVMではスタックフレームの再利用ができないという罠。

なんで？
じゃ、スタックフレームをローカル変数にコピーしてから操作すればいいんでないの？

>>779
JVMのドキュメントでも読ま！

Simon Peyton-Jones御大がそんな低レベルな事で悩んでると思うなぼ！

ごめん、大昔JavaVM第一版買ったけど、
読む価値見出せなかったから、
前の職場の本棚で肥やしになってる。

＃だって当時の連中って、HotJava α版 とか解析してプログラミングしてたし、
＃技術的にはSmalltalkの焼き直しっぽくて、型推論とか検証システムとか面白ソーナ仕組みが一切なかったから
＃放置しますた

ってゆーような、意味不明な言い訳はあっち置いといて、と。

末尾再帰の件は、重箱の隅突っ付くような些細な問題であって、
JavaVMが 関数型言語のVMとして不適であるのには別な理由があるって書いてるね。
原文どこ？

しらん。
フライブルグ大学の奴がcomp.lang.functionalで
書き込んだ内容をコピペしただけ。

ちぃっと話題がずれるけど。

世間知らずだった昔は、
comp.*　 読むに値する学術ｽﾚ
alt.*　　コピペ嵐、AA嵐が跳梁跋扈する２ちゃんのような玉石混合のｽﾚ
とか思ってたけど、comp も以外と糞っすね。

comp.lang.functionalも同じような話題を繰り（以下略

向こうには、「FAQを嫁」とか逝って怒り出すオジ^H^Hオニイサンが居ると思われ

AVAYAはよくみるな〜
Wadler?　と思ってしまう私

Unfortunately, tail-call primitive interacts badly with the the
stack-inspection based security model.

See
http://research.microsoft.com/~adg/Publications/details.htm#stack-inspection

Personally, I think the need to do tail call optimizations is a bit
overrated. There are a few examples where you absolutely need it, but most
of the time I'm happy to just write a while loop, or only have a local set of
mutually recursive functions turned into gotos.

comp.lang.functionalを初めて見たけど、
'vs'とかいう単語がいきなり目に飛び込んできて、
あー、どこも変わらないんだなってオモイマスタ。

武田騎馬軍団vs関数型言語

>>788
はいはい、
JavaVMにはセキュリティ検証ってゆう
検証システムがあるのが特徴でしたね.
んで、スタック使わないtail recursion は
本来意図したセキュリティ検証を実行できないからだめ、
って、本当にセキュリティホールになるのかー？

JavaVMで実現不可能なtail recursion が本当に必要なレアケースって、
なんでしょね？(複数のtail recursion 可能な関数を混合した再帰呼び出し？)

lexerとかオートマトンとか。（同じだけど）>791

投資家切込隊長が、
パソコン業界が発展するには
もはや演算能力を上げるだけでは駄目で、
フォンノイマン型を脱するような
ブレークスルーが必要だといっていた。

ということで、関数型言語age

> 投資家切込隊長

誰?

関数型言語だと、フォンノイマン型を脱するのか？

昔、九大の人がデータフロー計算機上で、関数型言語の実装の研究してたね。

>>794
知らないならいい

>>793
　そいつ、10年前にパソコン用拡張ボードで、
　Lispボードとかニューラルネットワーク・ボードとか、ニューロファジー・ボードとか
　出てたのを知らないんだろう.
　＃俺はニューロ・ファジーやってた会社２社ほど会社訪問ったっけ。なつかしー
>>794
　このｽﾚの>>1だろ
　http://science.2ch.net/test/read.cgi/infosys/1007295778/l50
>>796
　すげー興味あり。情報きぼん
　＃出世魚プロジェクトとか、おもろいﾈﾀプロジェクトが多いな

>>793
>フォンノイマン型を脱するような
>ブレークスルーが必要だといっていた。

それくらいのことはどこのＤＱＮでも言えるという罠

そーいや DSPも非ノイマン系。
ついでに言うと、DSPも10年以上前は日本優位だったらしーが、
国内半導体メーカの失策等で劣位になったとかならないとか。

凍死家さんはバイオ・インフォマティックにでも闘志して下さい

801ｹﾞﾄｰ

10年前と今を比較するには若干の無理が（以下略

自分は門外漢ですが、最近関数型言語を使い始めて思ったことです。
高速化を狙うなら関数型言語は良いと思います。

最近メモリーや演算回路はどんどん高速化していますが、データを要求してから
レスポンスが帰ってくるまでのターンアラウンドタイムが伸びがちです。

メモリーはランバス等の登場で転送速度自体は高速化していますが、
反面、データリクエストに必要な時間は複雑な回路を動作するため時間が非常に
かかります。
演算回路も動作クロックが高速化していますが、パイプライン段数は大きくなる一方です。

多分回路間の距離の問題だとおもうのですが、言えることは

小さい回路の高速化は簡単
データ転送量は大きくしやすい
ターンアラウンドタイムは縮まらない
これらは物理的問題と思われるため悪化しても改善しない

こういう状況では OOPL は、ものすごく不利です。
たとえば、OOPL の特徴のひとつで、オブジェクトの参照を駆使しますが、
参照というのは非常に小さいデータで、さらに参照先のメンバ変数を参照する
などということをしようものなら、CPUはひたすら小さなメモリーリクエストばかりと
いうことになります。
これではまるで、ダンプにうまい棒一本のせて右往左往するようなもので、
コンピュータの高速化の恩恵は期待できません。

また、深いパイプラインは分岐に非常に弱いです、メソッドを呼び出しまくると
実行時は分岐だらけです。

反面、関数型言語では、大きなデータのコピーが可能だと楽になる。
深いパイプラインには命令スケジュールが必須だが、それに必要な計算依存関係が
明白なプログラミングスタイルである。

そういうわけで、現在のプロセッサでも関数型を高速化に使うのは悪くないと思います。
その延長線上に非ノイマン型があってもいいんじゃないかなと思います。

これからの言語の方向性として関数型言語のライブラリとしてOOPサポートライブラリを入れるのが良いのではと思っています。

そんな訳で、関数型のメリットはだんだんと大きくなってきていると思う今日この頃です。
Ｃ言語的な利用目的の現代的な置き換えができないかと思ってたりします。

>>803
10点/100点くらい

>>804
採点基準を示せ

>>803
確かに、エンベデットやシステム記述の方面にも
関数型言語を使えるようにしようとしている動きもあるよ。

>>802-803
意味不明なので、省略せずわかるように説明して下さい
つうか、説明するのが面倒なら、ﾚｽ付けない方がﾏｼ

と煽りに煽りを入れるテスト

>>807
802 はともかく 803については、どこが意味不明なのか書いてみたら？
一通り説明になっていると思うが・・・

>>803
条件分岐がパイプラインを詰まらせるって、
関数型言語を実行しても分岐だらけに変わりないだろ。
その関数型言語のソースコードレベルに「if」があまり直接出ないだけで、
機械語レベルでは条件分岐だらけだと思うが。

>>808
　>>803は、
　「関数型言語だと静的解析が容易だから、
　　投機的実行を含む、CPUパイプラインのスケジューリングが容易、
　　だから今時のCPUは関数型言語に向いている(コンパイラーを作成しやすい)」
　ってなニュアンスかな。
　で、詳細に検討しようとすると、例えば >>809 みたいな疑問/反論が出る、と。

>>806
　面白そうな話題ですね。Embedded UML & OCL でしょうか？

条件分岐はパイプラインを詰まらせるのではなくて壊すが正解
パイプラインが詰まる原因はスケジューリングが難しいケースに起こるが正解
だと思う
803 の言いたいことは参照透明が維持されていれば、
その先のことを考えなくても済むので、スケジューリングをするときの障害が少ないと言う事では？

>条件分岐がパイプラインを詰まらせるって、
>条件分岐はパイプラインを詰まらせるのではなくて壊すが正解
ちなみに分岐は条件分岐ではなく、無条件分岐のことをいっていました。
確かに、説明不的確ではあります。
さらに、パイプラインが詰まることと分岐とは別問題です（まったくという訳ではないのですが・・・）。
あと説明中の OOPL が良くないですね、別に OOPL に限った事ではなく
「手続き型」と「関数型」の違い・・・ひょっとしたら「手続き型」と「それ以外」
かもしれませんが・・・

シンプルに説明しますと、

スケジューリングするとは、式の評価順序を入れ替える

というです。

手続き型では、例えばメソッドはプログラムの「評価されるにしかるべき行にあること」が重要な訳です。
ここで「評価順序を入れ替」に対して「評価されるにしかるべき行にある」はお互いに相反する事です。
関数型では、評価結果が次の評価に必要になる前ならばどこにあっても良いのです。
だから、制限付きながらも「評価順序を入れ替」を許容するわけです。
「評価順序を入れ替」が可能なら、スケジューリングも可能ということになります。
「手続き型」では入れ替えしても問題ないものを無理矢理探し出す作業が出てくるわけですが、そんなものはそれほど巧くいくわけもないのは道理たと感じています。

>その関数型言語のソースコードレベルに「if」があまり直接出ないだけで、
>機械語レベルでは条件分岐だらけだと思うが。
これは実装次第です、コンパイラ屋の気合次第です。(^^;
ちなみに僕は条件選択よりも、高階関数が嫌いです。
高階関数にも良い方法があるらしいのですが、まだ調べていません。

それは関数型言語が
並行処理に適合しているということにも繋がりますかね？

ベータ簡約だっけ？

この問題を教えて下さい
3×3行列Aに対し
1,Aを読み込みAの行列式を出力
2,Bを読み込みA×Bを出力
3,｜A｜≠０の時のA^-1を出力

>>815
ふぅ。宿題は自分でやれ。

みんな！ tail recursionとtail-call optimizationを混同しちゃ駄目だ！！
tail recursionはtail-call optimizationの特殊な場合にすぎなくて、
（相互再帰は駄目だけど単独再帰なら）JVMでもgotoで簡単に実装できるし、
stack inspectionの問題もないはずだ！！！

亀レス＆もし既出だったらスマソ

素朴な疑問で恐縮なんだが、
VMで実装することになんか意味あんの？
だいいち使うのか？
あんまりすごさを感じないんだよね。

インタプリタ型言語に多少メリットがあるんじゃないかな？
多様な言語->共通言語->機械語の形態で
各種コンパイラ言語 -> Ｃ -> 機械語
によって各種機種依存から逃れるという目的の流れが
JAVAその他インタプリタ言語 -> JAVAVM -> 機械語(なんかちょっとずれている気もする)
に変わった方がインタプリタには都合が良いということでは？
よく言われるマシンアーキテクチャの共通化とかいう旗印はＣに出来なかった以上JAVAVMにも不可能と見た。
考え方は時代の違いくらいだしね・・・

個人的には、あの重さにいまいちなじめない。
インタプリタ：遅いけど手軽
コンパイラ：コンパイル作業あるけど、速い
って言う発想になじんじゃってるから、
コンパイル作業あるし、速さもたいしたことない
っていうのには抵抗感あるよ

>>812
パターンマッチなんてifだらけだよ．

インタプリタ: 遅いが簡単
コンパイラ: 速いが面倒
なんとかならないの？

そんなあなたに partial evaluation (w

>>821
そういうレスはなんか意味があるのか？

dat落ち防止age

SML/NJなら（対話的環境という意味で）インタプリタで、かつ
実行する瞬間にコンパイルもしてくれるが、どうよ？

それはVMの話とは関係にゃーでよ

何とはなしにageてみる

.

>>176
初学者です。
「代入をしない」で初期設定ファイルから初期設定ができるん
ですか？
Schemeでは下の様にすると代入してます。さらにdataを
変数に代入しないとプログラミングなんてできないと思うの
ですが。
(define data (call-with-input-file "./data.db" read))

>>829
はあ、普通に束縛するだけで破壊代入する必要はないと思うけど…
何となく「代入しない」を勘違いしてるように見えます。
まずは関数型言語の入門書でも読んでみたらどうでしょ？

お勧めとしては武市先生の「関数プログラミング」が入門者向けでかつ分量もたいしたことない。
その本が手に入らなければ、MLの入門書はいろいろ出てるみたいだから読んでみたら？

「環境の中に入ってしまう」という感覚が
わからないと難しいと思われ

はぎゃ先生のほうの「関数プログラミング」の
ほうがいいかも。

>>829
・変数の出現と同時に値の「代入」を行なう。(未定義の値を排除)
・「代入」は一度だけしか行なわれない。(値が変わらない)
という考え方です。(変数の生存期間中値が変わらない)

そして、関数型言語の人たちはこれを「代入」とは呼びません。
C言語の人たちも「定義」と呼んでいます。

「初期化」と呼んでいます。

>>832
schemeの場合は同ブロックの既存の変数を上書きdefineした場合、
古い値は永遠に参照できなくなるから、意味的には完全に「代入」。
つーか、環境書き換えるってことはシンボルの意味が変わるってこと。
関数型の視点からみると、ネストされたletが>>832のそれに当たると思う。
またはlambdaのネスト。

>>834
LISP系やScheme系が「代入」を持っているのはその通りだが、
ラムダ束縛が「代入」に相当するとは思わない。

>>834
define で変わるのって、 symbol に対応する address とか…だよね。
普通の意味での「代入」って、 set! とかの方だと思う。
define だと…例えば、既存の closure からは、古い値が見えるから。

ICFP Programming Contest のページができました。

http://icfpcontest.cse.ogi.edu/

　別の板で下のようなのがありました。関数型でドンピシャなのって
ありますか？
　Cleanなんて近そうですが・・

>質問
(1) >UnixとWindowsで使えて
(2) >GUIと日本語(出来ればUTF8がいいな)が使えて
(3) >GPLじゃないバイナリがつくれて
>ありますか?

つーかマルチだろ。

>例えば、既存の closure からは、古い値が見えるから。
名前でアクセスすりゃ見えねえよ

>>839
失敬な。>>838 は私ではありません。誰か別の人です。
とは言え、Scheme に限らずとも知りたくはありますね。

>>838
Gaucheはどうよ。GaucheはSchemeの一実装。
次のバージョンでGUI対応。いつ出るのかは不明。

OCaml

Gaucheはインタプリタ・・・
バイナリ作れるのか・・・？
というか、目的ちがくないか・・・？

おれの！

schemeは！

バイナリ作れるにょー

http://kado7.ug.to/net/


朝までから騒ぎ！！
　　　小中高生
　コギャル〜熟女まで
　　　メル友
　　i/j/PC/対応

女性の子もたくさん来てね
　　小中高生大歓迎です　　　　　　　　　　　　　　　　　
全国デ−トスポット情報も有ります。
全国エステ＆ネイル情報あります。

　　激安携帯情報あります。

OCamlって、
Win版だと、VCが無いといけないのか？

>>847
cygwin版もあるょ

ょ、ってまさか・・・

半導体チップ設計で最大手(だと思う)のCadence社
のある設計ツールのスクリプト言語がSKILL++というので、
Schemeだった.manualにも
Cadence-supplied Scheme called SKILL++
とか
SKILL++ is designed with IEEE Scheme and CFI Scheme compliance in mind,
とか書いてある.ファイルを見たら括弧だらけでびびった.
なんでSchemeだったんだろう.
(1)たまたまそのツールを作るチームでSchemeが好きなやつがいた.
(2)Schemeをスクリプト言語とすると半導体チップが非常に協力に
　　設計が出来る何かしらの理由がある.
もし(2)なら是非知りたいものだ.
そんだけ.

>>850
(3)MIT出身者がいるとか（ｗ
アプリケーションの補助スクリプトとしてLISP系を選ぶ利点は
emacsやAutoCADとかで証明されてると思うけど、わざわざ
CommonLISP互換にしたり、オリジナルな独自LISPを一から設計
するよりは、お手軽にschemeを使った方が良いと判断された、
ってこともあるんでは。schemeなら機能的に不足は無いし。
メジャーなLISP系としては仕様が一番軽いし、組みこみでも実績あるし。
使う側からすれば、分厚いマニュアルを読まなくても良いに越したことはない。

逆にschemeのデメリットってなんでしょうか？

ライブラリが少ない。

あとは？

わかる人が少ない。
「普通のやつらの上を逝け」には競争相手が知らないことは逆にメリット
だみたいな感じに書いてあった、、気がする。