「コンパイラ・スクリ ..
39:デフォルトの名無しさん
03/12/10 23:41
>>34
>>8 にある本ではダメなの？
40:デフォルトの名無しさん
03/12/11 00:07
全文公開は延期してもらってもかまわないから、青木さんにはオライリーの
lex & yacc に変わるような本を書いてほしい。
41:デフォルトの名無しさん
03/12/11 00:11
>>8
佐々 政孝さんの本は出版が少し古いんですね。
42:デフォルトの名無しさん
03/12/11 00:34
>>39
全部コンパイラ系の本、
rubyはインタプリター
43:デフォルトの名無しさん
03/12/11 01:21
>>42
コンパイラはネイティブコードを生成することが多くて、
インタプリタはしないことが多いくらいで
やることは大体一緒だと思うけど。
44:デフォルトの名無しさん
03/12/11 01:23
インタプリタはしないことが多いんじゃなくてしないだろ。
45:デフォルトの名無しさん
03/12/11 01:28
Java VM の HotSpot とか。
46:デフォルトの名無しさん
03/12/11 01:39
>>43
違うのは最適化くらいか？
47:デフォルトの名無しさん
03/12/12 20:24
はっきりいって全然ちがう。（コンパイラとインタプリタ）
同じように使えるのは、字句解析器ぐらいか？
48:デフォルトの名無しさん
03/12/12 20:54
構文解析も意味解析も共通なはずだが。
なんで字句解析だけ？
49:デフォルトの名無しさん
03/12/12 22:46
>>47
C言語にはコンパイラとインタプリタが存在します。
本当に、同じように使えるのは字句解析だけだと思いますか？
50:デフォルトの名無しさん
03/12/12 23:18
構文木作るまでは大方一緒な気がする
51:デフォルトの名無しさん
03/12/12 23:26
釣れた？
52:デフォルトの名無しさん
03/12/12 23:48
LISPはいきなり構文木が手に入る
53:デフォルトの名無しさん
03/12/13 01:06
>>49
コンパイラとインタプリタを備えた C の処理系なんてあったっけ?
大抵どっちかだから、共通している部分が多い事の事例にならないような。
こんな事が出来たら嬉しい人も多いだろうに。
#! /bin/env gcc <-- shbang で呼び出せる
//load Xlib <-- ライブラリのロードはコメント文で ==> コンパイラに通す時も透過的
#include <X11/Xlib.h>
int main() {
// 以下略
// 以上妄想
54:デフォルトの名無しさん
03/12/13 01:19
>コンパイラとインタプリタを備えた C の処理系なんてあったっけ?
作らない（作っても意味無い）だけだろ
55:デフォルトの名無しさん
03/12/13 01:20
>>54
だから、共通している部分が多い事の事例にならないだろ。
56:デフォルトの名無しさん
03/12/13 01:24
>>55
同様な構文を持つ言語のインタプリタとコンパイラで
構文解析が共通化できない理由は何ですか？
57:デフォルトの名無しさん
03/12/13 01:27
>>56
そこには異論は無いです。細かい突っ込みｽﾏｿ。
58:デフォルトの名無しさん
03/12/13 02:56
Dylan や OCAML や Haskell はインタプリタとコンパイラの両方持ってるね。
Common Lisp もだけど。
59:デフォルトの名無しさん
03/12/13 04:18
>>58
源流がLISPだからね。
60:デフォルトの名無しさん
03/12/13 08:41
MLの源流はlispでねーぞ
61:デフォルトの名無しさん
03/12/13 09:29
っつーかDylanだけじゃん
62:デフォルトの名無しさん
03/12/13 10:38
URLﾘﾝｸ(www.levenez.com)
63:デフォルトの名無しさん
03/12/13 11:32
>>62
SchemeがAlgolから受け継いでるのって何？
64:デフォルトの名無しさん
03/12/13 18:30
>>63
lexical scopeじゃないかな？
65:デフォルトの名無しさん
03/12/13 19:22
構文解析器は、理論上はインタプリターやコンパイラに無関係に
整理可能であるが、現実問題としては、そうはならないということだろう。
66:デフォルトの名無しさん
03/12/14 23:36
きょう、ｒｕｂｙのソース開設本みつけたけど、
高いなぁ〜と感じた。
（２０００円までだったら、速攻でかったんだけど）
とりあえず、公開待ちます。
貧乏人で、スマソ
67:デフォルトの名無しさん
03/12/14 23:57
>>66
2000 円で買えるコンピューター書籍はそれほどないと思うが?
なにが売ってても買わないの?
68:デフォルトの名無しさん
03/12/15 00:03
bison本やlex本（GNUプレス）は
みんな安いよｗ
69:デフォルトの名無しさん
03/12/15 00:15
これ？
URLﾘﾝｸ(www.amazon.co.jp)
良さそうな本じゃん。Perlでこういう本ってあったっけ？
70:デフォルトの名無しさん
03/12/15 01:17
>>69
Perlはソースコードが多すぎる。
71:デフォルトの名無しさん
03/12/15 07:18
>>68
それってinfoで全文ローカルで読めるやつのこと？
72:68
03/12/15 21:36
>>71
infoは使ってないのでよくわからんが、そうかもしれない。
実はもれも、本文はどこかで（英語？？？）読んだ記憶があった。
でも、手元に書籍であると、またちがうんだな、これが！
73:デフォルトの名無しさん
03/12/15 22:10
>>72
たしか、利益の一部は FSF に寄付されるんじゃなかったかな。
ところで、参考文献としてこの本は既出？
Icon 自体が面白い言語なので読んで損はないと思う。無料だし。
The Implemetation of the Icon Programming Language
URLﾘﾝｸ(www.cs.arizona.edu)
74:デフォルトの名無しさん
03/12/15 22:49
yacc/lex使ってSQLパーサ作りたいんだけど、挑戦したことあるひといますか？
75:デフォルトの名無しさん
03/12/15 23:37
lex & yacc のサンプルがそのままSQLパーサだったような記憶。
76:デフォルトの名無しさん
03/12/15 23:41
>>75
そうそうあったあった。どこかにサンプルコード落ちてたよ。
英語版だけど
77:デフォルトの名無しさん
03/12/15 23:42
>>76
コードが英語なのは普通じゃ…。
78:デフォルトの名無しさん
03/12/15 23:47
>>73
ｆｌｅｘは読みやすかったけど、ｂｉｓｏｎは読みにくかった。
やはり、難しいからですかね？？？
79:デフォルトの名無しさん
03/12/15 23:58
すいません、ふと疑問に思ったんですけど、
正直、このスレってとっても
（良く言えば）→高度＆専門的
（悪く言えば）→難しいばっかりで、地味＆マイナー
な領域ですよね？
みなさん、本職は何をされているんでしょうか？
やはり、プロのコンパイラorスクリプト屋さんなんでしょうか？
80:デフォルトの名無しさん
03/12/16 13:54
>>79
プロのコンパイラ屋(コンパイラだけ作っててメシが喰える人)ってかなり少な
いと思う。(OS屋はもっと少ないけど。)
他の仕事でミニ言語が必要になったので書いてるとか、大学で論文書くために
作ったとか、あるいは趣味でやってる人がほとんどじゃないでしょうか。
僕はたまたま今仕事でコンパイラを書いていますが、100%のコンパイラ屋では
ありません。
81:デフォルトの名無しさん
03/12/16 16:47
>>79
ゲーム屋も多いと思う。
82:デフォルトの名無しさん
03/12/16 18:02
出来合いのエンジンを利用する場合でも、実装を知っていないと
どうにもならんからね。
83:デフォルトの名無しさん
03/12/16 21:39
>>82
ネタw
84:74
03/12/16 22:42
>>75、76 そのサンプルってどこにありますか？
もし知っていたら教えてください。
85:デフォルトの名無しさん
03/12/16 22:49
オライリーの yacc/lex 本。
86:74
03/12/16 22:54
おおおー。なるほど。早速買ってみようと思います。
87:74
03/12/16 22:57
ところでネットで見つけようとしても見つからないですね。
PostgreSQLとかのソースを見ればいいのかしらん。
88:85
03/12/16 23:09
>>87
だからオライリーのサイトにあるよ。
URLﾘﾝｸ(examples.oreilly.com)
89:74
03/12/16 23:31
>>85
きゃーありがとうございます。
90:デフォルトの名無しさん
03/12/17 22:16
>>80
おお〜、すごい！
本職＆プロですか！
ちなみに、どんなコンパイラ書いてるんですか？
差し支えない程度で結構ですので、
91:デフォルトの名無しさん
03/12/17 23:58
俺は80氏じゃないけれど、組み込み系に利用するためのコンパイラを書いたことがある。
独自のインストラクションセットを吐き出すCコンパイラだけど、
80氏と同じく本職じゃないために、とりあえず動くコンパイラを作っただけ。
最適化とかは必要最低限くらいにしか要求されていなかったし。
俺はフリーのプログラマだけど、
お金をもらえてこういう楽しい仕事が出来るときが一番嬉しいね。
92:デフォルトの名無しさん
03/12/18 00:19
>>91
おお〜、「フリーのプログラマ」で、しかもコンパイラまで
書けるのですか！
なんか括弧イイ！ですねぇ〜！
わたしも、フリーではあるのですが、フリーはフリーでも（ry
93:デフォルトの名無しさん
03/12/18 03:27
ASICとかFPGA屋さんもいるかも知れず。
94:デフォルトの名無しさん
03/12/18 11:28
>>90>>92
コンパイラ書くのはそんなに難しくないよ。
漏れも大学や専門学校でプログラム勉強したことなんか一度もないけど、
コンパイラを一回書いたことがある。
そのときのネタは、スクリプトを解釈して整数、浮動小数、文字列の計算をしながら、
その結果を GP-IB (RS232 の遠い親戚みたいなもの) に送り込むヤツね。
キーワードは Bison/Flex (またはYacc/Lex)。
これらのツールが食べられるような特殊な書式さえ覚えれば、
サルでも※簡※単※な※コンパイラなら書ける。
# ただし、サルにはGCCは書けない。
95:デフォルトの名無しさん
03/12/18 14:20
簡単なコンパイラ書くぐらいならGCCの移植作法を覚える方が
まだ ※簡※単※？
96:デフォルトの名無しさん
03/12/18 14:40
簡単なコンパイラ書く方が※簡※単※
97:デフォルトの名無しさん
03/12/18 15:02
※強※調※し※た※い※語※句※を※※※で※強※調※す※る※ス※レ※は※こ※こ※で※す※か※
98:デフォルトの名無しさん
03/12/18 15:10
＊＊＊ おおっと テレポーター ＊＊＊
99:デフォルトの名無しさん
03/12/18 15:58
>>95
UNIX USERのGCCプログラミング工房とか読んでると
すんげーキツそうなんですが。
100:デフォルトの名無しさん
03/12/18 16:03
URLﾘﾝｸ(www.wnishida.com)
こんなんとか。
101:デフォルトの名無しさん
03/12/18 17:37
誰かが移植してくれるのを待つのが一番簡単。
102:デフォルトの名無しさん
03/12/18 20:25
>>98
年 * 寄 * り * は * ｶ * ｴ * ﾚ * !
103:デフォルトの名無しさん
03/12/18 21:07
＊＊＊ いしのなかにいる！ ＊＊＊
104:デフォルトの名無しさん
03/12/18 21:22
>>103
俺がさんざん書こうと思って我慢してたのに（ｗ
105:デフォルトの名無しさん
03/12/19 18:45
>>103-104 わらた
106:デフォルトの名無しさん
03/12/20 18:08
VC++でyaccとlexを使ってexeを作りたいのですが、
うまくいきません。みなさんはどうやってやっていますか？
107:デフォルトの名無しさん
03/12/20 21:06
>>106
yaccとlexの出力ファイルをコンパイルして使ってる。
108:デフォルトの名無しさん
03/12/20 21:07
なんでlex/yaccつかうひつようあるの？
win系で？
109:デフォルトの名無しさん
03/12/20 21:09
>>108
ちなみに自分は何を使ってるんだ？
110:デフォルトの名無しさん
03/12/20 21:11
>>109
それはあんたしか知らない。
111:デフォルトの名無しさん
03/12/20 21:14
まともに使えるスクリプト言語って、なんでこんなに少ないんでしょうね？
112:デフォルトの名無しさん
03/12/20 21:18
>>110
その突っ込みは板違い
113:デフォルトの名無しさん
03/12/20 21:31
>>111
それはお前が使えてないだｋ（ｒｙ
114:デフォルトの名無しさん
03/12/20 22:34
>>110
質の低い書き込みするなよ
115:デフォルトの名無しさん
03/12/21 00:20
>111
マジできくが、それじゃどんなスクリプトが欲しい？
116:デフォルトの名無しさん
03/12/21 01:10
>>111
では、使えないと思ったスクリプト言語を理由と共に列挙してみよ
117:デフォルトの名無しさん
03/12/21 01:27
perl ｳﾝｺ
118:デフォルトの名無しさん
03/12/21 04:44
Perlが一番速いんじゃない？汎用的なスクリプト言語の中では。
ああいう方向もありだと思うよ。
119:デフォルトの名無しさん
03/12/21 13:34
速くはないだろperlは、早いけど
120:デフォルトの名無しさん
03/12/22 02:42
インタプリタを初めてつくりたい人に「これをよめ」という本はありますか?
洋書・和書は問いません。
上の方のレスを見るとコンパイラとインタプリタは少し違うようなので、、、
121:デフォルトの名無しさん
03/12/22 07:42
ホントーに初めてで右も左もわからないならCマガジン2000年5月号がお薦め。
122:デフォルトの名無しさん
03/12/22 08:38
URLﾘﾝｸ(www.cmagazine.jp)
特集1 スクリプト言語を作ろう インタプリタの構造と設計
123:デフォルトの名無しさん
03/12/22 12:02
>>120
bison, flex のドキュメント。
gcc の *.y ファイル。
124:デフォルトの名無しさん
03/12/22 13:02
字句解析は正規表現のようにした方がいいですか・・・
ハッシュにして48個（64個）を作ってそれぞれをチャインで
繋いで予約語と関数名と変数等を検索して方が早くないですか・・・
125:デフォルトの名無しさん
03/12/22 18:00
>>124
そう思うならそうすればいい。
っていうかそれでいい。
なにか問題でも？
126:111
03/12/22 21:59
パール：記述方法が暗号的すぎ
オーク：使用目的が限定的すぎ
るび〜：モデル化が変態的すぎ
>>122
もう手にはいらんのとちゃう？
127:デフォルトの名無しさん
03/12/23 00:18
>>126
バックナンバー情報をチェックしたら
２０００年のは無いみたいだね。
だが、大学の図書館とかなら多分ある。
漏れの母校の資料室にもあった。
っていうか俺んちの図書室にもある。
公的な図書館なら申請すれば
他の図書館から取り寄せてくれたりもする。
絶望的なほどではない。
でも、そこまでするなら本屋で他の本見繕った方がいい罠。
128:デフォルトの名無しさん
03/12/23 02:32
>>124
自分もハッシュです。
256でチェインしてます。
記号の"{"ごとにハッシュ表を新たに作り、
新しいハッシュ表から古い方に向かって調べます。
グローバル用は別に1個作り、
関数を呼ぶ場合にも、全く別のセットを作ります。
(じゃないと、下部の関数から上位の変数がみえたりしちゃいますからね)
ちなみに、ハッシュを使わずに作った物は、
6万語ぐらいの定義、10万回くらいの参照、マクロ展開があるファイルのコンパイルに10分、
ハッシュを使った物は30秒ぐらいでした。
129:デフォルトの名無しさん
03/12/23 02:47
>>124
今まではハッシュだったけど、
最近、キーワードだけswitch文の羅列で分別するようにしてみた。
もちろん手書きでは大変なので、perlで簡単なプリプロセッサを書いて
そいつに展開させてる。
130:デフォルトの名無しさん
03/12/23 05:26
>>127
> 公的な図書館なら申請すれば
> 他の図書館から取り寄せてくれたりもする。
こんど近所の図書館でも聞いてみよ。
千葉県だけど取り寄せてもらえるかな、、、
131:>>124
03/12/23 15:53
単純にflexじゃあかんの？
132:デフォルトの名無しさん
03/12/23 17:07
Cコンパイラのソースで読みやすいの教えろ
133:46
03/12/23 17:14
Kさん 好循環 Aさん 悪循環
（健康体） （喘息）
1.（神が喘息であるかないかを決める）
2.K 喘息でない人 A 喘息の人は
は体力がある 体力がなくなる
3.K A 行動力、
五感（嗅覚）が鈍り感性が変化する
4.K&P 神は異常な感性の人間は本来人に迷惑をかけ
るから外に出てはいけないと思っている。
5.K 変化なし A アトピーになる
6.K 正常な感性 A 外に出なくなりさらに異常な感性になる
7.K 正常な人間 A 異常な人間（レッテル）
134:46
03/12/23 17:14
8.K&A 死
9.K&A 来世
10.K&A 神は異常な人間は人に迷惑をかけるので行動
を抑制する必要があると思っている。
11.K&A 神が喘息であるかないかを決める
12.K 喘息でない A 喘息である
13.K&A 1.に戻る
これは事実。広めようぜ
解決法：体力をつけると感覚が正常に戻り、
アトピーも快癒に向かう。
目安としてグランドを10週くらい。
あとはウォーキング、なるべく長い間歩く
（ウインドーショッピングや散歩、五時間ぐらいを目安）。
無論最初は、無理なので徐々に体を慣らしていくといい
鼻に変な違和感があったり、頭がぼおっとする時の解決法。
口をつぐんだまま、口の中で空間を作る、すると口の中に空気がたまるのでそれを吐き出す。無論息が苦しくなったら、呼吸をして良い。
これを、100回くらい。
135:デフォルトの名無しさん
03/12/23 18:04
>>132
gcc
136:デフォルトの名無しさん
03/12/23 18:28
最近のスクリプト言語って、オブジェクト指向ばっかりね。
137:デフォルトの名無しさん
03/12/23 19:16
>>132
Bruce evans C Compiler (BCC) がおすすめ
16bitコード生成の最適化無しだけど、ソース分量も多くないし
再帰下降なんでyaccとかも使ってない
作者のBruce EvansはMinix386パッチ開発などで知られる
一応ELKSのコンパイルにも使用されている
138:デフォルトの名無しさん
03/12/23 21:21
えー・・・
139:デフォルトの名無しさん
03/12/23 22:18
>>137
YACC使ってるほうが、圧倒的にソース簡単なんじゃない？
なんで、勉強には不向きと思われ。
140:デフォルトの名無しさん
03/12/23 22:19
C+AWKみたなスクリプト言語ありますか？
141:デフォルトの名無しさん
03/12/23 23:07
>>140
そりゃperlでは…
142:デフォルトの名無しさん
03/12/23 23:08
☆チン マチクタヒ゛レタ〜
マチクタヒ゛レタ〜
☆ チン 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ ルビ〜ソ〜ス本はマダ〜〜〜？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣／|
|￣￣￣￣￣￣￣| |
| 愛媛みかん |／
143:デフォルトの名無しさん
03/12/23 23:14
>>141
変数に＄つけんとあかんのとちゃう？
144:デフォルトの名無しさん
03/12/24 14:21
>>143
それが?
145:デフォルトの名無しさん
03/12/24 14:44
Appel本の java 版のソースは ML の移植と聞いたのですが、実際にそうなのですか?
読んだ方の意見を聞いてみたのですが。
146:デフォルトの名無しさん
03/12/25 01:11
コンパイラって、入出力なんかのハードウェアに近いレイヤとか、FFI 等で自分の環境外に
アクセスする部分ってどうなってるのかしらん。インタープリタだと外のライブラリ使えば
良さそうなんだけど。
147:デフォルトの名無しさん
03/12/25 01:21
>>146
出力したオブジェクトにAPI呼ぶライブラリをリンクする。
あるいはAPIを呼ぶコードを吐く。
別に疑問なところはないとおもいますが。
148:デフォルトの名無しさん
03/12/25 01:37
>>147
レスどうもありがとうございます。
冬休みになったらコンパイラの勉強をしたいなと思ってるのですが、イマイチ基本的な
事から分かっていないのでダメですね。リンカーの本を読めばこの辺も理解出来るの
かなぁ。
149:デフォルトの名無しさん
03/12/25 01:57
>>132
C/C++インタプリター cii
URLﾘﾝｸ(village.infoweb.ne.jp)
150:デフォルトの名無しさん
03/12/25 02:34
知合いの方はAppel本のJava版はJavaじゃない，とまでおっしゃってました．MLからのひどい直訳で，Javaとしては(コンパイルの通らない)誤りも多々あるとか？私は実際どうなのかが分かる人間ではありませんが．
151:デフォルトの名無しさん
03/12/25 07:12
>>150
C は Java のひどい移植で、、、と書評で書いてあったのだけど、 ML を Java に移した時点で
すでに糞コードなんですか？
ML で勉強するのはちょっときついなぁ、、、
152:デフォルトの名無しさん
03/12/25 17:54
つーかサンプルコードなんてどうでもいいだろ。
個人的には、読みやすい疑似コードならあっても損ではないが。
153:デフォルトの名無しさん
03/12/25 18:56
>>144
つまり、c&awkとは、ぜんぜん違うということ。
154:デフォルトの名無しさん
03/12/25 19:11
>>153
きみは walk でも使ってなさい。
URLﾘﾝｸ(www-2.cs.cmu.edu)
155:デフォルトの名無しさん
03/12/25 23:59
Windowsで使えるyaccやlex、texはありませんか？
156:デフォルトの名無しさん
03/12/26 00:03
texは知らんがyacc/lexはcygwinのが使えるんでねえの？
157:デフォルトの名無しさん
03/12/26 08:09
>>154
それって、AWKと同じ？
158:デフォルトの名無しさん
03/12/26 10:43
>>156
cygwinのyacc/lexが吐き出すCをVC++が食べてくれないことを>>155は恐れている。
159:デフォルトの名無しさん
03/12/26 14:33
>>155
gnuwin32
160:デフォルトの名無しさん
03/12/26 19:11
>>155
上で>>156や>>159が言ってる他にも、yacc互換ツールにkmyaccってのがある。
Rubyのコンパイルにkmyaccを使うと実行ファイルが少し小さくなっていい感じ。
>>156
Texも余裕でいろんなバージョンがごろごろしてるよ。
161:デフォルトの名無しさん
03/12/26 20:11
Rubyの実行ファイルが少し小さくなったら何かいいことあるんですか？
162:デフォルトの名無しさん
03/12/26 21:04
>>161
大きくなるよりいい。
163:デフォルトの名無しさん
03/12/27 01:14
レベル低いねえ、ここ
処理系開発に携わった者としては、見ていて恥ずかしいよ
164:デフォルトの名無しさん
03/12/27 02:23
まともなプロは、他のプロの半端な仕事をバカにすることはあっても、
素人をバカにすることはない。
素人をバカにするのは、プロ気取りの汚らしいチンピラである。
165:デフォルトの名無しさん
03/12/27 03:07
もう冬休みか．．．
166:デフォルトの名無しさん
03/12/27 04:49
失業者かもよ。「携わった」と、過去形で書いているし。
167:デフォルトの名無しさん
03/12/27 06:50
漏れの記憶では確かVCはbison/flexが吐き出すCは食べてくれるがbison++が吐き出すC++は食べられなかったような
168:デフォルトの名無しさん
03/12/27 11:56
flex入門（ASCII）には、
”スキャナがあるテキストにマッチするために「逆行」しなければならない
ことを、バックトラッキングといいます。”
とあるのですが、ここでいう「逆行」とは具体的にはどういった状態を指す
のでしょうか？
169:デフォルトの名無しさん
03/12/27 12:36
一度見たトコをもう一度見る。
170:デフォルトの名無しさん
03/12/28 11:31
コード例から自動で言語処理系作れないかな？
171:デフォルトの名無しさん
03/12/28 11:43
>>170
ディスプレイに映るコードを眺めながら、博士はコーヒーを飲んでいた。
彼のお気に入りの陶器から口を離して、>>170の質問に答える。
「もし君が全てのトークンの機能と連鎖可能性を記述するのなら、もちろん可能だろう。」
博士は私のほうを向いて続けた。
「しかし、それはlexとyaccを使い実装と正規表現を記述するのと、どう違うのかね？」
172:デフォルトの名無しさん
03/12/28 12:07
関数の合成とオプティマイズまでを実装した処理系ってなんか無いですか？
もちろんソース公開されてる奴で。
たとえば、文字コード変換機とか、音声ファイルのコンバータなど
入力と出力パターンがそれぞれ複数あるとき、
すべてのパターンのコードを記述するのはむだなので
中間形式にいったん変換してから再変換をかけることになると思うのですが
関数合成で一度にできるようにならないかと。
173:170
03/12/28 13:03
>>171
妙に納得させられてしまいました。
不完全な記述でもある程度の結果が得られて
(現存する記述と意味の関係から自動推測して処理系を構築するとか？)、
さらに進展性が望めるシステムもあったらどうなるのかちょっと興味があったのです...
>「しかし、それはlexとyaccを使い実装と正規表現を記述するのと、どう違うのかね？」
自分はlex(flex),yacc(bison)を全然使いこなせてないんで
そんなのがあったら楽ができそうだなと思った次第です。(スイマセン)
174:デフォルトの名無しさん
03/12/28 15:05
>>170
例えば、
main {
print "Hello World!"
}
ってのから言語処理系を作れないかということですよね？
でも、それって、XMLのデータだけ見て意味づけしろ、というのと同じで、
意味情報が含まれていないから出来ないのでは？
175:デフォルトの名無しさん
03/12/28 15:10
>>140
私はそのまま awk を使ってます.
仕事柄 C/C++ とその他のスクリプト言語の使用比率が 9:1 くらいなので,
他の言語がなかなか覚えられなくて. C に似てて仕様的にも単純なものってことで
awk 使ってますが, awk 使うくらいならそのまま C でいいんじゃないかと最近思いました ...
関係ない独り言ですみません.
176:デフォルトの名無しさん
03/12/28 18:52
>>172
inlining？
177:デフォルトの名無しさん
03/12/28 18:54
あ
178:デフォルトの名無しさん
03/12/28 19:14
>>176
いや、静的ではなく動的に。
179:デフォルトの名無しさん
03/12/28 19:43
>>175
AWKってフィルタ指向が強すぎますよねぇ？
それさえなければ、最強なんだけど...
180:デフォルトの名無しさん
03/12/29 01:04
ゲームで使用するためのスクリプト言語を解説した
洋書を知りませんか？
Game Scripting 何とか
という名前だったような・・・
181:デフォルトの名無しさん
03/12/29 01:34
>>180
URLﾘﾝｸ(www.amazon.com)
漏れも前にちょっと買ってみようかと思った。
amazon.co.jpだと在庫切れ。
182:デフォルトの名無しさん
03/12/29 08:32
>>181
こんなのあったんだ。
GameProgrammingWith PYTHON, LUA, AND RUBYより、
そっちにスベキダッタ・・・
183:デフォルトの名無しさん
03/12/29 08:42
ﾜﾘｲ ゲ製作板と間違えた
184:デフォルトの名無しさん
03/12/30 19:39
bison は、記述ファイルから、その生成パーサの動作を正しく把握するのがつかれる。
というか、ほとんど無理？
185:デフォルトの名無しさん
03/12/30 19:59
>>184
把握する必要無いし。
186:デフォルトの名無しさん
03/12/31 01:19
でも、把握せんと動作がつかめんでしょ？
187:デフォルトの名無しさん
03/12/31 01:33
>>184
もしかして、シフト／還元のこと？
188:デフォルトの名無しさん
03/12/31 02:36
>>186
把握しても動作つかめんから心配するな。
再帰上昇型のパーサーは、慣れた人間にとっても予期せぬ動作をすることが
ままある。手っ取り早くすませたいなら yacc を使って、そうではなくエラー処理
などキッチリやりたければ、手で再帰下降型のパーサ書いた方が良いよ。
189:デフォルトの名無しさん
03/12/31 06:50
パーサーのテストどうやるの？
190:デフォルトの名無しさん
03/12/31 11:32
>>189
パースしてみる
191:デフォルトの名無しさん
03/12/31 16:16
>>188
(再帰上昇型/再帰下降型って何ですか?)
bison は再帰上昇型でいいのですか？
192:デフォルトの名無しさん
03/12/31 16:17
>>188
(再帰上昇型/再帰下降型って何ですか?)
bison は再帰上昇型でいいのですか？
193:デフォルトの名無しさん
03/12/31 18:19
>>191
ぐぐれ。キーワードはこんな感じで。
構文解析 上昇 下降
194:デフォルトの名無しさん
03/12/31 19:45
>>193
keywordありがとう！
195:デフォルトの名無しさん
03/12/31 22:41
>>188
> 再帰上昇型のパーサーは、慣れた人間にとっても予期せぬ動作をすることが
> ままある。
これって、本当ですか？
196:デフォルトの名無しさん
03/12/31 22:51
>>195
実装がへぼいか、定義がへぼいときは、本当です。
197:デフォルトの名無しさん
03/12/31 23:15
>>195
本当。
正常なトークン列を与えたときの動作は予期どおりになるが、異常なトークン列を
与えたときの振る舞いは直感に反することがままある。頑強なエラー・回復処理を
実装したい場合、たとえば
HTML パーサのように、厳密に規格に従ってなくとも受け付けたい
エラー時にそれなりに適切なエラーメッセージを出したい
なんつーばあいには、再帰上昇型は人間の手に余る。
198:デフォルトの名無しさん
04/01/01 01:17
>>197
ミジカな例まで出してくれてありがとう！
上昇型は、厳密な言語むきってことですかね？
メリットは、記述が少ないことぐらいですか？
199:デフォルトの名無しさん
04/01/01 03:34
ところで、ふつうのyaccが生成するパーサは再帰上昇型ではないと思うのだが。
(陽にスタックを持ち、表を引いてgotoしまくるだけで、再帰呼びだしはしない)
最近のbisonは再帰上昇型のコードも生成できるの？
200:デフォルトの名無しさん
04/01/01 05:02
URLﾘﾝｸ(www.futamura.info.waseda.ac.jp)
futamura projection の二村さんのサイト見つけた。
201:デフォルトの名無しさん
04/01/01 20:54
どうみてもbisonは再帰的だが
202:デフォルトの名無しさん
04/01/01 21:43
>>199
再帰呼び出しと再帰的文法解析を混同してないか？
再帰するためにスタック用意してるんでは？
203:デフォルトの名無しさん
04/01/01 23:39
>>202
英語でrecursive descent parserといえば、LL文法に基いて、いくつかの相互
に呼出しあう関数群で記述された構文解析器のことを指す。
これと同様、recursive ascent parserというのは、LR文法に基いて、明示的
な状態スタックを持たず、相互に呼出しあう関数群で構成されている構文解析
器のこと。yaccやbisonが作るパーサーは、明示的なスタックを持つ表駆動オー
トマトンなので、recursive ascent parserではない。(両者は言語を認識する
能力は同じだが、細かい記述能力の点で違いがある)
recursive ascent parser については僕も勉強中なのであまり突っ込まれると
困るが、comp.compilersの過去ログ↓に良いreferenceがあるのでそちらを参
照してください。
URLﾘﾝｸ(compilers.iecc.com)
URLﾘﾝｸ(compilers.iecc.com)
204:デフォルトの名無しさん
04/01/02 01:19
>>203
そう呼ぶ「流儀もある」というだけの話。
コンパイラ理論に限らず、専門用語は人によって解釈に幅があるのが普通だから、
適当に補って読み書きしとくのが吉だ。
205:デフォルトの名無しさん
04/01/02 13:02
>>203
そういえば思い当たる用語がいくつかある。
素数に１を含めている場合があって、教授の中の人に
「素数の定義のなかに『１以外の』ってあるんですけど」
って聞いたら
「小中高ではそのように教えているようだが学会によって違うし、
必要なら論文の冒頭で定義する。」って言ってた。
それと、以前知り合いに聞いたんだが、
そいつの学科では「逆ポーランド記法」
を「ポーランド記法」って呼んでて、
どうしても明確に区別する必要があるときだけ
前置・後置で分けてるんだそうな。
と、言うわけで構文解析に関する学会もいろいろあるだろうし
それぞれで違う定義だったり定義されてなかったりするの
かも知れない。
206:デフォルトの名無しさん
04/01/02 15:56
>>205
それは案外あるね。
ここのコンパイラ＆スクリプトだけでなく、全ての千問分野で
そういった傾向があるみたい。
なので、書籍とかでは著者がどういう定義でその用語を使っているかを
把握したうえで理解しないと混乱する時がたまにある。
207:デフォルトの名無しさん
04/01/02 16:23
言い訳にだまされてるだけ
208:デフォルトの名無しさん
04/01/02 16:54
アフォか素人
209:203
04/01/02 20:39
>>204
yaccの生成するパーサを「再帰上昇型」と呼んでいる教科書や文献があったら
教えて欲しいのだが。
僕は見たことがない。googleで検索しても見つからない。
210:デフォルトの名無しさん
04/01/02 20:46
しるか！
211:デフォルトの名無しさん
04/01/02 21:52
海外掲示板用オフラインリーダーを作るスレ
ｽﾚﾘﾝｸ(tech板)
海外でよく使われていうる掲示板スクリプト
専用のオフラインリーダー作って下さい。
必要な条件はID、PASSを管理できること、
OpenJaneみたいな三面型の見た目。
簡単にローカライズできるように言語ファイルを採用
212:デフォルトの名無しさん
04/01/02 23:55
アフォ
213:デフォルトの名無しさん
04/01/03 00:16
VBSの解析ソースください。
214:デフォルトの名無しさん
04/01/03 01:37
すいません、ちょっとお尋ねしたいんですが、
UNIX Programing Environment に出てくる「電卓hoc（最終形態）」が
行っている処理アプローチは、今のスクリプト言語にも十分通用するも
のでしょうか？
それとも、今となっては時代遅れのものでしょうか？
ここにおられる皆さんは、どう感じられますか？
215:デフォルトの名無しさん
04/01/03 01:52
URLﾘﾝｸ(www.cs.bell-labs.com)
ここにあるやつ?
216:デフォルトの名無しさん
04/01/03 05:15
>>214
時代遅れだと考えるくらい知識や経験があるならやらなくていい。
そうじゃなければ、やっても無駄にはならない。
217:214
04/01/03 10:58
>>215
そうです。（こんなページも有ったんですね。知りませんでした。）
218:デフォルトの名無しさん
04/01/03 23:03
URLﾘﾝｸ(www.okisoft.co.jp)
URLﾘﾝｸ(www.okisoft.co.jp)
URLﾘﾝｸ(www.okisoft.co.jp)
URLﾘﾝｸ(www.okisoft.co.jp)
『やさしい Lisp の作り方』と『やさしい Java インタプリタ の作り方』見つけた。
Java と C# で実装。
219:デフォルトの名無しさん
04/01/04 08:39
>>218
GOD
220:デフォルトの名無しさん
04/01/04 14:04
URLﾘﾝｸ(www.google.co.jp)タグビット
URLﾘﾝｸ(www.google.co.jp)タグ付きポインタ
URLﾘﾝｸ(www.google.co.jp)
221:デフォルトの名無しさん
04/01/04 16:56
スクリプト言語を設計・実装する場合の一番の難しさって何でしょうね？
222:デフォルトの名無しさん
04/01/04 17:09
>>221
妥協すること。
汎用的だが回りくどい書き方と、特定用途専門で簡単な書き方。
実行時の速度効率と、柔軟性。
メモリ使用効率とスピード。
いろいろいろいろ相反する要素が出てくるので、目標を明確にしておかないと
あれもこれも盛り込んだ挙句に、中途半端で使いにくいスクリプトになりがち。
223:デフォルトの名無しさん
04/01/04 23:29
>>222
思いもよらない視点にビクリ！
あんた、プロ？
224:デフォルトの名無しさん
04/01/06 18:37
>218
LISP処理系作るのは簡単だけど、
Schemeの末尾再帰や継続呼び出しを載せようとすると、
とたんに難しくなるよね。
末尾再帰だけならまだ楽か。
225:デフォルトの名無しさん
04/01/06 18:52
末尾再起も継続も簡単
大変なのはクロージャや継続の実装に必要な
環境の複製の効率化。
226:デフォルトの名無しさん
04/01/06 19:01
まぁ、LISPと言ってる時点で（ry
227:デフォルトの名無しさん
04/01/06 21:27
>大変なのはクロージャや継続の実装に必要な
>環境の複製の効率化。
これって Scheme に限らない問題だと思うんだけど（lexical closure を持っている
言語は沢山あるよね）、これに関して日本語のまとまったドキュメントってあまり
無いね（知らないだけ?）。
知ってるのはこことか。
URLﾘﾝｸ(www.shiro.dreamhost.com)
228:デフォルトの名無しさん
04/01/06 22:09
LISPで有効に実用化されているプロジェクトってあるのｗ
229:デフォルトの名無しさん
04/01/06 22:12
アーロン
230:デフォルトの名無しさん
04/01/06 22:21
>>228
Lisp そのものじゃないが、Lisp に極めて近い文法のファイルでデータを保存する
CAD ソフトは見た事あるな。確かに、書くの楽そうだ。
231:デフォルトの名無しさん
04/01/06 22:27
何かちょっと調べてみると、Pure な OO って意味があるのか疑問に感じてきた。
Java みたいにプリミティブを用意した方が効率良さそう。Hybrid 言語マンセー！
232:デフォルトの名無しさん
04/01/07 20:27
アホーン
233:デフォルトの名無しさん
04/01/08 09:13
なるほど、これが冬か。
234:デフォルトの名無しさん
04/01/11 15:46
URLﾘﾝｸ(merd.net)
URLﾘﾝｸ(rwiki.jin.gr.jp)
%a5%c8%b8%c0%b8%ec%a4%ce%c8%e6%b3%d3
色んな言語の構文の比較。
考えやすく、書きやすく、なおかつ読みやすいシンタックスって何だろう。
Haskell はちょっと良い感じ。
235:デフォルトの名無しさん
04/01/11 18:36
Windows上で使えるlexを教えてください。
よろしく
236:デフォルトの名無しさん
04/01/11 18:39
少しは調べる努力をしろ。
以上
237:235
04/01/11 18:42
>>236
調べたけど見つからなかった。
よろしく、
238:デフォルトの名無しさん
04/01/11 18:44
flex.
239:235
04/01/11 18:46
>>238
ありがとう
お礼にパトレイバーのプロトタイプをのせとく
URLﾘﾝｸ(www.enryu.jp)
240:デフォルトの名無しさん
04/01/11 21:43
夢のプログラミング言語＠いちごびびえす
URLﾘﾝｸ(www.ichigobbs.net)
241:デフォルトの名無しさん
04/01/11 22:53
>>240
プログラミング言語は満載した機能を特色の第一とするものではない。
あとになって機能の追加が必要と判明するような弱点と制限を取り除いて設計すべきである。
242:デフォルトの名無しさん
04/01/12 00:19
>proglam
頭の程度が知れたな
243:デフォルトの名無しさん
04/01/12 02:01
上の方にあった（↑）「UNIXプログラミング環境」に掲載されていた関数
電卓ｈｏｃですが。
ちょっとしたフロー制御や、ユーザー関数定義等ができることを考えると、
ほぼ、スクリプト言語のコアが出来上がっているとも考えられますが、い
かがでしょうか？
244:デフォルトの名無しさん
04/01/12 02:28
>>241
激しく同意。どうもC++系に知識が偏ってるぞ>>240のリンク先の>>1は。
とりあえず本当にSchemeぐらい齧って欲しいな。
245:デフォルトの名無しさん
04/01/12 03:10
>>244
lisp知りたてのおばかさんですか？
継続とかコードとデータの同一視とか、その辺の動的な事情が適合しない分野もあるだろうに。
lisp的な考え方は切り捨てるべきときがあることも勉強しときなさいな。
246:デフォルトの名無しさん
04/01/12 03:20
>>245 は Lisp を叩くと偉いとでも思っているのかな?
それとも継続って言ってみたかっただけか?
気持ちは分かるけど、スレの流れからしてそのレスは不自然。
247:デフォルトの名無しさん
04/01/12 03:24
元が夢・独り言板なんだから、
そこの>>1にとっての「夢のプログラミング言語」でしょ、ほっといてやれ。
まあ、C#++くらいの雰囲気になっているのは確かだけど。
248:デフォルトの名無しさん
04/01/12 03:25
継続って言ってみたかったってのはあるかもな。
ただlispといわずにあえてschemeというからには、継続しか要因がないだろうからな。
まあ、実るとは思ってないけど何かやろうとしている人を
頭ごなしに否定するレスってのはどうよって思うわけだ
249:!244
04/01/12 03:32
>>248
出典出さなくて申し訳ない。まずは下の「はじめに」を読んで欲しい。
そしたら何で >>244 が Scheme って書いたのかが分かると思う。
URLﾘﾝｸ(www.sci.toyama-u.ac.jp)
あと、何にせよコンパイラ作るのに Lisp は知っていた方が良いでしょ。
250:デフォルトの名無しさん
04/01/12 03:37
継続しか、ってことはないだろうに
251:デフォルトの名無しさん
04/01/12 03:41
schemeにはあってcommon lispには無いものって細かいことを除けば
継続と末尾再起の展開の規定くらいなものだろ
252:デフォルトの名無しさん
04/01/12 03:48
なんか増えてるな
調べるともっと増えるんだろうな
253:デフォルトの名無しさん
04/01/12 04:00
増えてるって末尾再起の展開か？
こんなもん実装詳細に分類されるものであって、
言語仕様の議論でいちいち取り上げるほどのものでもないだろ。
gccですら実現できてることだしな。
254:デフォルトの名無しさん
04/01/12 04:02
lispとschemeのコード読んで違いを認識してから出直して来い
255:デフォルトの名無しさん
04/01/12 04:12
>>251
> schemeにはあってcommon lispには無いものって細かいことを除けば
> 継続と末尾再起の展開の規定くらいなものだろ
おいおい、>>244たんの言いたいことが全然わかってないね。
言語設計の肝は機能の数ではなく、組み合わせによって
いかにシンプルかつ豊かな表現力をつけるか、ってことなんだよ。
256:デフォルトの名無しさん
04/01/12 04:14
>>251
一番大きいのは言語のポリシーの違い。
257:デフォルトの名無しさん
04/01/12 06:24
URLﾘﾝｸ(cs1.cs.nyu.edu)
URLﾘﾝｸ(www.cminusminus.org)
MLRISC とか C-- とかって誰か使っているのかな。
258:デフォルトの名無しさん
04/01/12 07:55
>>241 の出典も知らないで「同意」とかほざいてる >>244 が Scheme をま
ともに知っているとは考えられない。
259:デフォルトの名無しさん
04/01/12 08:49
そうは読めないけど。
260:デフォルトの名無しさん
04/01/12 08:50
>>253
> 増えてるって末尾再起の展開か？
> こんなもん実装詳細に分類されるものであって、
苦笑・・・
261:デフォルトの名無しさん
04/01/12 08:52
>>258
> >>241 の出典も知らないで「同意」とかほざいてる >>244 が
どうやって241の脳内を覗いたんだ？
262:デフォルトの名無しさん
04/01/12 09:45
Javaベースのコンパイラコンパイラ
SableCC
URLﾘﾝｸ(www.sablecc.org)
CUP & JLEX or CUP & JFlex
CUP URLﾘﾝｸ(www.cs.princeton.edu)
JLEX URLﾘﾝｸ(www.cs.princeton.edu)
JFlex URLﾘﾝｸ(www.jflex.de)
ANTLR
URLﾘﾝｸ(www.antlr.org)
JavaCC以外にもいろいろあるんすね
JavaCCはLL(k)だけど、上のはANTLR以外はLALR(1)
でもANTLRはC++なんかにも対応。
どれがつかいやすいのか。
Sableちょとみたところよさげだなと。
263:262
04/01/12 09:49
しつれー
上のSableCC URLつながってにゃい。
こっちからいけやす。
URLﾘﾝｸ(www.sablecc.org)
264:デフォルトの名無しさん
04/01/12 09:49
おまえら、おちけつ
265:デフォルトの名無しさん
04/01/12 09:57
>>240
＞もし取り込むとしたら表記法は
＞Pointer<PointeeType>
＞Reference<ReferredType>
禿しく胴衣！
だれか>>240言語実装してくれ俺には力不足だ。
266:デフォルトの名無しさん
04/01/12 11:01
>>262
¬＜＞＜∪∪ URLﾘﾝｸ(ne.cs.uec.ac.jp)
LALR(1)
も追加しておいて。
267:244
04/01/12 12:39
>>258
ん？ 流れの読めん不思議な断定はよしてくれ。
>>241の元ネタを知らずにどうやってSchemeを挙げられるっていうんだ。
偶然にしちゃできすぎだっつの。
……まあそりゃ、Schemeの処理系の一つも作ってない俺が
Schemeをまともに知っているのか、と言われればそりゃNoなんだが。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4960日前に更新/226 KB
担当:undef