[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 22:36 / Filesize : 235 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

「コンパイラ・スクリプトエンジン」相談室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 あたり

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
うはwまた荒れそうなネタをww

この議論に参加する者は、
「絶対的な答えはない」ということを肝に銘じておくように。

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 ]
お前ら馬鹿か?wwww

LISPがあるのに

これ以上何やろうっての?



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じゃ釣れなくなってきたなw
どんな阿呆でも、多少は学習能力があるということか

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 ]
既存のソフトウェア資産が全て0から作られると仮定して
OS側に管理が回りそうな機能と
言語側に標準的に割り当てられそうな機能を教えてくれ

例えばガベージコレクションはOSがやることになって
マルチスレッドは言語レベルでサポートされるのが良いのじゃないかと

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
>既存のソフトウェア資産が全て0から作られると仮定して

あのなー、

その「全て0から作らなくてはならなくなった理由」がない状態で、
どの機能を何処に割り当てるべきか、なんてのが決まる訳が無いだろ?


55 名前:デフォルトの名無しさん mailto:sage [2005/12/29(木) 13:21:18 ]
OSの足りない機能を補うためにソフトウェア資産があるんだよ
OSの足りない分はソフトウェアがカバーしてるんだよ


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書きなおしてやれよw

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
言語上の問題じゃなくてオブジェクトメモリ操作のアトミック性の問題のためにスタックまで見る羽目になってるだけなんだけど
どうしたもんかねぇ。
個人的にGC関係が勉強になったというか良くできてるな〜と関心しきりだったのはioなんだよね。
シンプルなのにジェネレーションベースなんでGCに興味がある人は見ておくべきだと思う。


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++の話は別でやってくれ
シッシッ

101 名前:デフォルトの名無しさん mailto:sage [2006/01/02(月) 18:42:13 ]
>>97
効率を考えると色々あるのですね
効率を考えずに単純に実装しようと思うのですが
一度中間言語へコンパイルし、仮想マシンなりで走らせるようにする部分は
継続を実装する上で必須なのでしょうか
中間言語とかなしでインタプリタのままで実装することはできないものかと・・・
例えば、(+ 2 (+ a 1)) とかで、(+ a 1) の継続を
その時点での環境を丸々コピー&(lambda (x) (+ x 2)) を
継続コードとして保存する、とか考えてたのですが、
S式全体から (lambda (x) (+ x 2)) の部分を取得する上手い方法が
思いつかないっす


102 名前:デフォルトの名無しさん mailto:sage [2006/01/02(月) 18:50:56 ]
っ CPS 変換

103 名前:デフォルトの名無しさん mailto:sage [2006/01/02(月) 18:58:58 ]
C++って、嫌われてるの?

104 名前:デフォルトの名無しさん mailto:sage [2006/01/02(月) 19:01:53 ]
>>102
なるほど!それがまさにそれに該当する方法っぽいです
ただどっちが簡単なんでしょうか

1.VM作って中間言語へコンパイルして継続を管理
2. CPSで継続渡し?みたいな形にS式をコンバート

なんか後者も結構メンドイ気がしてきた・・・
初心者向けなのはどっちですか?


105 名前:デフォルトの名無しさん mailto:sage [2006/01/02(月) 19:39:59 ]
別に中間言語にする必要もCPS変換かける必要もない。
ただ、スタックを陽に管理することになるので
(実装言語のスタックをそのままは使えない)
それを仮想マシンと言えなくはない。




106 名前:デフォルトの名無しさん mailto:sage [2006/01/02(月) 20:23:15 ]
効率、実用性を度外視して、とりあえず動くものを作りたいだけなら
CPS 変換の方が圧倒的に楽だと思う。
後は callcc 以外の Scheme インタプリタ作るだけだし。

ところで実装言語は何?



107 名前:デフォルトの名無しさん mailto:sage [2006/01/03(火) 05:30:35 ]
>>99
レスty!
ぜんぜん僕が思ってたのと違う方法なきがする。
型を理解するコードか・・・。変数のことかな。
勉強不足でうまく思い浮かばないOrz

そのほかでは、
名前と値保持の領域をmap使って管理するのがいいのかな。
これ使えばJS風味のバリアントできるな。
でも1オブジェクトに1mapってなんか色々コスト高いような・・・。

あとは関数をどうやって抽象化するかかな・・・。
これこそテンプレートのでばんか!?

という感じで色々ひねって見ます。
ありがとー。



108 名前:デフォルトの名無しさん mailto:sage [2006/01/03(火) 08:14:25 ]
>106
C#です。GCとか作る自信ないもんで。






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<235KB

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