「コンパイラ・スクリプトエンジン」相談室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 あたり 448 名前：初心者 [2006/01/29(日) 21:13:56 ] 質問です。 Yaccとかで論理式の短絡評価を行う常套手段はどのようなものでしょうか？ 例えば、if(a==b||c==d) でa==bが確定するとc==dの評価はスキップ可能ですが、 Yaccとかだと、先にa==bとc==dが認識されてしまうと思うのです。 449 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 21:53:31 ] >>448 yaccが生成するのは構文解析器。 意味解析は通常は構文解析で構文木を作った後のステップであって、yaccはやってくれません。 [文字列]→字句解析→[トークン列]→構文解析→[構文木]→意味解析→[一時コード]→最適化→[ましなコード]→コード生成→[出力コード] というように道のりは長い。 yaccがやってくれるのは構文解析だけ（でも構文解析は最適化の次に面倒くさい部分なので大助かり）。 450 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 23:39:37 ] >>447 それだ 451 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 00:42:32 ] まあ、たいていの入門書ではyaccの最初のサンプルは電卓で、 そのプログラムではアクションの中で計算もやっちゃってることが多いから >>448 のように思ってしまうのも無理はないのかも。 制御構造を持つちゃんとしたプログラミング言語を作ろうと思ったら、 yaccのアクションでは解析木を作るだけにしておいて、評価は後で行います。 452 名前：448(初心者) [2006/01/31(火) 02:22:55 ] >>449,451 そうでしたか。奥が深いですね。 一瞬、言語の仕組みが分かったような錯覚をしましたが、 本格的なものと電卓的なものとでは、ずいぶんとギャップがあるということが わかりました。 ありがとうございました。 453 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 02:33:12 ] C# コード出力するコンパイラコンパイラって、もしかして未だ無い？ 454 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 02:36:00 ] >>452 その錯覚はあながち間違いじゃないよ。 449で道のりは長いとか書いちゃったけど、実際には構文木まで作れれば終わったようなもんだし。 あとはその周辺の理論的な考察とか最適化の手法は好きなように学んだらいいだけ。 455 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 07:15:12 ] >>453 多分ある。というかC#でコンパイラ作るみたいな本がなかったっけか。 456 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 12:20:28 ] >>453 たしかANTLRが対応してたような気が 457 名前：448（初心者） [2006/01/31(火) 23:15:15 ] >>454 どうもです。すこしづつ勉強して行きたいと思います。 （老後の趣味です。ハハハ） ところで、Yaccってコンパイラコンパイラ等と呼ばれたりもしますが、 結構誇張された言い方とも受け取ったのですが、言語専門家の方は どのように感じますか？ （技術的な話でなくてすいません。） 458 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 23:30:38 ] そんなことを聞いてどうする 459 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 01:12:13 ] コンパイラコンパイラは言い過ぎ パーサジェネレータの方がしっくり来る 460 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 02:09:03 ] なんで２ｃｈの回答者って偉そうなのばっかりなんですか？ 461 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 02:16:09 ] Copying でも Generational でも、オブジェクトを移動させる GC で、 移動不可なデータ（ロックとか）ってどう扱ってるのでしょうか。 何かおいしい資料（論文とか）ありましたら教えて下さい。 462 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 06:49:40 ] 移動不可なデータのみを別に扱っておけば良いのでは？ 例えば、移動不可データ専用の予備領域を取っておくとか 463 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 10:08:04 ] >>460 質問者にとっては初めての質問でも、答える方は３度目、４度目というのが当たり前。 日常では温厚な人間でも切れ気味になる。顔が見えりゃいいんだけどね。 おれは一度目にした質問にはレスしないことにしている。 464 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 11:48:51 ] members.at.infoseek.co.jp/zzyyb/gc/incremental-collector.html のインクリメンタルガベコレの説明ですが、 GCが処理しているカレントオブジェクトをプログラムが変更しちゃう場合が 言及されていないのですがまさにその場合が問題である気がします。 カレントオブジェクトが保持する別オブジェクトへの参照のうち、既に処理 した参照が書き換えられるとおかしくなると思うんですが。 465 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 20:10:10 ] >>462 どうもありがとう。後で思いついたんですが、世代別なら一番古い世代に置くというのも手ですね。 466 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 21:42:14 ] >>460 ﾋﾝﾄ：ﾙｻﾝﾁﾏﾝ 467 名前：デフォルトの名無しさん [2006/02/01(水) 22:19:13 ] >>463 ハツモノでもあんたのレスはいらんよw 468 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 23:38:35 ] >>461 俺もちゃんと読んでないけどひとまず貼っとく。 www.nminoru.jp/~nminoru/java/cms/concurrent_mark_sweep.html#45 469 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 00:59:19 ] つ www.shos.info/develop/oo/dscsnptn.html#chapter4 >464 GCが処理しているカレントオブジェクト 　灰色 カレントオブジェクトが保持する別オブジェクトへの参照のうち、既に処理した参照 　灰色 -> 黒 または 　灰色 -> 灰色 灰色 -> 灰色については言及されていないけど、どちらの種類のリンクともうまく処理されます。 470 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 01:46:04 ] 灰色→白は？ カレントオブジェクトに参照A,B,Cがあってこの順で処理するとして、 Aをキューに追加して灰色にした後、Bを処理しようとしているときに 別プログラムがAを白への参照に書き換えてしまったら？ 471 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 23:59:03 ] >470 ごめん、ちょっと勘違いしていたみたい。 ・カレントオブジェクトの処理（参照先の灰色化 & 参照元の黒化）はアトミックに処理する ・カレントオブジェクトが参照された場合、処理を中断してキューの最後に持ってくる ・カレントオブジェクトは黒と同様に処理する あたりはどう？ 472 名前：デフォルトの名無しさん mailto:sage [2006/02/03(金) 00:49:26 ] >>471 最後でしょうか。つまりこの条件においては黒→白取り付けと同様に考える (のでその後に書いてある各手法のようなバリアを張る)と。 前二者はオーバーヘッドが重すぎますよね。 このページ、過渡状態を無視せずにもうちょっと厳密に書いてくれていれば よかったんですけどねえ。 473 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 01:50:29 ] まずカレントオブジェクトを黒にしてから参照先を灰色にすれば、カレントオブジェクトを 特別扱いしなくて済むかな？ 474 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 02:13:51 ] ちょっと考えたら分かることだろ。 475 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 02:48:08 ] >>473 処理中のカレントオブジェクトが 「それが参照している先は必ず灰色か黒」という黒の定義に反することになるのが 気持ち悪い。 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は教育用言語がはじまりだよ だれが書いても同じようなソースになるのは意図したこと 汚くないソースを書く癖を付けさせるためにインデントを強制している

---

---

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

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