- 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 あたり
- 2 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:44:10 ]
- ★コンパイラ一般
・色々なツールの紹介
catalog.compilertools.net/
・コンパイラ関連のリンク集
www.ulis.ac.jp/~nakai/rel_web_compilers.shtml
・スクリプティング言語資料室(仮) (リンク集)
www.kt.rim.or.jp/~kbk/
・Compiler Construction
rananim.ie.u-ryukyu.ac.jp/~kono/lecture/2000/compiler/index.html
・Compiler Construction (1997)
rananim.ie.u-ryukyu.ac.jp/~kono/lecture/1997/compiler/compiler.html
・情報システム工学実験 III コンパイラ・コンパイラ
math.cs.kitami-it.ac.jp/~fuchino/proin/experimentIII-2000/jikken.html
・OS/Programming 簡単な C コンパイラ
www.csg.is.titech.ac.jp/~chiba/lecture/os/
・正規表現
hp.vector.co.jp/authors/VA007799/viviProg/doc_regexp.htm
・コンパイラ研究・開発情報の一集積所
compilers.cs.uec.ac.jp/
・Links and Selected Readings
www.gnu.org/software/gcc/readings.html
・国産のコンパイラ共通インフラストラクチャCOINS
www.coins-project.org/
- 3 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:48:20 ]
- ★字句・構文解析
・Lex and YACC primer/HOWTO （邦訳）
ttp://www.linux.or.jp/JF/JFdocs/Lex-YACC-HOWTO.html
・Turbo Pascal Lex/Yacc
www.musikwissenschaft.uni-mainz.de/~ag/tply/tply.html
・Jim Roskind's LALR(1) C++ Grammar
ttp://www.empathy.com/pccts/roskind.html
・Flexと Bisonを同時に使う
guppy.eng.kagawa-u.ac.jp/~kagawa/1999/SysProg/both.html
・KITE_ASM (yacc,lex)
www.arch.cs.kumamoto-u.ac.jp/project/kite/kiteasm/
・bison用のC++ LALR skeleton
ttp://www.bj-ig.de/software/bison/
・ANTLR（非yaccのパーサジェネレータ）
ttp://www.antlr.org/
・JavaCC(Java Compiler Compiler)
ttps://javacc.dev.java.net/
ttp://village.infoweb.ne.jp/~fwif0083/program/java/javacc/javaccgrm.html
ttp://www.asahi-net.or.jp/~DP8T-ASM/java/tips/JavaCCHelloWorld.html
・CUP, JLex, JFlex
www.cs.princeton.edu/~appel/modern/java/ (JLex, CUP)
ttp://www.jflex.de/
・SableCC
ttp://www.sablecc.org/
・¬＜＞＜∪∪ （notavacc）LALR(1)
ne.cs.uec.ac.jp/~koto/notavacc/
・boost::spirit（C++のテンプレートでEBNFの構文を模倣）
spirit.sourceforge.net/
ttp://boost.cppll.jp/HEAD/libs/spirit/index.html（マニュアル日本語化プロジェクト）
ttp://www.fides.dti.ne.jp/~oka-t/cpplab-boost-spirit.html
- 4 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:48:57 ]
- ★ごみ集め
・GC FAQ -- draft
www.iecc.com/gclist/GC-faq.html
・A garbage collector for C and C++
www.hpl.hp.com/personal/Hans_Boehm/gc/
・一般教養としての Garbage Collection
www.is.s.u-tokyo.ac.jp/~vu/01/jugyo/processor/process/soft/compilerresume/gc/gc.html
・Garbage Collection : Algorithms for Automatic Dynamic Memory Management
www.amazon.com/exec/obidos/ASIN/0471941484/
★処理系,スクリプト
・kikyou.info (吉里吉里というゲームのスクリプト)
kikyou.info/
・tiny C コンパイラ (C)
www.watalab.cs.uec.ac.jp/tinyCabs.html
・6809用 Micro C コンパイラ
www.axe-inc.co.jp/pds/mc09.html
・Portable Object Compiler (Obj-C >> C のトランスレータ？)
users.pandora.be/stes/compiler.html
・自作コンパイラの部屋(PL/1, Pascal等)
www.tokumaru.org/
・『Rubyソースコード完全解説』サポートページ
i.loveruby.net/ja/rhg/
・『やさしい Lisp の作り方』『やさしい Java インタプリタ の作り方』
www.okisoft.co.jp/esc/go.html
・MSによるPEフォーマット仕様書(日本語)
www.interq.or.jp/chubu/r6/reasm/PE_FORMAT/intro.html
- 5 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:50:16 ]
- ★学会
・PLDI
research.microsoft.com/conferences/pldi06/
コンパイラの研究に関する最新成果を知りたければまずはここ。
・POPL
www.cs.princeton.edu/~dpw/popl/06/
PLDIよりは理論寄りだが大いに参考になる。
・ICFP
icfp06.cs.uchicago.edu/
関数型言語に関する学会。とても難しい。
・OOPSLA
www.oopsla.org/
オブジェクト指向言語に関する学会。最近はやや低調？
・ICCC
www.st.cs.uni-sb.de/cc/
ヨーロッパ系。派手さはないが堅実。
- 6 名前：また貼り忘れてないか mailto:sage [2005/12/20(火) 22:07:19 ]
- ★参考書籍
・コンパイラ 原理・技法・ツール １＆２
www.amazon.co.jp/exec/obidos/ASIN/4781905854/
www.amazon.co.jp/exec/obidos/ASIN/4781905862/
通称ドラゴンブック。バイブル。
・コンパイラ構成法 原田 賢一
www.amazon.co.jp/exec/obidos/ASIN/4320029224/
www.hara.cs.keio.ac.jp/kCompiler/ (ソース、正誤表のダウンロード)
・プログラミング言語処理系 岩波講座 ソフトウェア科学〈5〉 佐々 政孝
www.amazon.co.jp/exec/obidos/ASIN/4000103458/
一冊で済ませたい人へ。
・コンパイラの構成と最適化 中田 育男
www.amazon.co.jp/exec/obidos/ASIN/4254121393/
最適化がメインだが、構文解析からコード生成までの基本事項も解説されている。
・コンパイラの仕組み 渡邊 坦
www.amazon.co.jp/exec/obidos/ASIN/4254127081/
薄い奴(185p)を読みたい人に。
・21st Century Compilers (Alfred V. Aho, Sethi, Ravi Sethi, Jeffrey D. Ullman, Monica Lam)
www.amazon.co.jp/exec/obidos/ASIN/0321131436/
まだ出ていない。
・スモールコンパイラの制作で学ぶプログラムのしくみ
www.cbook24.com/bm_detail.asp?sku=4774121770
初心者向けの優しい解説本。
- 7 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 07:44:06 ]
- >>6
貼り忘れてないか、はいいけど、リンク先の確認ぐらいしようね、ボク。
- 8 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 07:55:32 ]
- このスレは質が高くなるといいなあ。
処理系の実装と関係ない、どの言語が優れてるだとかの話は願い下げに
してもらいたい。
あと、このスレの1は前スレのテンプレをそのままコピペしたみたいで
前スレの1が立てたwikiが載ってないね。
www6.atwiki.jp/compilerandscriptengine/
- 9 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 13:18:54 ]
- スクリプト言語の最小構成（これらの機能を満たす物をスクリプト言語と呼ぶと言う定義というか）について議論するのは
このスレでよろしいのでしょうか？
- 10 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 15:16:58 ]
- >>9
こちらでどうぞ。
pc8.2ch.net/test/read.cgi/tech/1131273918/
- 11 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 15:58:32 ]
- 前スレが埋まったので…
>>9
うはｗまた荒れそうなネタをｗｗ
この議論に参加する者は、
「絶対的な答えはない」ということを肝に銘じておくように。
- 12 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:08:27 ]
- 荒れそう以前に下らなすぎ。意味がない。
- 13 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:51:01 ]
- >>12
じゃぁ何があればスクリプト言語と呼べると思う？
- 14 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:54:00 ]
- だからそれが下らないって。日本語を理解できないのか?
- 15 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 21:21:23 ]
- >>13
必死だな市ね
- 16 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 21:46:33 ]
- >>14
くだらないか？別に結論をださなきゃいけないわけじゃないんだから、
答えの出ない問題をわいわい議論してもいいじゃんか。
なにをもってスクリプト言語というかと聞かれたら、おれなら「処理系（構文解析系）と実行系がひとつになっている言語」と答える。
- 17 名前：デフォルトの名無しさん [2005/12/21(水) 21:48:37 ]
- それじゃ、お前らの大好きなLISPを完全にリプレースできるような言語を考えてみないか。
Luaなんか良い線行ってる気がするんだけど、
コードをデータで扱ったり新しい構文は定義できないしなあ。
- 18 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 21:59:33 ]
- >>17
つECMAScript
- 19 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 22:00:22 ]
- >>16
言葉遊びにしかならん。逝け。
- 20 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 22:05:10 ]
- 「エンジン」相談室なんだからスレ違いな気がするが…まあいいか。
- 21 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 22:26:32 ]
- Lisp と Smalltalk を置き換える言語と言えば Apple の作った（作らせた） Dylan があるけど
盛り上がってないな。商用の Windows/Linux 処理系がオープン && フリーになったってのに。
純粋 OOPL かつ関数型言語でマクロもあるらしいけど。
- 22 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 22:28:01 ]
- >>16
全部リストだとシーケンスを扱う時に効率悪そうだから
いっそのこと全部ベクターや配列で表現してみてはどうか。
{1 2 3}[0]
=>1
{1 2 3}[1..]
=>{2 3}
{define func0
{function {a b c}
{return {infix a + b + c}}}}
{defmacro defun args
`{define ,args[0] {function ,@args[1..] }}}
{defun func1{a b c}
{return {infix a + b + c}}}
func0{1 2 3}
=>6
func1{1 2 3}
=>6
ふむ。
- 23 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 22:29:46 ]
- >「処理系（構文解析系）と実行系がひとつになっている言語」
これはインタプリタっていうと思います。
あと普通は、「言語」は「仕様」であって「実装」ではないと思います。
実装が仕様って言ってる某言語を除いて。
- 24 名前：デフォルトの名無しさん [2005/12/21(水) 23:25:16 ]
- お前ら馬鹿か？ｗｗｗｗ
ＬＩＳＰがあるのに
これ以上何やろうっての？
- 25 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 23:35:55 ]
- インタプリタだけじゃないと思うけど。
- 26 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 02:39:57 ]
- インタプリタ系の処理で構文木をツリーのままもって処理するのと、バイトコードに落として処理するのとどっちが都合がいいんだろう？
- 27 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 03:41:44 ]
- >21
FunctionalDeveloperがOpenDylanになって、Gwydion Dylanとそのうちマージされるんじゃ？
と、期待してはいるけどねぇ。
しばらくは混沌としたままという気はするね。MLも停滞中だしなぁ。
- 28 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 07:39:28 ]
- >>26
何の都合?
とりあえず速度ならバイトコード。デバッグしたいならツリーのまま。
- 29 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 11:30:30 ]
- 何気に Lisp 処理系は開発が盛んなんだよね。SBCL とか。
OpenDylan は何であんなに閑散としてるんだろう。
- 30 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 13:17:32 ]
- Lispがあるからだろうな。
正直なところ、これ以外どれも同じ。
- 31 名前：& ◆77HZD.NR0E mailto:sage [2005/12/22(木) 21:13:01 ]
- 同感、他は糞言語
- 32 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 21:24:49 ]
- >>23
すくりぷとげんごといんたぷりたとのちがいはなに？
ばいなりにおとすかどうか？
- 33 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 21:33:40 ]
- >>32
落ち着け！>>23は釣り臭いぞ。
- 34 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 22:18:33 ]
- さすがにLISPじゃ釣れなくなってきたなｗ
どんな阿呆でも、多少は学習能力があるということか
- 35 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 22:21:41 ]
- >>34
LISPに釣られてるアフォw
- 36 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 23:56:28 ]
- ベースはLispでも何でもいいんだけど、ドットで階層表現はほしい。
namespace.object.method
つーかluaって結構バランス良さげだね。
何気にproper tail recursionだし。
schemeと同じ様な書き方ができるっぽい。
- 37 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 00:30:46 ]
- >>36
>ドットで階層表現
リーダーマクロじゃ無理？
(そのままドットで繋げる形式は無理だと思うけど)
- 38 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 07:19:25 ]
- Lispスレでやれ。
どのみちこういう話してる面子は両方見てるんだろ? 俺もだけど。
- 39 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 08:00:10 ]
- Lispスレ見てる奴にとってはこのスレレベル低すぎだろ
- 40 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 08:17:24 ]
- そうなんだけどさ。>>36みたいな話はあっちでもたまに出た記憶が。
- 41 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 08:31:11 ]
- >>40
というか過去スレで a[x] みたいな配列アクセスとか . でのオブジェクトへの
アクセスとかは実現されてたと思う。でも荒しが粘着している現状で向こうの
住人がわざわざこっち覗きにきたりはしないと思われ。
- 42 名前：デフォルトの名無しさん [2005/12/23(金) 08:59:00 ]
- 質問。
oscm の構文定義で以下のようになっていたのだけれども
exp :
BOOL { Bool $1 }
| NUMBER { Number $1 }
| CHAR { Char $1 }
| STRING { String $1 }
| SYMBOL { Symbol $1 }
| LPAREN exp_list RPAREN
{ to_cons $2 Nil }
exp_list :
{[]}
| exp exp_list { $1::$2 }
上の定義の中で、
exp_list :
{[]}
の部分がどう作用するのかいまいちわかんないんですけど・・・
いつ、どの順序でこの部分がマッチするんですか？
- 43 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 11:08:52 ]
- その規則(1)は、何も無い部分（空トークン）からexp_listというnon terminalを
生成できることを意味している。exp_listを生成するもう一つの規則(2) exp exp_listは、
必ずexp_listというnon terminalを必要とするので、規則(1)がないとexp_listという
non terminalを生成することができない（帰納法のbase caseに相当する）。
規則(1)が使われる具体的なタイミングは、その構文規則でexpがstart symbolと
仮定すると、次のトークンがRPARENの時だと言える。
- 44 名前：42 mailto:sage [2005/12/23(金) 13:29:00 ]
- なるほど 次のトークンでRPARENが出たとき
exp exp_list { $1::$2 }
において、 $2 が [] になるということですね
ありがとうございました。
- 45 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 13:51:33 ]
- >>36
カモン。
pc8.2ch.net/test/read.cgi/tech/1132275726/20
- 46 名前：デフォルトの名無しさん [2005/12/29(木) 00:25:03 ]
- ECMAScript程度の言語の構文解析にboost::spiritを使うのってまずい？
- 47 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 00:40:05 ]
- べつにまずくない
- 48 名前：デフォルトの名無しさん [2005/12/29(木) 01:02:38 ]
- unko
- 49 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 01:09:40 ]
- ECMAScriptの文法は結構手強いよ。
- 50 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 09:20:53 ]
- 既存のソフトウェア資産が全て０から作られると仮定して
ＯＳ側に管理が回りそうな機能と
言語側に標準的に割り当てられそうな機能を教えてくれ
例えばガベージコレクションはＯＳがやることになって
マルチスレッドは言語レベルでサポートされるのが良いのじゃないかと
- 51 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 09:50:25 ]
- threading が kernel level で support されてなかったらどうなるか考えてみた?
- 52 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 10:28:34 ]
- なぜそんな中途半端に英語をしゃべる？
- 53 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 11:13:42 ]
- >>52
それがナウなヤングなんだよ。
- 54 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 12:50:23 ]
- >>50
>既存のソフトウェア資産が全て０から作られると仮定して
あのなー、
その「全て０から作らなくてはならなくなった理由」がない状態で、
どの機能を何処に割り当てるべきか、なんてのが決まる訳が無いだろ？
- 55 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 13:21:18 ]
- ＯＳの足りない機能を補うためにソフトウェア資産があるんだよ
ＯＳの足りない分はソフトウェアがカバーしてるんだよ
- 56 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 13:28:14 ]
- >>53
ナウでクォー（クール）でヤングですよ。
- 57 名前：デフォルトの名無しさん [2005/12/29(木) 20:52:43 ]
- マジレスすると、Rubyの多くの機能は本来はOSが提供するものだろうな。
- 58 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 21:05:47 ]
- それのどこがどうマジレスなんだ?
- 59 名前：デフォルトの名無しさん mailto:sage [2005/12/30(金) 04:58:42 ]
- >>57がRuby要らずのOSを公開するそうです。
みなさんお楽しみに！
- 60 名前：デフォルトの名無しさん mailto:sage [2005/12/30(金) 06:08:19 ]
- むしろRubyが必須なOSがあるのか知りたい
- 61 名前：デフォルトの名無しさん mailto:sage [2005/12/30(金) 06:21:04 ]
- >>60
ない
- 62 名前：デフォルトの名無しさん mailto:sage [2005/12/30(金) 06:24:26 ]
- Ruby 信者とアンチ Ruby が居なければ、このスレも随分と静かになるんだろうなぁ。
- 63 名前：デフォルトの名無しさん mailto:sage [2005/12/30(金) 08:02:02 ]
- >>62
大差ないと思うよ。
半分くらいは俺が信者になったりアンチになったりしながら煽ってただけだから。
ちなみに俺はRubyもLISPも使ったことはない。
来年もよろしく。
- 64 名前：デフォルトの名無しさん mailto:sage [2005/12/30(金) 09:38:36 ]
- >>63
大差あると思うよ。
もう半分は俺が信者になったりアンチになったりしながらｸﾏしてただけだから。
ちなみに俺はRubyもLispも長年使い込んだ。
今年限りにしておこうか。
- 65 名前：デフォルトの名無しさん mailto:sage [2005/12/30(金) 13:50:43 ]
- >>63 要するにお前の自演がウザいから消えてくれたらな…って話なんだよ。
空気読めねー奴だな…。「ちなみに」とかいわなくても君が Ruby を使えない
低能野郎って事は分ってるから来年こそは氏んでくれ。
でも空気読めないからノコノコでてくるんだろうなぁ
- 66 名前：デフォルトの名無しさん mailto:sage [2005/12/30(金) 19:39:50 ]
- Rubyついでで恐縮だが、あのソースは本当に凄いな。
まったくの別次元だ。
特にスキャナ
- 67 名前：デフォルトの名無しさん mailto:sage [2005/12/30(金) 23:27:35 ]
- パーサのトリックも凄いと思った。
- 68 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 04:07:32 ]
- GCもスレッドも凄いと思う。
...で、それって結局全部、Rubyの欠点になってるよな。
- 69 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 15:59:23 ]
- 誰かRuby書きなおしてやれよｗ
- 70 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 16:27:46 ]
- スキャナとパーサは疑う余地がないよな。でもGCとスレッドって凄いっけ？
GCは、前見たときは、わりと標準的なmark-sweepだと思った。
スレッドは基本的に使ったことしかなくて、
スレッドスケジューラとかを作るやり方の話をよく知らなかったから
いまいち判断できなかった。
それでも、現実のOSなんかが搭載してるスケジューラに比べれば、
かなり簡潔(悪く言えばチープ)だろうな、と何となく思った記憶がある。
- 71 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 17:11:19 ]
- >>70
>GCは、前見たときは、わりと標準的なmark-sweepだと思った。
うーん、Bohemとかと比べるんなら「標準的」なのかもしれないけど、
BohemはC向けだからああならざるを得ないのであって、インタプリタ言語で
なにもわざわざCスタックをスキャンすることないのではないかと。
あれのおかげでsetjmpでレジスタを対比するようなトリックが必要になっているし
(そのせいでCPUごとの#ifdefやインラインアセンブラも必要になっているし)、
ネイティブスレッドと相性が悪いのもあれのせいでしょ。
- 72 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 19:05:16 ]
- >>71
言語上の問題じゃなくてオブジェクトメモリ操作のアトミック性の問題のためにスタックまで見る羽目になってるだけなんだけど
どうしたもんかねぇ。
個人的にＧＣ関係が勉強になったというか良くできてるな〜と関心しきりだったのはioなんだよね。
シンプルなのにジェネレーションベースなんでＧＣに興味がある人は見ておくべきだと思う。
- 73 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 19:12:39 ]
- > わざわざCスタックをスキャン
CのプログラムがRubyのオブジェクトを捕まえたときに、
Cのプログラムが明示的にそれを開放しなくても良いという利点がある。
これのおかげでCで拡張ライブラリを作ったり
Rubyを他のアプリケーションに組み込んだりしやすくなる。
・・・という目的があったと思った。
でもvolatileつけないといつの間にかオブジェクトが回収される罠があったり、
これのせいでRubyの高速化がしにくかったり。
- 74 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 20:28:43 ]
- なんだかんだ言っても好きだなw
お前らw
- 75 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 20:51:44 ]
- >>74
好きです。結婚してくださ(ry
- 76 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 22:51:46 ]
- volatileによるガードを期待するのはやめて、やばげなところでは
明示的にガードできるようにした方がいいんじゃないかねえ。EmacsのGCPROみたく。
- 77 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 22:53:28 ]
- EmacsがGCPROとconservative GCを併用できるというわけじゃないんで念のため
(できるのはできるが目的が違う)
- 78 名前： 【小吉】 【1883円】 mailto:sage [2006/01/01(日) 11:53:17 ]
- Rubyの運勢
- 79 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 17:14:23 ]
- ここでやるなよ。
- 80 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 20:50:42 ]
- アンチRuby房のほとんどが、メジャーになれない
重箱研究者だったりする件についてw
- 81 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 21:29:14 ]
- 人生相談はこのスレの管轄ではありません
- 82 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 00:00:49 ]
- >>80
それは言えてるかも。ある意味素人が世界的に有名になって
（以下略
- 83 名前：デフォルトの名無しさん [2006/01/02(月) 00:22:58 ]
- すっぱい葡萄理論w
- 84 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 00:50:46 ]
- その点Lispはそのような心配がない罠
人機の秘密は案外こんなところおにあったりする。
- 85 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 00:52:48 ]
- やはりLispが原点だね
Rubyだのなんだのと遠回りする馬鹿の多いことよ
- 86 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 02:57:54 ]
- Lispはある意味Cよりもコンピュータに近い所をプログラマに処理させるわけだから、
そんなに使い易いもんでは無いわな。
Rubyのシンタックスシュガーはやりすぎな感じもするけど……
誰か表記改良版のLisp作らんかね？
- 87 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 03:00:55 ]
- 誰か＝御自分
いいだしっぺの法則
- 88 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 03:20:15 ]
- JavaScript が C の皮を被った Lisp と言われていますよ。
- 89 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 03:35:36 ]
- >>88
ネイティブコンパイラとオプショナルな静的型付けと Dylan 風マクロが備わったら認めてやる。
ECMAScript に静的型付けを導入する話はどうなったんだろうか。
- 90 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 04:30:38 ]
- >>89
どっかで見た4thエディションでは予約語にはなってたようにおもう。
俺はバリアント型大好きだからいまさら感、感じてるけどね。
- 91 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 04:53:19 ]
- ところで、バリアント型大好きなんだけど、実装ってどういう感じになってるのかぜんぜん検討つかないんですよ。
ライターのM氏のページで、Cでの実装だと型そのものはUNIONにまとめてる感じでした。
やっぱり処理系が扱う変数型をまとめてUNIONにしてしまってフラグ変数で型を見分けて扱うというのが一般的なんでしょうか？
そのときに、たとえばWinapiに対する拡張とか、製作時点で未知のオブジェクトに対応する場合はどういう方向になるんでしょうか？
ヒントでもいいので、お返事お待ちしております。
- 92 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 05:01:58 ]
- >>91
大筋その認識で間違いない。
ただし未知のオブジェクトなど存在しないと思って良い。
複雑な構造のオブジェクトがあったとしても、
レコード型などのなんらかの既知の型の組み合わせでしかない。
- 93 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 05:23:43 ]
- >>92
お返事ありがとう。大筋でもあっててよかった。
Winapiのハンドル関連も元をたどればvoid*だったりするのかな。
構造体の内部表現とか結構気になるな。
うぅ。夢は尽きません。
ま、それはそれとして、参考になりました。
- 94 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 06:48:16 ]
- 拡張モジュールを書いてバリアントを増やせる設計って可能だろうか?
つまり、型識別フラグのとりうる値がすべてわかっていないと書けない
部分というのが存在するかしないかなんだけど。
ちょっと考えた限りではなさそうに思える(効率は別として)。
- 95 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 08:23:22 ]
- 最近 scheme の処理系を勉強で書きはじめたのですが
call/cc の実装で、継続を作成するという処理は
トップレベルに戻るコードと
そのときの環境オブジェクトというか全フレームを
対にしてまとめたものを保存しておけばよいのかなあと思ったのですが
gauche とかで、call/cc の実装を見ると結構複雑っぽいことを
しているんだけど、なんか考えが足りないのかなあ
識者の見識を聞かせてください
- 96 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 09:03:14 ]
- 眠れないからC＋＋のバリアントを試作してみたよ。
未知の構造体を格納しつつ自由にメンバにアクセスしたいときってどうやってやるんかな。
リフレクション自作とかしないといけないのかな・・・。ドウヤッテツクルンダ・・・。
void*に突っ込んで使用時にキャストがいいのかな？？スクリプトエンジンでそんな指定どうやって？？
テンプレートは一個しかできない上に決めうちしないといけないから向いてない感じがする。
悩む。
>>94
C言語的構造体指向OO風味だと、メモリの配置さえあってれば問題なく下位の構造体にアクセスできるから、
なんとか構造体EXとかは可能だと思う。関数ポインタつければ仮想関数もどきとかもできますぜ。
ただ、型識別フラグは拡張を指しているだけとかそういうことになりそう。
細かい指定はどうだろ、enumの拡張って動的にできるのかな。あぁ、INTつかえばいいのかな？？
型ID予約制とかそういうことになって管理大変かも？？
とか、書いてたらねむくなってきたなぁ。
論点ずれてたらごめんね。
- 97 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 09:30:51 ]
- >>95
継続というのはその時点での全アクティベーションレコード (スタック
フレームと思っておけばいい) そのものだから、基本的にはそれだけ
取っておけばいい。アクティベーションレコードを全部ヒープに
アロケートする処理系なら単にその先頭のポインタを掴むだけで済む。
概念的にはとても単純。
複雑になるのは効率を考えるから。普通のプログラムは、継続が絡まない
通常の関数呼び出し/復帰の方がはるかに多く、その場合はスタックを
利用する方が一般的にずっと速い。けれどスタック上のアクティベーション
レコードは関数復帰時に自動的に開放されてしまうから、継続が作られた
場合にそれを防ぐ何らかの方法がいる。継続作成時にヒープにコピーするとか、
継続作成時にスタックのベースを動かしてそれまでのスタックをヒープに
しちゃうとか、色々テクニックはある。
それから、単純な関数呼び出し/復帰モデルで賢い最適化をしたつもりが、
継続が入るとうまく動かなくなるってことも多い。効率を考えてゆくと
だんだん実装は複雑になる。
- 98 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 09:51:55 ]
- >>97
C++で、コードが複雑な場合に、最適化でバグの発生する理由がようやく理解できた
- 99 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 16:10:25 ]
- >>96
型式別のフラグ=型を理解するコードへのポインタ
にすればフラグの値を全部知ってる必要は無いでしょう？
実行時にロードされた場所が被るハズないって前提なのではあるけど。
- 100 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 16:57:04 ]
- C++の話は別でやってくれ
シッシッ
|
 |
