トップページ⇒tech
986コメント341KB

関数型言語Part2

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
前スレ
http://pc.2ch.net/test/read.cgi/tech/987954395/
0685デフォルトの名無しさんNGNG
>>684
S式だと親近感が沸かない人が沢山いるらしいので・・・
0686デフォルトの名無しさんNGNG
>>685
Haskellと比較しているけど・・・
0687デフォルトの名無しさんNGNG
>>684
えーと…気分転換に括弧を<>に買えてみるとか
<list 'a 'b 'e>
=><a b e>
なんとなくXMLっぽいかな。
0688デフォルトの名無しさんNGNG
>>687
なんとなくチョンっぽい。
0689デフォルトの名無しさんNGNG
藁藁
0690デフォルトの名無しさんNGNG
>えーと…気分転換に括弧を<>に買えてみるとか
(´ー`)
↓
<`∀´>
0691デフォルトの名無しさんNGNG
超先生…
0692デフォルトの名無しさんNGNG
お前ら、形式的仕様記述スレの回し者でございますか…?

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
やめてくれ、これからそういう記号を扱う講義があるんだから…(笑)
0693名無しさん@お腹いっぱい。NGNG
職業プログラマだから日々の仕事においてCやC++で仕事をする上で必要な
ことを勉強するわけだけど、それとは別に学問としてのプログラミングも
勉強したい。つまり言語の理論的な根拠とかね。

関数型言語はそういったことを求めるプログラマの期待には応えてくれるもの?
数学の知識(代数、基礎論)はほんの僅かですがあります。
0694ななしNGNG
>>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
でどうよ?
0695名無しさん@お腹いっぱい。NGNG
>>694
ありがとうございます。
とりあえず、「論理とプログラム意味論」を注文しました。
とうちゃっくが楽しみです。
0696デフォルトの名無しさんNGNG
>>693
http://www.amazon.co.jp/exec/obidos/ASIN/489471163X/ref=sr_aps_d_1_1/250-9503446-8059411
おすすめ。
0697694だ〜!NGNG
>>694
あ、いい忘れたけど、上の二つはどちらもλ計算バリバリです。
MLも登場します。

ちょっと希望とは違ったかも〜、って時もまた相談してね。
0698デフォルトの名無しさんNGNG
副作用のないage
0699デフォルトの名無しさんNGNG
>>691
< `ш´> < 角張った顔が超先生に見えるかニダーに見えるか。それが君の人生を表している。
>>698
上手い。
0700デフォルトの名無しさんNGNG
頭の中がオブジェクト指向な人は関数型言語を受け入れにくい,
なんてことを言われたのですが,そういうもんですかねぇ
0701デフォルトの名無しさんNGNG
>>700
そりゃオブジェクト指向は副作用が(ほぼ)必須だから。
オブジェクトって状態のカタマリじゃん。
0702デフォルトの名無しさんNGNG
関数型にも副作用はありますよ
必須ですよ、ええ
0703デフォルトの名無しさんNGNG
>>702 は何のことを言ってるかわからんけど(実装の話?)、
OOだと*プログラマにとって*副作用を使いまくるスタイルが自然だろう。
「メッセージを受け取ると内部状態が変わる」というのが
ありがちなOOの計算モデルだから。
0704デフォルトの名無しさんNGNG
結局、副作用を使わないと何も出来ないということでいいですか?
0705デフォルトの名無しさんNGNG
参照透明性が確保できれば副作用ありまくりでも、
関数プログラミングとしては何の問題もないような気が・・・
0706デフォルトの名無しさんNGNG
>>705
どういうこと?
局所的な副作用を含むコードということ?
例を示してみよ。
0707デフォルトの名無しさんNGNG
>>705
例えばファイルとかにはバンバン書き込むけど
そのファイルを参照(読み出し)できなければ
プログラムの参照透明性は確保できるとか?
0708デフォルトの名無しさんNGNG
>>707
それは意味がわからない。
0709デフォルトの名無しさんNGNG
>>707
っていうか、子ね
0710デフォルトの名無しさんNGNG
>>707の脳は腐っている。不純度100%。
0711デフォルトの名無しさんNGNG
>>707の脳は透明です
0712デフォルトの名無しさんNGNG
マジレスしておくと、
 http://www.dcs.ed.ac.uk/home/jrl/
の
 "When is a functional program not a functional program?"
に、「副作用を使ってても参照透明になるのは、どういう場合か?」
みたいな論文も一応はある。
0713デフォルトの名無しさんNGNG
マジレスすると
 http://www.dcs.ed.ac.uk/home/jrl/
にある
 "When is a functional program not a functional program?"
は「副作用を使用してる関数が参照透明になるのはどういう場合か」
みたいな論文。そういう研究も一応は存在する。

なんか凍ったので再投稿してるんだが、二重カキコになったらすまん。
0714デフォルトの名無しさんNGNG
>>711
どうして透明なんだ?
空っぽという意味で透明ということならば納得できるが。
0715711NGNG
>>714
もちろん空っぽという意味
ネタに解説、カコワルイ>漏れ
0716名無しさん@EmacsNGNG
>>707
Concurrent Clean のユニークタイプがそんな感じじゃない?
Concurrent Clean に詳しい方いませんか?
0717デフォルトの名無しさんNGNG
>>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 だったようだな。(禿藁
0718デフォルトの名無しさんNGNG
>>717
訳してくれ。
おれには無理なのでよろしく。
0719デフォルトの名無しさんNGNG
>>707と>>717の内容がどう一致するのか誰か説明してくれ。
0720デフォルトの名無しさんNGNG
ていうか、例え707が間違ってるとしてもいきなり
連続で罵倒される発言には見えんが。
不自然すぎる。
0721デフォルトの名無しさんNGNG
>>720=707
ちゃんと説明しる!
0722720NGNG
>>721
俺は707じゃないが、707の言ってることぐらい説明しなくても
わかるだろ。(ワラ
ファイルを書き込む副作用があっても、参照しないから透明性は
確保されるってことだろ?
0723デフォルトの名無しさんNGNG
>>720
っつーかさ、最近特に煽りオンリーなアフォが増えてないか?
0724デフォルトの名無しさんNGNG
>>722
それは何か意味あんのか?
0725デフォルトの名無しさんNGNG
全く読み出さないというのは極論だが、
ファイルの同一位置に対して
読み → 書き → 読み の順序はダメだが
読み → 書き とか
書き → 読み といった
パターンのアクセスだけであることを保証できれば
参照透明性は確保されてるだろ?
0726デフォルトの名無しさんNGNG
>>724
意味が無いから問題なんだろ。
意味が無くなってしまうのに>>705はなぜ問題が無いのか、
意味がある別の状況だとしたらどういうことなのか。
こういうことを聞いてるんだろう。
0727デフォルトの名無しさんNGNG
実際的な意味としては「副作用ありまくり」でも
参照透明に解釈できれば問題ない、ってことでわ。

たとえばモナドやCleanのunique typeはそんな枠組みだな。
0728デフォルトの名無しさんNGNG
>>723
つーかさ、意味わかってないのに煽り入れて、後で自爆するやつ、増えてる気がする。
0729デフォルトの名無しさんNGNG
723=728は自作自演か?とかいってみる。
0730723NGNG
>>729
ちがうよ
0731デフォルトの名無しさんNGNG
unique typeって何よ?
マイナーな理論出すならちゃんと説明してくれ
0732デフォルトの名無しさんNGNG
>>731
データオブジェクトへの参照が1つであることが保証された型。
2つの変数から同時に参照しようとするとコンパイラがエラーを出す。
uniqueなベクタなら、破壊的に書き換える実装でも参照透明性は崩れない。

ESP処理系の「1ビットリファレンスカウンタ」とか、linear logicとか
も似てるね。
0733デフォルトの名無しさんNGNG
>>731
マイナーか?
0734デフォルトの名無しさんNGNG
>>733
マイナー中のマイナーの、どマイナーです。
0735731NGNG
>>732
説明ありがとう。
>uniqueなベクタなら、破壊的に書き換える実装でも参照透明性は崩れない。
これどういうこと?
vectorの状態は変わるんでしょ?
0736デフォルトの名無しさんNGNG
例えば
let (new_vector, old_value) = set_vector(vector, index, new_value)
in <body>
とする。

<body>のなかでvectorはもう参照できない(参照したらエラー)

set_vectorは、概念的には「vectorのうち、index番目だけを
new_valueに書き換えた新たなベクター(と、index番目に入っ
ていた元の値の組)を返す」わけだが、実装としては上書きし
ちゃってもだれも気が付かない。
0737デフォルトの名無しさんNGNG
>>736
monadの方が、言語の意味論を拡張しないですむので良いかも。
0738731NGNG
>>736
ああ、言わんとする事がわかりました。
0739731NGNG
噛み砕いて考えると、他に参照が無ければ関数の値渡し引数を参照渡しに
していいってことかな。
0740デフォルトの名無しさんNGNG
>>739
意味不明。
0741739NGNG
>>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には参照渡ししても値の変化を気にする必要が無い、
ということを言いたかったの。
これでもだめ?
0742739NGNG
さらに言うと、>>741の後者は末尾呼び出しなので、
末尾呼び出しは自然とこの性質を持ってることになるよ、ね?
func_aの最初〜func_b呼び出しまでの間なら、
破壊活動を行っても参照透過性は保てると。
0743デフォルトの名無しさんNGNG
ナンカズレテルキガスル

そういう順序依存のプログラムで参照透明性を気にするんなら
もともとモナドとか使うしかないよね。

それと、参照透明な言語では引数をコピーしてもしなくても
意味は変わらないので、値渡し/参照渡しという区別を言語は
しないと思う。まあ実装としては「ポインタの値渡し」が普通
だろうけど。
0744デフォルトの名無しさんNGNG
モナドおいしそう
0745デフォルトの名無しさんNGNG
unique typeは、linear typeのバリアントのようなものだよ。
0746705NGNG
というか、俺はそういうことが言いたかったんじゃなくて、
関数プログラミングでは、副作用があっては行けない
というようなことが言われていたような感じだったので、
別に参照透明性が確保できれば、副作用の有無は
関数プログラミングにとってはさほどの
問題ではないのではないかと、
実際モナドは、破壊的変更と参照透明性の両立を
目的とした技術であると言えるわけだし。
だから、707のような、
どのような場合に関数は参照透明であり得るかと言う議論は、
微妙に話がずれているのではないかと言うことだよ。
とまあ、思ったわけだ。
0747デフォルトの名無しさんNGNG
unique typeがマイナーとかいう奴は、
モナドやlinear typeがマイナーだと言っているようなもんだと思うが。
やはりストリームベースが本流か?環境渡し技術なんて邪道か?
それこそ頭空っぽだな。逝って来い。
0748デフォルトの名無しさんNGNG
>>747
頭がMirandaで止まってる人もいるのですよ。
0749デフォルトの名無しさんNGNG
>>731が鞭なだけ。
0750デフォルトの名無しさんNGNG
つーか、uniqueness typingのことをunique typeっていわれても
何のことかわからない人が多かったと思われ…
0751デフォルトの名無しさんNGNG
>>737 736からするに、言語のOperational Semanticsは変えずに、構文的に
uniqe typeの型チェックができればいいだけでは?
0752751NGNG
まとめると、モナドは型システムも変更しないで参照透明性が実現
できるが、unique typeだと、型システムは変更するが(Hindley-Milner
からは少しずれるが)、意味論は変えずに参照透明性が実現できる、
ということでよろしいか?

間違っていたらスマソ
0753デフォルトの名無しさんNGNG
>>750
それは駄目だよ〜ん
0754デフォルトの名無しさんNGNG
>>750
なんじゃそら…

unique typeを使う型付け体系がuniqueness typingだろ。表裏一体。
0755デフォルトの名無しさんNGNG
>>751-752
typing systemが違えば当然セマンティクスは違ってくると思うのだが。

あと、参照がuniqueかどうかのチェックは構文的な(文脈自由な)チェッ
クじゃ無理だよ。
0756デフォルトの名無しさんNGNG
>>752
hindley-milner?

つか、違いは、モナドが黙示的な環境渡し機構なのに対して、
unique type attributeを持つオブジェクトは、
明示的に渡されるっつーことだよ。
0757デフォルトの名無しさんNGNG
>>755
>あと、参照がuniqueかどうかのチェックは構文的な(文脈自由な)チェッ
>クじゃ無理だよ。

よほど簡単な型システムじゃないかぎり、型がつくプログラムの集合自身
文脈自由じゃないと思われ。心配するな。
0758デフォルトの名無しさんNGNG
>>752
hindley-milnerではなく、mycroft-milnerを拡張してるんだよ。
似てはいるけど、linear typeそのものではなく、いくつか違う点があるよ。
0759750NGNG
む、ほんとだ…。俺が無知でしたゴメン
0760デフォルトの名無しさんNGNG
CleanのObject I/O LibraryをHaskellに移植するというものを
ちょっと見てみた。
Linear typeのようなものを導入するのかと思いきや、
モナドを使っていた。
正直な話、若干無理がある気がしないでもない。
0761デフォルトの名無しさんNGNG
まあ、無理をしてみて、どんな具合いか調べるわけでしょ?
0762デフォルトの名無しさんNGNG
モナドはお菓子のホームラン王です
0763デフォルトの名無しさんNGNG
調べるっつーか、継続するんだとよ。
個人的には、ライブラリそのものの移植はできるとおもうよ。
それはさほど難しくないと思う。
俺が言っているのはそのことではなくて、
Cleanと同様の表現力を持って使えるとは思えないということだよ。
0764デフォルトの名無しさんNGNG
だから、何が足りなくて、同じ表現力にならないのか研究するわけでしょ?
0765デフォルトの名無しさんNGNG
表現力というと書きやすさとかそういった主観的な話なのかな。
in-placeで部分書き換えが可能なデータとかならmonadでできる
ように思うのだけど。
0766デフォルトの名無しさんNGNG
書き易さは主観的な問題なのか?
0767デフォルトの名無しさんNGNG
表現力というのは、ここでは
参照透明性を壊さない限りでの、
より制限のないオブジェクトへのアクセスということだよ。
そのことは、より高い表現力を担保し得ると思うんだが。
モナドは、正直な話、入出力リソースに対する制限が強すぎる上に、
その制限は、純粋関数型言語にとって
甘受しなければならないものとは思えない。
つまり、制限対利益のバランスが取れてないと言いたいんだが。
0768KOKUYONGNG
質問!!
member関数を、第2引数のリストの深いレベルまで
第1引数を探索して取り除くように拡張した関数はどうやって
作ればいいんですか?
あと、二重以上のリストを第一引数として受け取り、
深さ1のリストとして返す関数はどうすればいいんですか?
動作例)(makeflat '(a(b c)((d(e)f)g)h))  
    →(a b c d e f g)
0769デフォルトの名無しさんNGNG
>>768
まあ、宿題がんばってくれ。心の中で応援してるぞ (藁
0770デフォルトの名無しさんNGNG
>>768
宿題は自分でやりましょう。
0771デフォルトの名無しさんNGNG
>>768
flattenで検索すれ
0772デフォルトの名無しさんNGNG
OcamlとF#誰か日本語化してくれ。
0773デフォルトの名無しさんNGNG
>>772
F#についてはそのうち俺がやってやろう
期待しないで待っておれ
0774デフォルトの名無しさんNGNG
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.
0775デフォルトの名無しさんNGNG
>>774
糞サンのJVMは末尾再起しないが、
IBMは末尾再起(MSも)する。

IBMを使えばいいのだ。
0776デフォルトの名無しさんNGNG
javacはともかくとして。

Java VM でtail recursion optimizeできないって、どおゆーこと?
詳しく教えて
0777776NGNG
よく意味がわからないので、確認してみる。

単純な末尾再帰最適化って、
(1)終了条件満たしてなかったら
(2)引数スタック書き換えて
(3)関数の先頭付近にジャンプ!
だよね。JavaVMでできそう。
0778デフォルトの名無しさんNGNG
JAVAVMではスタックフレームの再利用ができないという罠。
0779デフォルトの名無しさんNGNG
なんで?
じゃ、スタックフレームをローカル変数にコピーしてから操作すればいいんでないの?
0780デフォルトの名無しさんNGNG
>>779
JVMのドキュメントでも読ま!

Simon Peyton-Jones御大がそんな低レベルな事で悩んでると思うなぼ!
0781デフォルトの名無しさんNGNG
ごめん、大昔JavaVM第一版買ったけど、
読む価値見出せなかったから、
前の職場の本棚で肥やしになってる。

#だって当時の連中って、HotJava α版 とか解析してプログラミングしてたし、
#技術的にはSmalltalkの焼き直しっぽくて、型推論とか検証システムとか面白ソーナ仕組みが一切なかったから
#放置しますた
0782デフォルトの名無しさんNGNG
ってゆーような、意味不明な言い訳はあっち置いといて、と。

末尾再帰の件は、重箱の隅突っ付くような些細な問題であって、
JavaVMが 関数型言語のVMとして不適であるのには別な理由があるって書いてるね。
原文どこ?
0783デフォルトの名無しさんNGNG
しらん。
フライブルグ大学の奴がcomp.lang.functionalで
書き込んだ内容をコピペしただけ。
0784デフォルトの名無しさんNGNG
ちぃっと話題がずれるけど。

世間知らずだった昔は、
comp.*  読むに値する学術スレ
alt.*  コピペ嵐、AA嵐が跳梁跋扈する2ちゃんのような玉石混合のスレ
とか思ってたけど、comp も以外と糞っすね。
■ このスレッドは過去ログ倉庫に格納されています