- 1 名前：デフォルトの名無しさん mailto:sage [2005/11/06(日) 19:45:18 ]
- プログラミング言語処理系の開発に興味のある人達のスレッドです。
字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，SSA変換，
CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン，
SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化，
JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。
意味論に関する話題も歓迎です。
前スレ
1 pc.2ch.net/tech/kako/981/981672957.html
2 pc2.2ch.net/test/read.cgi/tech/1021136715/
3 pc5.2ch.net/test/read.cgi/tech/1070089173/
4 pc5.2ch.net/test/read.cgi/tech/1100097050/
5 pc8.2ch.net/test/read.cgi/tech/1106129164/
6 pc8.2ch.net/test/read.cgi/tech/1115335709/
7 pc8.2ch.net/test/read.cgi/tech/1129287390/
関連リンクは多分 >>2-10 あたり
- 756 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 01:04:59 ]
- >>754
C++は最下位。
- 757 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 01:08:10 ]
- >>756
COBOLだろ
- 758 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 01:12:24 ]
- >>754
LispやSmalltalkなんかは前提とするコアイメージ弄くればなんでも1行で書けるよ。
それに配布物も本体とコアファイルの２ファイルだけで
perlみたいにごちゃごちゃライブラリディレクトリ掘ったりする必要ないし。
- 759 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 02:01:41 ]
- いや待て、言語同士を競争させるのにコアやライブラリを弄っちゃいかんだろ。
- 760 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 02:13:34 ]
- Smalltalkならいじるのが当たり前なんだが
- 761 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 02:31:30 ]
- ライブラリ弄っていいんだったらどの言語でも1〜数行で終わって
比較する意味ないじゃん。
- 762 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 03:17:26 ]
- ライブラリ弄るとかいう発想じゃなくて、LispやSmalltalkでは
言語環境が最初から違うスタート地点に立てる、という観点が
使ったことのない人には想像つかないのかな。
OSで言えば最初からスタンバイ状態になってると考えればいい。
そもそも「出来るだけタイプ量少なくすることで競う」って話だし。
- 763 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 03:19:35 ]
- いやいや駄目でしょ。
Lispは結構知ってるし、Smalltalkもある程度は知ってるけどさ。
標準ライブラリで、標準のコアで勝負でしょ。
- 764 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 03:22:05 ]
- まあ拡張を定義した部分まで行数に入れるんだったら
もちろんいい。
- 765 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 03:23:18 ]
- 他の言語じゃ不可能な時点で勝負にもなんないね。
- 766 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 03:23:25 ]
- あと、その言語として自然な記述で比べること。
7行プログラミングスレみたいな奇怪なコードならCでも短くなるけど、
そういうコードで比べるのも反則。
- 767 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 03:23:52 ]
- >>765
別に不可能じゃないよ。ライブラリなんてどの言語でも書ける。
- 768 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 03:27:34 ]
- >>766
ああいう奇怪なコードで書くのがPerlの自然な流儀ですが何か？
- 769 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 03:27:56 ]
- こんな夜中に何を必死になってんだ
- 770 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 03:46:42 ]
- >>767
知ってていってるならしょうがないが
開発環境と実行環境が一体化してるもんだから
単なるライブラリとは違う。
- 771 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 03:59:21 ]
- いくらそんなこと言ったって、同じにしなくちゃ駄目だろう。
やっぱりライブラリを作ってこれ使えば一行とか言ってるのと同じぐらい
反則に俺には感じる。
- 772 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 04:00:09 ]
- いい加減宗教戦争は勘弁して下さいよ、本当に。
- 773 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 04:56:09 ]
- スレの質が急激に低下してまいりました
- 774 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 05:33:44 ]
- >>1 に出てくる語句について教えてください。
「データ分散」って何ですか? NUMAとかのヘテロなアーキテクチャでの話?
「スクラッチメモリ」って何ですか? CellのSPEが持っているような
プロセサ固有のメモリ?
- 775 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 05:54:04 ]
- >>773
おまえが上質なネタを投下しろよ
- 776 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 06:08:41 ]
- >>775
おまえが上質なネタを投下しろよ
- 777 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 06:51:03 ]
- >>774
>>1に聞けよ
- 778 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 08:16:38 ]
- HTML化されてる最初のスレはかなりレベル高かったみたいだね。
今の>>1-5のテンプレはいつごろからあったんだろ？
- 779 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 14:52:11 ]
- >>774
厳密にはともかく概ねそれで合ってんじゃない？
>>772
宗教戦争になるのは
優劣を計ろうとしていながら物差しがちゃんと定義＆評価されてないからだと思う。
言語設計ということを理解するに当たって既存の言語を比較対照することそのものは
悪くないと思うのだけれど、基準が独りよがりすぎるから感情論になる。
それにRubyがでてくるのは話の流れとしてまだわかるが
Lispはいくらなんでも唐突過ぎる。
イキナリRubyと比較してるが使われる局面も設計時の背景や目的も明らかに違うから
何を比較したいのだかよーわからんことになってる。
言語設計の課題は設計目的にどのくらい適っているかどうかだし、
言語選択の問題は開発対象の性質に言語がどのくらい適合しているかだろう。
いずれにせよ目的も基準もハッキリしない漠然とした優劣は問題ではない。
- 780 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 14:55:35 ]
- プログラムの長さ、記述量が問題になっていたようだが…
情報理論の教えるところによって符号化という視点で考えれば
プログラムもまたプログラムの仕様という情報を符号化したもの。
言語が違えば符号化の体系が違うと考えられるわけで、
単純にコードの文字数を云々することにはあまり意味がない。
例えばコードの中でよく使われるパターンが短く、
あまり使われない構文が長くといった設計上の戦略もある筈だから
どういう目的で設計されているかということを考える必要がある。
また誤り訂正符号などの例のように純粋に内容の情報
（プログラムなら例えば中心となる内容はデータ構造とアルゴリズムだろう）
だけでなく誤りを見つけやすくするための付加情報が含まれるケースもある。
特にプログラミング言語という符号体系は人と機械の間をとりもつ際の
ユーザ側インターフェイスであるわけで
人の認知科学的な処理特性を無視することはできない。
例えば制御文と式と宣言文の構文が分かれていたり、
意味が連想しやすい名前がキーワードに使われるとか、
ユーザが把握しやすい動作モデルを提供するというのは
文字数単位でコード量（端的にはタイプする量）が増えても
そういう観点からは意味がある。
- 781 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:01:42 ]
- >>778
4からじゃね？
- 782 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:07:53 ]
- >>779-780
なげーよ
日記なら他所でやれ
- 783 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:20:39 ]
- 言語の設計には必ず設計目的があり、
設計目的はその時点での背景がある。
そういうことを考えずに闇雲に優劣をつけようとするのは無意味なことだ。
以下に技術的背景が言語設計に及ぼした影響について幾つか例を挙げる。
まず言語は既存言語の存在を前提にしている。新しいものは特にそうだ。
Javaの例で言えば：
JavaはCが存在していて必要ならば使うことができることが前提だから
比較的汎用指向の言語でありながら
Cで書くことが適切であるようなハードウェアレベルの記述機能を
潔くスッパリ切り捨てた設計ができている。
例えば、バイトコード＆仮想マシンの採用やポインタ演算の放棄などがそうだろう。
Javaではそれらと引き換えにより厳密な静的型検査が可能になり、
それがバイトコードの検証といったセキュリティ技術、
ひいてはモバイル・コードの実現といった当初の設計目標を支援している。
- 784 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:21:25 ]
- また、言語は設計当時の技術水準を前提にして設計されているし、
当時重要であった課題を優先して解決するように設計されている。
FORTRANの例で言えば：
FORTRANの行指向な言語設計は行単位に1枚のカードが使われていた
ハードウェア技術に大きな影響を受けている。
構文解析が案外面倒な面倒な算術式のパース技術が取り入れられた背景としては
当時算術演算を手軽に記述できる言語が他になく正にそれが求められていたからだ。
その一方で計算機のメモリやディスクの容量が限られていたこともあって
プログラム規模が当時は現代より比較的小さかったので
ユーザ定義のデータ型への需要は相対的に小さかったためそういう機能は貧弱だ。
LISPの例で言えば：
何よりAI研究で必要な柔軟なデータ形式である
リンクリストやそれを利用したツリーを簡単に操作できることが優先目標だったから
それが充実している一方で、算術式はお世辞に読みやすいとは言えないし、
効率のよいランダムアクセス可能な配列といった機能はなかった。
（近年LISPを語る際によく言及される、
メタな機構が充実したのはちょっと後のことで誕生当時の古LISPでのことではなかった筈だ。
言語のメタな構造がLISPが解く意図するツリー構造と相性がよかったこと、
元々の適用分野がAI研究だったことなどが影響しているのだろう。）
- 785 名前：訂正 mailto:sage [2005/12/14(水) 15:24:35 ]
- 解く意図する→得意とする
- 786 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:25:54 ]
- ここは公開オナニー劇場ですか
- 787 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:26:55 ]
- 宗教戦争なんてしてたっけ。
- 788 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:27:18 ]
- >>782
日記など書く趣味はないよ。
言語戦争の発端のグチを>>654-の記事の一部にポロっと書いた責任を取って
正攻法で技術論に戻して収拾しようとしてるだけ。
- 789 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:33:02 ]
- ｳｻﾞｽ
２、３行で要約しろよ
- 790 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:36:33 ]
- 冗長でも誤りを見つけやすくするため云々は一理あるけど、
冗長に書かないといけないせいで入るバグもあるから
トレードオフであることは意識しないとね。
「把握しやすい」ってのも、
その感覚はユーザによってばらつきがとても大きい。
これを意識しないで話すと宗教戦争になる。
- 791 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:41:37 ]
- >>787
顛末は例によってRubyが貶されて信者が暴れただけ。
- 792 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:10:36 ]
- >>783-784
知識の垂れ流し、結構なことです。
が、ここはお前の落書き帳じゃねーんですよ。
各言語の歴史的経緯についてなんかは言語仕様書の冒頭にでも
書いてありそうなことだし、こんな所で長々と解説されても信憑性も
疑わしいわでだんだん話が薄っぺらくなっていくだけですよ。
こちらとしては、そんなものより要点だけ数行でまとめて書いてくれると
読みやすいわ疲れないわでとてもありがたいわけですよ。
- 793 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:12:53 ]
- ｳｻﾞｽ
２、３行で要約しろよ
- 794 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:14:04 ]
- >>793
一行で要約できますた。
「ここはお前の落書き帳じゃねーんですよ。 」
- 795 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:25:20 ]
- つまり過剰な冗長さは悪し、という例ですな。
- 796 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:29:39 ]
- 長くなると（読解力が不足がち人には）ウザイってのはそうだろうけど
（なら読み飛ばせば？とも思うのではあるけども
読み飛ばしてもくれずわざわざウザイと書いてしまう
不思議な心理があるようですね。）
信憑性が薄くなるってのはよくわからないな。信憑性は内容の問題でしょ?
読解しきれないと内容が理解できないからそういう読み手にとっては
信憑性が薄く「感じられる」というなら納得。
ちなみに要約、要約と言ってるけど
要約というのも情報処理だから当然情報量が減るわけですが、
そこはわかってますか？
要約された梗概ばっか読んでたら
そりゃ目は楽だろうけども身のある話はできませんぜ？
要約なんてのは言わば骨格標本みたいなもので肉はないんだから。
それにこの程度のことで知識の垂れ流しと言われるのも心外。
議論のためのほんのとっかかりのつもりだし、
ちょっと年寄りの言語屋なら別に知るともなしに知ってるような話であって
自慢するほどの知識じゃない。
…と>>792を見た瞬間に思ったけども、>>794にある要約が>>792の真意なら
あまり意味はない単なる煽りなわけで無視したほうがいいのかな？
- 797 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:32:08 ]
- >>795みたいな茶々いれの冗長性はどんなもんすかね？
- 798 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:37:55 ]
- >>796
一行で要約できますた。
「無視したほうがいいのかな？」
- 799 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:42:58 ]
- 梗概が読めなかった。「こうがい」って読むのか。
- 800 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:53:40 ]
- >>796
>自慢するほどの知識じゃない。
そう。
あなたの知識の垂れ流しは、言わばほとんど無駄な情報＝ノイズなわけですよ。
あなたの言う骨と肉で例えると、見るに耐えないブヨブヨです。
すなわち骨が入ってるのかどうかさえ確認するのは困難です。
それをいちいち探りながら読んでいると時間も掛かり頭痛も絶えないわけでして、
長文をお書きならもうちょっと読ます文章を心掛けて書いて頂けませんか？
ということですが、お分かりになられませんかね。
- 801 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:00:51 ]
- よし、１０行縛りにしようぜ
- 802 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:08:25 ]
- >>797
丸ごと読み飛ばされる冗長性に比べると、一行コメントぐらいの冗長性ですな。
- 803 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:15:34 ]
- 3人の旅人がおりました。
ホテルを見つけて、そのホテルのオーナーに宿泊料金をたずねると、オーナーは「3人部屋で30ドルです」と答えました。
そこで、旅人はひとり10ドルずつ払って、そのホテルに泊まることにしました。
しばらくして、オーナーは3人の旅人の泊まっている部屋の料金は、本当は25ドルだったということに気付きました。
そこで、ボーイを呼んで「あの3人の旅人に、この5ドルを返してきておくれ」と頼みました。
ボーイは、3人に5ドルを返しても割り切れないと思い、自分のポケットに2ドルしまい込み、残りの3ドルを、３人の旅人に1ドルずつ返しました。
3人の旅人は、ボーイから1ドルずつ返してもらったので、9ドルずつ払ったことになり、9ドル×3人で27ドルです。ボーイのポケットの中の2ドルを足すと、29ドル。
さて、残りの1ドルはどこへいったのでしょうか？
- 804 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:33:35 ]
- ＞9ドルずつ払ったことになり、9ドル×3人で27ドルです。
問題が間違ってますよ。30-5+3で3人で28ドルですが。
端数切捨てですか？
- 805 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:37:43 ]
- いや3人が払ったのは27ドルでしょ。27-2=25ドルがオーナーの受け取った金で。
と、おいらも釣られてみましたよ。
- 806 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:38:31 ]
- >>784
いや、一番最初のLISPの目標は計算モデルを記述すること(チューリングマシンの代替)だろ。
それはまた、自分自身の処理系を簡潔に記述できる構造であることを意味する。
だからメタな機構はLISPの根本だと思うよ。メタサーキュラーな処理系があれば
それを種にして何でも出来るんだから。マクロやMOPは使い勝手の上で
追加されたおまけみたいなもん。
- 807 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:40:19 ]
- >>781
このスレ6から読み始めたので、2〜5のdatどれかしら持ってたらうｐしてもらえませんか？
- 808 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:43:32 ]
- 論争 Rubyで大規模プロジェクト 採用企業４割拡張ライブラリ使わず
www.toyama.hokkoku.co.jp/_today/T20051210002.htm
あるチーフプログラマーは「日本人なら、Ruby。大規模プロジェクトでも拡張ライブラリは必要ない」と言い切り、
今後も拡張ライブラリとの併用はしない考えだ。
- 809 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:46:47 ]
- 掲示板は書き手同士のコラボレーションで成り立ってるから、
そういうTPOとか特性を考えた上て書けってことだろ
そろそろこのスレの趣旨の話に戻せよ
- 810 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:53:38 ]
- >>808
この業界では技術に保守的なだけでもクズだというのに、
ついにナショナリストまで登場しているのか（笑）
- 811 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:59:31 ]
- >>808
ネタのつもりなんだろうけど、そういうまるっきりウソ流し続けてると
コミュニティ過激派から訴えられるかも知れんぞ
- 812 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 18:01:50 ]
- おれは2が欲しい
- 813 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 18:14:18 ]
- おれはお前が欲しい
- 814 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 19:13:58 ]
- >>803
真相をお話します。
オーナーはご想像の通り、物忘れが酷い人物ですが慈悲深く、
ボーイもまた欲深いという欠点を持つ人物ですが、それでも
ボーイはオーナーの人格を信頼して付き従っておりました。
さて、実はこのホテルのシステムは後払い方式なのですが、
オーナーの物言いにボーイは素直に頷き、オーナーから
預かった５ドルを欲深さからそのまま着服しました。
翌日オーナーは例外なくそのことを忘れており、
チェックアウトした旅人へ謝罪し２５ドルを受け取りました。
結局その時ホテルで５ドルの損失が発生したのですが、
オーナーはそれに気づかず運営を続け、やがて倒産してしまいました。
しかしその後ボーイは着服で貯めた金で大成し、
路頭に迷った元オーナーを雇ってあげたという話です。
経営者としてはボーイの方が格上だった、が正解です。
- 815 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 19:42:02 ]
- ﾋｿ(´д)(д｀)ﾋｿ
- 816 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 22:26:28 ]
- 3人の言語オタがおりました。
このスレを見つけて、そこの住人に最高と思う言語をたずねると、
「RubyとLisp以外です」と答えました。
- 817 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 22:28:14 ]
- eagerな言語は使う気がしない
- 818 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 22:42:51 ]
- クロージャまわりのメモリ管理ってどうやってます？
・基本はスタック上で、捕捉されたらヒープにコピー
・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
・めんどいので全部ヒープに取ってGCまかせ
・その他
と、ネタ投下してみる。
- 819 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 23:13:26 ]
- >>807
makimo.to/cgi-bin/search/search.cgi?q=%83R%83%93%83p%83C%83%89%81%40%83X%83N%83%8A%83v%83g&andor=AND&sf=0&H=&view=table&D=tech&shw=2000
- 820 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 23:57:16 ]
- >>818
全部ヒープでやってる。速度は今のところ考えてない。
いずれはスタック使いたいんだけどね。
とりあえず論文読み中。
www.cs.indiana.edu/~dyb/pubs/3imp.pdf
- 821 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 01:12:12 ]
- >>818
>・基本はスタック上で、捕捉されたらヒープにコピー
捕捉されたらとは？生成のこと？
>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
クロージャの生成構文を別々に設けるということ？
これらの意味は？
おれの見解ではクロージャを使うだけであればスタック、
クロージャを生成する際、親フレーム以下があれば
ヒープに落としてフレーム参照を繋ぎかえる、
この時既にヒープに落ちていれば何もしない、
という戦略がスマートというか、一般的じゃないかと。
使用回数＞生成回数という場合ね。
CPSやジェネレータみたいな使い方しかしない場合は
コピーが連続して不利になるけど、こんなことは
やろうと思わなければめったにない。
- 822 名前：807 mailto:sage [2005/12/15(木) 01:28:06 ]
- >>819
どもありがと。さいこー
- 823 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 02:53:00 ]
- >>818ではないですが面白そうな話題ですね。
>クロージャの生成構文を別々に設けるということ？
エスケープ解析とか？
>おれの見解では(略
すまん、理解不能。
といってもクロージャ変換で実装したことしかない俺の知識が足りないだけ。
興味あるので「一般的」の参照をくれるとうれしい。
- 824 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 04:31:04 ]
- >>803
○○○○○.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○ 最初に支払ったお金３０ドル
↓
●●●◎◎.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○ ３ドル返す ２ドルくすねる
└┼┘└┤└───────────┬─────────────┘
│ │ └ 主人の手元に２５ドル
│ └ ボーイの手元に２ドル
│
└ お客の手元に３ドル
支払ったお金は２７ドル
９×３＝２７ ９ドルずつを３人で払った
３０−３＝２７ ３０ドル払って３ドル返してもらった
２５＋２＝２７ 主人に２５ドル、ボーイに２ドル払った
ボーイがくすねたお金２ドルは、客が支払ったお金（２５＋２）の一部
だから支払った２７ドルにさらに２ドルを足すことが間違い（２５＋２＋２・・・×）
最初の金額３０ドルを求めるには、実際に支払ったお金２７ドルに 戻ったお金３ドルを足さなければならない
- 825 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 04:51:17 ]
- エスケープ解析というのを知らなかったのでぐぐってみたのですが、
関数等のスコープの中で定義した変数やクロージャの
利用がスコープの中だけで完結し、外には持ち出されないことを
調べるということでしょうか。
- 826 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 13:44:56 ]
- そうです。
- 827 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 17:01:53 ]
- >>783-784
おもしろい。長くてもいいからやってくれ。
くだらん短い書き込みより、長くてもおもしろいほうがいいや。
長いのがいやなら読まなきゃいいだけ。
>JavaはCが存在していて必要ならば使うことができることが前提だから
>比較的汎用指向の言語でありながら
>Cで書くことが適切であるようなハードウェアレベルの記述機能を
>潔くスッパリ切り捨てた設計ができている。
ここらへんはたぶん違ってて、Javaに低レベルの記述がないのは単にJavaがバイトコードインタプリタを採用したからであって、Cがあるから云々は関係ないと思う。
ポインタをなくしたのもGCを導入しやすくするためで、やっぱりCとは関係ない。
- 828 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 18:15:07 ]
- >>827
そのへんは、鶏が先か卵が先かみたいなもんじゃね？
>>780
>人の認知科学的な処理特性を無視することはできない。
認知科学的には、冗長だとミスが増える法則もあるので
トレードオフだよね。
>ユーザが把握しやすい動作モデルを提供する
同じ物でも「把握しやすさ」はユーザによって
ばらつきが大きいんだよね。
ここを意識しないと宗教戦争になる。
- 829 名前：デフォルトの名無しさん [2005/12/15(木) 21:03:36 ]
- >>827
ポインタはあるよ。
論文ばかり読んでる○○研究者か？
- 830 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 21:05:42 ]
- >818
継続も使いたいから
>めんどいので全部ヒープに取ってGCまかせ
かね……
- 831 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 21:35:49 ]
- >>823
>興味あるので「一般的」の参照をくれるとうれしい。
図にすると下みたいなイメージだけど、その辺は「クロージャ」が
出てくる速い処理系のソースかドキュメントでも読んでよ。
今の所これ以外に速い実装は思いつかないが。
※ |****| はフレームの変数とかの中身
※ (矢印)はフレームポインタ
スタック |******親1******|(←)|******親2******|(←)| ★クロージャ生成直前
ヒープ ヒープはまだ空の状態
↓ ヒープに落としてフレーム参照を繋ぎかえる
スタック | 親1 |(↓)| 親2 |(↓)| ★クロージャ生成完了
ヒープ |******親1******|(←)|******親2******|(←)|
エスケープ解析までするなら特定の親のみしかヒープのコピーは発生しない。
例えば親1のフレームしか参照しないのであれば親2のフレームは
そのままスタックに残しても良い。
スタック | 親1 |(↓)|*******親2*****|(←)| ★クロージャ生成完了
ヒープ |******親1******|(←)| ←─── 生成されたクロージャは直接親1を参照
- 832 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 22:12:03 ]
- >>829
参照のことをポインタだって言い張ってる人はいますね。
- 833 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 22:43:17 ]
- Javaでポインタがあるっていう人間は低脳。バイトコードの仕様書読み直してから来い
- 834 名前：818 mailto:sage [2005/12/16(金) 01:44:55 ]
- >>821
>>・基本はスタック上で、捕捉されたらヒープにコピー
>捕捉されたらとは？生成のこと？
「生成されたクロージャが、
子孫のスタックフレームでないフレームに捕まえられたら。」かな。
例えばforeach的な関数にクロージャを渡してそのまま捨てるような状況なら
コピーは要らないわけです。
これをやると破壊的な処理がやたらと高くついたり、
いざコピーとなったときにやたらと高くついたり、
その他色々と面倒なことになったりしそうですが。
>>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
>クロージャの生成構文を別々に設けるということ？
コンパイル時に絶対にコピーが要らないとわかったときのみ、
フレームはスタック上に置いて、
それ以外は最初から親フレームはヒープに置いておこうと。
「関数aはクロージャを引数に取るが、それはどこにも保存されない」
ということになればa以外を呼ばない関数のフレームはスタック上に置いて良いでしょう。
が、やっぱり色々あって面倒なことになったりしそうです。
どっちもクロージャより親フレームが長生きなら問題ないよねという方針。
- 835 名前：デフォルトの名無しさん [2005/12/16(金) 18:53:57 ]
- Javaでポインタが無いと信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。
- 836 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 19:38:44 ]
- 個人的な主観かもしれないけど、
ポインタ演算が無いものは参照と呼ばないか？
- 837 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 20:21:09 ]
- 例えば、Cのポインタをタンイポと呼ぶように2006年から改正したら、
2006年からポインタが無いことになるぞ。
ポインタだのタンイポだのと言われてることが全て。
- 838 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 20:41:20 ]
- ポインタをタンイポと呼ぶためには法改正が必要なわけだが、2006年からというのは早急すぎるな。
まずは有識者を集めた小委員会の設置を図った上で、再来年以降の国会提出でも十分だと思う。
- 839 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 20:44:35 ]
- 配列のイテレーターと参照と参照ポインタとメモリアドレスのポインタとを
一括してポインタと呼ぶべきでない。
- 840 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:04:11 ]
- >>835
Javaでポインタが有ると信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。
- 841 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:05:31 ]
- え、ポインタと参照の違いは常識だと思ってたのですが。
またトンデモ本の誕生ですか。
- 842 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:06:01 ]
- >>840
ほんたまですか？
- 843 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:06:22 ]
- 塗るタンイポえくせぷしょん
- 844 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:06:32 ]
- 懐かしい名前を出さないでください。せっかく忘れていたのに。
- 845 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:07:45 ]
- Pascalのポインタは演算できないけどポインタと呼ぶな
だから正解は>>837
- 846 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:10:09 ]
- でも一般的に見たら、参照とポインタの一般像みたいなもんはあるだろ。
Pascalは例外じゃないか？
- 847 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:12:33 ]
- PascalはInc, Decができるじゃん。
- 848 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:12:34 ]
- たしかにポインタの演算はできないけど数値にキャストできるから同じ事では。
- 849 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:21:12 ]
- みんなそんなにボロカスに言うなよ。
Mさんが可哀想じゃないかｗ
- 850 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:22:33 ]
- まあ少なくともJavaの参照はポインタではないことは確かだ。
名前が参照だから。
- 851 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:35:58 ]
- そんなの実際どうとかじゃなくて、
設計者がどう定義したかと、その思想によるだろう。
だから>>850が正しい。
- 852 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:41:17 ]
- 名前はともかくとしても、実際の内容を素直に受け止めれば
いいと思うけど。なので >>835 が正解。
- 853 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:42:47 ]
- >>835とか>>852は、ポインタと読んでCのポインタを連想した上で書いてるわけっしょ？
だったらやはりCの言葉の定義に(ry
- 854 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:44:40 ]
- 実際の所、Rubyにはポインタは存在するがLispには存在しない。
- 855 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:46:11 ]
- >>853 ポインタという言葉の定義or使用はＣが最初ですか？
- 856 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:48:01 ]
- RubyもLispもPascalも、同じ太陽を感じ、同じ月を見て. 同じ空気を吸っているのだから
ポインタの有無くらいで区別するのはよくないと思います。
|
 |
