5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【コンパイラ・スクリプトエンジン】相談室

1 :デフォルトの名無しさん:2001/02/09(金) 07:55
yaccやlexの使い方やら言語仕様やらの話題。

2 :リンク:2001/02/09(金) 07:58
http://www.cygwin.com/
http://cygwin.cjb.net/


3 :これでどうよ:2001/02/09(金) 11:14
参考リンク
http://rananim.ie.u-ryukyu.ac.jp/~kono/lecture/2000/compiler/index.html
http://compilers.cs.uec.ac.jp/
http://www.arch.cs.kumamoto-u.ac.jp/project/kite/kiteasm/lex/
http://www.arch.cs.kumamoto-u.ac.jp/project/kite/kiteasm/yacc/
http://www.is.s.u-tokyo.ac.jp/~vu/96/cad/compiler.html
http://www.is.s.u-tokyo.ac.jp/~vu/97/jugyo/processor/soft.html
http://www.ulis.ac.jp/~nakai/rel_web_compilers.shtml
http://member.nifty.ne.jp/nakamula/recurs.htm
http://www.tokumaru.org/


4 :デフォルトの名無しさん:2001/02/09(金) 11:26
ここも。
http://compilers.iecc.com/

それとガベージコレクタの話題もOKにしない?


5 :デフォルトの名無しさん:2001/02/09(金) 21:17
ガベージコレクタはマークスイープ法の他に何かありますか?
C/C++でガーベジコレクタは必要だと思いますか?
LISP/Schemeだとセルの大きさが一定な事が多いから、かなり回収率が良い気がしますが、この推論は正しいですか?

6 :デフォルトの名無しさん:2001/02/09(金) 21:20
スクリプトの実行は一般的にインタプリティング、または仮想機械で行なうので遅いです。
ネイティブオブジェクトコードに変換して実行するうまい方法はありますか?

7 :4:2001/02/09(金) 21:20
>>5
> ガベージコレクタはマークスイープ法の他に何かありますか?
http://www.iecc.com/gclist/GC-faq.html
とかどうですか?


8 :4:2001/02/09(金) 21:24
>>6
そういう用途にはスクリプト言語を使わずに
Cで書いたのを呼び出すとかしたほうがいいと思います。

一応こんなのもあるみたいです(ネイティブコードを実行させている)。
http://www19.freeweb.ne.jp/computer/yaneurao/ygs2k/


9 :デフォルトの名無しさん:2001/02/09(金) 21:31
GCは束縛されているオブジェクトのメモリの移動まではできないから、
malloc/freeの問題と同じと考えて良いでしょうか。
best-fit法とかfast-fit法ぐらいしか知らない者で…。

10 :6>8:2001/02/09(金) 21:33
おお!凄いですね。ゲームで使われているのですか。
もしかして、最近のエミュレータとかもこういう形式ですかね。

11 :5:2001/02/09(金) 21:39
>7
参照カウンタ(リファレンスカウンタ)は自己参照がある場合は使えないですね。
JargonとCopyingはどんなアルゴリズムかな。

12 :4:2001/02/09(金) 21:58
>>11
(よく知らないですが)Jargonってのはアルゴリズムじゃなくて
その分野特有の言葉のことだと思うんですけど、、、

http://www.iecc.com/gclist/GC-algorithms.html#Jargon
root setとかlive dataとか書いてるし。

13 :デフォルトの名無しさん:2001/02/09(金) 23:29
>>9
メモリ領域の移動(空き領域を1つにまとめる。デフラグみたい?)
はメモリコンパクションって呼んで
厳密にはGCとは別物
ただ一緒にやってしまうGCの実装も多そうだし
アルゴリズムによっては下記みたいに自動的に
コンパクションもできてしまうものもある
>>11Copyingはたしかヒープを2つに分けて片方がいっぱいになったら
必要なものだけたどってもう一方にコピーするヤツだと思った
メモリの無駄が多いけどコンパクションも一緒にできる

14 :デフォルトの名無しさん:2001/02/09(金) 23:38
>>10
64とか、プレステなんかの
MIPS系列のCPU積んだマシンは
たいていこの手法ですね。

ただ、もっと動的な再コンパイルですが。
jump/callの部分でコード変換したものを
キャッシングすることで速度を稼いでいるようです。

fpse.emuforce.comがソース公開です。


15 :スクリプト系:2001/02/10(土) 00:34
参考リンク
http://www.kt.rim.or.jp/~kbk/

参考になるかな?リンク
http://www.din.or.jp/~glit/TheOddStage/
http://www.sun-inet.or.jp/~yaneurao/


16 :デフォルトの名無しさん:2001/02/10(土) 00:42
LISPやSchemeはスクリプトに入るのかな?実装は一番楽だと思うけど。

17 :デフォルトの名無しさん:2001/02/10(土) 00:45
あ、CommonLISPやR5RSとかの規格に準拠させるならそれなりに大変なんだけども。
それでも他の言語よりは楽かな?

18 :デフォルトの名無しさん:2001/02/10(土) 12:52
自作コンパイラage

19 :デフォルトの名無しさん:2001/02/10(土) 18:46
Schemeが流行るといいなage

20 :デフォルトの名無しさん:2001/02/10(土) 19:47
CommonLISPはそれなりなんてレベルじゃないよ。
schemeもR5RSにキッチリあわせようとすると一月はかかるね。

21 :デフォルトの名無しさん:2001/02/10(土) 21:00
>>20
一ヶ月ですむならやってみようかなぁ…

22 :デフォルトの名無しさん:2001/02/10(土) 22:43
http://www.jah.ne.jp/~naoyuki/index.html
scheme実装とか載ってる。
あとソースも公開されてるし。参考になるかな

23 :デフォルトの名無しさん:2001/02/10(土) 23:27
俺の上司が昔8KバイトのROMにLISPのインタプリタ
を押し込んでいたな・・。


24 :デフォルトの名無しさん:2001/02/10(土) 23:28
>21
最新のR5RSじゃなくてもR4RSに準拠すればオンライン上にある大抵のスクリプトは通るよ。
(あんま変わらないかもしれないけど。)
がんばってね。

25 :デフォルトの名無しさん:2001/02/10(土) 23:30
昔8086のsmallモデルでも動くschemeをCで作ったけど、だいたい2kステップぐらいだった。

26 :デフォルトの名無しさん:2001/02/11(日) 04:41
期待age

27 :デフォルトの名無しさん:2001/02/12(月) 00:15
参考書籍
yacc/lex プログラミングジェネレータ on UNIX - 五月女健治 - tp



28 :デフォルトの名無しさん:2001/02/12(月) 01:28
>>27
その本って絶版じゃなかったっけ。図書館いけばあると思うけど。(啓学出版ってつぶれたんじゃ?)
参考書籍
C stepupシリーズ(3) yaccによるCコンパイラプログラミング
ソフトバンク
ISBN4-89052-136-4
内容:
簡単な8086のASMコードを吐くCコンパイラサブセットの実装が載っている。
niftyにこれの全ソースが落ちているのを昔見ました。

29 :デフォルトの名無しさん:2001/02/12(月) 01:32
コンパイラを作る方法
翔泳社
ISBN4-88135-072-2
内容:
Pascal-Bという処理系の実装(+仮想マシン)

30 :デフォルトの名無しさん:2001/02/12(月) 01:37
CプログラムブックI,II,III
アスキー出版局
ISBN失念
内容:
I にForceインタプリタ
II にREDAというコンパイラ、makeの実装、
III にlispの実装

31 :デフォルトの名無しさん:2001/02/12(月) 01:40
それから、niftyのFPLとかに結構な量の処理系があった。

32 :デフォルトの名無しさん:2001/02/12(月) 01:52
技評の本で、Cライクなコンパイラ、インタプリタと
アセンブラを作成する本があったな。
会社にあるのでいまは挙げられないけど、あとで調べておくよ。


33 :デフォルトの名無しさん:2001/02/12(月) 02:05
>>28
その本、今日買ったんですけど・・・
>>32
気が狂うほど期待です

34 :デフォルトの名無しさん:2001/02/12(月) 02:30
たしか'mc'なんとかでしょ>32
デバッグコンソール環境も付いてた筈。(ただしNEC9801用)

35 :デフォルトの名無しさん:2001/02/12(月) 02:36
昔、アジソンウェスレイ出版社の本でCのインタプリタが載ってるのがあったなあ。
その本は当時としてはかなり内容が濃かった。(マルチスレッドとかTSRとかエディタ、DBなど)
多分もう売ってない。工業系の図書館いけばあると思うけど。

36 :デフォルトの名無しさん:2001/02/12(月) 02:58
大学の図書館にコンパイラの本なんて腐るほど置いてあった。

37 :デフォルトの名無しさん:2001/02/12(月) 07:02
ハードカバーで活版印刷のやつも沢山あった

38 :デフォルトの名無しさん:2001/02/13(火) 01:29
解析を行うにはyacc/lexを選ぶしか方法は無いんでしょうか?
yacc/lex以外の手段はありませんか?
自分でやるのは大変過ぎるからパスですけど…


39 :デフォルトの名無しさん:2001/02/13(火) 01:56
bison/flex

あと、kmyaccとか言うのがなかったっけ?

40 :デフォルトの名無しさん:2001/02/13(火) 02:10
>39
それ全部似た様なモノでしょ?
C程度の構文なら自分でスタック作ってやった方が速いよ。>38

41 :39:2001/02/13(火) 08:47
>>40
マジレスしちゃいやん♥

42 :デフォルトの名無しさん:2001/02/13(火) 12:23
[PolyEditのマクロ言語エンジンの解説]
http://www.doga.co.jp/ptdoga/rensai/cmaga/9611.htm

つーか。
ソフト製作が容易になったせいでコンパイラの需要が増えたのか。
or コンパイラ技術が簡単になったのか。

なんにしても最近独自のスクリプト言語増えすぎ。
なにか標準的な言語を策定してくださいませませ>ISO



43 :ISO:2001/02/13(火) 12:32
Perlに決定しました。
それは置いといて、

>>42
別に色々あってもいいんじゃない?


44 :デフォルトの名無しさん:2001/02/13(火) 13:06
ALGOL 200x,,,

45 :デフォルトの名無しさん:2001/02/13(火) 18:46
LL構文解析はスタック作って、ヒープ領域に置いたほうがいい?
それとも、再帰使ってスタック領域を利用した方がいい?

46 :sage:2001/02/13(火) 19:12
>>45
LL構文解析に限った話題じゃないね sage
エラー処理はOSに任せてスタック使ったら?

47 :32ではないですが:2001/02/13(火) 21:34
>>32,33 技評の本で、Cライクなコンパイラ、インタプリタと
アセンブラを作成する本があったな。

たぶんこれじゃないですか?
「ハイクラスC言語 コンパイラ&インタプリタ」舟本奨 監修 末石吾朗+小林優 著
8080CPUもどきアセンブリコードを生成するコンパイラと、
そのアセンブリコードを実行するインタプリタのソースが載っています。


48 :しつもん:2001/02/14(水) 01:41
ソースが見やすいけど複雑な言語、(私が思うにC/C++みたいな)
ソースはみずらいけど簡単な言語、(私が思うにRubyみたいな)
どちらの方が一般に好まれますかね?


49 :デフォルトの名無しさん:2001/02/14(水) 01:59
ドラゴンブックを読んでるんですが、数学的な証明の部分とかも
ちゃんと理解しないとコンパイラは書けませんか?

50 :デフォルトの名無しさん:2001/02/14(水) 02:33
>>49
いらないと思う。
コンパイラ技術の論理的なこと(???)を理解するには
ドラゴンブックはいい本かもしれないけどあんまり実践的じゃない。と思う。:-)


51 :デフォルトの名無しさん:2001/02/14(水) 02:36
BNFで表したCやC++やJavaやJavaScriptの文法って
どっかにないでしょーか?

52 :デフォルトの名無しさん:2001/02/14(水) 02:46
>>51CならK&Rの付録についていたような、、、

53 :デフォルトの名無しさん:2001/02/14(水) 12:15
>43
ソフトごとにマクロ言語を覚えるのが面倒です(^^;

誰かが優秀な言語のスクリプトエンジンを公開すれば
多分それがデファクトになるのかなぁとも思うんですけどね。


54 :デフォルトの名無しさん:2001/02/14(水) 12:35
>>51 これじゃ駄目?
Javaの文法
http://java.sun.com/docs/books/jls/html/19.doc.html#52996


55 :デフォルトの名無しさん:2001/02/14(水) 15:25
>>53
うーむ。
優秀ってのはよくわからないけど、
o GNU Makefile,VC++,BCBなどのプロジェクトファイルが付属している。
-> .libや.aなどのバイナリも付属させる?

o なるべく小さく。
-> 考え方にもよると思うけどソースファイルで50KBぐらいが限度?

o Lisp系の文法でも良いかもしれないけど、普及するとは考えにくい
(「わ、括弧だ」で敬遠する人がいるかもしれない)。
-> なのでC言語ライクにする。

o ライブラリに依存しない。
-> 構築するのが面倒になるから。
こんなの?

それと聞きたいんだけど、例外処理っていると思う?
型なし言語だとして
try
{
throw "例外";
}
catch e
{
print e, "\n";
}


56 :デフォルトの名無しさん:2001/02/14(水) 16:17
おお、おもしろそう


57 :デフォルトの名無しさん:2001/02/15(木) 00:33
compiler.age();


58 :デフォルトの名無しさん:2001/02/15(木) 12:56
>>55
ソースでの配布キボンヌ。

59 :55:2001/02/15(木) 23:13
>>58
>>55 は「こんなのだったらーいいなー」ってのを書いただけです。。。^^;
作ってるのは作ってるんですけどForthっぽい+自前のGCを装備というやつです。



60 :デフォルトの名無しさん:2001/02/15(木) 23:41
age

61 :baka:2001/02/16(金) 00:51
ほんとに頭よい人は、日本語の文法に由来するコンピュータ言語を
開発してます。英語の文法に由来する言語なんて開発したって、ま
してそれらを理解して使っているレベルでは奴隷以外の何物でもな
いよん。原点に返って日本語で考えることからスタートしないと
日本はいつまでたっても追いつかないのだ。つーか、中国に追い越
されるよん。あっちの人はさすがに精神的な文化レベルは日本にも
ひけをとらないため、ユニークな言語があるよん。それも中国語に
由来する文法で考えたコンピュータ言語が。



62 :デフォルトの名無しさん:2001/02/16(金) 01:10
>>61
これは日本語に由来してますか?
10 a =
# 10をaに代入する

63 :デフォルトの名無しさん:2001/02/16(金) 01:48
>>61
こんなスレにも煽りがいるのか。
そんなあなたはMINDを使っててください。

あと、そのユニークな中国製言語の具体例を挙げてください。
さぁ、どうぞ。

64 :デフォルトの名無しさん:2001/02/16(金) 02:28
ま、面白そうかなとは思うけどね。
しょせんは英語読めない人間の戯言でしょ。

時に、中国語の文法は日本語より英語の文法に近いんじゃなかったっけw


65 :デフォルトの名無しさん:2001/02/16(金) 02:40
何を言う! 我らにはギコBASICがあるではないか!

66 :baka:2001/02/16(金) 02:45
ば〜か、中国語が英語に似てるにはS+Vと動詞に慣用的にくっつく
一部の前置詞くらいのもの。時制なんか日本語のほうに近いよ。
例えば中国語に完了形なんてない。
中国製の言語か?自分で調べろ。誰がタダで教えるか。
確かに俺は英語読めないかもしれんが、少なくとも64よりはあ
るよん。
あおったつもりはない。聖書を読んでああでもないこうでもない
と屁理屈いってるやつと同じレベルの君たちに危機感をもっただ
けだよん。


67 :baka:2001/02/16(金) 02:55
>62

おっと見落としてた。何がいいたんだ?なんの反応もできないが
しょせん俺もバカだから許してくれ。一言いわせてもらえば
そーいう解釈する普通の日本人がどれだけいるかが問題だ。
そーいうルールを作ったとして、拡張、応用していけるかが問題
だな。拡張、応用するにしたがって解釈するのにヘイコラとなっ
たらその言語は失敗だ!
それしか胃炎。




68 :デフォルトの名無しさん:2001/02/16(金) 06:45
>>66
えっと、プログラミング言語についてかんがえてるんですよね。
時制ってそんなに関係のあるものってわけでもないと思います。
むしろS+Vみたいな部分のほうが大切。

69 :デフォルトの名無しさん:2001/02/16(金) 09:21
おお。bakaの意見は、煽りと思わせつつ、かなり建設的ではないか!

70 :デフォルトの名無しさん:2001/02/16(金) 09:41
わけわかんないこと叫んでるbakaがいるなー。
英語に由来しようが、日本語に由来しようが、
数あるプログラミング・パラダイムに沿って
プログラムを組み立てられなければ実用性なし。
せいぜい理想を追っかけててください。


71 :デフォルトの名無しさん:2001/02/16(金) 10:56
>>baka
バカなら黙ってろ。

ところでMLみたいな関数型言語を作ってみようという人はいませんか?

72 :デフォルトの名無しさん:2001/02/16(金) 11:14
>>66
>中国製の言語か?自分で調べろ。誰がタダで教えるか。

そりゃ、知らないものは教えようがないよね。

73 :デフォルトの名無しさん:2001/02/16(金) 11:18
>>68
そうだね、プログラム言語に過去とか現在なんて概念はないし。
>>66が言ってることは、ちんぷん漢文だよ(藁

74 :デフォルトの名無しさん:2001/02/16(金) 11:20
>>66
君が>>64よりも英語ができると思った根拠を示せ。

75 :デフォルトの名無しさん:2001/02/16(金) 11:45
話題を変えようぜ。
関数型言語ってどんなのなんですか?
全部が関数で作られてるとか???


76 :デフォルトの名無しさん:2001/02/16(金) 11:49
>>66
今何時ですか?

77 :デフォルトの名無しさん:2001/02/16(金) 12:02
>>75
この辺とか。
http://www.gin.or.jp/users/daikoku/ml/whatml.htm

Appelのコンパイラ本(タイガーブック)にはML、Java、C版があって、
本来意図したのはML版だそうです。なのでJava版やC版の記述に
は不自然な箇所が結構あるそうなのですが、私はC版しか読んで
ないので、具体的にどこなのかよくわかりません。

タイガーブック
http://www.cs.princeton.edu/~appel/modern/
ドラゴンブックよりも実践指向で、オブジェクト指向言語とか最近の
トピックも押さえているので、ぜひ日本語版が出てほしい本です。

78 :デフォルトの名無しさん:2001/02/16(金) 22:41
>>75
ループが無いとか、
変数に代入ができない(するべきではない)とか、
わたしも最初、「こんなのでプログラム書けるの?」と不思議でした。
でも、慣れるとCやJavaよりすっきりとしたコードで
プログラムできるんですよ。

日本語では
「プログラミング言語ML」ウルマン、アスキー
「プログラミング言語」武市正人 岩波講座ソフトウェア科学
が関数型言語を解説しています。


79 :デフォルトの名無しさん:2001/02/17(土) 00:27
完全なオブジェクト指向の言語ってどうもとっつきずらいです…
C++なんかはオブジェクト指向のいいとこどりみたいでいいかんじだと思うんですが、
どうでしょう?
やっぱりオブジェクト指向なら完全にオブジェクト指向でいかないとだめなもんですか?

80 :デフォルトの名無しさん:2001/02/17(土) 00:45
オブジェクト指向プログラミング言語と他のオブジェクト指向なんちゃら
はちょっと違うよーん。JavaとかC#みたいなのはそのオブジェクト指向設計
とかと親和性が高いというのが使いやすい人にとっては使いやすいよーん。

81 :部外者A:2001/02/17(土) 01:31
>78
Lisp/Schemeも関数型言語じゃなかった?
ローカル変数使えるけど。
MLが完全な関数型に近いと聞くけど、どうちがうのか調べてないのでわからんです。

82 :デフォルトの名無しさん:2001/02/17(土) 02:27
http://www.ascii.co.jp/ghelp/21/002130.html

83 :デフォルトの名無しさん:2001/02/17(土) 03:28
言語処理系は一から自分でアルゴリズムを考えようとすると死にそう
ですが、みなさんどんな本を読みましたか?
洋書の定番として読みにくさの順で、

ドラゴンブック
タイガーブック

あたりだと思いますが、他にもっと読みやすい本とかないでしょうか?

パーサや正規表現の解説も「yaccとlexに頼れ」で飛ばすんじゃなく、
ある程度わかりやすく説明して本がいいのですが。

84 :デフォルトの名無しさん:2001/02/17(土) 05:50
C++はテンプレートがかなりいい。
でも、規則の組み合わさり方が複雑すぎる。

85 :デフォルトの名無しさん:2001/02/17(土) 06:41
>>80
>よーん
馬鹿?(ワラ

86 :デフォルトの名無しさん:2001/02/17(土) 06:51
>>85
まあまあ、別に「よーん」って言おうが言うまいが、コンピュータ言語
について話す上では関係ないことだし。
つーか、そんなとこにいちいち突っ込む君の方が馬鹿じゃん。

87 :デフォルトの名無しさん:2001/02/17(土) 11:20
ていうか意味わかんねーなと思ったけど、80。

88 :デフォルトの名無しさん:2001/02/17(土) 12:57
よーん、、87がいじめるモナー
         ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄ ̄
           ∩_∩
          ( ´Д⊂ヽ
         ⊂    ノ
           人  Y
          し (_)

89 :デフォルトの名無しさん:2001/02/17(土) 14:01
赤塚ファンが苛められてるな。
いや、とりみきファンの可能性も、、

90 :83:2001/02/17(土) 18:14
だれか洩れの質問>>83に答えてください。

91 :not 83, not 90:2001/02/17(土) 23:19
>>83
ageなきゃ意味ないだろー。

92 :部外者A:2001/02/18(日) 00:20
ドラゴンブックは翻訳されてるけど。>83
他に何か?

93 :ミトコンドリ子:2001/02/18(日) 03:13
>>83
プログラミング言語処理系 岩波講座ソフトウェア科学5
ISBN4-00-010345-8
なんてどうかしら? 適当に端折られてるから、ドラゴンブックよりは
読みやすいかもしれないわ。

ついでに、タイガーブックってしらないんだけど、正式名称教えていただけ
ないかしら。

94 :部外者A:2001/02/18(日) 03:19
それ持ってるけど、内用はまんまドラゴンブックの縮小版って感じだね。>93
(それでも辞典並みに分厚いけど)

95 :デフォルトの名無しさん:2001/02/18(日) 03:25
>>93
あー思い出した。俺もそう思うよ。
>>94
読み比べるとやっぱり読みやすいと思うよ。
ただそれを元に実装しようと思うと足りない情報があって、
結局ドラゴンブック読むことになるって感じかな……
どうよ。

96 :部外者A:2001/02/18(日) 03:27
>94
x内用
o内容

薄っぺらいのが良いなら、
計算機科学/ソフトウェア技術講座7「コンパイラの理論と実現」
ISBN4-320-02382-X
共立出版 2700円
てのもある。
最後にC--というコンパイラの実装が乗っている。
これのパーサはyaccを使った物と、再帰下降の2種類が掲載されている。

97 :ミトコンドリ子:2001/02/18(日) 03:28
>>95
そうそう、そのとおり。
理屈だけ知るなら93
実装までするならドラゴンブックって感じかしらね。

98 :デフォルトの名無しさん:2001/02/18(日) 06:12
実装だけならドラゴンブックいらん・・・。

99 :83:2001/02/18(日) 07:13
>>93
ドラゴンブックとは、

Modern Compiler Implementation in ML/Java/C
Andrew W. Appel
ISBN 0-521-58274-1
ISBN 0-521-58388-8
ISBN 0-521-58390-X

のことです。
ドラゴンブックの竜に対して、こちらの表紙は虎になっています。

ドラゴンブックよりも薄くて読みやすいとか、新しい分だけ最近の
トピックを押さえているとかの良い部分もあるんですが、字句解析
や構文解析の説明をはしょり気味な内容です。

理論よりも自分で実装することに興味があるので、ドラゴンブック
は読んでてつらいのです…

100 :83:2001/02/18(日) 07:20
>>99
一行目の「ドラゴンブックとは、 」は「タイガーブックとは、 」の間違いです。

101 :デフォルトの名無しさん:2001/02/18(日) 07:47
>>99
実装より理論のが簡単なんだって。

102 :デフォルトの名無しさん:2001/02/18(日) 08:35
>>101
え?理論なんて全然知らなくても、yaccなどの助けで
実装できるよ。
一方、構文解析等の理論は本格的な学問で奥が
かなり深い。

103 :デフォルトの名無しさん:2001/02/18(日) 08:49
>>102
yacc/lexに頼らないってのがそもそもの前提じゃん。
>>83
を参照。

104 :83:2001/02/18(日) 10:19
>>103
えと、yacc/lexを使いたくないというんではなく、ブラックボックスなのが
気持ち悪いので、いちおう基本理論の理解だけしておきたいという程度
です。「ドラゴンブック読め!」と言われるのはわかっているんですが、
難解で…

105 :83:2001/02/18(日) 10:22
age忘れ。

106 :103:2001/02/18(日) 10:22
だからね、まとめると、
ドラゴンブック = 理論+実装
>>93 = 理論
なので、>>93 読め。

107 :コンパイラ屋(休日出勤):2001/02/18(日) 11:53
最近はTiger Book以外にもいい本が沢山でているよ.以下は
どれも実際の処理系を作るのに役立つ内容です.

Reinhard Wilhelm, et al., Compiler Design,
Addison-Wesley, 1995, ISBN 0-201-42290-5.

Steven Muchnick, Advanced Compiler Design and Implementation,
Morgan Kaufmann, 1997, ISBN 1-55860-320-4.

Robert Morgan, Building an Optimizing Compiler,
Digital Press, 1998, ISBN 1-55558-179-X.

中田育男, コンパイラの構成と最適化,
朝倉書店, 1999, ISBN 4-254-12139-3,9500円.

Dick Grune, et al., Modern Compiler Design,
Wiley, 2000, ISBN 0-471-97697-0.

Michael L. Scott, Programming Language Pragmatics,
Morgan Kaufmann, 2000, ISBN 1-55860-442-1.

108 :83:2001/02/18(日) 12:59
>>107
ありがとうございます。
コンパイラ初心者におすすめというか、あまりアカデミックでない実践
指向な本はこの中にあるでしょうか?

英語でもかまわないのですが、コードの例が多い方が嬉しいです。
竜本も虎本もコンパイラの完結したコード例がついてないのが、
ちょっと好きになれません。

ところで理系の本の著者名でよく見るet al.って、どういう意味なんで
しょうか?ネタに訊いているわけではなくて、本当に知りません。

109 :デフォルトの名無しさん:2001/02/18(日) 13:27
>108
et al.「〜と愉快な仲間達」

110 :ミトコンドリ子:2001/02/18(日) 13:43
>>107
情報ありがとう。

>>83=108
コードの例が載ってなくても、アルゴリズムが理解できて、
実装できるようになんなきゃダメよ。それにドラゴンブックだって、
ちゃんと擬似コードで説明してるじゃない。
コンパイラじゃなくても、わりとアカデミックよりな文献だと
環境が特定されているサンプルコード(打ち込んだらすぐ動く)なんて
ついていること少ないわよ。擬似コードすらないこともザラよ。
(分野によるのかしら?)

逆に、理論からコードに起こすことが、必要ない、やりたくない、
できない、人のためにlex/yaccみたいな処理系が普及してるわけでしょ?
がんばりなさい。

et al.って、「ほか何人か」って意味じゃなかったかしら。
辞書に載ってるわよ。

111 :83:2001/02/18(日) 14:40
>>106
>>93読んでみます。
ただ、海外在住なもので入手がちょっと大変です。

112 :コンパイラ屋(休日出勤):2001/02/18(日) 15:14
107です.以下の本は動くコード例付です.

David L. Clarke, et al, Systems Software Programming: The Way Things Work,
Prentice Hall, 1997, ISBN: 0-13-490558-X.
(邦訳 システムソフトウェアプログラミング―コンパイラの設計法と並行処理の基礎,
小松伸行訳,プレンティスホール出版,1998, ISBN 4-89471060-9, 4800円)

疋田輝雄・石畑清,コンパイラの理論と実現 (計算機科学・ソフトウェア技術講座7),
共立出版, 1998, ISBN 4-32002382-X, 2700円.

原田賢一,コンパイラ構成法,
共立出版,1999, ISBN 4-3200292-2, 6500円.

113 :コンパイラ屋(休日出勤):2001/02/18(日) 15:38
実際に動く処理系をインプリメントするには,コンパイラ本だけで
なくこんな本も結構役に立ちます.もっともインタプリタを作るに
はここまでいろいろ知らなくても十分なんとかなりますが.

Richard Jones, Rafael D Lins,
Garbage Collection : Algorithms for Automatic Dynamic Memory Management,
Wiley, 1996, ISBN 0-471-94148-4.

Jonathan B. Rosenberg,
How Debuggers Work : Algorithms, Data Structures, and Architecture,
Wiley, 1996, ISBN 0471149667.
邦訳: デバッガの理論と実装,吉川邦夫訳,
アスキー, 1998, ISBN: 4-7561-1745-7, 3500円.

John R. Levine,
Linkers and Loaders,
Morgan Kaufmann, 1999, ISBN 1-55860-496-0.

114 :コンパイラ屋(休日出勤):2001/02/18(日) 15:40
そうそう,スクリプト言語ならこんな本もいいかもしれません.

Randy M. Kaplan,
Constructing Language Processors for Little Languages,
Wiley, 1994, ISBN 0-471-59754-6.

115 :コンパイラ厨房(83):2001/02/18(日) 15:44
>>コンパイラ屋(休日出勤)さん
趣味でやる練習としては、既にある言語のサブセットを作ってみるのが
一番いいんでしょうか?

たとえば、どうせ実用にはしないからということで最適化は後回しにして、
SchemeやCのサブセットとか。

116 :コンパイラ屋(にせもの):2001/02/18(日) 16:11
大事な本をわすれてはおらぬか?

麻宮騎亜,
コンパイラ1,
講談社,1999,ISBN 4062606100.

麻宮騎亜,
コンパイラ2,
講談社,1999,ISBN 4062606119.



117 :デフォルトの名無しさん:2001/02/18(日) 16:22
Delphi屋になってから、Lex/Yaccから遠ざかってたけど
http://www.musikwissenschaft.uni-mainz.de/~ag/tply/tply.html
ここらあたりから勉強し直してみよーかなーと言ってみるテスト
やっぱPL/0からかな

118 :デフォルトの名無しさん:2001/02/18(日) 17:00
> 原田賢一,コンパイラ構成法,
> 共立出版,1999, ISBN 4-3200292-2, 6500円.

これはコードがネットに落ちてるから拾ってくるといーよ。
本の値段はちと高いな...

ttp://www.hara.ics.keio.ac.jp/kCompiler/index.html


119 :コンパイラ厨房:2001/02/18(日) 18:29
インターフェース増刊でコンパイラ実装の特集号があった記憶がある
んですが、あれはどうでしょうか?

120 :デフォルトの名無しさん:2001/02/19(月) 19:45
age

121 :ななしさん:2001/02/19(月) 20:17
Grail+プロジェクトで技術的援助を求めてるみたい。
2ちゃんで支援要請しなさい、それはあるから。
と書いてみる。



122 :Yet another コンパイラ屋:2001/02/19(月) 20:23
Grail+プロジェクトって何ですか?

123 :デフォルトの名無しさん:2001/02/19(月) 23:16
本ばっか読んでてもしょうがない。
実践しろ。>コンパイラ厨房
スキルは後から付いてくるから。

124 :デフォルトの名無しさん:2001/02/20(火) 00:56
本読むのはスキルのためではないと思うが。

125 :デフォルトの名無しさん:2001/02/20(火) 01:03
コンパイラ厨房へ:
とりあえずそこらへんの小さなインタプリタのソースを読め
自分でも何か作れ
本もきっちり読め
以上.下がってよし.

126 :デフォルトの名無しさん:2001/02/20(火) 01:55
スクリプトエンジンってやっぱり最適化なんてサ行はしてないですよね?
ソース書く人が自分で最適化するんですよね?


127 :言い訳パターン1:2001/02/20(火) 02:21
>>126
そこまで速度が要求される場面には使わないでください。
もしくはC言語で拡張してください。
とか。。。

128 :デフォルトの名無しさん:2001/02/20(火) 02:31
言い訳というよりは、それをやったら「スクリプト」でなくなるという
感じではないかね。

129 :126:2001/02/20(火) 05:22
>>127
CGIとして使う場面でも速度を求められる場合があると思いますが…
どちらにせよ遅いより速い方がいいですし、
それに最適化って速さだけじゃないでしょ?
CGIって最適化してコンパイルされたものをどっかに保存してそれを実行みたいなふうにはできないのでしょうか?
CGIファイルが更新されたらまた再コンパイルして。


130 :デフォルトの名無しさん:2001/02/20(火) 07:41
>>129
CGI自体のオーバーヘッドがそれなりにあるので、Java Servletを使う
方が得策です。

131 :デフォルトの名無しさん:2001/02/20(火) 08:00
130につっこみいれてぇ…

132 :デフォルトの名無しさん:2001/02/20(火) 09:35
挿れちゃってくださいな。>131
そして逝かせちゃってください。

133 :デフォルトの名無しさん:2001/02/20(火) 10:09
さすがにネタだと思われ。

134 :デフォルトの名無しさん:2001/02/20(火) 14:25
>>129 mod_perlは最適化はどうかは知らないが
メモリ上にperlスクリプトをコンパイルした状態で保持します。

135 :デフォルトの名無しさん:2001/02/22(木) 02:57
アセンブラからCソースを吐くようなコンパイラ(逆コンパイラ?)ありませんか?
結構おもしろいとおもうんだけど、やっぱ難しいのかな?

136 :デフォルトの名無しさん:2001/02/22(木) 03:08
でこんぱいら

137 :デフォルトの名無しさん:2001/02/22(木) 19:29
でじこんぱいら

138 :コンパイラ厨房:2001/02/23(金) 18:39
>>123
>>125
じゃあ、とりあえずインタプリタを作るとして…
やっぱ、お約束通りSchemeからでしょうか?

139 :デフォルトの名無しさん:2001/02/24(土) 17:22
>>138
実装は大丈夫なのか?

これくらい楽勝だろうな
問題:Cソースからコメントを抜き出し表示する関数を100行以内でつくれ
補足:ANSI-Cにのっとった全てのパターンで動作すること
(注:コピペ)

140 :デフォルトの名無しさん:2001/02/24(土) 20:10
>>139
138->139の話の流れ方がよくがわからんのだが・・・
ANSI-Cにのっとった全てのパターンとは何?
コメントって/*...*/は良しとして、//は含めるの?
だったらネストとか行末の0x5cも頭にいれなきゃだめだねぇ...

141 :コンパイラ厨房:2001/02/25(日) 05:05
目的としては、あとで適当に使いまわして、自作ソフト用の組み込み
スクリプト言語として使えるような言語の骨組みを作るということで。

Scemeって実装は楽そうだけど、自分で使いたいかって考えると…
あんなカッコだらけのソースコード見たくないですよ、カテジナさん!

ついでに愛用エディタの秀丸だと、対応カッコのハイライト機能も
ないですよ、マーベットさん!

142 :デフォルトの名無しさん:2001/02/25(日) 07:40
>>141
秀丸に対応括弧のハイライト機能はあるよん

143 :コンパイラ厨房:2001/02/25(日) 08:34
>>142
ホントだ。
最近Visual Studioばっか使ってたから、鬱だ、氏のう。

144 :デフォルトの名無しさん:2001/02/25(日) 13:13
とりあえずschemeのインタプリタ書いて
あとでパーサだけ取り替えれば?

145 :デフォルトの名無しさん:2001/02/26(月) 00:34
そういやLips/Schemeって、数式は逆ポーランド表記で括弧が必要ない
のに、それ以外の部分で括弧だらけだよね。どういうポリシーだ?

146 :145:2001/02/26(月) 00:35
○ Lips
× Lisp

147 :デフォルトの名無しさん:2001/02/26(月) 00:38
>>145
?言いたいことがよくわからない。
LispもSchemeも1+2や10-5は
(+ 1 2)
(- 10 5)
こう書くよ。


148 :146:2001/02/26(月) 00:42
逆だ…鬱。

149 :145:2001/02/26(月) 00:46
>>147
加減乗除の演算子優先順位と括弧のハ・ナ・シ。
中置法だと括弧を使うでしょ。

150 :デフォルトの名無しさん:2001/02/26(月) 01:02
>>145=149
それ以外ってどこよ?
元々括弧だらけですが、何か?

151 :デフォルトの名無しさん:2001/02/26(月) 01:03
>>149
lispの括弧は優先順位と何の関係もないからなあ。
言ってることがわからない。
なぜ同列の問題として扱ってるのか。

152 :デフォルトの名無しさん:2001/02/26(月) 01:11
Lisp/Schemeの構文の
(+ 1 (- 2 1) 3 4 5)
こういうのを中置記法で書くと、
1 + (2 - 1) + 3 + 4 + 5
になるけど、これとごっちゃにしてるんだろうね145は。

153 :コンパイラ厨房:2001/02/26(月) 05:23
皆さんがちょこっと使ってみるかと思うようなスクリプト言語って、どんな
のでしょうか?

Perlみたいに色んなところで使い回せる汎用言語じゃなく、秀丸マクロ
みたいにソフト依存のad-hocな組み込み言語で、あまり覚えるのに労力
払いたくねぇ!って場合、

CやPascalっぽい言語(Algol系)
Lisp/Schemeっぽい言語
BASICっぽい言語
上記が適当に混ざった言語(構文に一貫性なし)

の中だと、個人的な好みではAlgol系なんですが…
ちなみに構文の話です。

154 :デフォルトの名無しさん:2001/02/26(月) 07:50
使ってるうちに覚えるとか
使ってるうちに慣れるとかってのはヤダな…
スクリプトって手軽なのが瓜なわけだから
使いたいって時にパッとはじめられる感じのがいい。
個人的にはPascalが好きだけど。


155 :デフォルトの名無しさん:2001/02/26(月) 16:35
PASCAL だったらこんなプロジェクトがあるそうですよ。

http://homepage1.nifty.com/ht_deko/ppa.html

> PPA(Poor-Pascal for Application)はDelphi/C++Builder用のPascalインタプリタコンポーネントです。

> 1) Project-PPA(PPA-ML)に参加し、積極的にPPA開発に寄与すると約束する。
> 2) 1)が不可能な場合、Project-PPAに決められた金額(\10,000)を送金する。

ただ利用条件ちょっと厳しいんで、私のような低級プログラマでは
使いたくても使えませんけど(泣


156 :デフォルトの名無しさん:2001/02/26(月) 18:03
PPAかー。俺も見つけて、利用条件で引いたよ。

157 :デフォルトの名無しさん:2001/02/26(月) 21:58
初歩的な話ですみません。
flex bison 使い始めたばかりなのですが、
正規表現考えるのめんどくさぁ、
浮動小数点の表現みたいな、複雑怪奇なのとか
文字列みたいに複数行にまたがるとかそういったパターンは
いやになりそう。

どこか正規表現集ってないかなぁ?


158 :デフォルトの名無しさん:2001/02/26(月) 23:30
http://cmaga.zdnet.co.jp/bookreview/19990701.html

159 :デフォルトの名無しさん:2001/02/26(月) 23:41
abcdefg.y contains 1 shift/reduce conflict
うう

160 :デフォルトの名無しさん:2001/02/26(月) 23:44
作(使)ってるうちに嫌でも慣れるぞ>155
その中だとLISP/Schemeはちょこっとしたプログラムなら完成するのが比較的早いと思う。

161 :デフォルトの名無しさん:2001/02/26(月) 23:48
私も、アプリケーションのカスタマイズ用の言語が欲しくて
探したりしたりしてるのですが
PPAに毛が生えかけたぐらいのが言語仕様的にも
手のひらにすっぽり収まる感じでちょうどいいと思うんですよ
それか、UWSCのスクリプトかなぁ
www07.u-page.so-net.ne.jp/ca2/umiumi

162 :デフォルトの名無しさん:2001/02/27(火) 09:42
私は配布条件がゆるいので Python を使ってますけど、
付属スクリプトを梱包する必要があるのと、
実行速度が遅めなのがちょっと。


163 :デフォルトの名無しさん:2001/02/27(火) 09:49
>>162
附属スクリプト?
なんで?そんなことライセンスに一言も書いてないよ。

164 :age!:2001/02/28(水) 11:36
>>155
なんだか凄い利用条件だ。
いろんな世界があるもんですね。


165 :デフォルトの名無しさん:2001/02/28(水) 12:21
>>163

付属スクリプトで実装されている機能を使っているんだろう。

166 :デフォルトの名無しさん:2001/02/28(水) 13:09
>163 165
C で言うところの標準ライブラリ的な機能が
付属のスクリプトで実装されているんで。


167 :デフォルトの名無しさん:2001/03/13(火) 15:21
メモリー管理で、もっと賢い方法あったら教えてください。
文字列演算なんかで、たとえば
%union {
  char * str ;
}
%token STRING  <- flex の方は \"[^\"]*\" とかといった感じ
%type <s>  str
exp:
   str ';'
  |
  ;

str:
   STRING '+' STRING  { $$ = str2( $1 , $2 ) ; }
  | STRING        { $$ = str1() ; }
  ;

%%



168 :デフォルトの名無しさん:2001/03/13(火) 15:21
続き
C言語側
char * str2( char * l , char * r )
{
  char * ret = new char [ strlen( l ) + strlen( r ) + 1 ] ;
  strcpy( ret , l ) ;
  strcat( ret , r ) ;
  delete [] l ;     // もう使用しないので削除
  delete [] r ;     // もう使用しないので削除
  return ret ;
}

char * str1()
{
  char * ret = new char [ yyleng + 1 ] ;
  strcpy( yytext , yytext ) ;
  return ret ;
}



169 :デフォルトの名無しさん:2001/03/13(火) 15:21
続き
とまあ、現在このようにしているわけですが、
見るからに、見てのとおりで、
メモリーの解放忘れの嵐を食らうはめになります。
皆さんはどのようにされてますか?



170 :デフォルトの名無しさん:2001/03/13(火) 17:44
>>169
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
これ使うとか。

171 :デフォルトの名無しさん:2001/03/14(水) 12:55
169 です。
>>170
すばやいレスどうもありがとう誤差います。
実は英語があんまり得意ではないのですが、内容はガベージコレクション
関連の内容なのでしょうか。
僕の例の場合、メモリを開放する必要のある瞬間は、より上位の文法の
ツリーが解決した瞬間なんですね、ですから何とかガベージコレクション
のような大規模なものを用いなくてもなんとか、いい方法が存在しそうな
気がします。

という訳で・・・
だれかそういった場合の良い方法、こんなのあるよとかないでしょうか?


172 :デフォルトの名無しさん:2001/03/14(水) 12:57
std::stringつかえよ。

173 :デフォルトの名無しさん:2001/03/14(水) 13:03
>>172
いきなりトンチンカンな事書くな、解決ぜんぜんせんやんけボケ


174 :デフォルトの名無しさん:2001/03/14(水) 14:22
C++おぼえたてを自慢したい年頃なんでしょ(^^;
ちなみに私はコンテナに登録する方式ですが、美しくない・・・ぅぅ


175 :デフォルトの名無しさん:2001/03/14(水) 14:33
union にデストラクタと代入演算子がつけられたらと思う今日この頃。


176 :170:2001/03/14(水) 15:55
>>171
じゃこういうのはどう?
http://www.fsinet.or.jp/~nito/CocoaClub/article03.html


177 :デフォルトの名無しさん:2001/03/14(水) 17:04
おぶじぇくてぃぶぅシーだああぁぁああ。たすけてー。

178 :174:2001/03/14(水) 17:44
>>171
おれと同じじゃん。
しかし、なぜに Objective C な訳?

179 :174:2001/03/14(水) 17:46
間違えた
>>171>>176


180 :170:2001/03/14(水) 19:02
>>177
Objective-Cってやってみればわかるけど
(C++と比較にならないほど)素直でいい言語だぞ。

この辺から読んでみるとか。
http://www.fsinet.or.jp/~nito/OSPT/Objective-C.html

コンパイラはGNUの実装もあるけど
Stepstone系のObjective-Cコンパイラ(トランスレーターだけど)
http://users.pandora.be/stes/compiler.html
が個人的には好き。

181 :かい:2001/03/15(木) 01:50
アプリのマクロ言語としてRubyを使うって手はないの?
実装が大変?


182 :デフォルトの名無しさん:2001/03/15(木) 02:44
つーか、でかすぎ>181

183 :デフォルトの名無しさん:2001/03/15(木) 08:28
>175
Unionのメンバを含むクラスじゃダメなの?

184 :デフォルトの名無しさん:2001/03/15(木) 13:05
169 です。

>>174
コンテナクラス作って全部ほうりこむという方法ですか、
確かに手間は少しは省けそうですが、決定的な解決策には
なりにくそうですね。
昨日スタックのクラスを作って中身の取り出し用メンバ
を工夫してやってみました、これでかなりいけるような感じ
ですが、やっぱり決定打にはなってないです。

プロのコンパイラ屋さんのコード見てみたい今日この頃。

>>176 181
見てるこちらは、ちょっと困ったかも(笑)



185 :169:2001/03/15(木) 13:17
>>175
コントラクタとデストラクタがあればフック関数つくれるということでしょうか。
たしかにあったら使えるかも知れませんね。



186 :デフォルトの名無しさん:2001/03/17(土) 11:32
>>184
ガベージコレクションでもいろいろ種類があるそうですから、
その中で一番実装が簡易なものを使うのが良さそうな気がします。
(トリッキーな方法を使うぐらいなら、ですが。)


187 :デフォルトの名無しさん:2001/03/20(火) 00:22
コンパイラを作ってみたいのですが、
大学の授業とかで使われるような解りやすいソースで、
Cのコンパイラのソースってどこかにありませんか?

188 :デフォルトの名無しさん:2001/03/20(火) 00:34
>>187
URL忘れたけど、電通大(http://www.uec.ac.jp/)の情報工学科 渡辺研究室にTinyCってのがあるよー。

uecの学生より

189 :デフォルトの名無しさん:2001/03/20(火) 01:51
>>188
ここですね。
http://watalab.cs.uec.ac.jp/tinyCabs.html
ゆっくり勉強したいと思います。どうもありがとう。

あと、bisonとflex関連も見つけたんでリンクしときます。
http://www.omoikane.co.jp/i/info/html/bison-1.28/bison-ja_toc.html
http://www.omoikane.co.jp/i/info/html/flex-2.5.4/flex-ja_toc.html



190 :デフォルトの名無しさん:2001/03/20(火) 12:27
>>187

こんなのもあるよ。

Micro-C
http://rananim.ie.u-ryukyu.ac.jp/~kono/lecture/2000/compiler/index.html

191 :デフォルトの名無しさん:2001/03/20(火) 13:53
Cマガの99/10に昔のコンパイラに関する記事がCDに収録されています。
印刷しても字が読み取りにくかったから、
ディスプレイで読んでるけど、つかれるなぁ。
まだ読み始めですが、既に読み終えた方、どうでしたか?

192 :名無しさん@こんせぷつ:2001/03/21(水) 15:20
>>188
この書籍のサンプルコードですね。

情報科学こんせぷつ8
コンパイラの仕組み
電通大 渡邊 坦著
SBN4-254-12708-1
A5判 196頁 定価(3,500円+税)

「問題解決に必要な技術を具体的に解説した実践書。(朝倉書店のページより)」
〔内容〕概要/字句解析/演算子順位/再帰的下向き構文解析/
記号表と中間語/誤り処理/実行環境とレジスタ割付/コード生成
/Tiny C/他

UNIXUSERの書評見て買ったら、いい本だった。巻末のコードは読みにくい
ので、>>188のサイトからゲットすべし。

193 :デフォルトの名無しさん:2001/03/21(水) 16:01
>>192
初耳なんだけど、どこの出版社から何時出た本なの?

194 :デフォルトの名無しさん:2001/03/21(水) 16:58
情報科学こんせぷつ〈8〉
コンパイラの仕組み
ISBN:4254127081
185p 21cm(A5)
朝倉書店 (1998-04-01出版)
・野崎 昭弘・黒川 利明・疋田 輝雄・竹内 郁雄・岩野 和生【編】・渡辺 坦【著】
NDC分類:007.64 販売価:\3,500(税別)

195 :デフォルトの名無しさん:2001/03/21(水) 20:04
tinyCはmips用のコードを吐き出すようですが、
これをpentium用に変えるにはどうしたらいいのでしょう?
だれか講義してみない?

196 :デフォルトの名無しさん:2001/03/21(水) 20:25
>>192
この本はなかなかわかりやすかったよ。
コンパイラの本を2冊読んだけど、断然そっちがわかりやすかった。
でも、あんまり深いことは書いてないんだよなぁ。

197 :デフォルトの名無しさん:2001/03/21(水) 20:27
>>195
i386用のならあるっぽい
http://rananim.ie.u-ryukyu.ac.jp/~kono/lecture/2000/compiler/index.html

198 :デフォルトの名無しさん:2001/03/21(水) 20:41
>>197
TinyCとMicroCって全然別物なんじゃ…

199 :デフォルトの名無しさん:2001/03/21(水) 23:11
>>191
スキャン画像を無理やりpdfにしてるから
スクロールが重くてしかたない
なめてんのか、と思った
内容も浅いんで専門書読んだほうがいいでしょう

200 :デフォルトの名無しさん:2001/03/22(木) 01:24
Zendはどう?

と、流れをぶちきってみます

201 :デフォルトの名無しさん:2001/03/22(木) 02:16
C--

202 :デフォルトの名無しさん:2001/03/22(木) 23:27
今日、194の本立ち読みしてきた。
で、FirstとかFollowとかよくわからなかった。
それを使って表を作ってそれをもとにプログラム書くみたいだけど(LL(1))、
とりあえず意味はよくわからんかったけど、方法はわかったような…。

だれか、FirstとFollowの説明だれかお願いします。
金がないので買えませんでした。

203 :デフォルトの名無しさん:2001/03/23(金) 00:51
>>202
YaccとLex使ってください。

204 :デフォルトの名無しさん:2001/03/23(金) 02:34
Firstが、その非終端記号の一番初めに来る可能性のある終端記号の一覧。
Followが、その非終端記号の直後に来る可能性のある終端記号の一覧。

205 :デフォルトの名無しさん:2001/03/23(金) 23:11
yaccの解説本だと、電卓とかCライクな言語が解説されている本が多いけど、
N88-BASICみたいな昔ながらのステートメントを並べるタイプの言語を
yaccで解説している書籍orURLご存知ありませんか?


206 :デフォルトの名無しさん:2001/03/24(土) 11:57
>>205
Cライクな言語でも、N88-BASICでも、必要な考え方は
同じだと思うけど。

207 :デフォルトの名無しさん:2001/03/24(土) 16:23
>>206
Cライクだと、関数の引数とか省略できないのですが、N88-BASICだと途中の引数を
省略できたりします。その辺が一番の悩みどころなんです…。頭悪くてすみません。

208 :デフォルトの名無しさん:2001/03/24(土) 16:39
>>207
そうですねぇ、こんな感じでどうでしょ。
Statement:
Statement arg_list {}
;

arg_list:
arg_list arg
;
arg:
ほげほげ {}
| {}
;

うまくでるかな、ちなみに私の黄金パターンです。
ちなみに書籍は見たこと無い(^^;



209 :デフォルトの名無しさん:2001/03/24(土) 16:40
ぎゃぁ!!やっぱりつぶれた!
適当にスペースあると思ってみてね。


210 :デフォルトの名無しさん:2001/03/24(土) 16:42
yacc&lexで
FORI=0TO10STEP100のFORI=0をFOR I = 0と解釈して
FORI=0をFORI = 0と解釈できるの?

211 :デフォルトの名無しさん:2001/03/24(土) 16:45
もういっぺん、なんか間違ってるし・・・
Stat:
  Stat arg_list {}
  ;

arg_list:
  arg_list ',' arg { 引数取り込み処理}
  | arg_list ',' ',' { 引数スキップ処理 }
  | arg_list
  ;

さっきのより、こっちの方が簡単?


212 :デフォルトの名無しさん:2001/03/24(土) 16:50
>>210
すみません、意味良くわかんないです。
詳しく説明してもらえれば答えられるかも?


213 :デフォルトの名無しさん:2001/03/24(土) 17:01
>>210
なんとな〜く意味判ってきた、
要するに、先に FOR がくっつくのかという問題ですね。
それは lex に仕事させればいいです。
正規表現に後ろが hoge の時マッチするというやつあります(たしかあんまり使わないから忘れた)
それで {変数}={式}TOが登場するときに決定すればいいです。



214 :デフォルトの名無しさん:2001/03/24(土) 17:12
まだ間違ってる(^^;
arg_list:
  arg_list ',' arg { 引数取り込み処理}
  | arg_list ',' ',' { 引数スキップ処理 }
  | arg <- ここね
  ;



215 :デフォルトの名無しさん:2001/03/25(日) 05:04
>>214
何度もありがとうです。アホなんで直ぐには理解できませんが、
レスを参考にして頑張ってみます!

216 :デフォルトの名無しさん:2001/03/25(日) 15:38
yacc lex は、頭つかうより体つかってやってみてね。
どっかのクソ教授の書いた本なんか使えるようになってからでなきゃ理解できんものばっかりです。
まあ、コンピュータ関連のツールは総じて頭より体なんですが・・・


217 :いつでもどこでも名無しさん:2001/03/28(水) 10:32
体育会系アホプログラマ発見

218 :216:2001/03/28(水) 14:00
すまんねぇアホで。
でも実際頭で憶えられんもんって一体いくつあるんでしょ。
頭使えると云うのでしたら理屈書いてみたら?
論破してやろうか?


219 :デフォルトの名無しさん:2001/03/28(水) 21:23
yaccあげ
ついでに >>216 激しく同意

220 :デフォルトの名無しさん:2001/03/28(水) 21:30
つーか、むしろ理屈わかっても使えなかったりするからな。

221 :デフォルトの名無しさん:2001/03/30(金) 20:44
lexでレキシカルアナライザ生成すると遅いという話を聞きますが、
パーサはyaccで作るのと、LRとかで手書きするのとで速度にそれほど差が出る
ものなのでしょうか。
手書きコードは極端に酷くなく、作るのはコンパイラでなくインタプリタを想定。
保守性は無視で…。

222 :デフォルトの名無しさん:2001/03/30(金) 21:16
LRって手書きするものなの?
LLとかならわかるけれど。

223 :>221:2001/03/31(土) 01:49
lexと手書きでは確かに速度に差がでまくるね。
まあトークン切り出しは比較的簡単だから手作業でも良い。メンテも可能。
yaccと手書きについては、複雑な文法をメンテする手間を考えたら
yaccの方がよい。
再帰下降とかLL(1)のみで完結する文法なら手作業でもいいけど。
速度は手作業が有利なのには変わりなし。

224 :デフォルトの名無しさん:2001/03/31(土) 07:47
Cライクなスクリプトエンジン考えてたんだけど、はたと気がつけば普通のC言語のプログラムと何ら代わらないと言うことに気がついた(鬱だ‥‥‥

ということで、スクリプトエンジンの利点って?


225 :デフォルトの名無しさん:2001/03/31(土) 07:56
>>224
コンパイルしなくて済む。

226 :>224:2001/03/31(土) 08:34
自分のソフトに組み込める

227 :>224:2001/03/31(土) 08:37
他人に技術力を誇示できる

228 :デフォルトの名無しさん:2001/03/31(土) 10:10
ソフトを拡張してくれる人が出てくる

229 :デフォルトの名無しさん:2001/03/31(土) 11:58
>>224
WZ editorのマクロがCライクだったような気が。

230 :デフォルトの名無しさん:2001/03/31(土) 13:55
>>224
実行速度が遅い言い訳になる。
「いや、何せスクリプトで動作しているものですので・・・」

231 :デフォルトの名無しさん:2001/03/31(土) 16:03
>>224
多くても安心。

232 :デフォルトの名無しさん:2001/03/31(土) 16:24
>>224
パクりパクられの関係なのに平和

233 :デフォルトの名無しさん:2001/03/31(土) 17:12
>>224
突然のお客様にも安心

234 :デフォルトの名無しさん:2001/03/31(土) 17:25
>>223
よほど特異でなければ、flex 程度でいいと思うよ。
文脈依存型の文法で語彙の意味がコロコロ変わるのは手書きにすると
てき面に効くような気がする。
あと、流し込み型ではなくて、う〜ん例えばタブの位置で文法が
決まるようなミョウチクリンな言語を作る場合とか、
例の上の方で発言されていた fori=0to の問題見たいなのとかは、変わると思うよ。
ちなみにタコが strcmp とか使って作った奴使うくらいなら間違いなく flex の方が
いや・・・lex でもその方が速い。
はっきりいって素人じゃ flex には勝てんです。
素直に flex で書いて、チューニングした方がいい。



235 :デフォルトの名無しさん:2001/03/31(土) 17:27
レス先間違い >>223 -> >>221

236 :デフォルトの名無しさん:2001/03/31(土) 17:41
>>224
萌えられる。

237 :デフォルトの名無しさん:2001/03/31(土) 19:11
bison/flexが出力するソースはなんであんなに汚いんだ。
C++/Java用のパーサクラスを出力するようなツールってないんかな。


238 :デフォルトの名無しさん:2001/03/31(土) 19:26
>237
検索せよ。
JavaCC
http://www.metameta.com/
とか。

239 :名無しさん:2001/03/31(土) 19:31
逆にどうすれば美しいスケルトンになると思う?
漏れもジェネレーターやるから意見聞きたい。
lexでC++をサポートするのは文字コードの実装の
抽象化って意味で効果的だけど。


240 :厨房:2001/03/31(土) 20:28
その前に、きれい、汚いってどういうこと?

241 :>240:2001/04/01(日) 00:46
んこまみれかどうか

242 :>240:2001/04/01(日) 00:50
例:C++はんこまみれ

243 :デフォルトの名無しさん:2001/04/01(日) 01:57
C++は んこ まみれ ?
C++ はんこ まみれ ?

244 :名無しさん:2001/04/01(日) 03:08
「んこ」って何よ。
うんこ?まんこ?ちんこ?どれ?

245 :USO800委員会:2001/04/01(日) 03:30
そんなの「げんご」に決まってるだろ。
嘘です。今日は4月1日です。

246 :>244:2001/04/01(日) 03:56
んこ:うんこまんこちんこの抽象クラス


247 :デフォルトの名無しさん:2001/04/03(火) 13:40
んこあげ

248 :デフォルトの名無しさん:2001/04/03(火) 15:31
他の派生クラス例
あんこ、インコ、援交〜、温厚〜、金庫〜、健康〜、参考〜、センコ〜
炭坑〜、天候〜、敦煌〜、軟膏〜、判子、メンコ、四個、ワンコ

249 :デフォルトの名無しさん:2001/04/03(火) 16:45
んこ
{
public:
&nbsp;&nbsp;static におい
}

んこ::におい = くさい;

250 :デフォルトの名無しさん:2001/04/04(水) 04:14
んこ &大便(食い物) {
 if(食い物.量 > 腹八分) {
  if (rand()&1)
   throw 便秘;
  return げり;
 }
 return うんこ;
}

251 :デフォルトの名無しさん:2001/04/04(水) 23:07
>>234
だいぶ前の話なんですが…どうしても気になったもので
strcmpよりも高速な文字列比較の方法ってどのような物なのでしょうか?
自前でstrcmp相当の関数をinlineするとか、その程度しか思いつかないのですが

252 :デフォルトの名無しさん:2001/04/04(水) 23:09
>>251
strcmpが遅いんじゃなくて、strcmpを正面から使うような
単純なアルゴリズムが遅いってことじゃない?

253 :デフォルトの名無しさん:2001/04/05(木) 03:17
>>251
strcmpでバカ正直に比較していたら、
最悪用意されているシンボルの回数だけ比較することになるだろ?
だったら素直に決定性有限オートマン使っとけって事

254 :>251:2001/04/05(木) 05:01
hashがお手軽。
最適なのはトライ木かな。(文字単位で区切られた木を作る)

255 :254>251:2001/04/05(木) 05:07
あとスライド辞書圧縮(LZ系)とかのソース見るのもいいかと。

256 :デフォルトの名無しさん:2001/04/05(木) 11:22
>>253
オートマトンの間違いだろ。
しかも251は構文解析ではなく字句解析の話をしているのでないのか?


257 :>256:2001/04/05(木) 12:45
lex を使えば字句解析もオートマトンになるにょ

258 :251:2001/04/05(木) 16:11
なるほど
そういう意味の文章だったんですね
文意を誤解していました
さすがに厨房な私でもstrcmpで逐次比較するような事はしないでハッシュ使ってます

259 :デフォルトの名無しさん:2001/04/05(木) 16:20
>>256
http://hp.vector.co.jp/authors/VA007799/viviProg/doc_regexp.htm

260 :デフォルトの名無しさん:2001/04/05(木) 16:21
ハッシュはお手軽だけど、すべての数値文字列とかといった
抽象的な対象に使えないので、字句解析にはちょいと向かないと思う。
やっぱオートマトンじゃないかな。


261 :252:2001/04/05(木) 16:25
ずっとオートマンだと思ってたよ、、、
人前で発言しなくてよかったぞ。
アリガト>256

262 :256:2001/04/05(木) 19:05
正規表現で字句解析か。
正規表現で字句解析するよりstrcmp使ったほうが速くないかな?
正規表現ってコンパイルしてバックトラックしながら文字列のマッチングしてたら結構遅くなるように思う。
NFAからDFA作って最短一致のみの正規表現にすれば高速になるのかな。

まぁでもコンパイルの時間がかかるのはあまり気にしないでいいか。
要は生成したブツが速く動けばいいわけだし。

263 :デフォルトの名無しさん:2001/04/05(木) 19:49
正規表現は自分で実装した事ないんで実際にどの程度複雑なのか判りませんが
字句解析では、シンボルテーブルとハッシュ組み合わせています
でも、最近のコンピュータは速いですから、よっぽど長大なソースでも扱わない
限りどちらでも大差ないような気もします・・・

264 :monner:2001/04/05(木) 20:34
ええーっとですね、演算子ORを含む正規表現って
全部のパターンを同時に比較する
というか、仮想機械が動いている可能性がゼロになるまで
入力を行っているだけなんでめっちゃ速いです。
ただしNFAの場合は実行中に仮想機械のタスクが
増化するような状況になる(2チャンオリジナル
正規表現ライブラリ参照)ので、実際の速度は低下します。
DFAの場合は実行する前にテーブルがパンクしなければ
最高のパフォーマンスで走ります。
(圧縮方式によっては速度の低下はあるが)

蛇足:DFAでデータベース組めればとんでもない速度
が出ますが、メモリーも天文学的容量になる



265 :デフォルトの名無しさん:2001/04/05(木) 21:28
>>264
厨房ですみません。「2チャンオリジナル正規表現ライブラリ」ってなんでしょう?

266 :名無しさん:2001/04/05(木) 21:39
http://www.fuel.co.jp/~bull/monner/doc/


267 :>>264:2001/04/05(木) 22:14
http://piza.2ch.net/test/read.cgi?bbs=tech&key=978997438&ls=50
叩かれまくってるじゃん


268 :デフォルトの名無しさん:2001/04/06(金) 02:23
最近Cの標準ライブラリに正規表現使えるようにするライブラリが
追加されたと聞いたんですけど、本当ですか?
本当なら、どういう使い方をするんですか?

269 :名無しさん:2001/04/06(金) 10:54
regcmpとかはかなり前からPOSIXの標準だろ。
man -k regcmp
ただ、漢字対応しっかりやってるシステムは
意外と少ない。


270 :デフォルトの名無しさん:2001/04/06(金) 13:19
>264
超高速字句解析の話

最近字句解析の高速化をしていて思ったことですが、テーブル圧縮はむしろ有効に働くことが時にあります。
理由はおそらく、キャッシュとメインメモリの間のスピードのギャップでしょう。
なにしろ最近はアクセスタイムのギャップが10倍を超えようとしてます(もう超えてるのかな?)、こうなってくるとせっかくの工夫がこの問題で一発で台無しになってしまいます。
ゲーム屋あたりではバスボトルネックっていってヒイヒイいってます。
それで自作物字句解析は、より小さいテーブルを作るアルゴリズムを中心に私は考えています。

まあ、そんなことしてまで高速化してるのは精精、とあるCGツールのプラグインが掃き出すクサレギガバイト級テキストファイル(んなもんつくるなぁぁぁ)のパースくらいなもんでが。

>262
ちょいと横槍 lex だというなら正規表現のコンパイル時間は関係ないよ。
あとは monner 氏(女史?)の書かれてるとおり。


271 :デフォルトの名無しさん:2001/04/12(木) 16:18
スクリプト言語 Rythp (ソースあり)
>LISPを良く理解せずに形だけ似たようなのに仕立て上げようと
>ヘボプログラマが適当に作るとこんなのができあがります、って感じの言語です。
http://hp.vector.co.jp/authors/VA017441/lib/

ソースが付属しているので、参考までに。

272 :デフォルトの名無しさん:2001/04/12(木) 18:07
へ...へぼすぎる >>271
だれか構文解析という言葉を教えてやれ

273 :デフォルトの名無しさん:2001/04/13(金) 01:33
>>271
落せない。なんでtext/htmlなんだ。
つーか、なんだPLATHOMEって。

274 :デフォルトの名無しさん:2001/04/13(金) 11:29
>>271,272
人が一生懸命つくってるのをそういうふうにするのは嫌いだな。


275 :デフォルトの名無しさん:2001/04/13(金) 12:24
>>274

作者か?(藁

276 :271:2001/04/13(金) 13:54
>>274
私は紹介しただけなんですけど・・・
Webで公開されているものを紹介しちゃダメなの???


277 :デフォルトの名無しさん:2001/04/13(金) 13:55
>>276
そうだ

278 :デフォルトの名無しさん:2001/04/13(金) 14:14
ていうか、2chで紹介するってのは、ある意味そのサイトに対する
攻撃だよな?

279 :271:2001/04/13(金) 14:32
そーですか・・・じゃあ削除願を出してきますよ。
すいませんでした。


280 :デフォルトの名無しさん:2001/04/13(金) 15:36
>>278
それはそうだが、
>>279
何も削除依頼せんでも。

281 :デフォルトの名無しさん:2001/04/14(土) 03:24
攻撃になるかどうかはサイトの内容と、紹介された時の
2ch側の状況によるけどな。

282 :デフォルトの名無しさん:2001/04/14(土) 10:44
>>271
なるほど、こういう計算をやっているから皆が口をそろえて
「Lispは遅い、メモリを食う」って言うのか!(w

でもさらっと目を通したところ、とりあえず
動作に関しては致命的な問題はなさそうだったぞ
(だよね?)。
作者の苦労が偲ばれ、思わず目頭が熱くなったのは
俺だけだろうか・・・

283 :デフォルトの名無しさん:2001/04/14(土) 10:48
>>271-272を攻撃ととるか意見ととるかでその作者の資質がわかるな。

284 :>282:2001/04/14(土) 13:11
LISP系はガベコレ前提だからね・・
ところでLISP系でガベコレしない(必要ない)実装ってあるのかな?

285 :284:2001/04/14(土) 13:14
やべ、hageてた・・

286 :デフォルトの名無しさん:2001/04/14(土) 14:50
やーい、ハゲハゲ〜

287 :さくしゃ:2001/04/14(土) 15:17
>>272 自分でも同意。

>>273 わりぃ間違えてた。

>>275 ハズレ〜

>>279 いや別に消さんでも。

>>282 ホントにこんな計算やってるLISPがあったら笑えるネ。

>>283 んなこと言われると反応しづらいじゃねーかコラ。

288 :272:2001/04/14(土) 15:20
>>287
こんな恥ずかしいものを公開できる心理を教えてくれ

289 :271=279:2001/04/14(土) 16:35
>>280 >>287
私はFlameを起こすような真似はあまり好きではないですし、
折角のいいスレが打ち止めになるのも嫌なので。。。

290 :デフォルトの名無しさん:2001/04/15(日) 13:51
みなさんマターリ逝きましょう。


291 :デフォルトの名無しさん:2001/04/15(日) 17:13
Lisp系の実装は仕事ではたまにやりますが、
物作るときに不便でないですか>皆様?
いや、だめっちゅうんじゃなくて、LISPで
ゲーム作ってる人もいるし、便利だと思ってる
人がいるなら、ちょっと使える風につくろうかなぁと。


292 :252:2001/04/15(日) 17:58
javaとRubyの中間くらいの言語希望
いや、今書いてるんだが、ハジメテなのも手伝って
あまり思うように逝ってないんだよね。

293 :>291:2001/04/15(日) 18:25
LISPの良い点はリストが簡単に書ける所なんだけど、それ以外は結局
Cとかで組み込み関数作ってそれを呼出すだけになってしまう。
Schemeだと環境のコピー(保存)も発生するから、長々と定義書くのを躊躇したくなる。
それ以前にガベコレの問題があるからねえ・・
(大規模になると探索のコストが結構かかる)
リアルタイム処理に向いてるとは言えないかな

294 :デフォルトの名無しさん:2001/04/21(土) 20:27
http://free01.plala.or.jp/~yfuji/

このスクリプト言語はどうですか?
ウィンドウが扱える簡単なプログラムが作れそう
でも説明書がわけわからなくて作れない....

295 :デフォルトの名無しさん:2001/04/21(土) 21:19
>294
じゃ、やめとけよ

296 :294:2001/04/21(土) 22:07
言語的にイケてますか?
もし学ぶ価値のあるものなら頑張ろうと思うのですが....

297 :>296:2001/04/21(土) 23:32
知るか

298 :デフォルトの名無しさん:2001/04/22(日) 21:07
>>295, >>297

なんかいやなことでもあったのか?
それとも作者とか?

299 :デフォルトの名無しさん:2001/04/22(日) 21:41
何でもかんでも他人の影しか追えんような、開拓者精神に
欠ける野郎はプログラミングなんかやるんじゃねぇ、と
>>295,>>297 さんは仰ってます。


300 :300:2001/04/22(日) 23:27
切り番get!

301 :入門者:2001/04/25(水) 00:38
yacc系パーサ自動生成ツールで、ツールの使い方でなく、文法定義の方法というか
コツについて詳しく述べられている書籍をご存知の方居られませんか?

啓学出版の、Cコンパイラ設計 という本が良いと聞いていましたが、
絶版で入手できませんでした。よろしくお願いします。

302 :>301:2001/04/25(水) 00:43
図書館使えば?
あとはこのスレの前に方に十分紹介されてると思うけど。

303 :壊れたデバイスさん:2001/04/25(水) 12:58
>>301
Java 言語仕様書にも付録的に何か書いてあったような。

304 :デフォルトの名無しさん:2001/04/25(水) 21:04
タイトルが動物の本がいいと思います。
アスキー出版からでてます。
Bison 入門
石川直太訳

大きな本屋さんなら置いてあるとおもいます。


305 :300:2001/04/25(水) 22:10
切り番get!

306 :>304:2001/04/25(水) 22:52
アレ内容に割に高い。1500円だけど
あれの元文書オンラインでどっかにあった様な・・

307 :306:2001/04/25(水) 23:14
内容の

308 :デフォルトの名無しさん:2001/04/26(木) 17:35
http://math.cs.kitami-it.ac.jp/~fuchino/proin/experimentIII-2000/jikken.html
ここ、
>アレ内容に割に高い。1500円だけど
しょうがないよ、だって読む人限られてるもん。


309 :304=308:2001/04/26(木) 17:37
おお、bison は日本語化されてない(笑)

310 :デフォルトの名無しさん:2001/04/26(木) 17:39
>>308
GNUへの寄付金も入ってるしね。

311 :301:2001/04/28(土) 18:36
失礼しました。

過去ログで紹介されていた本を図書館で探してみました。洋書は読めないので、和書だけですが、
・C stepupシリーズ(3) yaccによるCコンパイラプログラミング ソフトバンク
・プログラミング言語処理系 岩波講座ソフトウェア科学5
・計算機科学/ソフトウェア技術講座7「コンパイラの理論と実現」共立出版
が、ありました。まだ、ざっと目を通しただけですが、残念ながら文法定義の手法そのものについてはあまり触れられていないようです。

そこで、やはり、啓学出版のCコンパイラ設計という本を入手したいと思いまして、古本屋に行こうと思います。ここは田舎で大きな古本屋などないため、大阪まで行こうと思いますが、こういった専門書がありそうなお店をご紹介いただけませんでしょうか。

312 :301:2001/04/28(土) 18:39
すいません、スレ違いだったのにageてしまいました…。

313 :デフォルトの名無しさん:2001/05/01(火) 20:59
http://www.omoikane.co.jp/i/info/html/bison-1.28/bison-ja_toc.html
もう、どうでもよくなってるかもしれないけど、これ見つけました。

314 :デフォルトの名無しさん:2001/05/02(水) 02:14
ユニコードと C++ OPP に対応してる flex/bison 処理系ってありますか?
ライブラリ化されてるとうれしいんですが..
どちらも C 時代なのでソースコードが汚いんですよね

315 :デフォルトの名無さん:2001/05/02(水) 10:13
flexにはC++のスケルトンは用意されていて使える。
実装したけれど使うメリットがないというコメントがtarに入ってる。
lexはマルチバイトパッチのやり方やテーブル構造の工夫で
UNICODE対応は可能だけど、
ただ対応しただけではテーブルサイズが爆発的に増える。
たとえばマルチバイトパッチの仕組ではA+を(A)+に置き換え、
[AB]を(A|B)に置き換えるものがある。
またjava用のもののソースも見たけど、0x100以上のコードの
処理が実装されてなかったり、テーブルの圧縮の部分が
シングルバイトのものと同じのしか見てない。

316 :デフォルトの名無しさん:2001/05/02(水) 17:22
>>314
ほんと、これ欲しいんですよね。
だ〜れも作らないし、えっお前作れって(^^;
ひまできたら冗談抜きで作りたいんだよなぁ。

#flex の C++ 版・・・ありゃほんと〜に使えねぇ。
#作った本人も爆死してるんじゃないだろうか(笑)
#あれは、クラス化するよりも、テンプレート使って抽象アルゴリズムにするのが
#正攻法なのかもしれないと思ってます。

317 :314:2001/05/02(水) 19:28
>>315
ありがとうございます。大変勉強になります。
考えてみると yacc/bison は特にユニコードに対応する必要なさそうですね
flex のスケルトン見てみたのですが、なんて言うか・・
これって OOP じゃないような..感じです(^-^;

>またjava用のもののソースも見たけど
JFlexでしょうか? u100以上は処理しないのは keyword が実質 ASCII と等価な
マッピング部分限定になっちゃいますよね。一応、ASCII だけでも使えますけど・・
utf8 に適当に変換して騙しながら使うことになりそうです。
BMP 超えたコードが来たらこれもアウトですが...

318 :314:2001/05/02(水) 20:03
>>316
はいです。作れるなら作りたいんですけど
時間と才能と経験がほしいところです... (^^;

理想としては flex source -> intermediate code になって
flex object がそれ読んで処理してくれれば.. って感じなんですが..

319 :名無しさん@1周年:2001/05/02(水) 23:29
javacでのエラーの時、MS-DOSプロンプトって
どうやって、スクロールさせるの?

320 :デフォルトの名無しさん:2001/05/03(木) 00:02
>>319
Win95/98のコンソールは、スクロールできません。
エラー出力が見たいなら、ファイルに出力を書き込んでからそれ見てちょ。

WinNT、Linuxとかなら標準エラー出力をファイルにリダイレクト。
Win95/98はリダイレクトできないので、ソースの中でPrintStream
開いて、System#setErr()で標準エラー出力をそっちに変更しちまえ。

321 :デフォルトの名無しさん:2001/05/03(木) 20:12
あげよう

322 :デフォルトの名無しさん:2001/05/04(金) 06:54
>>319
javac -J-Djavac.pipe.output=true Foo.java > error.txt

323 :デフォルトの名無しさん:2001/05/04(金) 19:32
既出かも知れないけど…
http://gaogao.moemoe.gr.jp/main.html#id6did4

> DMonkey
> Delphiアプリケーションへの組込みを目的としたスクリプトエンジン

JavaScriptのサブセットだそうです。ソース付き。

324 :デフォルトの名無しさん:2001/05/14(月) 12:45
墜落ピンチ!!サルベージあげ

325 :デフォルトの名無しさん:2001/05/14(月) 13:25
>>314
構文解析器は兎も角、字句解析器は自力で作っても大して
時間変わらないんじゃない?極端に複雑なのは別にして。
C言語くらいのなら数時間あれば一通り作れるでしょ?

326 :デフォルトの名無しさん:2001/05/14(月) 17:21
少なくとも325には無理だ。(藁

327 :デフォルトの名無しさん:2001/05/14(月) 18:08
>数時間
すごい、私もできないことないと思うけど、数時間で作れとか言われたら
血尿でるかも。

328 :デフォルトの名無しさん:2001/05/16(水) 00:47
>>327
字句解析器ならすぐ作れないか?
仕様はK&Rでも見ればいいし、lexerは決まりきった書き方があるし。
とはいえ、設計から完成までで数時間で作れといわれたら丁重にお断りするけど(笑
実コーディング時間が数時間なら同意。

329 :デフォルトの名無しさん:2001/05/17(木) 11:58
>>327
lexがやってるのと同じように1文字読むごとに状態遷移して、ってのは無理だけどね。
一度数字がきたら、A〜F以外の非数字が来るまで数字として読む、シンボルの先頭に
許される文字がきたら空白や記号を読むまで、シンボルとして読む、って感じで。
漏れも字句解析は手書きだよ。日本語を扱えるようにするにはこれが一番。

330 :デフォルトの名無しさん:2001/05/17(木) 12:50
K&RのBNFみたって数時間で作れるのかねぇ。甘いよ。
全然C言語がわかってない。

331 :デフォルトの名無しさん:2001/05/17(木) 13:02
数時間で作れない330はタコプログラマー

332 :デフォルトの名無しさん:2001/05/17(木) 13:30
今から作って明日までにアプせよ>>331

333 :デフォルトの名無しさん:2001/05/17(木) 14:06
>>330
字句解析器と構文解析器の違い知ってる?

334 :デフォルトの名無しさん:2001/05/17(木) 14:17
自分は優良プログラマだと言いたいなら、数時間で作れる
などと言わない方が賢明です。(藁

335 :デフォルトの名無しさん:2001/05/17(木) 15:10
>>334
同意。

336 :デフォルトの名無しさん:2001/05/17(木) 18:54
<数> ::= <数字>*
<数字> ::= 0|1|2|3|4|5|6|7|8|9

337 :デフォルトの名無しさん:2001/05/17(木) 19:11

鬱駄根用

338 :デフォルトの名無しさん:2001/05/18(金) 07:25
僕もコンパイラに興味があるんですけど、本などを読むと

<数> ::= <数字>*

336さんが書かれたような表記をよくみます。これって
どのように読むのでしょうか?

339 :デフォルトの名無しさん:2001/05/18(金) 07:28
BNF 表記
EBNF 表記
結合規則
優先順位
lex yacc bison
などで検索>>338
現行の言語の仕様書や本とかには必ず付いてると思いますが。

340 :デフォルトの名無しさん:2001/05/18(金) 10:58
<数> ::= <数字>*
<数>は<数字>の後に*がついたもの????
頭痛い

341 :デフォルトの名無しさん:2001/05/18(金) 12:19
>>340
繰り返しだよバカ

342 :デフォルトの名無しさん:2001/05/18(金) 13:25
「どのように読むのか」って、どのように発音するのか?って意味かと
おもたよ。
「山カッコ 数字 山カッコ閉じ スター」ってかんじでしょうか

343 :デフォルトの名無しさん:2001/05/18(金) 17:22
<数> ::= <数字>*
<数> ::= <数字>{<数字>}
<数> ::= <数字>|<数> <数字>
どれがいいのですか

344 :デフォルトの名無しさん:2001/05/19(土) 02:05
>340
*は0回以上、+は1回以上の繰り返しじゃなかった?

345 :デフォルトの名無しさん:2001/05/19(土) 02:07
>343
3つ目はそのままでは実装しにくい。

346 :345:2001/05/19(土) 02:08
間違えた、スマソ

347 :デフォルトの名無しさん:2001/05/20(日) 07:58
あげておく

348 :デフォルトの名無しさん:2001/05/21(月) 18:47
じゃあ俺も

349 :困憊羅:2001/06/01(金) 02:00
Cでpascalコンパイラをつくったソースがのってる本とかないですかねー

350 :デフォルトの名無しさん:2001/06/01(金) 02:11
>>349
あるよ。
このスレの過去ログ参照

351 :困憊羅 :2001/06/01(金) 15:18
>>350
29 desuka?


352 :デフォルトの名無しさん:2001/06/01(金) 21:10
コンパイラを作る方法 生越
って本がまさにそれ>351

353 :age:2001/06/04(月) 06:05
ねぇ、話題つきた?

354 :デフォルトの名無しさん:2001/06/04(月) 11:23
今ないだけ、そのうちでてくる。

355 :おしらせ:2001/06/11(月) 14:49
http://www.fuel.co.jp/~bull/monner/doc/
このサーバーから降ろしてくれと言われたので近々公開停止になります。
利用禁止ではありません。
ミラーしてくれる人がいたらroot@mail.fuel.co.jpまで。

356 :デフォルトの名無しさん:2001/06/11(月) 15:11
もっとマシなものなら考えるけどなー
こんな誰でも作れる程度のものを公開するなよ

357 :デフォルトの名無しさん:2001/06/13(水) 19:04
構文解析ってあるじゃないですか?
具体的にどんなコードをはけばいいんですか?

358 :名無しさん:2001/06/13(水) 19:27
基本は構造をトレースすること。
1+2*3は ADD(1, MUL(2, 3))という構造、
IF COND THEN STMT1 ELSE STMT2は
IF(COND, STMT1, STMT2)
トレースのやり方は
入門書に有るけど、
X ::= A B;
というパターンの定義があると
スタックにAとBが乗っかると
Xに変換するという仮想機械を造って実現する。
2つ目の条件式
Y ::= X B
でABBがスタックにあると最終的にYという結果になる.
続きがいるならまた後で。

359 :デフォルトの名無しさん:2001/06/14(木) 07:39
つまり、仮想機械の設計次第でコードが変わるということですか?

360 :デフォルトの名無しさん:2001/06/14(木) 08:25
構文解析は関係ないんじゃない?
構文解析は構文木作って終わりだよね?

361 :デフォルトの名無しさん:2001/06/14(木) 09:54
蛇足だが、
構文解析の結果が木になるとは限らないぞ。
たまたま木になる文法の言語かどうか?ということだ。

たとえばForth系言語だと木じゃなくフラット構造にしかならない。
木をバイトコード(フラット)形に展開する手順を
ユーザーがやってくれるようなもんだからな。

木になる文法のほうが人間様にとってはふつー快適だとは思われるが。

362 :デフォルトの名無しさん:2001/06/14(木) 15:03
アセンブラもフラットだ。
木になる文法、言い換えれば構造化された文法かね。

363 :デフォルトの名無しさん:2001/06/15(金) 13:39
アセンブラはフラットじゃないだろ。
ニモニックとオペランドという構造もってるから。

364 :デフォルトの名無しさん:2001/06/15(金) 14:25
確かにそういわれればFORTHの方が単純だな、、

365 :デフォルトの名無しさん:2001/06/16(土) 01:40
>>363
汗は、1行の範囲内では構造を持った文法だ、とでも
呼ぶべきなのかも。

上下方向は…ありゃアセンブラという言語(?)から見れば
あくまでセマンティックの問題でしかないよねえ?
どこへどう飛ぶかは100%プログラマの責任であって
「アセンブル」エラーで教えてくれたりはしないという。

>>364
言語処理系作るの、マヂ、楽よ。
厨房の夏休みの自由研究の題材でもいいくらいに、楽。
他にも楽な言語は多いだろうけど、
構文というものを"いっさい"処理しなくていい言語なんてのは
Forth系くらいしかないんじゃないかな。

366 :デフォルトの名無しさん:2001/06/16(土) 01:45
>>365
Forthってどういうコードになるんですか?
後置記法って事しか知らないから、簡単に解析きぼん

367 :デフォルトの名無しさん:2001/06/16(土) 01:46
解析じゃなくて解説

368 :デフォルトの名無しさん:2001/06/16(土) 02:48
>>365は一度も作った事の無いドキュン

369 :デフォルトの名無しさん:2001/06/16(土) 05:42
>>368
実用レベルの汎用言語を作るのは難しいが、
機能を絞った処理系なら本当に楽だぞ。
lex+yacc使ってインタプリタで最適化なしとか。

370 :デフォルトの名無しさん:2001/06/16(土) 08:17
>>365
Forthってどういうシンタックスになるんですか?
後置記法って事しか知らないから、簡単に解説きぼん

371 :デフォルトの名無しさん:2001/06/16(土) 11:15
ForthとFortranを読み間違えたよ・・・。鬱だ。

372 :デフォルトの名無しさん:2001/06/16(土) 11:57
Forthは知らぬけど、同類だといわれてるPostScriptについて。

ひたすら「オペレータ」つまり単語を並べる。それだけだ。あれの文法は。
それを計算機(言語処理系)が順に処理する。それだけだ。

だからlexは使うとしてもyaccは要るかどうか怪しい。

1 2 add print ってのはそれぞれ、
1を記憶する(記憶場所としては御存知Stackを使う)
2を記憶する
1つ前の記憶と2つ前の記憶を取りだし、足し、記憶する
1つ前の記憶を取りだし、画面出力する (printってのは標準OPじゃないが、説明用
って意味。機械はそれぞれを順に実行するだけ。

味噌は、「どの単語がどの場面で出たか?」なんてことを
機械はいっさい感知(&関知)してない、ってことだ。
ふつーの言語は関知する。*がポインタなのか掛け算なのかとか、
,が引数区切りなのかそうじゃないのかとか、を考える。

で、PSには、それが無い。そういう意味ではアセンブラと同じだ。
なにがどんな順で出たかの責任はプログラマが負う。

{ 1 2 > } { 1 print } { 2 print } if
{と}は、実行ブロック(実行可能配列ってのが正式名称。
つまりプログラムも所詮はOperatorの配列に過ぎぬ。
実行可能だというフラグがONになるだけ)としての
切りだし処理を開始する/終了する、という、これまた単なるOP。
ifは、3つ前に記憶したブロックを評価し、
真なら2つ前のブロックを、偽なら1つ前のブロックを、評価する
という、これまた単なるOP。

それ以外のヒネリは、いっさいなし。

/aaa 1 def
/bbb {1 print} def

defは、2つ前のシンボル名で、1つ前の値を、「辞書」に登録するというOP。
aaaというシンボル名で1を登録。
bbbというシンボル名で{1 print}という実行可能配列を登録。

/aaa 1 def
aaa print >>>>> 1
3 dict begin /aaa 2 def print end >>>>> 2
aaa print >>>>> 1

dictは容量n個の辞書を作って記憶するOP。
beginは1つ前の記憶を取りだし辞書Stackに記憶するOP。
endは辞書Stackのtopの辞書を捨てるOP。
Stackが1つ増えた(辞書Stack)だけで、ローカル変数も実現。

名前(変数名?)解決の規則は、辞書をStackのTopから順に下に
検索するというもの。TOPで空振りしたら2つ目に当たる。

言い忘れたがStackは、OperandStack(さっきから記憶記憶と書いてるあれ)
と辞書Stackが有る。他にGraphicに特化したStackもあるが本質じゃないんで割愛。

373 :デフォルトの名無しさん:2001/06/16(土) 14:34
>つまりプログラムも所詮はOperatorの配列に過ぎぬ。

結局、コンパイル(?)されると、
プログラム全体がソース見たマンマの順序の
巨大な実行可能配列になる、と考えるとすっきるする。
バイトコードならぬオペレーターコードとでも言うのかな。
ん?おぺこーど?

まぁただ、{}ぐらいは実行時じゃなくコンパイル時に解釈する
ようにしたほうが、実装は楽かな。
そうすると結局コンパイル結果は、ひたすらまっすぐなコード配列、
ではなくて、時折サブルーチン呼び出しの枝が伸びた
木のような形のコードツリーが、内部的に出来あがる。

木といっても構文木の木とは全然違う形&意味だ。
構文木は実行順序に対して垂直に刺さった木(の根?)みたいな感じ
だが、上記コードツリーは実行順序に沿わせる向きに寝かせた木
という感じだ。

それと今更だが、というか見れば判るが、
実行可能配列つまりルーチンもまた
FirstClassObjectになっているわけだ。
実行の区切りが見えない(あくまでOPの処理内容に依存)ので
やりたくはないが、死ぬ気でやろうと思えば恐らく
Lispと同じ位(ってLispは知らぬのだが)の
記述能力はあると思われ。

374 :デフォルトの名無しさん:2001/06/16(土) 19:03
lispぐらい知っっててほしいけど・・
形としては、
(func param param ...)
基本的にこれしかない。
syntaxも例えばifなら
(if test-expr true-expr false-expr)
つまり先頭がfuncやifの様なシンボルで、
それが何かに関連付けられていればその文を実行できる。
関数だとparam部分が全て評価されてから関数に渡るけど、
ifの様なsyntaxの場合は部分的に評価される
test-exprを評価し、真ならtrue-exprが評価される偽ならfalse-expr

無名関数
((lambda (x y) (+ x y)) 1 2)
=>3
これは、2引数を取る無名関数。
(lambda (x y) (+ x y))がfuncに対応し、1 と 2がparamに対応する
(define func (lambda (x y) (+ x y)))
と定義すれば
(func 1 2)
3
で普通の関数と同じ結果になる
あとはこれの応用。
処理系はforthに次いで簡単に書ける。

375 :デフォルトの名無しさん:2001/06/16(土) 19:38
>lispぐらい知っっててほしいけど

まぁそう言うな。PSだって知らぬ人多いだろう。
Lispほど知る必要無いというのもある意味真実だが(藁

前置か後置かの違い、
前置を実現するためのカッコが有るかないかの違い、
その2つ程度なんだろうな、LispとPSの差は。

両者の中間みたいな感じの言語を
作ることは{できる,試みる意味(藁)は有る}か?ってのが
今ちょっと感じている疑問というか興味。
どうなんだろう?ていうかナニをもって中間なのかも
よく判らないのだが…

>無名関数

{add print} 1 2
1 1 rot ####Stack上の積み順を「回転」させるOP。これで無名手続きがTOPになるよね?
execute ####StackTopのポインタ(?)を「実行」するOP。

こんな感じか。Stack処理手順を手作業しないとならんのは
ちとダサイところ。

376 :デフォルトの名無しさん:2001/06/16(土) 22:45
>>374
lispは他にリスト操作もあるからね。quoteの概念を理解できるか
どうかってのがある。(使い続けていれば自然に身につくけど)

>>375
繰返しは
{test-expr} {body-expr} while
ですか?
「{test-expr} が真の間 {body-expr} を繰り返す」
と書けますね。(これがMIND?)

>両者の中間みたいな感じの言語を
間をとると中置記法?
lispは式をリストと見なす事ができるので、中置記法は後づけで作れます。
forth系でのやり方は知りませんが、多分同様な事が可能でしょう。
所でforth系はスタックを直接操作するからgcみたいな機構は必要無い?
作りたくなってきた。

377 :デフォルトの名無しさん:2001/06/17(日) 00:46
もうあんまり覚えてないんだが…。

たしかforthだとimmediate wordってのがあって、
これはcompilation mode(だと思った)でも動作する。
それ以外のwordは、compilation modeだとそのword自体が走るんじゃなくて
そいつへの呼出にcompileされる。
: func (: はcompilation modeに入るword)
1 2 +
; (; でcompilation modeを抜ける)

378 :デフォルトの名無しさん:2001/06/17(日) 06:29
Forthはなかなか日本語の資料(文法とか)が検索でみつからない。
見つかった処理系は
Portable Forth
GNU ANSI Forth
SCMForth (Schemeで書かれたサブセットらしい)
あとはPostScriptで検索した方が早いかな?

379 :デフォルトの名無しさん:2001/06/17(日) 06:41
ANSI FORTH 規格書 (英語)
http://www.taygeta.com/forth/

380 :デフォルトの名無しさん:2001/06/17(日) 06:47
電通大のForthの解説 (日本語)
http://www-lab.ee.uec.ac.jp/text/forth/

381 :デフォルトの名無しさん:2001/06/17(日) 13:01
>>376
PSでリストの代用になりそうなものを探すとすると
配列と辞書くらいかな。サイズ2の配列か辞書を作ればいい。
まぁ言語が直接支援してくれないんで辛いけど。

同様に、Objectの代用になりそうなものも
配列か辞書だな。勿論これも直接は使い勝手悪いが。

>{test-expr} {body-expr} while

んな感じ。whileそのものは無いけど
似たようなのは有るし当然自作も可能。

>間をとると中置記法?
なんか違うような気がする(^^;

>所でforth系はスタックを直接操作するからgcみたいな機構は必要無い?

Stackゆーても(PSは)Stackに記録される値はあくまでPointerなので
あるObject(文字列にせよ辞書にせよ配列にせよ)が
複数箇所(StackやArrayやDict)から同時に参照されることは有るし、
そういう意味ではリファレンスカウントだけじゃ循環参照が云々…
とかいうアッチ方面の問題は、同じように全部抱えてると言えます。

面倒ならboehmGCだな(藁

382 :デフォルトの名無しさん:2001/06/17(日) 13:08
>>377
それって、インタラクティブに(BASICみたいに)ソースを
1行づつ入力&実行するモードと、そうでないモードとを
うまく使い分けるための機能、でもあるわけですよね?きっと。

直接関係ないがPSにはbindというOPが有るらし。

/aaa { 1 2 add foo } bind def

と書くと、1つ前の実行可能配列の中の
アドビ(藁)定義済みOPを、その名前への参照じゃなくて
実行実体(?)への参照に置換してくれるそうだ。
ここではaddがソレだな。
これで実行が少し速く効率的になる、らし。

定義済みOPをどっか別のReadOnly辞書で一元管理してる模様。
まぁ類似実装系を自作するときには、面倒なら省ける機能の
筆頭でもあろうけど(藁

383 :デフォルトの名無しさん:2001/06/17(日) 18:40
急にアツイ議論がage

384 :デフォルトの名無しさん:2001/06/18(月) 00:39
トランスレータも面白いよ

385 :377:2001/06/18(月) 01:18
>>382
> それって、インタラクティブに(BASICみたいに)ソースを
> 1行づつ入力&実行するモードと、そうでないモードとを
> うまく使い分けるための機能、でもあるわけですよね?きっと。

いや、Forthにはインタラクティブかどうかって区別はほとんどなかっ
たような。
immediate wordっていうのは何をするためのものかというと、例えば
ifならまず条件ブランチ命令をおいて、そのアドレスを記憶しておく。
そのあとthenで条件ブロックが終ったところでブランチ命令のところ
に終端までのオフセットを書き込む。
つまりほんとにコンパイラのコードジェネレータと同じようなことを
したりするためのもの。

> アドビ(藁)定義済みOPを、その名前への参照じゃなくて
> 実行実体(?)への参照に置換してくれるそうだ。

つまりデフォルトでlate bindingなのをその時点でbindしちゃうわけ
ね。Forthはlate bindingじゃないし、前方参照も許してないからそう
いうのはないけど。

Forthの実装もいろいろで、小さいwordはその場にインライン展開して
しまうのとかもあったはず。
おもしろいのは、m68000用でipにA7レジスタを使うやつ。各wordの終
りにはrts命令がおかれてる。

386 :デフォルトの名無しさん:2001/06/18(月) 02:50
forthの条件式if then else
これの文法がよくわかりませんでした。

そこで、問題

(a) if (b) else (c) then (d)

(a)〜(d)は式とします。
例えば、(a)〜(d)にそれぞれ何が入るんでしょう?
また、条件式と関係の無い式を(a)〜(d)の中から選びなさい。(15点)

387 :デフォルトの名無しさん:2001/06/18(月) 03:00
(a) 条件式
(b) (a)が真のときに実行される式
(c) (a)が偽のときに実行される式
(d) 条件式と関係の無い式

388 :デフォルトの名無しさん:2001/06/18(月) 03:29
ありがとうございました。>>387
やっぱり条件式はifの前に書くんですね。
thenの位置が謎ですが。

389 :デフォルトの名無しさん:2001/06/24(日) 13:48
あげ

390 :デフォルトの名無しさん:2001/06/24(日) 15:50
Forthって、データもアドレスも16bitだったときはエレガントな設計だと思ったけど
やれ倍精度整数だ実数だとかいいだしてから、ちょっとうざくなってきた
インタプリタもワードを並べて置いただけの頃は数バイトで済んでたのにね
何やかんや言っていても、私は今でもあこがれてるな
http://www.forth.org/
FIGなんてまだあったんだなぁ

391 :デフォルトの名無しさん:2001/06/29(金) 06:02
lispはC言語の関数呼出しだけで構成されてると思えば、
ほぼ同じ見方ができるけど、
C言語 a(b(c())); lisp (a(b(c)))
forthはスタックが丸見えだからc b aという感じに記述するから違和感あり?

392 :デフォルトの名無しさん:2001/06/30(土) 11:34
>>391
forthは境目がないのが痛い。
どっからどこまでをどう括って解釈すべきか?は、
あくまでコンテクストと意味に依存するから、
コードを理解できるかどうかは
ほぼ語彙の知識の有無に依存しちまう。
人間様には痛い。

393 :デフォルトの名無しさん:2001/07/06(金) 18:12
age

394 :デフォルトの名無しさん:2001/07/08(日) 18:24
WindowsのGUIインタフェース持たせてる処理系って、
コールバック関数の辺りとかはどうやってるの?
例えばWNDCLASSに登録するコールバック関数とか。
やっぱり内部で専用に作ったCのコールバック関数を用意してるのかな?

395 :デフォルトの名無しさん:2001/07/08(日) 23:51
>>394
どの処理系?
まあ、処理系がサポートしてその部分を隠してるなら、何だかの方法で
フックしておく必要はあると思うけど・・・
内容としては若干スレ違い気味?

396 :デフォルトの名無しさん:2001/07/09(月) 00:58
>>395
えーと、WindowsのGUIをサポートしてる処理系の事です。
(メジャーなスクリプトや言語の処理系はほとんど対応してると思いますけど。)

CALLBACKやWINAPI(__stdcall)の関数を引数のつじつま合わせて呼び出すのって、
Cでそのままの型でテンプレート持っておくか、アセンブラで書くしか無いですよね?
Cの関数にしちゃうと、コールッバックの形だけ関数定義が必要になってしまうんで、
他にいい方法が無いか探してます。
アセンブラでやるしかないですかね。

LRESULT CALLBACK WndProc(HWND hwnd, UINT m, WPARAM w, LPARAM l)
というコールバックだったら
引数は、
8[esp] ;hwnd
12[esp] ;m
16[esp] ;w
20[esp] ;l

戻り方は、
ret 16
としないといけないみたいなので、引数やret xxxの決定をどうやって
動的にやるのかがわかれば良いんですが。

397 :デフォルトの名無しさん:2001/07/09(月) 06:08
>>394 >>396
何をやりたいのかサパーリ分からん

398 :デフォルトの名無しさん:2001/07/09(月) 07:00
>>394
多分、GUIの作成をサポートした処理系のことを言ってるんだと思うけど、

スクリプトで動的に生成されるプロシージャーは全ウインドウ共通にする。(ウインドウのタイプごとに分けてもいい)
内部で処理したいメッセージ等は共通のプロシージャーに直接書く。
HWNDをキーとしたハッシュテーブルを作っておき、CreateWindowしたあとに戻り値のHWNDと必要なデータ(多分メッセージがきたときのスクリプトの飛び先の情報なんかになるかな)とともに保管する。
どのウインドウからのメッセージなのかは第一引数のHWNDでわかるから保存しておいたハッシュのデータをもとに適切な処理をすればいい。
(ボタンなどの子ウインドウからのメッセージの場合はWM_COMMANDのlparamがメッセージの送り元になるので注意。)

こんな感じでどうでしょうか

399 :398:2001/07/09(月) 07:46
訂正

スクリプトで動的に生成されるプロシージャーは

スクリプトで動的に生成される"ウインドウの"プロシージャーは

400 :デフォルトの名無しさん:2001/07/09(月) 08:40
>>398
del方面から話題2つ。

1:delにおける解決方法
http://www.asahi-net.or.jp/~HA3T-NKMR/vcl3-1.htm

2:delにおける独占方法(わら
この特許にひっかからないようにヤらないと駄目だな
http://www.borland.co.jp/news/patent.html

401 :デフォルトの名無しさん:2001/07/09(月) 09:19
>>396
混乱してませんか?
とりあえず簡単なインタプリタ(コンソールベースがいいと思う)を作ってみてはどうでしょう。
コンパイラであれば、その部分はテンプレート的に生成しておいて、あとで命令スケジューリングして
依存関係を考慮しつつ並べ替えます。
スクリプトの場合は考える必要はないです、やり方は 398 さんのやり方が妥当だと思います。

>>400
あなたも混乱してません?発言がdel厨房っぽいぞ(藁

402 :401:2001/07/09(月) 09:21
アゲときます。

403 :401:2001/07/09(月) 09:25
私も混乱気味、スクリプト−>インタプリタ(自爆

404 :代打名無し:2001/07/09(月) 11:48
>>400
もしかして、サンク方式なんかやばいですかね。

405 :デフォルトの名無しさん:2001/07/09(月) 13:34
>>404
ATLで似たようなことやってるよ

406 :デフォルトの名無しさん:2001/07/09(月) 20:21
>>401
てゆーかまんまdel亡です。
delにおいてくだんの問題はこう解決されてる、っていう頁ね。

>>404-405
特許頁見たら、del発売の頃から申請して
今ごろやっと通ったという特許らしい。

とはいえ、ふつー誰でもやる技法だと思うんだがな。
ヘジ(delを作った人らしい)もヤキまわったか(わら

407 :396:2001/07/09(月) 21:04
みなさんありがとうございます。
汎用性を考えて、コールバック関数のアセンブラコードを動的に生成する事を
考えています。
例えば、RegisterClassをインタプリタで実行するときに必要な、
WNDCLASS構造体のコールバック関数を設定する時、
インタプリタ言語側のシンタックスで
LRESULT func(HWND, UINT, WPARAM, LPARAM);;
という型の関数が必要である事を処理系に伝えます。
処理系側で、コールバック関数のテンプレートをヒープにコピーして
インストラクションコードを追加/書き換えた物を登録する。
という方法です。
(でもアセンブラスキルはいまいちなので、完成するかどうかは判りませんが。)
なるべく同期処理を行なわずにスレッドセーフにしたいのもあります。

>>398さんの方法も考えたんですが、汎用性が無くなるのが嫌なんです。

>>401
コンソールベースのインタプリタはもう存在します。
DLLを動的にロードしてAPIを直接扱ってGUI対応するのが目標です。

408 :398:2001/07/09(月) 22:05
>>407
どう汎用性がなくなるのかよくわからんが、コールバックだけを動的に変えたいだけなら
SetWindowLong()でできるぞ。詳しくはMSDNあたりを参照してくれ。

409 :デフォルトの名無しさん:2001/07/09(月) 22:50
>>408
そんなんじゃ出来ないから質問してるんじゃないの?

410 :401:2001/07/09(月) 23:10
要するに DLL から関数の型情報が動的に取り出せるか
という事と
型からどのようにスタックフレームが決定されるのか
という問題ですね。
この辺になってくると、Windows の知識がかなりいりそうですね。
自分はこのへんになってくるとゲーム屋のMIPS屋なので
ウインドウズは Windows は GDI かじった程度なので知識量不足です。

このへんはウインドウズの低レベルインターフェイスの
詳しい人が出てくるのを待ちますか・・・(^^;
お役に立てなくてすみません。

>>アセンブラコードを動的に生成
ちなみにコードの自動生成はあんまりお勧めできないです、
近年のCPUの状況を考えると・・・
テーブルジャンプしたほうがいいとかいう事になるかもしれません。
なぜかといいますと、インストラクションキャッシュとデータキャッシュは、
まず間違いなく分かれていますから、生成したコードを実行するには
キャッシュを一旦全部メインメモリーにフラッシュして再度読み込みしないと
いけません、8K〜16Kbyteをメインメモリに書き込むとなると
これはかなりタスクスイッチ並に嫌なものがありますので、
できれば最終手段にしたほうがいいのでは、と感じています。
もしも、どうしてもやりたいならば、次の様にしてみることをお勧めします。

ret_2: ret 2
ret_6: ret 4
ret_8: ret 6
...

とコードどを全部あらかじめスタテックに生成しておいて、これにテーブル
式でジャンプしてみてください、このほうがはるかに効率が良いはずです。(多分)

411 :396:2001/07/09(月) 23:14
>>408
伝わりませんでしたか?
例えばRegisterClassに登録するコールバックと、
EnumWindows、EnumChildWindowsに設定するコールバックの関数の型は、
それぞれ違いますよね?(EnumWindowsとEnumChildWindowsは同じですが。)
また、将来新たに作られたり、ユーザー側が作ったDLLのコールバック関数も、
型が同じとは到底思えません。
その全てのコールバック関数の動的対応をどうするか、について質問しているのですが。

412 :401:2001/07/09(月) 23:15
>>410
ん、esx 操作すりゃいいか(藁)

413 :401:2001/07/09(月) 23:19
>>412
esx -> esp
鬱だし脳

414 :396:2001/07/09(月) 23:28
>>410
その方法は衛生的で良いですね。
まだ引数をどうするかの問題が残ってますが。
それと、書き換えは遅くなる可能性があるんですね。勉強になりました。
でも一度作って、それを使いまわす状況ならいいでは?
とも思ったんですが違いますか?

415 :401:2001/07/09(月) 23:30
>>410
多分OKだと思います。
スクリプト中のどこかにまとめて宣言しておいて、
起動前に全部作ってしまうのがいいかも知れませんね。

416 :396:2001/07/10(火) 01:04
>>415
そうですか。
とりあえず作ってみます。
みなさんありがとうございました。

417 :デフォルトの名無しさん:2001/07/10(火) 02:51
int *fun1(...)、long *int(...)の二つの関数ポインタを作って、
無理矢理キャストするというのは駄目かな?

418 :401:2001/07/10(火) 12:23
>>417
パスカル式には、それは使えません。
スタックフレームを呼び出し側で処理しているC型の呼び出しのみ有効です。

419 :396:2001/07/10(火) 20:14
なんとか動く物が作れました。__cdecl/__stdcall
(まだEnumWindowsでしかテストしてないですけど。)
これの実装、コード量の割にかなり辛かったです。
(アセンブラをあんまり触わってないのが原因ですが。)
とにかく、DLL-APIの直呼出しと、コールバックが使える様になった事で、
かなり表現の幅が広がった様な気がします。

420 :396:2001/07/11(水) 00:33
無事、ウィンドウのメッセージループまで行き着くことができました。
それにしても、winapiインクルードファイルの変換は大変ですね。
今の所メッセージは全部DefWindowProcに渡してるからいいけど、
インタプリタ側で処理を追加していくと、かなり遅くなりそうです・・。
というわけで、お答え下さった方々、ありがとうございました。

421 :デフォルトの名無しさん:2001/07/11(水) 04:59
Rubyに入ってるwin32api呼び出しモジュールのソースや、
HSP用のloadlib.dllのソースが任意のdllの関数を呼び
出すためにマシン語使ってたな。

422 :VB厨房:2001/07/11(水) 17:01
誰かソースからドキュソメント作成するのに便利なawkのスクリプトがあったらおせーて!
hellプ(for ActiveServerPages)

423 :VB厨房:2001/07/11(水) 17:04
ちなみに関数一覧と変数一覧をコメントつきで生成するやつは自力で作った。
それっぽいやつヨロピク

424 :デフォルトの名無しさん:2001/07/11(水) 23:17
age

425 :デフォルトの名無しさん:2001/07/11(水) 23:36
sage

426 :デフォルトの名無しさん:2001/07/12(木) 00:04
>>422-423
思いっきりスレ違い、スクリプトすれかVBスレに逝きなはれ。

427 :デフォルトの名無しさん:2001/07/14(土) 02:19
スクリプト言語で二重ロード防止策ってどんな方法が良いんでしょう?
C/C++は#ifndef#define#endif、マクロ定義
Pascal/perl/lispなどはuseとかrequireとか。
やっぱ後者の様にロードされてなかったらロードするって処理を
言語側でやった方がわかりやすいのかな。
こう考えるとC/C++のマクロって汚いですね。

428 :デフォルトの名無しさん:2001/07/14(土) 02:29
perlは一度読んだファイル名を%INCにつっこんでるだけなので汚いかと。

429 :デフォルトの名無しさん:2001/07/14(土) 02:44
>>427-428
管理に、違う名前空間を使うか、グローバル変数として持つのか。
ぐらいの違い?
ふつーの変数にしとけば、プログラム側で覗けるから
便利なんじゃない?(前例が無ければ後者がお勧め)
どちらにしろ特別な処理はあんま増やさない方が良いよ。

430 :デフォルトの名無しさん:2001/07/14(土) 02:53
>>427
二重ロードされても問題ないような文法にしてしまうとか・・・(藁)
それは、ともかくとして

インクルード宣言作りは「ファイル分離の目的」というのを明確にするべきではないだろうかと最近考えてたりします。
C++ のテンプレートなどは、綺麗に分離されない文法なので、ソースがあるべきところと宣言のあるべきところがゴチャゴチャになってしまいます。
#まあ、自己責任で出来ないことはないんですが・・・

作る言語の構造を考えて、これはどのようにコードが分類されれば、綺麗に整頓できるかが分かれば、インクルードの形式もそれに伴って綺麗な形の物を考える事ができると思います。
先に構造ありき、次に分類方法を考えて、それができたらインクルード方法と思います。

431 :デフォルトの名無しさん:2001/07/14(土) 02:53
Cのマクロって大した事できないくせに実装が大変。
CINTの作者とか苦労してそうだね。ハゲてるし。

432 :デフォルトの名無しさん:2001/07/14(土) 02:59
>>431
(hageはともかく)同意。
NULLとかの誤解も多いし。
あのプリプロセス処理は早めにつぶすべきだったと思う。
確かに便利だけど、代替手段は他にもあったと思う。

433 :デフォルトの名無しさん:2001/07/14(土) 07:47
>>431
マクロの実装は大変か?
たいしたことないと思うが。手を抜きすぎて不便なのはわかるが。

434 :デフォルトの名無しさん:2001/07/14(土) 12:24
lispのマクロは単純な割に使い勝手が良い。
これはマクロが完全に言語の一部だから。

435 :427:2001/07/14(土) 23:57
ありがとうございました。
後者で作ってみます。名前空間の独立は考えていないので、
グローバル変数か何かに、load情報を記録していくことになりそうです。

436 :デフォルトの名無しさん:2001/07/15(日) 00:04
スクリプト言語の作者はハゲますか?

437 :デフォルトの名無しさん:2001/07/15(日) 00:27
>>436
オレはハゲてないよ。

438 :デフォルトの名無しさん:2001/07/15(日) 21:06
>>436
すまん、はげそうです

439 :デフォルトの名無しさん:2001/07/17(火) 04:40
CINTの本(何かの雑誌の別冊っぽい作り)のCDROMに、
作者を写したmovieが入っているのだが、ハゲていたな。確かに。

440 :デフォルトの名無しさん:2001/07/19(木) 02:13
>>439
そういうこと言わない、気にしたらストレス溜まってハゲが加速する。

441 :デフォルトの名無しさん:2001/07/19(木) 02:34
ハゲ板逝け

442 :デフォルトの名無しさん:2001/07/19(木) 03:06
初心者な質問ですみません。
yacc/lexでファイル終端の構文エラーを検出する方法を教えて下さい。

line : hogehoge semicolon {}
   | error semicolon {}
   ;

こう書くと semicolon が無いとうまくエラーになってくれないので
終端の semicolon の無い行のエラーが検出できなくて困っています。

443 :デフォルトの名無しさん:2001/07/22(日) 02:00
h-age

444 :デフォルトの名無しさん:2001/07/22(日) 02:12
EOFを終端記号としてエラー認識すれば良いと思われ。>>442

445 :442:2001/07/22(日) 23:48
>>444
ありがとうございます。
お教えのとおりやってみたらできました。

117 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)