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

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

1:デフォルトの名無しさん
05/12/20 21:43:02
プログラミング言語処理系の開発に興味のある人達のスレッドです。

字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，SSA変換，
CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン，
SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化，
JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。
意味論に関する話題も歓迎です。

過去スレ
1 URLﾘﾝｸ(pc.2ch.net)
2 ｽﾚﾘﾝｸ(tech板)
3 ｽﾚﾘﾝｸ(tech板)
4 ｽﾚﾘﾝｸ(tech板)
5 ｽﾚﾘﾝｸ(tech板)
6 ｽﾚﾘﾝｸ(tech板)
7 ｽﾚﾘﾝｸ(tech板)
8 ｽﾚﾘﾝｸ(tech板)
関連リンクは多分 >>2-10 あたり

2:デフォルトの名無しさん
05/12/20 21:44:10
★コンパイラ一般

・色々なツールの紹介
　URLﾘﾝｸ(catalog.compilertools.net)
・コンパイラ関連のリンク集
　URLﾘﾝｸ(www.ulis.ac.jp)
・スクリプティング言語資料室(仮) (リンク集)
　URLﾘﾝｸ(www.kt.rim.or.jp)
・Compiler Construction
　URLﾘﾝｸ(rananim.ie.u-ryukyu.ac.jp)
・Compiler Construction　(1997)
　URLﾘﾝｸ(rananim.ie.u-ryukyu.ac.jp)
・情報システム工学実験 III コンパイラ・コンパイラ
　URLﾘﾝｸ(math.cs.kitami-it.ac.jp)
・OS/Programming 簡単な C コンパイラ
　URLﾘﾝｸ(www.csg.is.titech.ac.jp)
・正規表現
　URLﾘﾝｸ(hp.vector.co.jp)
・コンパイラ研究・開発情報の一集積所
　URLﾘﾝｸ(compilers.cs.uec.ac.jp)
・Links and Selected Readings
　URLﾘﾝｸ(www.gnu.org)
・国産のコンパイラ共通インフラストラクチャCOINS
　URLﾘﾝｸ(www.coins-project.org)

3:デフォルトの名無しさん
05/12/20 21:48:20
★字句・構文解析

・Lex and YACC primer/HOWTO （邦訳）
　URLﾘﾝｸ(www.linux.or.jp)
・Turbo Pascal Lex/Yacc
　URLﾘﾝｸ(www.musikwissenschaft.uni-mainz.de)
・Jim Roskind's LALR(1) C++ Grammar
　URLﾘﾝｸ(www.empathy.com)
・Flexと Bisonを同時に使う
　URLﾘﾝｸ(guppy.eng.kagawa-u.ac.jp)
・KITE_ASM (yacc,lex)
　URLﾘﾝｸ(www.arch.cs.kumamoto-u.ac.jp)
・bison用のC++ LALR skeleton
　URLﾘﾝｸ(www.bj-ig.de)
・ANTLR（非yaccのパーサジェネレータ）
　URLﾘﾝｸ(www.antlr.org)
・JavaCC(Java Compiler Compiler)
　URLﾘﾝｸ(javacc.dev.java.net)
　URLﾘﾝｸ(village.infoweb.ne.jp)
　URLﾘﾝｸ(www.asahi-net.or.jp)
・CUP, JLex, JFlex
　URLﾘﾝｸ(www.cs.princeton.edu) (JLex, CUP)
　URLﾘﾝｸ(www.jflex.de)
・SableCC
　URLﾘﾝｸ(www.sablecc.org)
・￢＜＞＜∪∪ （notavacc）LALR(1)
　URLﾘﾝｸ(ne.cs.uec.ac.jp)
・boost::spirit（C++のテンプレートでEBNFの構文を模倣）
　URLﾘﾝｸ(spirit.sourceforge.net)
　URLﾘﾝｸ(boost.cppll.jp)（マニュアル日本語化プロジェクト）
　URLﾘﾝｸ(www.fides.dti.ne.jp)

4:デフォルトの名無しさん
05/12/20 21:48:57
★ごみ集め

・GC FAQ -- draft
　URLﾘﾝｸ(www.iecc.com)
・A garbage collector for C and C++
　URLﾘﾝｸ(www.hpl.hp.com)
・一般教養としての Garbage Collection
　URLﾘﾝｸ(www.is.s.u-tokyo.ac.jp)
・Garbage Collection : Algorithms for Automatic Dynamic Memory Management
　URLﾘﾝｸ(www.amazon.com)

★処理系,スクリプト

・kikyou.info (吉里吉里というゲームのスクリプト)
　URLﾘﾝｸ(kikyou.info)
・tiny C コンパイラ (C)
　URLﾘﾝｸ(www.watalab.cs.uec.ac.jp)
・6809用 Micro C コンパイラ
　URLﾘﾝｸ(www.axe-inc.co.jp)
・Portable Object Compiler (Obj-C >> C のトランスレータ？)
　URLﾘﾝｸ(users.pandora.be)
・自作コンパイラの部屋(PL/1, Pascal等)
　URLﾘﾝｸ(www.tokumaru.org)
・『Rubyソースコード完全解説』サポートページ
　URLﾘﾝｸ(i.loveruby.net)
・『やさしい Lisp の作り方』『やさしい Java インタプリタの作り方』
　URLﾘﾝｸ(www.okisoft.co.jp)
・MSによるPEフォーマット仕様書(日本語)
　URLﾘﾝｸ(www.interq.or.jp)

5:デフォルトの名無しさん
05/12/20 21:50:16
★学会

・PLDI
　URLﾘﾝｸ(research.microsoft.com)
　コンパイラの研究に関する最新成果を知りたければまずはここ。
・POPL
　URLﾘﾝｸ(www.cs.princeton.edu)
　PLDIよりは理論寄りだが大いに参考になる。
・ICFP
　URLﾘﾝｸ(icfp06.cs.uchicago.edu)
　関数型言語に関する学会。とても難しい。
・OOPSLA
　URLﾘﾝｸ(www.oopsla.org)
　オブジェクト指向言語に関する学会。最近はやや低調？
・ICCC
　URLﾘﾝｸ(www.st.cs.uni-sb.de)
　ヨーロッパ系。派手さはないが堅実。

6:また貼り忘れてないか
05/12/20 22:07:19
★参考書籍

・コンパイラ　原理・技法・ツール　１＆２
　URLﾘﾝｸ(www.amazon.co.jp)
　URLﾘﾝｸ(www.amazon.co.jp)
　通称ドラゴンブック。バイブル。
・コンパイラ構成法　原田賢一
　URLﾘﾝｸ(www.amazon.co.jp)
　URLﾘﾝｸ(www.hara.cs.keio.ac.jp)　(ソース、正誤表のダウンロード)
・プログラミング言語処理系岩波講座ソフトウェア科学〈5〉佐々政孝
　URLﾘﾝｸ(www.amazon.co.jp)
　一冊で済ませたい人へ。
・コンパイラの構成と最適化中田育男
　URLﾘﾝｸ(www.amazon.co.jp)
　最適化がメインだが、構文解析からコード生成までの基本事項も解説されている。
・コンパイラの仕組み　渡邊　坦
　URLﾘﾝｸ(www.amazon.co.jp)
　薄い奴(185p)を読みたい人に。
・21st Century Compilers (Alfred V. Aho, Sethi, Ravi Sethi, Jeffrey D. Ullman, Monica Lam)
　URLﾘﾝｸ(www.amazon.co.jp)
　まだ出ていない。
・スモールコンパイラの制作で学ぶプログラムのしくみ
　URLﾘﾝｸ(www.cbook24.com)
　初心者向けの優しい解説本。

7:デフォルトの名無しさん
05/12/21 07:44:06
>>6
貼り忘れてないか、はいいけど、リンク先の確認ぐらいしようね、ボク。

8:デフォルトの名無しさん
05/12/21 07:55:32
このスレは質が高くなるといいなあ。

処理系の実装と関係ない、どの言語が優れてるだとかの話は願い下げに
してもらいたい。

あと、このスレの1は前スレのテンプレをそのままコピペしたみたいで
前スレの1が立てたwikiが載ってないね。
URLﾘﾝｸ(www6.atwiki.jp)

9:デフォルトの名無しさん
05/12/21 13:18:54
スクリプト言語の最小構成（これらの機能を満たす物をスクリプト言語と呼ぶと言う定義というか）について議論するのは
このスレでよろしいのでしょうか？

10:デフォルトの名無しさん
05/12/21 15:16:58
>>9
こちらでどうぞ。
ｽﾚﾘﾝｸ(tech板)

11:デフォルトの名無しさん
05/12/21 15:58:32
前スレが埋まったので…

>>9
うはｗまた荒れそうなネタをｗｗ

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

12:デフォルトの名無しさん
05/12/21 20:08:27
荒れそう以前に下らなすぎ。意味がない。

13:デフォルトの名無しさん
05/12/21 20:51:01
>>12
じゃぁ何があればスクリプト言語と呼べると思う？

14:デフォルトの名無しさん
05/12/21 20:54:00
だからそれが下らないって。日本語を理解できないのか?

15:デフォルトの名無しさん
05/12/21 21:21:23
>>13
必死だな市ね

16:デフォルトの名無しさん
05/12/21 21:46:33
>>14
くだらないか？別に結論をださなきゃいけないわけじゃないんだから、
答えの出ない問題をわいわい議論してもいいじゃんか。

なにをもってスクリプト言語というかと聞かれたら、おれなら「処理系（構文解析系）と実行系がひとつになっている言語」と答える。

17:デフォルトの名無しさん
05/12/21 21:48:37
それじゃ、お前らの大好きなLISPを完全にリプレースできるような言語を考えてみないか。
Luaなんか良い線行ってる気がするんだけど、
コードをデータで扱ったり新しい構文は定義できないしなあ。

18:デフォルトの名無しさん
05/12/21 21:59:33
>>17
つECMAScript

19:デフォルトの名無しさん
05/12/21 22:00:22
>>16
言葉遊びにしかならん。逝け。

20:デフォルトの名無しさん
05/12/21 22:05:10
「エンジン」相談室なんだからスレ違いな気がするが…まあいいか。

21:デフォルトの名無しさん
05/12/21 22:26:32
Lisp と Smalltalk を置き換える言語と言えば Apple の作った（作らせた） Dylan があるけど
盛り上がってないな。商用の Windows/Linux 処理系がオープン && フリーになったってのに。
純粋 OOPL かつ関数型言語でマクロもあるらしいけど。

22:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/12/21 22:29:46
>「処理系（構文解析系）と実行系がひとつになっている言語」
これはインタプリタっていうと思います。
あと普通は、「言語」は「仕様」であって「実装」ではないと思います。
実装が仕様って言ってる某言語を除いて。

24:デフォルトの名無しさん
05/12/21 23:25:16
お前ら馬鹿か？ｗｗｗｗ

ＬＩＳＰがあるのに

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

25:デフォルトの名無しさん
05/12/21 23:35:55
インタプリタだけじゃないと思うけど。

26:デフォルトの名無しさん
05/12/22 02:39:57
インタプリタ系の処理で構文木をツリーのままもって処理するのと、バイトコードに落として処理するのとどっちが都合がいいんだろう？

27:デフォルトの名無しさん
05/12/22 03:41:44
>21
FunctionalDeveloperがOpenDylanになって、Gwydion Dylanとそのうちマージされるんじゃ？
と、期待してはいるけどねぇ。
しばらくは混沌としたままという気はするね。MLも停滞中だしなぁ。

28:デフォルトの名無しさん
05/12/22 07:39:28
>>26
何の都合?
とりあえず速度ならバイトコード。デバッグしたいならツリーのまま。

29:デフォルトの名無しさん
05/12/22 11:30:30
何気に Lisp 処理系は開発が盛んなんだよね。SBCL とか。
OpenDylan は何であんなに閑散としてるんだろう。

30:デフォルトの名無しさん
05/12/22 13:17:32
Lispがあるからだろうな。
正直なところ、これ以外どれも同じ。

31:& ◆77HZD.NR0E
05/12/22 21:13:01
同感、他は糞言語

32:デフォルトの名無しさん
05/12/22 21:24:49
>>23
すくりぷとげんごといんたぷりたとのちがいはなに？
ばいなりにおとすかどうか？

33:デフォルトの名無しさん
05/12/22 21:33:40
>>32
落ち着け！>>23は釣り臭いぞ。

34:デフォルトの名無しさん
05/12/22 22:18:33
さすがにLISPじゃ釣れなくなってきたなｗ
どんな阿呆でも、多少は学習能力があるということか

35:デフォルトの名無しさん
05/12/22 22:21:41
>>34
LISPに釣られてるアフォw

36:デフォルトの名無しさん
05/12/22 23:56:28
ベースはLispでも何でもいいんだけど、ドットで階層表現はほしい。
namespace.object.method
つーかluaって結構バランス良さげだね。
何気にproper tail recursionだし。
schemeと同じ様な書き方ができるっぽい。

37:デフォルトの名無しさん
05/12/23 00:30:46
>>36
>ドットで階層表現
リーダーマクロじゃ無理？
(そのままドットで繋げる形式は無理だと思うけど)

38:デフォルトの名無しさん
05/12/23 07:19:25
Lispスレでやれ。
どのみちこういう話してる面子は両方見てるんだろ? 俺もだけど。

39:デフォルトの名無しさん
05/12/23 08:00:10
Lispスレ見てる奴にとってはこのスレレベル低すぎだろ

40:デフォルトの名無しさん
05/12/23 08:17:24
そうなんだけどさ。>>36みたいな話はあっちでもたまに出た記憶が。

41:デフォルトの名無しさん
05/12/23 08:31:11
>>40
というか過去スレで a[x] みたいな配列アクセスとか . でのオブジェクトへの
アクセスとかは実現されてたと思う。でも荒しが粘着している現状で向こうの
住人がわざわざこっち覗きにきたりはしないと思われ。

42:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/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
05/12/23 13:29:00
なるほど次のトークンでRPARENが出たとき
exp exp_list { $1::$2 }
において、 $2 が　[] になるということですね
ありがとうございました。

45:デフォルトの名無しさん
05/12/23 13:51:33
>>36
カモン。
ｽﾚﾘﾝｸ(tech板:20番)

46:デフォルトの名無しさん
05/12/29 00:25:03
ECMAScript程度の言語の構文解析にboost::spiritを使うのってまずい？

47:デフォルトの名無しさん
05/12/29 00:40:05
べつにまずくない

48:デフォルトの名無しさん
05/12/29 01:02:38
unko

49:デフォルトの名無しさん
05/12/29 01:09:40
ECMAScriptの文法は結構手強いよ。

50:デフォルトの名無しさん
05/12/29 09:20:53
既存のソフトウェア資産が全て０から作られると仮定して
ＯＳ側に管理が回りそうな機能と
言語側に標準的に割り当てられそうな機能を教えてくれ

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

51:デフォルトの名無しさん
05/12/29 09:50:25
threading が kernel level で support されてなかったらどうなるか考えてみた?

52:デフォルトの名無しさん
05/12/29 10:28:34
なぜそんな中途半端に英語をしゃべる？

53:デフォルトの名無しさん
05/12/29 11:13:42
>>52
それがナウなヤングなんだよ。

54:デフォルトの名無しさん
05/12/29 12:50:23
>>50
>既存のソフトウェア資産が全て０から作られると仮定して

あのなー、

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

55:デフォルトの名無しさん
05/12/29 13:21:18
ＯＳの足りない機能を補うためにソフトウェア資産があるんだよ
ＯＳの足りない分はソフトウェアがカバーしてるんだよ

56:デフォルトの名無しさん
05/12/29 13:28:14
>>53
ナウでクォー（クール）でヤングですよ。

57:デフォルトの名無しさん
05/12/29 20:52:43
マジレスすると、Rubyの多くの機能は本来はOSが提供するものだろうな。

58:デフォルトの名無しさん
05/12/29 21:05:47
それのどこがどうマジレスなんだ?

59:デフォルトの名無しさん
05/12/30 04:58:42
>>57がRuby要らずのOSを公開するそうです。
みなさんお楽しみに！

60:デフォルトの名無しさん
05/12/30 06:08:19
むしろRubyが必須なOSがあるのか知りたい

61:デフォルトの名無しさん
05/12/30 06:21:04
>>60
ない

62:デフォルトの名無しさん
05/12/30 06:24:26
Ruby 信者とアンチ Ruby が居なければ、このスレも随分と静かになるんだろうなぁ。

63:デフォルトの名無しさん
05/12/30 08:02:02
>>62
大差ないと思うよ。
半分くらいは俺が信者になったりアンチになったりしながら煽ってただけだから。
ちなみに俺はRubyもLISPも使ったことはない。

来年もよろしく。

64:デフォルトの名無しさん
05/12/30 09:38:36
>>63
大差あると思うよ。
もう半分は俺が信者になったりアンチになったりしながらｸﾏしてただけだから。
ちなみに俺はRubyもLispも長年使い込んだ。

今年限りにしておこうか。

65:デフォルトの名無しさん
05/12/30 13:50:43
>>63 要するにお前の自演がウザいから消えてくれたらな…って話なんだよ。
空気読めねー奴だな…。「ちなみに」とかいわなくても君が Ruby を使えない
低能野郎って事は分ってるから来年こそは氏んでくれ。

でも空気読めないからノコノコでてくるんだろうなぁ

66:デフォルトの名無しさん
05/12/30 19:39:50
Rubyついでで恐縮だが、あのソースは本当に凄いな。
まったくの別次元だ。

特にスキャナ

67:デフォルトの名無しさん
05/12/30 23:27:35
パーサのトリックも凄いと思った。

68:デフォルトの名無しさん
05/12/31 04:07:32
GCもスレッドも凄いと思う。

...で、それって結局全部、Rubyの欠点になってるよな。

69:デフォルトの名無しさん
05/12/31 15:59:23
誰かRuby書きなおしてやれよｗ

70:デフォルトの名無しさん
05/12/31 16:27:46
スキャナとパーサは疑う余地がないよな。でもGCとスレッドって凄いっけ？

GCは、前見たときは、わりと標準的なmark-sweepだと思った。

スレッドは基本的に使ったことしかなくて、
スレッドスケジューラとかを作るやり方の話をよく知らなかったから
いまいち判断できなかった。
それでも、現実のOSなんかが搭載してるスケジューラに比べれば、
かなり簡潔(悪く言えばチープ)だろうな、と何となく思った記憶がある。

71:デフォルトの名無しさん
05/12/31 17:11:19
>>70
>GCは、前見たときは、わりと標準的なmark-sweepだと思った。

うーん、Bohemとかと比べるんなら「標準的」なのかもしれないけど、
BohemはC向けだからああならざるを得ないのであって、インタプリタ言語で
なにもわざわざCスタックをスキャンすることないのではないかと。
あれのおかげでsetjmpでレジスタを対比するようなトリックが必要になっているし
(そのせいでCPUごとの#ifdefやインラインアセンブラも必要になっているし)、
ネイティブスレッドと相性が悪いのもあれのせいでしょ。

72:デフォルトの名無しさん
05/12/31 19:05:16
>>71
言語上の問題じゃなくてオブジェクトメモリ操作のアトミック性の問題のためにスタックまで見る羽目になってるだけなんだけど
どうしたもんかねぇ。
個人的にＧＣ関係が勉強になったというか良くできてるな～と関心しきりだったのはioなんだよね。
シンプルなのにジェネレーションベースなんでＧＣに興味がある人は見ておくべきだと思う。

73:デフォルトの名無しさん
05/12/31 19:12:39
> わざわざCスタックをスキャン
CのプログラムがRubyのオブジェクトを捕まえたときに、
Cのプログラムが明示的にそれを開放しなくても良いという利点がある。
これのおかげでCで拡張ライブラリを作ったり
Rubyを他のアプリケーションに組み込んだりしやすくなる。
・・・という目的があったと思った。

でもvolatileつけないといつの間にかオブジェクトが回収される罠があったり、
これのせいでRubyの高速化がしにくかったり。

74:デフォルトの名無しさん
05/12/31 20:28:43
なんだかんだ言っても好きだなw
お前らw

75:デフォルトの名無しさん
05/12/31 20:51:44
>>74
好きです。結婚してくださ(ry

76:デフォルトの名無しさん
05/12/31 22:51:46
volatileによるガードを期待するのはやめて、やばげなところでは
明示的にガードできるようにした方がいいんじゃないかねえ。EmacsのGCPROみたく。

77:デフォルトの名無しさん
05/12/31 22:53:28
EmacsがGCPROとconservative GCを併用できるというわけじゃないんで念のため
(できるのはできるが目的が違う)

78: 【小吉】【1883円】
06/01/01 11:53:17
Rubyの運勢

79:デフォルトの名無しさん
06/01/01 17:14:23
ここでやるなよ。

80:デフォルトの名無しさん
06/01/01 20:50:42
アンチRuby房のほとんどが、メジャーになれない
重箱研究者だったりする件についてw

81:デフォルトの名無しさん
06/01/01 21:29:14
人生相談はこのスレの管轄ではありません

82:デフォルトの名無しさん
06/01/02 00:00:49
>>80
それは言えてるかも。ある意味素人が世界的に有名になって
（以下略

83:デフォルトの名無しさん
06/01/02 00:22:58
すっぱい葡萄理論w

84:デフォルトの名無しさん
06/01/02 00:50:46
その点Lispはそのような心配がない罠
人機の秘密は案外こんなところおにあったりする。

85:デフォルトの名無しさん
06/01/02 00:52:48
やはりLispが原点だね
Rubyだのなんだのと遠回りする馬鹿の多いことよ

86:デフォルトの名無しさん
06/01/02 02:57:54
Lispはある意味Cよりもコンピュータに近い所をプログラマに処理させるわけだから、
そんなに使い易いもんでは無いわな。
Rubyのシンタックスシュガーはやりすぎな感じもするけど……

誰か表記改良版のLisp作らんかね？

87:デフォルトの名無しさん
06/01/02 03:00:55
誰か＝御自分
いいだしっぺの法則

88:デフォルトの名無しさん
06/01/02 03:20:15
JavaScript が C の皮を被った Lisp と言われていますよ。

89:デフォルトの名無しさん
06/01/02 03:35:36
>>88
ネイティブコンパイラとオプショナルな静的型付けと Dylan 風マクロが備わったら認めてやる。

ECMAScript に静的型付けを導入する話はどうなったんだろうか。

90:デフォルトの名無しさん
06/01/02 04:30:38
>>89
どっかで見た4thエディションでは予約語にはなってたようにおもう。
俺はバリアント型大好きだからいまさら感、感じてるけどね。

91:デフォルトの名無しさん
06/01/02 04:53:19
ところで、バリアント型大好きなんだけど、実装ってどういう感じになってるのかぜんぜん検討つかないんですよ。
ライターのM氏のページで、Cでの実装だと型そのものはUNIONにまとめてる感じでした。
やっぱり処理系が扱う変数型をまとめてUNIONにしてしまってフラグ変数で型を見分けて扱うというのが一般的なんでしょうか？
そのときに、たとえばWinapiに対する拡張とか、製作時点で未知のオブジェクトに対応する場合はどういう方向になるんでしょうか？
ヒントでもいいので、お返事お待ちしております。

92:デフォルトの名無しさん
06/01/02 05:01:58
>>91
大筋その認識で間違いない。
ただし未知のオブジェクトなど存在しないと思って良い。
複雑な構造のオブジェクトがあったとしても、
レコード型などのなんらかの既知の型の組み合わせでしかない。

93:デフォルトの名無しさん
06/01/02 05:23:43
>>92
お返事ありがとう。大筋でもあっててよかった。
Winapiのハンドル関連も元をたどればvoid*だったりするのかな。
構造体の内部表現とか結構気になるな。
うぅ。夢は尽きません。

ま、それはそれとして、参考になりました。

94:デフォルトの名無しさん
06/01/02 06:48:16
拡張モジュールを書いてバリアントを増やせる設計って可能だろうか?
つまり、型識別フラグのとりうる値がすべてわかっていないと書けない
部分というのが存在するかしないかなんだけど。
ちょっと考えた限りではなさそうに思える(効率は別として)。

95:デフォルトの名無しさん
06/01/02 08:23:22
最近 scheme の処理系を勉強で書きはじめたのですが
call/cc の実装で、継続を作成するという処理は
トップレベルに戻るコードと
そのときの環境オブジェクトというか全フレームを
対にしてまとめたものを保存しておけばよいのかなあと思ったのですが
gauche とかで、call/cc の実装を見ると結構複雑っぽいことを
しているんだけど、なんか考えが足りないのかなあ
識者の見識を聞かせてください

96:デフォルトの名無しさん
06/01/02 09:03:14
眠れないからC＋＋のバリアントを試作してみたよ。
未知の構造体を格納しつつ自由にメンバにアクセスしたいときってどうやってやるんかな。
リフレクション自作とかしないといけないのかな・・・。ドウヤッテツクルンダ・・・。
void*に突っ込んで使用時にキャストがいいのかな？？スクリプトエンジンでそんな指定どうやって？？
テンプレートは一個しかできない上に決めうちしないといけないから向いてない感じがする。
悩む。

>>94
C言語的構造体指向OO風味だと、メモリの配置さえあってれば問題なく下位の構造体にアクセスできるから、
なんとか構造体EXとかは可能だと思う。関数ポインタつければ仮想関数もどきとかもできますぜ。
ただ、型識別フラグは拡張を指しているだけとかそういうことになりそう。
細かい指定はどうだろ、enumの拡張って動的にできるのかな。あぁ、INTつかえばいいのかな？？
型ID予約制とかそういうことになって管理大変かも？？

とか、書いてたらねむくなってきたなぁ。
論点ずれてたらごめんね。

97:デフォルトの名無しさん
06/01/02 09:30:51
>>95
継続というのはその時点での全アクティベーションレコード (スタック
フレームと思っておけばいい) そのものだから、基本的にはそれだけ
取っておけばいい。アクティベーションレコードを全部ヒープに
アロケートする処理系なら単にその先頭のポインタを掴むだけで済む。
概念的にはとても単純。

複雑になるのは効率を考えるから。普通のプログラムは、継続が絡まない
通常の関数呼び出し/復帰の方がはるかに多く、その場合はスタックを
利用する方が一般的にずっと速い。けれどスタック上のアクティベーション
レコードは関数復帰時に自動的に開放されてしまうから、継続が作られた
場合にそれを防ぐ何らかの方法がいる。継続作成時にヒープにコピーするとか、
継続作成時にスタックのベースを動かしてそれまでのスタックをヒープに
しちゃうとか、色々テクニックはある。

それから、単純な関数呼び出し/復帰モデルで賢い最適化をしたつもりが、
継続が入るとうまく動かなくなるってことも多い。効率を考えてゆくと
だんだん実装は複雑になる。

98:デフォルトの名無しさん
06/01/02 09:51:55
>>97
C++で、コードが複雑な場合に、最適化でバグの発生する理由がようやく理解できた

99:デフォルトの名無しさん
06/01/02 16:10:25
>>96
型式別のフラグ=型を理解するコードへのポインタ
にすればフラグの値を全部知ってる必要は無いでしょう？
実行時にロードされた場所が被るハズないって前提なのではあるけど。

100:デフォルトの名無しさん
06/01/02 16:57:04
C++の話は別でやってくれ
シッシッ

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

102:デフォルトの名無しさん
06/01/02 18:50:56
っ CPS 変換

103:デフォルトの名無しさん
06/01/02 18:58:58
C++って、嫌われてるの？

104:デフォルトの名無しさん
06/01/02 19:01:53
>>102
なるほど！それがまさにそれに該当する方法っぽいです
ただどっちが簡単なんでしょうか

1．ＶＭ作って中間言語へコンパイルして継続を管理
2. ＣＰＳで継続渡し？みたいな形にＳ式をコンバート

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

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

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

ところで実装言語は何？

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

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

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

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

108:デフォルトの名無しさん
06/01/03 08:14:25
>106
Ｃ＃です。ＧＣとか作る自信ないもんで。

109:デフォルトの名無しさん
06/01/03 08:35:02
>>107
typeinfoクラスへの参照をメンバに持っとけって話だろ。

110:デフォルトの名無しさん
06/01/03 08:49:43
>>108
実装する目的がわからんのだけど、もしただの勉強なら、
せっかくだから Scheme で実装したらどう？
(eval 使ってはい終わりって意味じゃないよ)
自分のインタプリタで自分のインタプリタを動かすのは
一度はやっておくべきだと思う。
見当違い、余計なお世話だったら無視してくれ。

111:デフォルトの名無しさん
06/01/03 09:23:29
>>110
Ｃ＃で実装して、.net framework, managed directX と連携してゲームとか
簡単な画像処理のフィルタとかをお手軽に作れるような scheme インタプリタを
作ろうというのが処理系の目的といえば目的ですが・・・
現状はＣ＃のインタプリタ部分は call/cc とかマクロとかその辺を
除けばほぼ完成まで来たので、とりあえずはこの路線で進もうかと。
scheme で実装するというのは発想自体思いつかなんだ
いずれやってみようかなと思いました

112:デフォルトの名無しさん
06/01/03 09:25:40
>>105
スタックを陽に管理するとは？

113:111
06/01/03 09:33:39
ごめん、上げてしまった

114:デフォルトの名無しさん
06/01/03 13:05:21
>>112
構文木を直接評価してくときに、素直に実装言語の(非末尾)再帰を
使うと、対象言語のスタックが実質的には実装言語のスタック上に
置かれることになるでしょ。そうすると継続を捕まえるのが面倒。
対象言語のスタックは自分で管理して、実装言語側で再帰しないように
評価器を呼んで行くことを「陽に管理する」と表現した。
実行時にCPS変換かけてるのと同じことだけどね。

115:デフォルトの名無しさん
06/01/03 19:18:40
ＧＣを自分で実装しようとする人が多いのは
自分でメモリ管理することで（ＧＣ以外の部分でも）最適化の
余地が大きいからでせうかね？

116:デフォルトの名無しさん
06/01/03 19:24:11
>>115
コアの部分に、他人のクセだらけのソースコードを使えるか？という問題かと

117:デフォルトの名無しさん
06/01/03 19:43:53
良くも悪くもＧＣには、作った人の技術の粋が集まるから
他人のＧＣを使うのは、リスクが大きすぎるんだよな
何処にどんなバグが潜んでいるかは、作った人にしか分からない……

118:デフォルトの名無しさん
06/01/03 19:58:43
つか、他人の作ったGCって、Bohem以外にあったっけ?
C/C++にライブラリ乗せただけで使えるGCは原理的にコンサバ以外になり得ないので、
exactなGCが欲しければ、自分で作るしかあるまい。
だいたい、(mark sweepだとすれば)mark phaseはその言語のオブジェクト構造に
モロに依存するから、結局自分で書くことになると思うんだが。

119:デフォルトの名無しさん
06/01/03 20:29:35
Boehm使ってる。
自分で書くことも考えたんだけど、ネイティブスレッドとか
incremental GCへの対応はプラットフォーム依存のコードが
入って来るから、自分一人ではサポートしきれないという判断。
色んなアーキテクチャでテストとデバッグしてくれる要員が
いるくらいプロジェクトが大きくなればいいんだけれどね。

120:デフォルトの名無しさん
06/01/03 20:47:56
>>109
な！そんなクラスが！！！！
目から鱗です。
レスty！！

121:デフォルトの名無しさん
06/01/03 20:52:43
所詮俺言語ってことかw
俺言語に俺研究、本当にお前らときたら（ry

122:デフォルトの名無しさん
06/01/03 21:23:18
そりゃな、誰が好き好んで他人向け言語なんて作るんだ？
自分が好き勝手に色々な事をやりたいから作るんだよ。ｗ
それで他人向けにもなっていて、神になれれば万々歳だよ。ｗｗｗ

妄想入り過ぎだな……orz

123:デフォルトの名無しさん
06/01/03 23:19:20
それで成功した例が、お前らの嫌いなRubyって訳か。
ある意味皮肉なもんだ

124:デフォルトの名無しさん
06/01/03 23:28:49
つまり、ツンデレ？

125:デフォルトの名無しさん
06/01/03 23:43:19
そもそもC言語が自分がUNIX作るために作った俺言語だから。

126:デフォルトの名無しさん
06/01/03 23:45:05
>>124 なにそれ？
>>125 正当化に必死ワロw

127:デフォルトの名無しさん
06/01/03 23:51:48
>>126
表面上は嫌っている（ツンツン）が、
内面では認めている（デレデレ）って意味

128:デフォルトの名無しさん
06/01/04 00:21:52
Ruby最高！
実行速度の遅さと、色々と無駄の多くて破綻している文法以外……

129:デフォルトの名無しさん
06/01/04 00:33:21
ruby の文法って日本語的な思考方向（熟語が最後に来る）になってるような
気がしている

130:デフォルトの名無しさん
06/01/04 00:39:14
>>123
まあねえ。
このスレにいるような連中(のうち何割か)は、俺言語の5つや6つとっくに作ってて
(あるいは作りかけていて)、みーんなディスクの肥やしにしてるんだと思う。
言語処理系作るのなんて別に難しくないんだけど、ちゃんと完成させて、
かつちゃんと普及させる人は珍しい。その点じゃまつもとさんはすごいんだと思う。

131:デフォルトの名無しさん
06/01/04 00:39:41
obj.m1.m2.m3.m4
を
objをm1してm2してm3してm4する。
と書けるようになればいいのかも。

132:デフォルトの名無しさん
06/01/04 00:58:01
ruby のイメージってそんな感じなんですけど

133:デフォルトの名無しさん
06/01/04 01:05:40
>130
まだまだ諦めとらんよ。
（SchemeとIOを合わせたようなのを作成中）

134:デフォルトの名無しさん
06/01/04 01:10:11
SchemeやLispを使うとプロトタイプ作成は早いですよ
最近実感した

135:デフォルトの名無しさん
06/01/04 01:13:51
>>133
くだらねぇなあ。
そういう既存のものを中途半端に組み合わせたのって
数あるつまらん言語のうちの1つになるだけだろ。

136:デフォルトの名無しさん
06/01/04 01:21:07
有名どころが作ったとかではないなら、少なくとも何らかの他と
違う特徴がないとほんとに俺用で終わってしまうな。
Rubyだってフリーで国産とか、イテレータとか、一応特徴あったしな。
LispやSmalltalkやPrologやPerlなどは言うまでもないし。

137:デフォルトの名無しさん
06/01/04 01:24:14
Rubyが出てきた頃は、最初からオブジェクト指向を元に設計されてる
スクリプト言語が無かった。
今では珍しくもないと思われるかもしれないが。

138:デフォルトの名無しさん
06/01/04 02:21:53
Lisp系言語を作っても、ほぼLisp系言語愛好者（超少数派）しか注目しない
しかも、Lisp系言語愛好者は多少浮気をしたところで、
必ず最後はメジャー（少数派の中でだが）なCLかSchemeに戻る
したがって、どうあがいてもユーザーはほとんど出来ないだろうね

139:デフォルトの名無しさん
06/01/04 02:24:17
え？Lispなんて超がつくほどメジャーな部類では？

140:デフォルトの名無しさん
06/01/04 02:30:58
メジャーな言語一覧。
URLﾘﾝｸ(www.answers.com)
ここに載ってないのがマイナーの条件。

141:デフォルトの名無しさん
06/01/04 02:42:32
>>140
Hspとなでしこは世界ではダメだったか･･･
世界的にはRubyのほうが知名度高いんだな。

142:デフォルトの名無しさん
06/01/04 03:15:58
やっぱりLispですね
議論はここに戻る
遠回りするアホは嘲笑の対象だね

143:デフォルトの名無しさん
06/01/04 03:24:58
お願いだから、あんまり Lisp を釣りネタに使わないでくれ。

144:デフォルトの名無しさん
06/01/04 04:27:34
>>139
Lispがマイナー言語だとは書いてないだろ
Lisp愛好者が超少数派と書いたんだ
Lisp愛好者が多数派だと、本気で思ってるなら
死んだほうが良くねえか？
少なくとも、ボケ老人レベルの判断力としか思えんわ

145:デフォルトの名無しさん
06/01/04 05:31:54
全体の割合で見たら超少数派かもしれんが、
A言語愛好家、B言語愛好家、C言語愛好家、
～言語愛好家って、たくさん見てけば超人数
多い部類だと思うが。

146:デフォルトの名無しさん
06/01/04 05:40:35
"Cが好き" の検索結果約 440 件
"Lispが好き" の検索結果約 316 件
"Javaが好き" の検索結果約 259 件
"Rubyが好き" の検索結果約 186 件
"C++が好き" の検索結果約 175 件
"Perlが好き" の検索結果約 134 件
"Pascalが好き" の検索結果約 57 件
"Basicが好き" の検索結果約 25 件

147:デフォルトの名無しさん
06/01/04 05:49:19
Lisp愛好者って最近になってちょっと増えたんじゃないか？
高学歴の若者にファンが多い気がする。

148:デフォルトの名無しさん
06/01/04 05:55:12
>>146
"Cが好き"は別回答含んでねぇか？

149:デフォルトの名無しさん
06/01/04 06:02:24
ウェブ全体から検索で

"I love Ruby" の検索結果約 21,500 件
"I love Java" の検索結果約 17,200 件
"I love C" の検索結果約 13,800 件
"I love Perl" の検索結果約 9,980 件
"I love C++" の検索結果約 1,610 件
"I love Basic" の検索結果約 1,290 件
"I love Lisp" の検索結果約 310 件

いろんな意味で m9（＾Д＾）ﾌﾟｷﾞｬｰ!!

150:デフォルトの名無しさん
06/01/04 06:09:34
vのあとのlは比較的発音しにくいからな。
likeにしてみると多少マシなんじゃないかな？
やってないけど

151:デフォルトの名無しさん
06/01/04 06:13:08
"Lisp hacker" の検索結果約 17,200 件中
"Java hacker" の検索結果約 14,800 件中
"C++ hacker" の検索結果約 1,540 件中
"Ruby hacker" の検索結果約 969 件中

152:デフォルトの名無しさん
06/01/04 06:17:53
>>150
"I like Ruby" の検索結果約 15,700 件
"I like Perl" の検索結果約 14,600 件
"I like Java" の検索結果約 14,000 件
"I like C" の検索結果約 11,000 件
"I like Basic" の検索結果約 1,600 件
"I like Lisp" の検索結果約 653 件
"I like C++" の検索結果約 508 件

なるほど、確かに多少マシだｗ

おまけ。

"Pythonが好き" の検索結果約 91 件
"I love Python" の検索結果約 12,100 件
"I like Python" の検索結果約 24,300 件
"Python hacker" の検索結果約 808 件

153:デフォルトの名無しさん
06/01/04 06:21:59
>>152
しかし、C++より多いのか。
いずれにせよ、それら超メジャー言語と張り合う程度に
愛好家はいるんだから、超少数派というのは当ては
まらないのではないか？

154:デフォルトの名無しさん
06/01/04 06:23:58
Lisp Hackerが多いってのがLispを象徴してるな。
Lisperっていうメジャーな代替表現があるのにこれはすごい。

155:デフォルトの名無しさん
06/01/04 06:30:48
おまいらプラス思考だな。
まあ、Ruby 厨の俺から見ても Lisp が超少数派なわきゃないと思うけどね。

>>153
C++ は確かに超メジャー言語だが、
"I love C++" "I like C++" って発言するほど C++ 自体が好きな奴って
あんまりいないんじゃないかという先入観がある。

>>154
Lisp Hacker ≒ Paul Graham

156:デフォルトの名無しさん
06/01/04 06:31:23
とりあえず、PythonとRubyは人名と宝石が引っかかってるぞ。

157:デフォルトの名無しさん
06/01/04 06:36:19
>>156
今じゃ誰もこんなこと言わないとわかっているが敢えて言わせて貰おう。
ネタにマジレスｶｺﾜﾙｲ

158:デフォルトの名無しさん
06/01/04 08:00:51
まあ何だ。こと布教にかけては、本職の宣教師が最強だったってことじゃねえ?

159:デフォルトの名無しさん
06/01/04 08:28:35
話題がRubyに向かいやすいのは、Rubyの人気が出たことに対する
言語設計者の嫉妬にみえなくもない

160:デフォルトの名無しさん
06/01/04 08:44:56
このスレではRubyのソース読んだ人の割合が他の言語より多いってのも多少関係するかと。
ソースコード完全解説が出版されるはオンラインで公開されるは、挙句Matz氏もソース嫁と言わんばかりの勢いだからな。

161:デフォルトの名無しさん
06/01/04 09:27:27
308 "I hate Ruby"
743 "I hate Perl"
15500 "I hate Java"
726 "I hate C"
988 "I hate Basic"
257 "I hate Lisp"
1320 "I hate C++"

Javaダントツ人気で砂

162:デフォルトの名無しさん
06/01/04 09:32:26
何が嫌いということもないけれど
わざわざ触りたいという気には不思議とならない

163:デフォルトの名無しさん
06/01/04 10:00:09
Python Python!
URLﾘﾝｸ(www.boingboing.net)

164:デフォルトの名無しさん
06/01/04 10:04:42
ていうか、JavaとかBasicとかも違うのひっかかってるから。

165:デフォルトの名無しさん
06/01/04 10:24:01
まあ検索なんかに頼らなくても、
愛好家の数で言ったら、大体

C++、Java、Perl、Pythonなど＞Ruby、Delphi、VBなど＞Lisp、Basic、Pascalなど
＞Cobol、PL/I、Fortran、Prologなど＞＞＞＞＞＞＞＞＞マイナー言語の数々

って感じになるのは、これらを知ってる奴なら納得するだろ？

166:デフォルトの名無しさん
06/01/04 10:49:03
年も改まったのに頭の中は進歩しない奴ばっかりだな。
処理系の実装に関係ない話はどっかよそでやってくれ。

167:デフォルトの名無しさん
06/01/04 11:00:34
処理系と関係ないようでいて間接的に関係あります。

処理系を作っても、特徴がなければただの俺言語になる。
特徴があってもLispのように超少数派になる。
いや、Lispは超少数派ではない。←いまここ

168:デフォルトの名無しさん
06/01/04 11:04:45
特徴の有無が問題なのかよ
レベル低いなあ

169:デフォルトの名無しさん
06/01/04 11:06:55
特徴の有無は問題だろ
レベル低いなあ

↑これと同じくらいお前の論理は無意味

170:デフォルトの名無しさん
06/01/04 11:46:48
なんか、このスレすごいレベル低い・・・もうお気に入りから消そうかな・・・

皆さん、どう思います？

171:デフォルトの名無しさん
06/01/04 11:48:34
>>165
愛好家ってカテゴリだったらC++の位置はそこじゃねぇだろ、実用性じゃダントツだってのは認めるけどさ。
チームに一人デコ助がいるだけで地獄を「簡単」にみられる言語の筆頭だぜ。

172:デフォルトの名無しさん
06/01/04 11:50:58
もうスレ違い議論はやめてくれr
いつから言語比較スレになったんだ？

173:デフォルトの名無しさん
06/01/04 11:54:05
言語比較ほどの価値もないな。
個人個人が好き勝手に好きな言語を推しているに過ぎない。
検索結果がどうのこうのしょうもない外人が書いたようなリストを持ち出そうが、そんなもんが言語研究と何の関係があるんだよ。
お前らもうちょっと理性的に考えたらどうなんだ？

174:デフォルトの名無しさん
06/01/04 12:07:59
自分の好きな言語を押し付けたいだけの厨にそんな事言っても無視するだけだろうな

175:デフォルトの名無しさん
06/01/04 12:09:19
>>167
第二段が間違ってるぞ
「特徴があってもLisp系ではLisperしか食いつかないうえ、
　Lisperは試食しただけで、またCL Schemeに戻る」だ

176:デフォルトの名無しさん
06/01/04 12:20:32
特徴を「他の言語との比較」に頼ってるあたりが
井の中の蛙臭さの原因なんじゃなかろうか

177:デフォルトの名無しさん
06/01/04 12:27:35
まあLispとIoを組み合わせるなんて、いかにも中途半端なオタクが
考えそうなありふれたアイディア。
目だった特徴にはならん。

178:デフォルトの名無しさん
06/01/04 12:28:37
>>176
原因はむしろ比較の基準が使用者の人口なことじゃね？

179:デフォルトの名無しさん
06/01/04 12:31:14
IoってSmalltalkみたいなもんだろ？
CLOSじゃいかんのか？

180:デフォルトの名無しさん
06/01/04 12:34:10
Smalltalkはフォロワーを生み出してるところが偉大だな。
LispもSchemeやJavaScript、果てはRubyやPythonに至るまで
フォロワーを生み出したことに凄さがある。

181:デフォルトの名無しさん
06/01/04 12:42:45
そうニダ
Lisp起源ニダ
Ioも実はLispが起源ニダ

182:デフォルトの名無しさん
06/01/04 12:50:07
>>181
そもそもSmalltalkがLisp起源・・・

183:デフォルトの名無しさん
06/01/04 12:51:57
やっぱりLispですね
議論はここに戻る
遠回りするアホは嘲笑の対象だね

184:デフォルトの名無しさん
06/01/04 13:13:39
>>180
そうだな。何だかんだ言われても、HSPにもフォロワーはいるからな

次ページ