5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

関数型言語Part2

1 :デフォルトの名無しさん:01/12/03 22:58
前スレ
http://pc.2ch.net/test/read.cgi/tech/987954395/

774 :デフォルトの名無しさん:02/06/10 11:34
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.

775 :デフォルトの名無しさん:02/06/10 19:42
>>774
糞サンのJVMは末尾再起しないが、
IBMは末尾再起(MSも)する。

IBMを使えばいいのだ。

776 :デフォルトの名無しさん:02/06/10 19:58
javacはともかくとして。

Java VM でtail recursion optimizeできないって、どおゆーこと?
詳しく教えて

777 :776:02/06/10 21:22
よく意味がわからないので、確認してみる。

単純な末尾再帰最適化って、
(1)終了条件満たしてなかったら
(2)引数スタック書き換えて
(3)関数の先頭付近にジャンプ!
だよね。JavaVMでできそう。


778 :デフォルトの名無しさん:02/06/10 22:15
JAVAVMではスタックフレームの再利用ができないという罠。


779 :デフォルトの名無しさん:02/06/10 22:24
なんで?
じゃ、スタックフレームをローカル変数にコピーしてから操作すればいいんでないの?

780 :デフォルトの名無しさん:02/06/10 22:32
>>779
JVMのドキュメントでも読ま!

Simon Peyton-Jones御大がそんな低レベルな事で悩んでると思うなぼ!

781 :デフォルトの名無しさん:02/06/10 22:36
ごめん、大昔JavaVM第一版買ったけど、
読む価値見出せなかったから、
前の職場の本棚で肥やしになってる。

#だって当時の連中って、HotJava α版 とか解析してプログラミングしてたし、
#技術的にはSmalltalkの焼き直しっぽくて、型推論とか検証システムとか面白ソーナ仕組みが一切なかったから
#放置しますた

782 :デフォルトの名無しさん:02/06/10 22:39
ってゆーような、意味不明な言い訳はあっち置いといて、と。

末尾再帰の件は、重箱の隅突っ付くような些細な問題であって、
JavaVMが 関数型言語のVMとして不適であるのには別な理由があるって書いてるね。
原文どこ?

783 :デフォルトの名無しさん:02/06/10 22:49
しらん。
フライブルグ大学の奴がcomp.lang.functionalで
書き込んだ内容をコピペしただけ。

784 :デフォルトの名無しさん:02/06/10 22:56
ちぃっと話題がずれるけど。

世間知らずだった昔は、
comp.*  読むに値する学術スレ
alt.*  コピペ嵐、AA嵐が跳梁跋扈する2ちゃんのような玉石混合のスレ
とか思ってたけど、comp も以外と糞っすね。

785 :デフォルトの名無しさん:02/06/10 23:06
comp.lang.functionalも同じような話題を繰り(以下略

786 :デフォルトの名無しさん:02/06/10 23:14
向こうには、「FAQを嫁」とか逝って怒り出すオジ^H^Hオニイサンが居ると思われ

787 :デフォルトの名無しさん:02/06/11 00:05
AVAYAはよくみるな〜
Wadler? と思ってしまう私

788 :デフォルトの名無しさん:02/06/11 13:37
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.

789 :デフォルトの名無しさん:02/06/11 14:36
comp.lang.functionalを初めて見たけど、
'vs'とかいう単語がいきなり目に飛び込んできて、
あー、どこも変わらないんだなってオモイマスタ。

790 :デフォルトの名無しさん:02/06/11 15:26
武田騎馬軍団vs関数型言語

791 :デフォルトの名無しさん:02/06/11 21:24
>>788
はいはい、
JavaVMにはセキュリティ検証ってゆう
検証システムがあるのが特徴でしたね.
んで、スタック使わないtail recursion は
本来意図したセキュリティ検証を実行できないからだめ、
って、本当にセキュリティホールになるのかー?

JavaVMで実現不可能なtail recursion が本当に必要なレアケースって、
なんでしょね?(複数のtail recursion 可能な関数を混合した再帰呼び出し?)

792 :デフォルトの名無しさん:02/06/14 00:21
lexerとかオートマトンとか。(同じだけど)>791

793 :デフォルトの名無しさん:02/06/15 23:15
投資家切込隊長が、
パソコン業界が発展するには
もはや演算能力を上げるだけでは駄目で、
フォンノイマン型を脱するような
ブレークスルーが必要だといっていた。

ということで、関数型言語age

794 :デフォルトの名無しさん:02/06/15 23:26
> 投資家切込隊長

誰?

795 :デフォルトの名無しさん:02/06/15 23:33
関数型言語だと、フォンノイマン型を脱するのか?


796 :デフォルトの名無しさん:02/06/15 23:55
昔、九大の人がデータフロー計算機上で、関数型言語の実装の研究してたね。

797 :デフォルトの名無しさん:02/06/16 00:39
>>794
知らないならいい

798 :デフォルトの名無しさん:02/06/16 01:02
>>793
 そいつ、10年前にパソコン用拡張ボードで、
 Lispボードとかニューラルネットワーク・ボードとか、ニューロファジー・ボードとか
 出てたのを知らないんだろう.
 #俺はニューロ・ファジーやってた会社2社ほど会社訪問ったっけ。なつかしー
>>794
 このスレの>>1だろ
 http://science.2ch.net/test/read.cgi/infosys/1007295778/l50
>>796
 すげー興味あり。情報きぼん
 #出世魚プロジェクトとか、おもろいネタプロジェクトが多いな

799 :デフォルトの名無しさん:02/06/16 02:31
>>793
>フォンノイマン型を脱するような
>ブレークスルーが必要だといっていた。

それくらいのことはどこのDQNでも言えるという罠

800 :デフォルトの名無しさん:02/06/16 12:43
そーいや DSPも非ノイマン系。
ついでに言うと、DSPも10年以上前は日本優位だったらしーが、
国内半導体メーカの失策等で劣位になったとかならないとか。

凍死家さんはバイオ・インフォマティックにでも闘志して下さい

801 :デフォルトの名無しさん:02/06/16 14:23
801ゲトー

802 :デフォルトの名無しさん:02/06/16 14:54
10年前と今を比較するには若干の無理が(以下略

803 :デフォルトの名無しさん:02/06/16 16:28
自分は門外漢ですが、最近関数型言語を使い始めて思ったことです。
高速化を狙うなら関数型言語は良いと思います。

最近メモリーや演算回路はどんどん高速化していますが、データを要求してから
レスポンスが帰ってくるまでのターンアラウンドタイムが伸びがちです。

メモリーはランバス等の登場で転送速度自体は高速化していますが、
反面、データリクエストに必要な時間は複雑な回路を動作するため時間が非常に
かかります。
演算回路も動作クロックが高速化していますが、パイプライン段数は大きくなる一方です。

多分回路間の距離の問題だとおもうのですが、言えることは

小さい回路の高速化は簡単
データ転送量は大きくしやすい
ターンアラウンドタイムは縮まらない
これらは物理的問題と思われるため悪化しても改善しない

こういう状況では OOPL は、ものすごく不利です。
たとえば、OOPL の特徴のひとつで、オブジェクトの参照を駆使しますが、
参照というのは非常に小さいデータで、さらに参照先のメンバ変数を参照する
などということをしようものなら、CPUはひたすら小さなメモリーリクエストばかりと
いうことになります。
これではまるで、ダンプにうまい棒一本のせて右往左往するようなもので、
コンピュータの高速化の恩恵は期待できません。

また、深いパイプラインは分岐に非常に弱いです、メソッドを呼び出しまくると
実行時は分岐だらけです。

反面、関数型言語では、大きなデータのコピーが可能だと楽になる。
深いパイプラインには命令スケジュールが必須だが、それに必要な計算依存関係が
明白なプログラミングスタイルである。

そういうわけで、現在のプロセッサでも関数型を高速化に使うのは悪くないと思います。
その延長線上に非ノイマン型があってもいいんじゃないかなと思います。

これからの言語の方向性として関数型言語のライブラリとしてOOPサポートライブラリを入れるのが良いのではと思っています。

そんな訳で、関数型のメリットはだんだんと大きくなってきていると思う今日この頃です。
C言語的な利用目的の現代的な置き換えができないかと思ってたりします。




804 :デフォルトの名無しさん:02/06/16 21:14
>>803
10点/100点くらい

805 :デフォルトの名無しさん:02/06/16 22:05
>>804
採点基準を示せ

806 :デフォルトの名無しさん:02/06/16 22:23
>>803
確かに、エンベデットやシステム記述の方面にも
関数型言語を使えるようにしようとしている動きもあるよ。

807 :デフォルトの名無しさん:02/06/22 01:00
>>802-803
意味不明なので、省略せずわかるように説明して下さい
つうか、説明するのが面倒なら、レス付けない方がマシ

と煽りに煽りを入れるテスト


808 :デフォルトの名無しさん:02/06/22 02:59
>>807
802 はともかく 803については、どこが意味不明なのか書いてみたら?
一通り説明になっていると思うが・・・

809 :デフォルトの名無しさん:02/06/22 09:58
>>803
条件分岐がパイプラインを詰まらせるって、
関数型言語を実行しても分岐だらけに変わりないだろ。
その関数型言語のソースコードレベルに「if」があまり直接出ないだけで、
機械語レベルでは条件分岐だらけだと思うが。

810 :807:02/06/22 10:54
>>808
 >>803は、
 「関数型言語だと静的解析が容易だから、
  投機的実行を含む、CPUパイプラインのスケジューリングが容易、
  だから今時のCPUは関数型言語に向いている(コンパイラーを作成しやすい)」
 ってなニュアンスかな。
 で、詳細に検討しようとすると、例えば >>809 みたいな疑問/反論が出る、と。

>>806
 面白そうな話題ですね。Embedded UML & OCL でしょうか?

811 :デフォルトの名無しさん:02/06/22 11:12
条件分岐はパイプラインを詰まらせるのではなくて壊すが正解
パイプラインが詰まる原因はスケジューリングが難しいケースに起こるが正解
だと思う
803 の言いたいことは参照透明が維持されていれば、
その先のことを考えなくても済むので、スケジューリングをするときの障害が少ないと言う事では?


812 :デフォルトの名無しさん:02/06/23 16:50
>条件分岐がパイプラインを詰まらせるって、
>条件分岐はパイプラインを詰まらせるのではなくて壊すが正解
ちなみに分岐は条件分岐ではなく、無条件分岐のことをいっていました。
確かに、説明不的確ではあります。
さらに、パイプラインが詰まることと分岐とは別問題です(まったくという訳ではないのですが・・・)。
あと説明中の OOPL が良くないですね、別に OOPL に限った事ではなく
「手続き型」と「関数型」の違い・・・ひょっとしたら「手続き型」と「それ以外」
かもしれませんが・・・

シンプルに説明しますと、

スケジューリングするとは、式の評価順序を入れ替える

というです。

手続き型では、例えばメソッドはプログラムの「評価されるにしかるべき行にあること」が重要な訳です。
ここで「評価順序を入れ替」に対して「評価されるにしかるべき行にある」はお互いに相反する事です。
関数型では、評価結果が次の評価に必要になる前ならばどこにあっても良いのです。
だから、制限付きながらも「評価順序を入れ替」を許容するわけです。
「評価順序を入れ替」が可能なら、スケジューリングも可能ということになります。
「手続き型」では入れ替えしても問題ないものを無理矢理探し出す作業が出てくるわけですが、そんなものはそれほど巧くいくわけもないのは道理たと感じています。

>その関数型言語のソースコードレベルに「if」があまり直接出ないだけで、
>機械語レベルでは条件分岐だらけだと思うが。
これは実装次第です、コンパイラ屋の気合次第です。(^^;
ちなみに僕は条件選択よりも、高階関数が嫌いです。
高階関数にも良い方法があるらしいのですが、まだ調べていません。


813 :デフォルトの名無しさん:02/06/25 13:40
それは関数型言語が
並行処理に適合しているということにも繋がりますかね?

814 :デフォルトの名無しさん:02/06/25 14:08
ベータ簡約だっけ?

815 ::02/06/25 16:57
この問題を教えて下さい
3×3行列Aに対し
1,Aを読み込みAの行列式を出力
2,Bを読み込みA×Bを出力
3,|A|≠0の時のA^-1を出力


816 :デフォルトの名無しさん:02/06/25 19:04
>>815
ふぅ。宿題は自分でやれ。

817 :デフォルトの名無しさん:02/06/26 00:35
みんな! tail recursionとtail-call optimizationを混同しちゃ駄目だ!!
tail recursionはtail-call optimizationの特殊な場合にすぎなくて、
(相互再帰は駄目だけど単独再帰なら)JVMでもgotoで簡単に実装できるし、
stack inspectionの問題もないはずだ!!!

亀レス&もし既出だったらスマソ

818 :デフォルトの名無しさん:02/07/01 11:50
素朴な疑問で恐縮なんだが、
VMで実装することになんか意味あんの?
だいいち使うのか?
あんまりすごさを感じないんだよね。

819 :デフォルトの名無しさん:02/07/02 00:17
インタプリタ型言語に多少メリットがあるんじゃないかな?
多様な言語->共通言語->機械語の形態で
各種コンパイラ言語 -> C -> 機械語
によって各種機種依存から逃れるという目的の流れが
JAVAその他インタプリタ言語 -> JAVAVM -> 機械語(なんかちょっとずれている気もする)
に変わった方がインタプリタには都合が良いということでは?
よく言われるマシンアーキテクチャの共通化とかいう旗印はCに出来なかった以上JAVAVMにも不可能と見た。
考え方は時代の違いくらいだしね・・・


820 :デフォルトの名無しさん:02/07/03 09:47
個人的には、あの重さにいまいちなじめない。
インタプリタ:遅いけど手軽
コンパイラ:コンパイル作業あるけど、速い
って言う発想になじんじゃってるから、
コンパイル作業あるし、速さもたいしたことない
っていうのには抵抗感あるよ

821 :デフォルトの名無しさん:02/07/14 19:43
>>812
パターンマッチなんてifだらけだよ.

822 :デフォルトの名無しさん:02/07/14 19:49
インタプリタ: 遅いが簡単
コンパイラ: 速いが面倒
なんとかならないの?

そんなあなたに partial evaluation (w

823 :デフォルトの名無しさん:02/07/15 16:58
>>821
そういうレスはなんか意味があるのか?

233 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)