「コンパイラ・スクリプトエンジン」相談室9

1 名前：デフォルトの名無しさん [2005/12/20(火) 21:43:02 ] プログラミング言語処理系の開発に興味のある人達のスレッドです。 字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，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/ 8 pc8.2ch.net/test/read.cgi/tech/1131273918/ 関連リンクは多分 >>2-10 あたり 476 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 10:51:06 ] >>472 そのページはマルチスレッドは考えてないでしょ。 シングルスレッドなら普通 >>471 の 1 にするかと。 477 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 13:02:40 ] >>475 アホかお前 478 名前：デフォルトの名無しさん mailto:sage 情報の無い発言には付き合いません [2006/02/04(土) 17:24:37 ] >475 黒の定義を変えるヨロシ 「GCから『それが参照している先は灰色か黒しか存在しない』と認識されるオブジェクト」 かな？ 479 名前：デフォルトの名無しさん mailto:sage [2006/02/07(火) 00:59:07 ] スタックアロケーションには定数時間が必要なのに対し、 生きているオブジェクトの数だけに比例する時間がかかるGCは メモリを大きく取ることでいくらでも1セルあたりのGCコストを減らせますよね。 だからGCはスタックアロケーションよりも速いっていうのは間違ってますか? 480 名前：デフォルトの名無しさん mailto:sage [2006/02/07(火) 01:39:53 ] 全体的にどういう計算、それ? 481 名前：デフォルトの名無しさん mailto:sage [2006/02/07(火) 10:54:53 ] >>480 例えばコピーGCでメモリのサイズをM、GCで生き残ったオブジェクトのサイズをA とすると、GCにかかる時間は定数Cを使ってCAになります。 回収されたオブジェクトのサイズはM-Aなので、これで割るとCA/M-Aになります。 スタックのポップだと一般にサイズ当たりにかかる時間は定数です。 コピーGCではMを大きくすることで、いくらでもコストが減るので "Garbage Collection Can Be Faster Than Stack Allocation" Andrew W. Appel ということらしいです。 482 名前：デフォルトの名無しさん mailto:sage [2006/02/07(火) 12:22:38 ] よくわかんないけど その理論だとスタックの最大サイズM（仮想メモリ使えば∞と思ってよい） に対して同じ式が出てくるんじゃないか？ スタックのポップのコストがサイズ当たりってことは、 ポップのコストはサイズに比例って意味だよね？ 483 名前：デフォルトの名無しさん mailto:sage [2006/02/07(火) 12:44:12 ] >>482 スタックのポップは引き算すればいいだけなので、ほんとは比例しないんですが 使い終わる度にポップするのでサイズに比例するってことです。 スタックのポップのコストにスタックの最大サイズは関係ありません。 484 名前：デフォルトの名無しさん mailto:sage [2006/02/07(火) 13:01:35 ] >479 それって、前提条件が １スタック＝１オブジェクト になっていない？ ただ単に「GCによるオーバーヘッド > まとめてメモリ回収する時間節約」つうてる だけのような気がする 485 名前：デフォルトの名無しさん mailto:sage [2006/02/07(火) 13:28:06 ] >>484 すいませんがよく意味が分からないです... VMのスタックをポップせずに一杯になったときにGCを起動した方が 性能がいいんじゃないかって話です。 環境をヒープにコピーしたり末尾再帰を最適化したりしなくてすみます。 ただコンパクションしないと断片化するのでGCは結構重そうです。 >>482 のようにメモリが無限にあるのなら GC自体必要ないのでコストは0です。 で、現実問題としてどんなもんなのかなあと。Chickenで実装されているらしいのですが... 486 名前：デフォルトの名無しさん mailto:sage [2006/02/07(火) 13:35:44 ] 元論文をつまみ読みして想像するに ・Mはメモリのサイズというよりは、今までアロケートしたセルのサイズ ・「スタックアロケーション」といっているのはヒープに確保したセルを明示的に開放する話。スタックは関係ない。 ・「スタック〜」では開放するセルの個数に比例したコストがかかるが、 　コピーGCでは生き残ったセルの個数に比例したコストがかかる。 ・コピーGCでは開放するセルあたりのコストはCA/M-A なので、 　開放するセルあたり１インストラクションより小さくなることすらある。 487 名前：デフォルトの名無しさん mailto:sage [2006/02/07(火) 13:57:28 ] >>486 > ・Mはメモリのサイズというよりは、今までアロケートしたセルのサイズ MはコピーGCで使われるメモリ領域です。つまり 2Mのメモリが必要です。 > ・「スタックアロケーション」といっているのはヒープに確保したセルを明示的に開放する話。スタックは関係ない。 どちらにしても explicit freeingはセルの個数(開放する回数)に比例したコストがかかります。 この論文でも特にヒープかスタックか特定していないような気がします 5章でもスタックとヒープを比較しているので、どちらかといえばスタックかなあと 間違ってたらすいません。 >・「スタック〜」では開放するセルの個数に比例したコストがかかるが、 >　コピーGCでは生き残ったセルの個数に比例したコストがかかる。 >・コピーGCでは開放するセルあたりのコストはCA/M-A なので、 >　開放するセルあたり１インストラクションより小さくなることすらある。 その通りです。 他の論文にも StackGCの性能がよいと書いてあったのですが Chicken くらいしか実装例を知らないのでどうなのかと思ったんです。 飯喰ってきます。 488 名前：484 mailto:sage [2006/02/07(火) 14:49:37 ] ごめん。 意図しているのは >486 の通りね。 GCによるオーバーヘッド => GCでの生き残ったセルの個数に比例したコスト まとめてメモリ回収する時間節約 => スタックでの開放するセルあたりのコスト - GCでの生き残ったセルの個数に比例したコスト といった感じかな？ 489 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 14:42:58 ] >>481 >これで割るとCA/M-Aになります。 うんうん。なるほど・・・ ところで、その割った「値」っていうのは、 一体何を意味している数なのかな？ 490 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 17:20:13 ] >>489 そのまんま「回収したサイズ当たりの計算量」です。 一般的なコピーイングでは 2Mのメモリが必要ですが、explicit freeing と効率が同じになるサイズNを超す生存オブジェクトを許さないのならば M + Nで済みます。 (コピーGCでは生存オブジェクトのサイズに比例したコストがかかるので、 Nを超えると explicit freeingの方が効率的になるということです。) 生存オブジェクトのサイズがNを超えたらスタックオーバーフローにします。 で、この論文の例の場合 M = 7Nなので 8Nのメモリが必要となります。 これは コンスセル一つ 3ワードという前提の上での計算です。 VMスタックにこの GCを使った場合、環境フレームの大きさは固定では ありませんがほとんどの場合 3ワードよりも大きいので、M/Nはもっと大きいです。 という訳で生存オブジェクトに対して十分大きなメモリが確保されないと GCの優位性は保たれないので、現実問題としてどうなのかと思ったのです。 20年前の論文なのでもっと流行っててもよさそうなものですし (停止時間が長いという欠点はありますが)。 491 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 19:20:52 ] コピーGCでは1回のGCのコストがヒープ領域の大きさに依存しないので、 ヒープ領域が大きいほどGC回数が減ってGCのオーバヘッドが小さくなる ということ自体は別に直感に反してないし、流行る流行らないの話ではない と思うな。他の要因がなければヒープ領域は大きいに越したことはないに 決まってるし。 492 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 19:34:11 ] >>490 ＞現実問題としてどうなのか が知りたいなら、>>479の時点でそう書け。 学生がゼミの宿題で悩んでるのかと思って 時間割いちまったじゃねぇか。 493 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 20:30:01 ] 知ってる人には当たり前の内容で 知らない人には何を言ってるかわからない説明力。 494 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 20:42:14 ] >>491 その通りなんですが、スタックをヒープとみなしてポップせずにGCで回収してしまおう って話なんです。何度も書きますが。 VMのスタックをGCで回収させる処理系って何があるでしょうか。 >>492 ごめんなさい。2chにこんな優しい人がいるなんて。 495 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 21:00:24 ] さあどんどん後出し設定が出てきますよ。 496 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 22:22:51 ] >>485 ＞VMのスタックをポップせずに一杯になったときにGCを起動 >>494 ＞スタックをヒープとみなしてポップせずにGCで回収 それって普通はスタック上で確保するフレームを ヒープ上に確保するのと一緒だから パフォーマンスが悪くなることはあっても良くなる事はないんじゃない？ 497 名前：デフォルトの名無しさん mailto:sage [2006/02/09(木) 06:21:45 ] >>496 494はたぶんHenry BakerのCheney on the M.T.A.みたいな話を してるんだと想像するが。この話のキモは、多くのオブジェクトは 短命で、GCが走る頃にはごみになってるからヒープにさえ移らな いってこと。スタックを世代別GCの第0世代とみなしてると考えても良い。 で、Chickenがそれを実装してるわけだが。Scheme処理系としての 性能はそこそこ良いらしいが、処理系の性能はGC以外の部分にも 依存するからねえ。Cheney on the MTA自体がどのくらいの性能かを 測るには、GC部分だけを取り替えて比べるしかないんじゃない。 498 名前：デフォルトの名無しさん mailto:sage [2006/02/09(木) 07:35:56 ] >>497 言語の構造にも依存するんだよね、ヒープ上につくるオブジェクトの種類。 もし比較するならそのあたりの事も考慮しないといけないし、その場合の 試験プログラムの内容も影響受けるだろうし面倒臭そうだね。 499 名前：デフォルトの名無しさん mailto:sage [2006/02/09(木) 11:11:46 ] そだね。特に第一級の継続が無い言語ではアクティベーションフレームの エクステントは関数を抜けるまでに決まってるから、popしてしまう方が 良さそうだ。継続がある場合はどうせ捕捉時にスタックを何とかしなくちゃ ならないからCheney on the MTAと相性が良さそうなんだが。 500 名前：デフォルトの名無しさん mailto:sage [2006/02/09(木) 11:22:34 ] >>499 環境に関してはどうですか？ 一般的にはクロージャが生成されたときにスタックからヒープにコピーすると 思うんですが、それが必要なくなりますよね。 どちみちGCのときにはコピーするので微妙ですが。 501 名前：デフォルトの名無しさん [2006/02/12(日) 14:59:24 ] yaccを使ってるんですが、トークンの数字を文字列に変換することはできますか？ NUMBER => "NUMBER", STRING=>"STRING", '+' => "+" みたいなかんじです。 502 名前：デフォルトの名無しさん [2006/02/12(日) 23:09:56 ] アフォ？ 503 名前：デフォルトの名無しさん mailto:sage [2006/02/13(月) 13:11:20 ] >>501 yaccはそんなことするためのものではないので、ご自分でどうぞ。 504 名前：デフォルトの名無しさん mailto:sage [2006/02/13(月) 20:24:30 ] >>501 yaccの仕事じゃない。 もしどうしても今組んでいるコードがそれを要求するのであればlex側で処理しておくべし（トークンの持ち方で２つの意味づけしとけ） 505 名前：デフォルトの名無しさん [2006/02/14(火) 23:32:01 ] >>501 kmyaccならできる。起動時に-tオプションをつけてみて。 506 名前：デフォルトの名無しさん [2006/02/16(木) 20:56:42 ] kimyacc ? キムチ！ 507 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 00:34:11 ] >>506 うまい！！！！！！！！１ 508 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 00:39:37 ] sage 509 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 01:10:02 ] >>506 ﾜﾛｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ 510 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 04:59:51 ] そういや、少し前にGUI型言語の話が出ていたけれども、 それってオーサリングツールとどう違うの？ 511 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 08:53:21 ] スクリプトや言語の支援ツールとしてのモデリングツールなら、 たま〜に見る。 で思った事なんだが、言語の一部としてモデリングツールがあり、 モデリングツールの細かい調整用にスクリプトを用いたツールを 作ろうと思ってるのだが、このツールは何と呼べば良い？ 512 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 08:56:15 ] >>511 コンパイラでは？ 513 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 09:06:47 ] >>510 オーサリングツール自体が、広義ではコンパイラだと考えられる。 514 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 09:28:22 ] >>512 どちらかといえばスクリプトエンジンの方かと 515 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 09:38:07 ] 「細かい調整」の内容による？ 516 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 11:08:33 ] 大昔のPlusの時代のMacにブロックダイアグラムをGUI上で用いて機能設計 （というよりモジュールプログラムって感じ）して、バイナリを出すシステム があったけど、そういう奴のこと？>>510 それともIBMのVisualAgeシリーズみたいな奴かな？ 517 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 11:33:02 ] >>516 前スレの最後の方で出てたネタなんだが・・・見れないな。 CAD/CAMとか、UMLとか、電子回路みたいな奴の事。 DVDの編集ツールとか、アニメーション製作ツールといったオーサリングツールと、どうも似てるなと。 518 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 11:34:53 ] 前々スレだったかもしれんし、はっきりとは覚えて無いが。 519 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 11:59:53 ] 『コンパイラ入門 C#で学ぶ理論と実践』 って、本はどうなのでしょう？ 初心者向け？ 520 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 02:11:30 ] >519 だれか答えてやれよ。 521 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 03:03:09 ] amazonの書評にも誰も書いてねーよーな 1000部も出てないだろう本の内容なんか知るかボケ。 自分で買うなり立ち読みするなりして調べろバーカ。 522 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 05:37:26 ] 無理してレスつけなくてもいいんだよ 523 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 07:32:33 ] omaemona 524 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 12:09:03 ] 521は無理矢理感ありまくりだけど 522はそうでもない 525 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 14:22:05 ] と、522が寂しそうにつぶやいた。 526 名前：デフォルトの名無しさん [2006/02/19(日) 20:07:33 ] やっぱりこのスレLispやRubyがネタに絡まないと寂れる一方ですね。 Lisp最高!!! と言ってみるtest 527 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 20:15:00 ] ↓Ｌｉｓｐｎおなにが良いか答えなさい 528 名前：デフォルトの名無しさん [2006/02/19(日) 20:42:23 ] ば〜かw Rubyがいいに決まってるだろ？ 新しい時代には新しい言語が必要だ Lisp？はぁ〜？ コボルジジイと一緒にオナ●ーでもしてる！ 529 名前：デフォルトの名無しさん [2006/02/19(日) 20:46:14 ] はぁあ……Ｌisp……カッコいいのぉ…… S式……すごい興奮します…… あふっ、いぐのぉおおおっ、インデントすごいぃいいい！ いくっ、いきます、いっちゃう！いぐぅぅぅぅぅぅぅぅぅぅぅぅぅぅぅぅぅ!!! 530 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 21:07:07 ] よし、いいだろう！ 531 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 21:12:10 ] 燃料投下の自作自演イラネ 532 名前：デフォルトの名無しさん [2006/02/20(月) 00:27:06 ] 最強はJRubyだろ Javaの機能も使える超絶的多機能Ruby 533 名前：デフォルトの名無しさん mailto:sage [2006/02/20(月) 00:29:24 ] AspJ 534 名前：デフォルトの名無しさん [2006/02/20(月) 00:56:14 ] lispy 535 名前：デフォルトの名無しさん mailto:sage [2006/02/20(月) 03:19:33 ] ようやく俺Lispにクロージャが加わった記念にカキコ 536 名前：デフォルトの名無しさん [2006/02/21(火) 20:42:51 ] Lispって存在意義あるの？ ゴボルと一緒で保守用？ 537 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 21:02:06 ] そろそろ釣り餌の変え時では？ 信者の多そうなHaskellとかSmalltalkがお勧め 538 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 21:23:40 ] 信者率は高いだろうが、絶対数がな 539 名前：デフォルトの名無しさん [2006/02/21(火) 23:40:07 ] 釣り餌じゃなく本当に lisp の存在意義が疑問なんだが （除く、研究用） 540 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 23:46:27 ] >>539自分で答え言ってるじゃ 541 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 23:47:50 ] 疑問に思う >>529 に尋ねる。 なぜ「研究用」が除かれるんだ？ 542 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 23:50:05 ] 手軽に自分用のスクリプトを組み込むという用途としては 最適であるのは間違いないと思うがな。 543 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 00:37:49 ] >>539 には Python の存在意義を問うてみたいな。 544 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 00:46:40 ] Java用のスクリプト言語にHaskellが加わったらしいね Javaのスクリプトコレクションがどんどん増えていって楽しい 545 名前：539 [2006/02/22(水) 21:51:56 ] 釣り餌じゃなく本当に python の存在意義が疑問なんだが （除く、実用） 546 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 21:53:16 ] > Lispの存在意義 新しい言語を手軽に実装できる、に尽きるような。 (で、この言葉がまた誤解されると。) 547 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 00:44:35 ] 釣り餌じゃなく本当に ruby の存在意義が疑問なんだが （除く、他の言語を見下して優越感に浸る） 548 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 00:49:39 ] Pythonは教育用言語がはじまりだよ だれが書いても同じようなソースになるのは意図したこと 汚くないソースを書く癖を付けさせるためにインデントを強制している 549 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 01:11:55 ] >>548 Pythonって使ったことないんだけどtabの扱いってどうなるの？ 550 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 02:35:36 ] >>542 >手軽に自分用のスクリプトを組み込むという用途としては >最適であるのは間違いないと思うがな。 なんで? パーサ書くのが簡単だから、というのはよく聞くけど、パーサなんて パーサジェネレータ使えば簡単に生成できるから、メリットにならんと思う。 LL(1)文法なら再帰下降パーサでもそんなに大変じゃないし。 # だからよく聞く「言語処理系を作りたければまずLispから」ってのは # おかしいと思う。みんな、自分が普段使ってるCとかJavaみたいなのから # 処理系に興味を持つんだから、そういうのを作ってみたいんじゃなかろうか。 それとも他の理由? 551 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 03:01:37 ] >>549 www.python.jp/doc/nightly/ref/indentation.html >まず、タブは (左から右の方向に) 1 つから 8 つのスペースで置き換えられ、 >置き換え後の文字列の終わりの位置までの文字数が 8 の倍数になるように調整されます >(Unixで使われている規則と同じになるよう意図されています)。 で、下がったインデントが上がるときには以前のどっかのインデントレベルと 合ってなければいけないけれど、1回のインデントでどれだけ下げるかは 決められてなくて、2文字インデントと4文字インデントと8文字インデントが 混在していてもいいってことか。 >>548 >だれが書いても同じようなソースになるのは意図したこと >汚くないソースを書く癖を付けさせるためにインデントを強制している 中途半端だよなあ。 www.artima.com/weblogs/viewpost.jsp?thread=101968 >All code indented with four spaces. This will also get rid of the tabs problem! やっぱこれだこれ。 552 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 07:19:59 ] >>550 他の理由。 飽きれるぐらい繰り返し出てる話だけど、 新しい言語を追加できるんだよ。 553 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 09:40:18 ] 　 554 名前：デフォルトの名無しさん [2006/02/23(木) 21:26:25 ] >>547 それ程までに、優越感を感じる言語って 一体…？ 555 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 22:27:38 ] 習得が難しい言語でなければ ユーザーが優越感を感じたりはしないだろうな 556 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 22:29:43 ] >>555 よい言語ではある、でも偉いのは作ったmatzで優越感を感じてる厨房は単なる馬鹿 557 名前：デフォルトの名無しさん mailto:sage [2006/02/24(金) 00:35:12 ] >>552 >新しい言語を追加できるんだよ。 新しい言語を「何に」追加するのさ。 542は、AutoCADがAutoLispを組み込んでいるように、アプリケーションにLispを 組み込む話をしてるのかと思ったから550を書いたんだけど、違ってたのかね。 Lispでプログラムをばりばり書きながら、そのなかのある特定の領域について DSLが欲しいと思ったときにLispだと楽に作れるって話? だとすれば、それはどんな言語をどんな形態で組み込むことを想定しているの? (1)Lispでスキャナやパーサを書いて、Lispとはまったく似ていない言語を組み込む。 (2)Lispのリーダを使ってS式を読み込み、自力で評価する。 (3)Lispのマクロで俺言語っぽいものを作る。 どれ? (2), (3)だと、作れる言語は所詮S式になるな。 558 名前：デフォルトの名無しさん mailto:sage [2006/02/24(金) 01:16:46 ] >>557 もちろんLispを使うということはS式ありきだよ。 552じゃないけどLisperの思考なら(1)も結果をS式に変換して、 Lispにそのまま食わせたり(これが(2)や(3)に繋がったり)すると思うよ。 適当に俺言語っぽいものを作ってみたとして、仮にS式で不満に なったらフロントエンドに俺言語スキャナを追加したりという、 色んな箇所で入出力できるのがLispの使い勝手の良さに繋がってる のではないかと。 アプリの組み込みについては、とりあえずS式読めるように Lispコアを埋め込んでおくと便利という意味じゃないかな。 559 名前：デフォルトの名無しさん [2006/02/24(金) 09:22:51 ] 括弧が深くならないLISPってないですか？ 560 名前：デフォルトの名無しさん mailto:sage [2006/02/24(金) 09:29:13 ] >>559 (　´Д｀)　キサマ・・・見た目に惑わされているな 561 名前：デフォルトの名無しさん mailto:sage [2006/02/24(金) 10:53:43 ] >>559 XML 562 名前：デフォルトの名無しさん mailto:sage [2006/02/24(金) 20:46:42 ] 括弧開くと括弧閉じるの書き方が違うだけでは 563 名前：デフォルトの名無しさん [2006/02/24(金) 23:13:29 ] 結局は括弧ばかりのカッコウ言語w 564 名前：デフォルトの名無しさん mailto:sage [2006/02/24(金) 23:46:35 ] なにその昭和な親父ギャグ 565 名前：デフォルトの名無しさん [2006/02/25(土) 01:44:26 ] ワンライナーならPythonのPLY。 アプリ組むならC++Boostのspritがデフォなんだけどどうなんだろう。 開発業務における調査・解析の仕事って結構あるのよね。 最終的にはgrep一覧と確認結果をレポートするんだけど、当たりを付ける時は 自前のスクリプト使ってる。 抽象的な入力を対話式に行って解析出来るツールが欲しいなぁと思うこの頃。 誰か作ってません？ 566 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 02:25:16 ] prolog? 567 名前：565 mailto:sage [2006/02/25(土) 02:35:29 ] >>566 あー、そういうアプローチもあるねｗ 自分が考えているのは、もっとバカチョンなやつ。 理想は自然言語をINPUTとして扱えるとか。 チームで使うのに、Prolog覚えるのは敷居を上げてしまうので 普及しない希ガス。 568 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 02:40:22 ] Eliza? 569 名前：565 mailto:sage [2006/02/25(土) 02:53:28 ] >>568 それやりすぎだしｗ つか、相当マニアックだなおい。 文章は命令形式で良いと思うんだ。 list param CFoo::m_bar1 when CFoo::m_bar2 == 0 見たいな感じ。全然自然言語じゃないな。やっぱ形式言語がいいかｗ SQLみたいだと良いかも。 すまんな、求めているものが変わってきたｗ 570 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 10:19:44 ] 死ねよ 571 名前：デフォルトの名無しさん [2006/02/25(土) 11:59:25 ] こうして、またひとり Ruby ユーザが増えました。 めでたしめでたし。 572 名前：デフォルトの名無しさん [2006/02/25(土) 13:34:49 ] >>569 こんな感じだろ もしお金が１０億あれ場合 　会社を辞める それ以外の場合 　銀行を襲う 以上 573 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 15:00:20 ] >>572 ElizaよりMedicが必要な希ガス 574 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 19:01:55 ] 上のほうにあった コンパイラ入門 C#で学ぶ理論と実践 ソフトウェア実践講座 冨沢 高明 (著) www.amazon.co.jp/exec/obidos/ASIN/4797331690/qid=1140946035/sr=1-1/ref=sr_1_10_1/250-3599959-2832238 マクロアセンブラのコードを吐く「ジェネレータ」の説明に60ページほど費やしてました。 このコードをインラインに展開するツールも添付されてます。 現在MS社の上級社員？である著者がアメリカの大学で行っていた講義の中身を再編集した本らしいです。 MS製品の開発環境の使い方から書かれてあるので 手元にC#があれば便利ですが、C++が使える人には多分問題でないでしょう。 Javaのバイトコードを吐く「スモールコンパイラ」本と同程度の内容ですが、 類書でマクロアセンブラのコードジェネレータまで扱う本はあまり無かったのではないでしょうか？ やる気のあるアメリカ人大学生相手の講義が元ネタなので内容はずっと真面目で、 著者は特に情報工学部の実習本・TAのためのガイド本を意識されておられるようです。 ただ、アセンブラ「ジェネレータ」部分ですが、複雑なテクニックは使っていないはず なので、「俺はCのソースを見るだけでアセンブラのコードが頭に浮かんでくる、 これまでにコンパイラはいくつも書いてきた」、という方やRuby厨は買う必要ないと思います。 インタプリタやスクリプト言語の作成から、コンパイラの作成へとステップアップしたいが アセンブラの勉強がどーにも…、という方には喜ばれる内容だと思いました。 575 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 19:04:44 ] 上のほうにあった コンパイラ入門 C#で学ぶ理論と実践 ソフトウェア実践講座 冨沢 高明 (著) www.amazon.co.jp/exec/obidos/ASIN/4797331690/qid=1140946035/sr=1-1/ref=sr_1_10_1/250-3599959-2832238 マクロアセンブラのコードを吐く「ジェネレータ」の説明に60ページほど費やしてました。 このコードをインラインに展開するツールも添付されてます。 現在MS社の上級社員？である著者がアメリカの大学で行っていた講義の中身を再編集した本らしいです。 MS製品の開発環境の使い方から書かれてあるので 手元にC#があれば便利ですが、C++が使える人には多分問題でないでしょう。 Javaのバイトコードを吐く「スモールコンパイラ」本と同程度の内容ですが、 類書でマクロアセンブラのコードジェネレータまで扱う本はあまり無かったのではないでしょうか？ やる気のあるアメリカ人大学生相手の講義が元ネタなので内容はずっと真面目で、 著者は特に情報工学部の実習本・TAのためのガイド本を意識されておられるようです。 ただ、アセンブラ「ジェネレータ」部分ですが、複雑なテクニックは使っていないはず なので、「俺はCのソースを見るだけでアセンブラのコードが頭に浮かんでくる、 これまでにコンパイラはいくつも（心の中に）書いてきた」、という方は勿論買う必要ないと思います。 インタプリタやスクリプト言語の作成から、コンパイラの作成へとステップアップしたいが アセンブラの勉強がどーにも…、という方には喜ばれる内容だと思いました。 576 名前：デフォルトの名無しさん [2006/02/26(日) 22:27:19 ] 上のほうにあった コンパイラ入門 C#で学ぶ理論と実践 ソフトウェア実践講座 冨沢 高明 (著) www.amazon.co.jp/exec/obidos/ASIN/4797331690/qid=1140946035/sr=1-1/ref=sr_1_10_1/250-3599959-2832238 マクロアセンブラのコードを吐く「ジェネレータ」の説明に60ページほど費やしてました。 このコードをインラインに展開するツールも添付されてます。 現在MS社の上級社員？である著者がアメリカの大学で行っていた講義の中身を再編集した本らしいです。 MS製品の開発環境の使い方から書かれてあるので 手元にC#があれば便利ですが、C++が使える人には多分問題でないでしょう。 Javaのバイトコードを吐く「スモールコンパイラ」本と同程度の内容ですが、 類書でマクロアセンブラのコードジェネレータまで扱う本はあまり無かったのではないでしょうか？ やる気のあるアメリカ人大学生相手の講義が元ネタなので内容はずっと真面目で、 著者は特に情報工学部の実習本・TAのためのガイド本を意識されておられるようです。 ただ、アセンブラ「ジェネレータ」部分ですが、複雑なテクニックは使っていないはず なので、「俺はCのソースを見るだけでアセンブラのコードが頭に浮かんでくる、 これまでにコンパイラはいくつも書いてきた」、という方やLisp厨は買う必要ないと思います。 インタプリタやスクリプト言語の作成から、コンパイラの作成へとステップアップしたいが アセンブラの勉強がどーにも…、という方には喜ばれる内容だと思いました。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef