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

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

■過去スレ
1 http://pc.2ch.net/tech/kako/981/981672957.html
2 http://pc2.2ch.net/test/read.cgi/tech/1021136715/
3 http://pc5.2ch.net/test/read.cgi/tech/1070089173/
4 http://pc5.2ch.net/test/read.cgi/tech/1100097050/
5 http://pc8.2ch.net/test/read.cgi/tech/1106129164/
6 http://pc8.2ch.net/test/read.cgi/tech/1115335709/
7 http://pc8.2ch.net/test/read.cgi/tech/1129287390/
8 http://pc8.2ch.net/test/read.cgi/tech/1131273918/
9 http://pc8.2ch.net/test/read.cgi/tech/1135082582/
10 http://pc8.2ch.net/test/read.cgi/tech/1146844753/
11 http://pc11.2ch.net/test/read.cgi/tech/1160879890/
12 http://pc11.2ch.net/test/read.cgi/tech/1188688416/
13 http://pc12.2ch.net/test/read.cgi/tech/1233143342/
14 http://hibari.2ch.net/test/read.cgi/tech/1258431145/

Wikiのまとめページ
http://www6.atwiki.jp/compilerandscriptengine/

★コンパイラ一般

・色々なツールの紹介
　http://catalog.compilertools.net/
・コンパイラ関連のリンク集
　http://www.ulis.ac.jp/~nakai/rel_web_compilers.shtml
・スクリプティング言語資料室(仮) (リンク集)
　http://www.kt.rim.or.jp/~kbk/
・Compiler Construction
　http://www.ie.u-ryukyu.ac.jp/~kono/lecture/compiler/
・情報システム工学実験 III コンパイラ・コンパイラ
　http://math.cs.kitami-it.ac.jp/~fuchino/proin/experimentIII-2000/jikken.html
・OS/Programming 簡単な C コンパイラ
　http://www.csg.is.titech.ac.jp/~chiba/lecture/os/
・正規表現
　http://hp.vector.co.jp/authors/VA007799/viviProg/doc_regexp.htm
・コンパイラ研究・開発情報の一集積所
　http://compilers.cs.uec.ac.jp/
・Links and Selected Readings
　http://www.gnu.org/software/gcc/readings.html
・国産のコンパイラ共通インフラストラクチャCOINS
　http://www.coins-project.org/

★字句・構文解析

・Lex and YACC primer/HOWTO （邦訳）
　ttp://www.linux.or.jp/JF/JFdocs/Lex-YACC-HOWTO.html
・Turbo Pascal Lex/Yacc
　http://www.musikwissenschaft.uni-mainz.de/~ag/tply/tply.html
・Jim Roskind's LALR(1) C++ Grammar
　ttp://www.empathy.com/pccts/roskind.html
・Flexと Bisonを同時に使う
　http://guppy.eng.kagawa-u.ac.jp/2005/SysProg/both.html
・KITE_ASM (yacc,lex)
　http://www.arch.cs.kumamoto-u.ac.jp/project/kite/kiteasm/
・bison用のC++ LALR skeleton
　ttp://www.bj-ig.de/software/bison/
・ANTLR（非yaccのパーサジェネレータ）
　ttp://www.antlr.org/
・JavaCC(Java Compiler Compiler)
　ttps://javacc.dev.java.net/
　ttp://village.infoweb.ne.jp/~fwif0083/program/java/javacc/javaccgrm.html
　ttp://www.asahi-net.or.jp/~DP8T-ASM/java/tips/JavaCCHelloWorld.html
・CUP, JLex, JFlex
　http://www.cs.princeton.edu/~appel/modern/java/ (JLex, CUP)
　ttp://www.jflex.de/
・SableCC
　ttp://www.sablecc.org/
・¬＜＞＜∪∪ （notavacc）LALR(1)
　http://ne.cs.uec.ac.jp/~koto/notavacc/
・boost::spirit（C++のテンプレートでEBNFの構文を模倣）
　http://spirit.sourceforge.net/
　ttp://boost.cppll.jp/HEAD/libs/spirit/index.html（マニュアル日本語化プロジェクト）
　ttp://www.fides.dti.ne.jp/~oka-t/cpplab-boost-spirit.html

★ごみ集め

・GC FAQ -- draft
　http://www.iecc.com/gclist/GC-faq.html
・A garbage collector for C and C++
　http://www.hpl.hp.com/personal/Hans_Boehm/gc/
・一般教養としての Garbage Collection
　http://www.is.s.u-tokyo.ac.jp/vu/jugyo/processor/process/soft/compilerresume/gc/gc.html
・Garbage Collection : Algorithms for Automatic Dynamic Memory Management
　http://www.amazon.com/exec/obidos/ASIN/0471941484/

★処理系,スクリプト

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

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

★参考書籍

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

・最新コンパイラ構成技法（Modern Compile Implementation in ML（タイガーブック）の訳）
　http://www.amazon.co.jp/dp/4798114685

・ふつうのコンパイラをつくろう
　http://www.amazon.co.jp/dp/4797337958

・プログラミング言語を作る
　http://www.amazon.co.jp/dp/4774138959

・やさしいインタープリタの作り方入門
・やさしいコンパイラの作り方入門
　http://www.amazon.co.jp/dp/487783219X
　http://www.amazon.co.jp/dp/4877832203

>>1
スレ立て乙

前スレ終盤で「漢字嫁ねカタカナ表記の方が分かり易くね？」というカキコに対して賛否あった。
で、手元に「翻訳系構成法序論」という1982年刊行の古い本があるけど、
題名で分かるように(w)徹底的に漢字を使う。この本から「さ行」の一部を引用してみる。

元の英単語は、このスレに興味を持つようなヤシなら誰でも知っているものばかり。
お前ら、対応する英単語を即答できるか？(カナでも可とする)

・算体
・算帖
・算程
・算譜
・算法

>>4
>・『やさしい Lisp の作り方』『やさしい Java インタプリタ の作り方』
>　http://www.okisoft.co.jp/esc/go.html

URL が変更になっていました。

http://www.oki-osk.jp/esc/go.html

タイガーブックは硬い訳で、言い回しが多少くどい
すらすら読めるところもあるんだけどたまに引っかかって、文意を解くのに疲れる
いい本だとは思うけどね

・算体 データ？
・算譜 プログラム
・算法 アルゴリズム

残りはわからん。

算体　object
算帖　file
算程　process
算譜　program
算法　algorithm

Holub氏のCompiler Design in Cと言う本を持ってる人いませんか？

譲り受けた物が手元にあるのですが、最後にピンク色の破線で切り離せるっぽい頁があったみたいなのですが、切り離されていました。
これが何だったのか気になりましてw

>>12
素晴らしい。全問正解だ。

>>11
それが(自分を含めて)普通の感覚だと思うよ。

ちなみにこの本では、前スレで誰かが言ってた初出の箇所は「漢字(英単語)」という表記で、
しかも巻末にまとめとして対訳表があるから、漢字だらけでも苦痛に感じられなかった。

BNFとか全然わかんね

力押しでゴリゴリ動かしてるぜー

BNF は読み書きできるようになった方がいい

構文解析分野共通の言語あるいは図解フォーマットみたいなものだから

>>16
BNFとか見てるとなんでlexとyaccに分解されちゃうのか時々わかんなくなる（自己記述可能な言語でパーサ書いたあととか特に）

中間言語経由した方が便利だからじゃね？

当時のハード・ソフトでは字句解析と構文解析を分けないと、時間のかかるεNFAからDFAの変換が
どうしようもなく時間がかかるようになるからでない

片方だけ利用って局面が稀にあるから独立してないと困るな
ツール的にはむしろyacc(bison)は更に２つに分かれてた方が助かる
状態と遷移表の抽出結果を入力として、表圧縮とソース成形の機能だけ利用したい時があるんだよね

入力内の遷移表にshift/goto/reduce以外の独自操作を定義追記出来る形ならなお良い

>>15
BNFが使えるようになれば、言語処理系以外の
一般的なデータ構造の記述(定義)にも応用がきくから、慣れた方がいいと思う。

BNFが難しければ、最初は構文図(Syntax Diagram)でスケッチして、
それをBNFに書き換えるという練習をするのがいいと思われ。

構文図については、たとえば http://www.json.org を参照。
他にもググるといくつも例が見つかるから、自分で調べてね。

>>17
言語定義の規模が大きくなるから機能分割しているのではないかと。
より一般的な言い方をすれば、字句解析(下位層)と構文解析(上位層)への階層化。
階層化によって、>>19が指摘した効率化(処理の高速化)という利点も生まれる。

実用的な言語レベルの規模になると、lex/yaccのようなパーサジェネレータを使わずに
実装された例としては、自分の知る限りSmalltalkしかない。(Lisp/Prolog系は別格なので除く)
しかもSmalltalkの構文は二項演算子に優先度が無い等、かなり簡素な定義になっている。

また、自己記述可能な言語としては、自分はPrologのDCG(Definite Clause Grammer)を
使うことが多いけど、定義言語の規模が小さくても意識的にscannerとparserに分割して書いているよ。

スキャナがパーサの状態に依存する言語は多いけどな

>>22
gccは手書きだよ

>>23
Rubyとかは、その典型例だね。
Rubyは人に優しい言語だから自分は大好きだけど、中の人にはなりたくないw

>>24
えええっ！、そうなんだ。知らんかったよ。

ていうか今時の言語だとたいがいパーサは手書きでしょ

ここはポコポコオレ様言語を作るスレだろ。

>>24
よく知らんのだけど、
パーサジェネレータの吐いたコードを下敷きにしてるとかじゃなかったっけ？
エラーメッセージの丁寧さがうんたらかんたら

エラーメッセージじゃなくて、エラーハンドリングが丁寧ね。
構文エラーでも、コンパイル続けたいし。

字句解析/構文解析分割については、
字句解析ないと、BNFレベルで字句解析もやることになるから、
予約語や数値リテラルの解析なんかも全部BNFに入ってくる。
嬉しいことなんてないと思うが。

そこで PEG ですよ

>>22
FORTRANとCOBOLに火炎瓶投げられても知らんぞw

俺、A=aAa|aに相当するPEG(若干違った鴨)が2^(n-1)個のaを表すってのを知ってPEGがわからなくなった
ぐぐったらちょうどこの文法がPackrat Parserで受理出来ないって英語版Wikiにかいてあるね

書籍「コンパイラの構成と最適化」 で分からないところがあったので質問させてください。

13.4 SSA形式での最適化のアルゴリズム　の　13.4.6 定数伝播　内の、
b. 条件文を考慮したアルゴリズム　の部分です（第2版ではp.367）。

図13.41 の定数伝播の例(その1)(c) にて、
　k3 = φ(k2,k1);
の行を処理した結果が 未→0 となっていますが、この理由が分かりません。
この時点で
　k1→1
　k2→0
なので、表13.1 により、不定(c≠c') になるのではないでしょうか。

>>22
lispのリーダーマクロみたいな仕組みで別言語に化けられる奴とかってないかな？

Scheme実装であるPLT Schemeが発展したracketに
言語開発フレームワークがある。

Algol 60の例
http://docs.racket-lang.org/algol60/index.html

LR(1)において、規則左辺と右辺と先読み記号の組 A->αβγ..., aにおいて、先読み記号はどのように決定されるのですか？

AのFollow-setでいいんじゃない

ありがとうございます。

すみません。なんだか37も日本語おかしいですね。死にます。

L -> E

E -> a
E -> a b

のとき、first(E) in follow(L)なのでしょうか？
Eはepsilonを生成しないのでfollow(L) = phiだと思うのですが...

ドラゴンブックによる解説だと
(1) A -> alpha B betaの時
　　follow(B) := first(beta)∪follow(B)＼epsilon
(2) A -> alpha B betaでepsilon in first(beta)もしくは A -> alpha Bの時
　　follow(A) := follow(B)∪follow(A)＼epsilon
なのであっている気がするのですが...

すみません。言葉足らずでした。

6行目は「のとき、follow(E) in follow(L)なのでしょうか？」が正しいです。

それと、自分で組んだ実装では、follow(L)はfollow(E)を含みませんでした。
タイガーブックにある例とドラゴンブックにある例をパスしましたが、これが気になって先にすすめません。

立て続けにすみません。
生成規則の右辺に出てくる終端記号以外に関してはfollow集合は作らなくても大丈夫なんですか？

COINSのソースを読んで解決しましたので、質問を取り下げます。

ところで、LLVM の '条件文を考慮した定数伝播' って実装途中なんですかね。
肝心な部分の処理が足りてない気がします。

SECDとbf間のトランスレータってありますか？

月刊・コンパイラ。
毎号付属するモジュールを組み立てていくと、あなたオリジナルのコンパイラが完成します。
創刊号は字句解析器が付いて1200円。
ディアゴスティーニ♪

ぷよぷよ

付属のモジュールを組み立てるだけなのにオリジナルとは一体

ウリジナルニダ

旧版ドラゴンブックp296 アルゴリズム4.12の『先読みの決定』について疑問があります。
----
for K の中の各項 B -> γ.δ do begin
　J' := closure {[B -> γ.δ, #]}; // (1)
　if a を # 以外の記号として、[A -> α.Xβ, a] が J' に含まれている then
　　goto(I, X) の中の項 A -> αX.β に対して、先読み a が内部生成される;
　if [A -> α.Xβ, #] が J' に含まれている then
　　I の中の B -> γ.δ から goto(I, X) の中の A -> αX.β に先読みを伝播する;
end
----

ここで例えば拡大文法の開始部分 {[S' = .S, #]} で4.12が開始されると
その goto(I, X) の中で {[S' = S., #]} とドットの位置がひとつ右に動かされ、その状態で closure({[S' = S., #]}) と実行されるので
後半部分の closure はドットの位置が最後にあり実行される意味がなく、
それ以上伝達が起こらないと思うんですが実際のアルゴリズムはどうなんでしょうか？
自分で書いたコードでも、上記の通り伝達が S' = S. までしか起こりませんでした。

基本的にCを元に、ちょっと改造したC作ってみたいんだけど、
参考しても(パクっても)GPLに汚染されない、無料なwindows向けのCのソースってない？

>>51
http://pcc.ludd.ltu.se/building/

>>52
ありがとう。
でもmingw32(gcc)のライブラリが必要っぽいんだけど、
ライブラリだけなら、汚染されないんだっけ？

>>53
http://www.mingw.org/license

http://www.mingw.org/license

>>54
なるほど、大丈夫なんですね。
w32apiの
> If distributed as a modified package, then a copy of this notice must be included.
の部分は
> This library is distributed in the hope that it will be useful, but WITHOUT WARRANTY OF ANY KIND;
> without even the implied warranties of MERCHANTABILITY or of FITNESS FOR A PARTICULAR PURPOSE.
を通知しなさいってことでOK？

>>56
自分なら w32api: のパラグラフ全文を入れると思う

>>57
全文入れれば間違いないのは分かるけど、文章の掛かってる部分はどこなのかと…
まぁ、取り合えず、GPLにはならないことは間違いなさそうなので、
もう少し良く考えて、分からなければ、全文にします。

>>58
>文章の掛かってる部分

だから w32api: の項目全文でしょ

1. This library... の部分は免責の事しか書いていない（利用制限をしてはいけないという条項が入っていない）
2. This library... の部分だけなら、"the notice below must be included." みたいに書く筈

他人の助言を信じるにせよ信じないにせよ、Use at your own risk.

クラウドコンパイラーってないの？
手元でやるより超高速で出来そうじゃないか？

昔SourceForge.jpがやってた。

西日本も福島原発の放射能に曝される。

4/7 予測 http://up3.viploader.net/ippan/src/vlippan198234.jpg
発表はドイツ気象庁 http://www.dwd.de/

>>61
どうして止めたんだろう

ANTLRの*.gって日本語書けないの?
コメントすら日本語入れるとinternal errorとかいってくれちゃうんだけど、
何か設定なりオプションなり加えれば通るのかしら。

hosyu

BNFで検索すると２ちゃんねるとかいうわけのわからない検索結果ばかり出てくるんだけど。
２ちゃんねるってなんなの。シネよ。

バッカス-ナウアー記法で親父ギャグが飛び交ってないだけマシ

エイホは知らんが。

下降型の構文解析のエラー処理をどうしたらよいのか考えているのですが、
どうも、うまく出来ません。

できれば、エラー復帰もできるとうれしいのですが、そういう話の前に、
エラーをうまく管理できてないので、ちゃんと管理したいんです。
エラーコード表つくって、エラー発生時はエラーコードから、メッセージを取り出せば、
管理は出来そうな気はしてます。

みなさんはどのようにしてますか？

http://sky.zero.ad.jp/~zaa54437/programming/clean/CleanBook/part2/Chap5.html#sc16
が参考になると思う。オリジナルは、
http://wiki.clean.cs.ru.nl/Documentation

ドラゴン２版の字句解析器の章で一番最後に乗ってる
表をずらして保存して圧縮するアルゴリズムの一般的な名前ってなんですか？

https://github.com/tolmasky/language

http://chris.wailes.name/?page_id=97

常識無いな
何のコメントも無しにリンク張るなよ紛らわしい。

ご立腹ですねw

>69

ありがとうございます。参考になります。

>>71 が JavaScriptで書いたPEGのパーサ
>>72 がRubyで書いた、パーサやら、LLVMのなにか
みたいですね。

言語処理系入門したいんですが、ドラゴンブックから入ればいいんですかね？

プログラミング歴はそれなりで、構造化されたものを読むのに
なんとなく再帰下降型のパーサを書くくらいのことはできます
情報科学については学部レベルの知識……かなぁ

仮想マシンの設計や JIT コンパイルとかやってみたいのです

>>76
仮想マシンはドラゴンブックでいいかもしれんがJITだとあんまり良い書籍無いような気がする
JITで良い書籍あったら自分も読みたい

#第一版しかもってないからかもしれんけど

JITコンパイルについて詳しいことが書かれた成書って無いんじゃないかなぁ

>>76
具体的なことまで読みたくなると、ドラゴンブックだけでは足りない。
もちろんドラゴンブックだけで書いてしまう人もいる。

JITはインタプリタ、コンパイラ、リンカ、機械語の知識が必要になるので、
いきなりJITを目指さないほうがいいと思う。仮想機械方式にしておけば、
コンパイラからJITへの発展は、ほぼ仮想機械の書き換えで済む。

ｔccにJITを付けるプロジェクトが幾つかあったはずだが、今はもうないようだ。

最近だとLLVMを触ってみるのもいいかもしれんねぇ

それから前に会ったとあるコンパイラ屋はドラゴンブックよりタイガーブックと言っていた

英語読めるならこの辺りをとっかかりに。
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.3985&rep=rep1&type=pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71.3303&rep=rep1&type=pdf

>>80
タイガーブックのほうが実際的だね。
ドラゴンブックは網羅的概論。

これはドラゴン、タイガーの中間くらい？
http://www.amazon.co.jp/dp/012088478X/

竜虎って言うけどまさに言葉どうりの２冊だな。

うちの先生は「二つ組み合わせるのがよい」とか言ってたな
フロントエンドはドラゴンのほうが詳しいが、
最適化の部分はタイガーのほうが良いとか

おおう沢山のアドバイスありがとうございます
JIT がレベル高そうな直感はありました
参考にさせて頂きつつ段階的に勉強したいと思いますです

----
((((((((( 最近だとLLVMを触ってみるのもいいかもしれんねぇ )))))))))(キリッッッッ！！キリッッッッ！！！！キリッッッ!!キリッッ！ッッッ！
----
(((((( それから前に会ったとあるコンパイラ屋はドラゴンブックよりタイガーブックと言っていた ))))))(←キリッッッ!!キリッッ!キリッ！！！！ッッ
--------------(キリッッ


ゴミは何いってもゴミ

https://github.com/GenTiradentes/tinyvm

Flex2.5.4を使用しています。

355/113のような文字列を分数として認識させたいと思い、後続コンテキストを使用して

ureal   {uinteger}|{numerator}\/{uinteger}
numerator   {uinteger}/\/
uinteger    [:digit:]+

のように定義を書いてみたのですが、
urealのルール部分でunrecognized ruleというエラーになってしまいます。
（意図しているのは、「スラッシュが続く無符号整数を分母と認識する」というものです）

ルールnumeratorが悪いのか、一時的に

ureal   {uinteger}|{uinteger}\/{uinteger}

と置くとエラーは無くなるのですが、正しい書き方とはどのようなものでしょうか。

自己解決しました。

　|　と　/　では　|　の方が優先度が高かったため、

{uinteger2}|{numerator2}\/{uinteger2}

だと、

({uinteger2}|{numerator2})\/{uinteger2}

として解釈されていたようです。

{uinteger2}|({numerator2}\/{uinteger2})

のように括弧をつけたところエラーがなくなりました。

すいません、誤報でした

何度か弄っている間にnumeratorの後ろの　/\/　を誤って消してしまっていて

numerator   {uinteger}

になっていました。

Flex「落ち着いて！」

やりたいことが単純すぎて、どこに盲点があるのか…

暑くて半分頭茹ってるし。へるぷ

次こそは間違いないはずだ！

Lex とFlex では定義の展開の方法が違います。Flex（およびPOSIXのドラフト仕様）は、
定義を展開する時に丸括弧( ) で囲みますが、Lex は囲みません。
このことは、Flex 定義では演算子`^'、`$'、`/'、`<<EOF>>'、および`<start state>'は使うことができない
ということを意味しています。

だって（マニュアル8章）。

-l コマンドオプション使ったら排他的スタート状態を使えなくなるし…。うーあー。

ジャングルブックってのもあるらしいぞ

ジュマンジ。

色々な本読むと先読みするのを１文字にするのが滅茶苦茶大事みたいな雰囲気がひしひしと伝わって来るんですけど
そんなに大事とは思えないのは俺だけ？

読み直し

昔はこだわったけど、
つまり1文字先読みだけで解析できればメモリも消費しないし、
入力ファイルを先頭からサーッとなめるだけで終わる。

現代ではぜんぜん大事ではないね。

>>99
> 入力ファイルを先頭からサーッとなめるだけで終わる。

何文字先読みしようがここは変わらんだろ。

ワンパスで処理しきれん時代も今は昔、だな

re2c 0.13.5で使用しています。

いくつかのルールからなる正規表現の、各部分を検出するごとにアクションを実行したいのですが、
一番長い（最長一致）ルールのアクションしか実行してくれません。

このような動作をさせるのはre2cでは不可能なのでしょうか。


re2c 0.13.5で現在、以下のコマンドラインで実行しています。
re2c -i -w -o "lexer2.cpp" "lexer2.re"

re2cには最短一致指定がないしねえ。

ウイルスが作成が犯罪になるからオートマトン全体を表すクラスの中にウイルスが存在するから
これからはウイルスを含むクラスとの差を取らないといけなくなるな。

ウイルスを含まないオートマトン全体の集合……パラドックス発生の臭い……！

セル・オートマトンじゃないんだから増殖しないでしょ。
受理するだけなんだから。

オートマトンの定義をみなおしてこい。

新しい言語を作りたいのだけど
関数型とか手続き型とかじゃなくて、既存にない新しい型の言語を作りたいけど
そんな型はもう発見できないのでしょうか？

設計したところで、実装しなければ絵に描いたモチなので、
まずは実装する腕力を付ける必要がある。
なのでまずは手続き型でも関数型でも、なんでもいいから簡単なものを実装してみること。

「関数型とか手続き型」ってくらい大きく枠組みを変える話なら、
新しい計算モデルを考えないといけないよねえ。

絵に描いた餅といえば、
Steele先生のConnection Machine Lispは面白かった。
立派な餅だった。
(*Lispの方じゃないよ)

>>108
頑張って発明しろ

>>108
これからのパラダイムと言えば、「確率的コンピューティング」かな。
http://slashdot.jp/science/article.pl?sid=09/02/11/0219213
http://slashdot.jp/hardware/article.pl?sid=11/03/23/0228212
http://slashdot.jp/developers/article.pl?sid=11/06/07/0151249

>>108
キューマシンに特化したような言語はまだないと思うから、それ作ってみたらどうよ。
ＶＭの実装も簡単な部類みたいだし。

キューマシンの研究そのものがマイナーだから、自分でいろいろ考えなきゃだけど、
それを楽しんだり発表したりしたいんだよな？

FIFOLか

結局キューじゃ順序に制約が多すぎて、
データフロー計算やることになる。
データフロー計算は昔流行ったので、特化言語も結構ある。
昔、九州大学でやってて、九大は関数型がメインだった。

ドラゴンブック２みたら
重要状態とはε遷移を含む状態である。
って訳してあるけど原著を見ると
重要状態とはε以外の遷移を持つ状態である。
の誤訳だな。
ドラゴンブックの翻訳、訳者は内容わかってなくて翻訳したんだろうな。

１５７ページに　set alreadyOn[s] to TRUE
って書いてあるけど、これってnewStateの状態だから
TRUEにするっていうのは間違いですよね？
ドラゴンブック２の原著です。

誰も興味ないと思うけど訂正するよ
含む状態→含まない状態

ttp://www.geocities.co.jp/SiliconValley-Oakland/3432/man/bison/bison-ja_8.html#SEC69
で
「最後のn個のトークンとグループが文法規則に当てはまる場合には、
それらは規則に従って組み合わされます。これを、還元（reduction）と呼びます。」
とあるのですが、最後のn個というのは複数通りの文法規則があてはまる場合
長い方と短いほうどちらになるのでしょうか？

還元/還元コンフリクト

>>121
どうもです。
あとbisonの
a: /*空*/ |
...
っていうような
/*空*/ってどういうときマッチするんでしょうか？
一回以上の繰り返しとかを終わらせるとかくらいしかないです？

>>122
例えばこういうのはどうです
f()
f(1)
f(1, 2)
関数呼び出し: 関数名 '(' 0個以上の引数 ')'
0個以上の引数: /*空*/ | 1個以上の引数
1個以上の引数: 引数 | 1個以上の引数 ',' 引数

>>123
いまいち>>120のリンクにある説明での動作との対応がとれないんですが、
a: /*空*/ |
hoge
;
ってあったとき
hogeって入力があったら,
hogeが先読みスタックへつまれて、
現在スタックには何も無いので/*空*/とマッチ,
シフト還元衝突でhogeが読み込まれるってことでいいんでしょうか？
それだと5.6の還元/還元衝突がよく分からないのですが。
5.6ではsequenceとmaybewordの還元/還元衝突が起こって
先にあるsequenceが選ばれると書かれているように見えるのですが
実際にマッチするのはmaybewordみたいです。

sequence: /*空*/ | maybeword | sequence word;
maybeword: /*空*/ | word;
にwordを入力すると、3通りの解釈の方法が生じる

スタック:(空) 先読み:word
↓空をsequenceに還元
スタック:sequence 先読み:word
↓シフト
スタック:sequence word 先読み:$
↓sequence wordをsequenceに還元
スタック:sequence 先読み:$

スタック:(空) 先読み:word
↓空をmaybewordに還元
スタック:maybeword 先読み:word
↓maybewordをsequenceに還元
スタック:sequence 先読み:word
↓シフト
スタック:sequence word 先読み:$
↓sequence wordをsequenceに還元
スタック:sequence 先読み:$

スタック:(空) 先読み:word
↓シフト
スタック:word 先読み:$
↓wordをmaybewordに還元
スタック:maybeword 先読み:$
↓maybewordをsequenceに還元
スタック:sequence 先読み:$

2種類の還元と1つのシフトが衝突している
シフトと還元ではシフトが優先されるので最後のシフトの方法が選ばれる

ドラゴンブック２は原著も翻訳も間違いが多いの？

>>125
どうもです。

「どうもです。」とは日本語おかしくありませんか。
正しい日本語をつかいましょうね。

>>125
恐悦至極にございます。

いや、誰も誉めてないから

恐悦至極
意 味：　相手の厚意に大変喜び感謝すること。

C++をflex,bison等で構文解析するコードってありませんか?
#includeとかは全部無視してて良いのですが。
あってもおかしくなさそうな物なんですが見つかりません。

構文解析関係の本をamazonで探して買えば？

C++の仕様を、bisonで構文解析できると思わない方がいい。と言うかまず無理。

a * b; // 掛け算ですか？　いいえ、変数宣言です

C++は複雑すぎてないらしい

昔のgccがそうじゃなかった？
Cのみかもしれないけど

今のg++はbisonの吐いたコードを基に手で書いてる。

今でもメインテナンスされてるbisonコードはないんじゃないだろうか。

この辺り読んでみて。
http://scottmcpeak.com/elkhound/
http://www.nobugs.org/developer/parsingcpp/
http://www.computing.surrey.ac.uk/research/dsrg/fog/FogThesis.pdf

「コンパイラの構成と最適化　第2版」中田育男　朝倉書店
の13.静的単一代入形式(SSA形式)のp.344の図13.15
「変数の名前変えアルゴリズム」についてですが、一カ所、
プログラムの最後から二つ目のfor eachブロックが、
for each ブロックY∈child(X) do
call SEARCH(Y) /*支配木の上から下の順で名前替え*/
end for
となっているのですが、Y∈child(X)は、Y∈succ(X) の間違いではない
でしょうか？

自分の理解だと、succ(X)だと上手く動く様に思えますが、child(X)だと、
「抜け」が出てくるんじゃないかと思います。

そんな最後の方のページまで読んでるなんてすごいね。

え、みんな最後まで行かないで投げちゃうの？w

>>139
succ() と child() の定義を確認してみ。
p.339 の最後の段落。IDOM() がポイント。

succ()にしたら同じブロックを二度以上処理しちゃうよ。

>>142
有り難うございます。succ, child, IDM については表面的には理解して
いたつもりだったんですが、今回より深い理解に到達できた様に思います。

succ()にした場合、あるブロックBから2つのブロックC1,C2に分岐し、
再度、一つのブロックDに合流する様な場合に、SEARCH(C1)とSEARCH(C2)
の両方からSEARCH(D)が呼び出されてしまうことになり、Dに対して二重に
処理が行われることになってしまいますね。

最初に、今回、理解が深まったと言った事は、直接支配のIDOM(B)が
必ず唯一、しかもBが入り口ブロック以外では、絶対1つは必ず存在する
事の重要性です。このことは、IDOM(B)によってリンクされた木である
「支配木」が、循環がないこと(合流が存在しない、親が必ず1つ)は
もちろん、必ず全てのブロックが含まれている、非常に有用な構造で
有る事を意味するんですね。

このことから、全てのブロックを「巡る(walkする)」には、支配木の子で
あるchild()に対して再帰呼び出しをすることが一つの方法である、と言う
事に気付きました。つまり、>>139の部分で、Y∈child(X) に対して、
SEARCH(Y)を呼び出していけば、必ず全てのブロックを一回づつ巡る事に
成るんですね。

しかも、実際のプログラム実行時の実行順序と同じ順序関係を満たしている
んですね。

今回、勘違いしてしまった理由は、Y∈child(X) に対して SEARCH(Y)を
再帰的に呼び出して行くだけでは、全てのブロックを巡ることが出来ない
場合があるのではないか、と思ってしまったことです。

しかし、実際には、>>143 に書いたとおり、child(X)に対応した構造で
ある「支配木」は、プログラム中の全てのブロックを必ず一回づつ含む
面白い構造をしているんですね。

そういうことです。根から順に一度ずつ辿れるんですね。
最適化って、うまく動くとすっごい楽しいです。

　　　∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧
　＜SSA！SSA！SSA！SSA！SSA！SSA！SSA！SSA！SSA！SSA！　＞
　　∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨∨
　　　 、　　　　　　 　、　　　　　　　　、　　　　　　 、　　　　　　　 、
　 /っﾉ　　　　　　/っﾉ　　　　　　/っﾉ　　　　　/っﾉ　　　　　　/っﾉ
　/ /　 ∧＿∧ / /　 ∧＿∧　/ /　 ∧＿∧ / /　 ∧＿∧ / /　 ∧＿∧
　＼＼（　　　　）＼＼（　　　　）＼＼（　　　　）＼＼（　　　　）＼＼（　　　　）


ところで、C言語風の構文解析でBisonファイルを3つ書いて三層構造にしたんだが、こういうのって普通？
字句解析 → マクロ展開層 → プリプロセス命令解析層 → 普通の構文解析層 の順で、マクロ展開層はバッファに展開した文字列を字句解析器が読むように設定する。

普通。

flexは？

>>146
ありがちな話

やっぱそうなのか。ありがとう。

>>148
字句解析は一層で大丈夫だった。

「コンパイラの構成と最適化　第2版」中田育男　朝倉書店
の15.レジスタ割付けのp.409の厚被覆アルゴリズムの部分で、
大体の方針は分かったのですが、細かい部分が分からないので
質問させてください。

アルゴリズムとしてi)〜iv)が書かれていますが、 特に iv)の部分が分か
りません。

ii) 循環区間グラフの左から右に向かって、厚被覆の要素の候補となりうる
生存区間を全てリストしていく．その際，どの生存区間との組み合わせで
候補となるかを記しておく．

iii) 最初に選んだ循環区間のループの最後の部分（のステップ）に到達
したとき，ii)で最後の厚点に対して選んだ生存区間に，その循環区間と
重ならないものがないときは，厚被覆は存在しない．そのようなものが
あったときは，その１つを選ぶ．

iv) iii)で選んだものから始めて、ii)とは逆向きに、ii)で作った候補
の中から厚被覆となる組み合わせを作っていく(それまで選んだものと
重なりの無いものを選んでいく).


【分からない理由】

iii)で既に最良のものが選ばれていると思えるのに、iv)ではいったい
何をしようとしているのか分かりません。既にいっぱいいっぱになっている
ように思えるのに、逆向きに選んだところで、隙間が無いのでどうしようも
ないように思えてしまいます。


ご親切な方のアドバイスをお願いします。

ドラゴンブックのアルゴリズム4.12「先読みの決定」を本にある文法（4.20）に適応させた場合において、
アルゴリズム中に現れるgoto(I, X)（ただしI∋ [B→γ･δ]）の結果に一致する主要項の集合がどうしても見つかりません。
自分で走らせたプログラムを実行すると、以下の様になります。
J = {
　[S'→･S, #/$]
　[S→･L=R, #]
　[S→･R, #]
　[R→･L, #]
　[L→･*R, #/=]
　[L→･id, #/=]
}

(1回目の試行) 「[A→α･Xβ, #]がJ'に含まれている（伝搬）」
　 [A→α･Xβ, #] = [S'→S･, #/$] （「#」に対して）
　 goto(I, X) = {[S'→S･, $]}
(2回目の試行) 「aを#以外の記号として[A→α･Xβ, a]がJ'に含まれている（内部生成）」
　 [A→α･Xβ, #] = [S'→S･, #/$] （「$」に対して）
　 goto(I, X) = {[S'→S･, $]}
(3回目の試行) 「[A→α･Xβ, #]がJ'に含まれている（伝搬）」
　 [A→α･Xβ, #] = [S'→L･=R, #] （「#」に対して）
　 goto(I, X) = {[S→･S, $], [S→･L=R, $], [S→･R, $], [R→･L, $], [L→･*R, $/=], [L→･id, $/=]}

三回目の試行で[S'→L･=R, #]がgoto(I, X)に含まれていないためエラーになります。
本を読み進めていくと「I_4の主要項L→*･Rには先読み=が内部生成され、項[L→･id, =]によってI_5のL→id･には先読み=が内部生成される」
とあるので主要項から主要項集合へのマップを考えたのですが、I_2とI_8でR→L･が重複してうまくいきません。
どなたかご教示ください。

すみません、
[A→α･Xβ, #] = [S'→S･, #/$]
[A→α･Xβ, #] = [S'→S･, #/$]
[A→α･Xβ, #] = [S'→L･=R, #]
はそれぞれ、
[A→α･Xβ, #] = [S'→･S, #/$]
[A→α･Xβ, #] = [S'→･S, #/$]
[A→α･Xβ, #] = [S'→･L=R, #]
です。

対象も手順も、根本的にアルゴリズムをちゃんと理解してないように見えるけど。
まず説明を読んで手でやってみたら?
その後に表つきで例として載ってるんだから答合わせも楽でしょう。

すみません。どうしても理解ができません。
アルゴリズム4.12の「goto(I, X)の中の項A→αX･βに対して先読みaが内部生成される」と
「goto(I, X)の中のA→αX･βに先読みを伝搬する」はそのままの意味でJ' := closure({[B→γ･δ]});された
J'中の項としか受け取れないのですが…。
表に関しても、図4.44の伝搬元と伝搬先の対応を見るにgoto(I, X)で求めた主要項から
主要項集合への対応を見てlookaheadを伝搬させているという風にしか読めません。
その場合だと図4.42のI_2の二番目の主要項とI_8が重複してうまく動作するようには思えません。
何度も何度も申し訳ありません。理解のある方、ご教示ください。

本の読み方と言うか学習の仕方は
各自身につけてないとねぇ…

>>155のような大先生に教示するなんておそれ多くてとてもとても……

大学生かな？もしかして院生？
コンパイラの勉強をされてる方に
今更自習の仕方をお教えするなんて大それたことを………

構文論の複雑な部分を見ると、「構文と動作が直結したForth最強」とか思うよな。

Forth はスタックマシン用の複数のアセンブラコードを
一行にまとめて書いた感じ

構文なんて有って無いようなモンだ

自己解決しました。
LR(1)のgotoを用いていたのが間違いだった様です。
文脈上、LR(0)の主要項集合を扱うのでLR(0)のgotoを使わなければいけませんでした。

>>151 の質問にも回答をお待ちしておりますので、よろしくお願いします。

ここまで突っ込んだこと聞くなら先生に直撃の方がいいんじゃなかろか?
www.k.hosei.ac.jp/~nakata/
一番下にメアドあるし

それはダメだろ。
明確な間違いを指摘するなら結構だが、理解できないなんて理由でメールしてたら中田神に迷惑だ。
答えられる人がいなくたって仕方ないよ。
正誤表は確認しとくべきだが。

そうかなあ

俺は以前、瀬山士郎の数学の本について
本人に理解できないとメールで質問したら、
数回にわたって理解できるまでメールのやりとりをしてくれたよ

もちろん、どこまで理解できて、何が理解できないのか、
こういう理由でこういう事ではないかという
自分の考えを説明した上でのことだが

他にも、海外の著者にも拙い英語で質問したら、
皆さんちゃんとやりとりしてくれた

普通はこちらが真摯に質問すれば、相手も真摯に答えてくれるよ
ただ、相手も仕事や研究があって忙しいから返事に時間かかるかもしれんし、
クヌース先生みたいに秘書に任せているかもしれんが

迷惑な奴だ

企業と同じように、社会貢献は大学の義務だから、
まともな内容であれば問題ない。

金払って大学行けよ

>>167
その考え方は勿体ないなぁ
せっかくメールアドレスが公開されてるんだから、
遠慮しないで、思い切って質問してみた方がいいよ

専門書は著者も金稼ぎや頼まれて書いてる分はほんの僅かで、
ほとんどは情報を発信したくてうずうずするから書いてる
俺の恩師もそうだったが、真面目な質問は大歓迎なんだよ

質問歓迎って書いてるならどんどん質問すればいいんじゃね？

ただ、メールアドレスが書いてるからとかどっかの恩師が大歓迎してたからとか
そんなアホな理屈で一般的に質問OKという風潮ができるのは恐ろしい
うっかりアドレスも書けなくなるな

所詮は他人事。

そういうフィードバックは改訂の時の参考になるだろうし、著者にとっても良いんじゃないかな？

むしろ、なぜ質問大歓迎の風潮になっていないのか不思議でならん

学術書じゃない書籍の執筆経験ならあるけど、
その編集プロダクションでは読者からの質問には
回答義務……まではいかないけどできるだけ回答すべき、
みたいな空気だったよ。
最終的には相手が判断することでいいんじゃない？
回答がおっくうなら無視するか断ればいいんだし。

>>164 が勝手に思い込んでるだけだと思うけど

>>164 >>171

個人的な意見ですが、学者は、税金で色々と支援されているので、
少なくとも同じ国の人から教えを請うた時は、それに答える義務が
存在すると私は常日頃から思っています。

そうでなくては、自国で学者を支援する意味がありません。

回答を受ける人自身が「私には義務がある」というのは気にならないけど、
他人から「おまえには義務がある」と言われる人を見るのは少し抵抗があるなあ。
心情的にはわかるけど語感としてキツい印象を持った。

>>177
ごめん、「回答を受ける人自身」は「質問を受ける人自身」の間違いです。

そんな事になったらセンセイは一切本を出せなくなっちまうな
こわいこわい

>>176
そんな義務ないよ。給料分のことはしてるから。
たぶん良質の質問、および質問者ばかり想定して
そういう事言ってるんだろうけど…
金払っていて明確な義務がある学生の中でも基地外対処に苦労してる。
質問および質問者も選別されるのは当然のこと。
それが人と人とのつながりというものですよ。

>>180
自国民の役に立つ義務は必ずあるんですって。

税金で研究していますが、それだけだと、外国人でも研究成果は活用でき
てしまいますから、自国民にはせめて優先して成果が伝える義務があるん
です。

そこを勘違いしている教授が多くて感覚のズレに憤りを感じます。

>>179
本も自分の利益のためではなく、国民への奉仕として出す義務があるんです。

それが嫌なら、国から研究費を貰わないで下さい。

日本を代表する企業である、Panasonicの創業者である松下幸之助も、
　「大学はろくな事を教えないから、教育し直さなくては成らない」
と言っています。

実際的でないセンスの悪い研究や教育が多いと言うことなんですよね。

NASAとかは国民の税金で宇宙開発やってるんだから、その成果は
無償で写真とかの著作権を放棄するとか立派だと思うけどな

>>181
ないよ。そんな狭い考え方で本当に有意味な成果は生まれてこない。あなたの勘違いの方が甚だしいw

まあ本出した先生も
真面目な質問来たら嬉しいだろう
好意で答えてくれるのはありがたい
回答を義務とか言うのはお門違い

>>184
米国民以外の人間も見放題だけどな

なんか俺がメアドあるから聞いてみたらって書いたせいで荒れているけど
自分は真摯に著書で理解できない場合割と質問するんだ、中田先生はどうかわからないけど、
学術書の場合自分の不理解を説明した上での質問は割と答えてもらえるし、
改訂版で不理解が多かった部分に手直し入れたよって教えてもらえてうれしかったりした経験があったから軽い気持ちで書いたんだ。
元の質問者の学習態度がよかったから勧めてみたけど、スレあれちゃってごめんな。

荒れたうちに入らないだろ。たまにはこんな話題もいいさ。
著者にもメリットあるし、いいかもね。

まぁ、変なことを主張した奴が一人いただけだ。
多分そいつは他人に迷惑を一切かけない、酸素を全く消費しないで生きてる奴なんだろう。

>>188
いや、あなたは正しいでしょう。書いた方も、解答できる時間があるかは別にして、率直に嬉しく思うでしょ。

>>181
自国民の役に立つ義務はあっても
お前の質問に答える義務はない

いちいち一人一人相手にしてたら仕事にならん
そのために本出したり、一般向けの講演会やったりしてんだよ

>>183
そもそもpanaみたいなオワコン企業の役に立つ人間を育てようとしてないから
勘違い甚だしい

パナソニックは、ハイブリッド車のリチウム電池を供給してる

そろそろ他の板でやってくれ

>>192 てめえの存在がこのスレの妨害だから消えろヴォケ

>>193
Panasonicをオワコンというなら、日本企業でオワコンで無い物はどこなの？

続けるなアホが

え？

>>197
いくらでもあるよ
もっとレベルの高い仕事をしてる会社、利益率の高い会社・・・いくらでもある
ざっと四季報にでも目を通してみたら？

実際、panaは儲かってもいないし、優秀な人も行ってないしね
一部優秀な人もいるけど、大半は作業員レベル。学歴も低い。

>>200
具体的にどこ？

時代時代によってコロコロと事情は変わるけど、今の時代、大メーカーの
正社員で研究・開発、と言えば、そこそこ優秀な人はいってると思うけどね。

そろそろスレタイ見ようか (--##

大学教員自身が自分がセンスの悪い的はずれなことを研究していると自ら
気付くことはないんだろう。

馬鹿は自分が馬鹿なことに気付かないらしいから。

まさしく >>204 自身のことだな

>>202
panaの研究・開発がレベル低いなんて言ってないよ。
「一部優秀な人」と書いたのは研究開発の人たちのつもり。
でもね、panaは連結で30万以上の社員がいるけど、そのうちの大半は
低レベルな仕事しかしてないんだよ。低レベルな仕事というのは
工場の現場のこと。こういう低レベルな仕事を抱えこんでいるかぎり
どうしようもないよ

>>201
ファナックとか、製薬全般とか、たくさんあるよ
東証一部だけでも1000以上の会社があるんだから、自分でいろんな会社調べてみたら？
低レベルな仕事をたくさん抱え込んでいる会社は図体がでかいから目立つけど、
そんなもんは日本を代表する会社じゃないよ。中身が伴ってない。でかいだけ。

テレビ作る仕事なんてもはや昔の繊維産業と同じ。オワコン。
韓国がライバルになった時点で負けたも同然。なぜなら韓国の
ほうが給料が安いから。韓国人と同レベルの仕事しかできないから
panaはオワコンなんだよ。
給料の安い韓国人と同じ仕事しかできないのに日本人の高い給料を
取るから、サムスンは黒字なのにpanaは赤字になるんだよ。

ファナックや製薬はどう？
ライバルはどこ？中国でも韓国でもないよ。
それがレベルの高い仕事をしてる証拠だよ。
こういう会社は給料は高いし、高い給料を出しても儲かってる。

>>206
>ファナックとか、製薬全般とか、たくさんあるよ

現状、発展途上国が台頭してきてないとは言えるけど、ロボット作り
がPanasonicがやってることに比べてそんなに高度だとは思えないし、
製薬に関しては口に入れる物だから国内産に人気があることが大きく
影響している。

パナソニックは産業ロボットの先駆けだけどな。
俺が生涯で初めて見たロボットがパナソニックの5軸だった。
それは、博覧会で書道やってたやつだったな。

そろそろスレタイ見ようか (--###

自習で行き詰まった奴の次はスレチな話題かよ

>>206
でおまえはどういう仕事してるの？、自宅警備？

>>207
>ロボット作りがPanasonicがやってることに比べてそんなに高度だとは思えないし、

何の根拠もなく思うとだけ言われても困るけど・・・
現実の評価はではロボットのほうが高度なんだよ。
それだけのお金をみんな現実に払ってる。
それだけファナックは儲かってる。ほかにはできない、高度な仕事だから
みんな高いお金を払ってるんだよ。
あれだけ儲かってるのに、テレビ作りみたいに簡単に真似できることなら
すぐに韓国や中国に真似されるよ。できないんだよ。

>製薬に関しては口に入れる物だから国内産に人気があること

そんなことじゃないよ
日本国内の製薬売り上げランキングでもファイザーとか
ノバルティスはベスト10に入ってるんよ。
つまり日本人も外国産の薬をたくさん飲んでる。
でも中国や韓国の薬は飲んでない。なんでかわかる？
人気の問題じゃなくて、そもそも中国や韓国にまともな製薬企業がないんだよ。
世界の製薬企業の売り上げランキングを見てみたら？
中国や韓国じゃ薬は作れないから、彼らは外国産の薬ばかり飲んでるんだよ。

>>208
そう
だからパナもテレビ作りなどというくだらない仕事を早く捨てて
高度なことだけをやったほうがいい。
ようやく捨て始めてるようだけどね。

とスレタイすら読めない馬鹿が喚いてます

panaはこのスレタイにそったテーマだと、
携帯向けのJVMは黎明期に結構頑張っていたよ。

IBMの東京基礎研が頑張ってるとか聞いたような　＞JVM

あそこは昔、所長がsmalltalkのVM屋だったことがある。

VisualSmalltalkとかあったねぇ

>>217
あれの発展系がVisualAgeJavaなんだよね、今再開しても十分魅力的だとおもうんだがだいぶ前にVA*系はとだえちゃったな

IBMって言語開発系のプロダクト凄くいいのに長続きしないの悲しいな

>>218
Eclipseに引き継がれてる。
元々どの言語向けもsmalltalkで書かれていたのを、
組み込みJava用VisualAgeでJavaで書き換えたのが始まり。

>>216
http://www.bayspo.com/kurasu/kurasu8xx/kurasu807/807.html

質問させてください。
簡単な言語処理系のようなもの（基本的な制御構造・関数・ローカル変数がある程度）を作っています。
速度を追求する必要がないので、構文木を直接、再帰的に評価しています。
この評価器を
0. suspend/resume できるようにしたい。
1. ファイル入出力などを非同期に行いたい。
ため、自前でスタック相当のものを用意して非再帰的な形に書き換えられれば、と思っています。
単純な木のトラバースなら非再帰の形に書き換えられるのは理解しているのですが、
構文木の評価を非再帰的に行おうとすると、中間コードを吐く以外の方法が思いつきません。
用途的に中間コードを吐くのはちと大げさなので、もし構文木を非再帰的に評価する
良い方法がありましたら教えてください。

中田先生の本に、確かLLパーサを非再帰的に構成する手法の解説があったと思うけど

>>221
構文木の「評価」がわかんないのです。具体的には例えば、
type stmt = Seq of stmt * stmt | If of expr * stmt * stmt | While of ...
みたいな木があったとして、再帰的な評価は
evalStmt(s) {
match(s) {
| Seq(s0, s1) -> evalStmt(s0); evalStmt(s1);
| If(cond, then, elze) -> if(cond) evalStmt(then) else evalStmt(elze);
| While(...) ...
....
}
}

こんな感じでできるんですが、この木を非再帰的に評価する方法が分からんです。

再帰なんて自分でスタックフレーム作って地道に積むだけだろ？
中間コード吐けない事情があるなら同情するけど

諸々のLR法なら上向き解析の効率的な手法はかなり研究されているし、解析のための前準備の方法も効率的に行えるんだけど
LLはよく分からないっていうか>>223が言っている通りなんじゃないかな。

>>223
if 文とかがあって動的に評価されるかされないか決まる場合を考えてください。
条件の値を評価してからどっちを積むか決めなければいけないので、再帰しない条件だと、
stack.push( stmt.cond );
stack.push( new IfStmtEvaluator( stmt.then, stmt.elze ) ); // なんか if 文を実行する特殊な値を積む。
こんな感じにしないといけない。この「特殊な値」が増えてくると事実上中間コードを吐いているような状態
になってしまうのです。

あ、上のコード、スタックに積む順序が逆でした。すいません。

質問文が異常に分かりにくいですね…。ゆとりですいません。
単純に
type expr = Add of expr * expr | Value of int
こんな木を評価したいとして、
func evalStmtNonRecursive( tree ) {
　Stack<expr> treeStack;
　Stack<int> retvStack;
　treeStack.push( tree );
　while( !treeStack.empty() ) {
　　match( treeStack.pop() ) {
　　　Add(lhs, rhs) -> treeStack.push( new EvaluateAdd() ); treeStack.push(rhs); treeStack.push(lhs);
　　　Value(val) -> retvStack.push(val);
　　　EvaluateAdd() -> retvStack.push( retvStack.pop() + retvStack.pop() );
　　}
　}
}
こんな感じのコードしか思いつかないんです。

>この「特殊な値」が増えてくると事実上中間コードを吐いているような状態になってしまうのです。
はい。それしか方法はありません。

なぜ中間コードを使いたくないのか分からん
かえって大げさになるだけだと思うが

携帯か組み込み用途か？

再帰パーサをCPS変換してみたら幸せになれるかも

> はい。それしか方法はありません。
うーん。そうですか。もしかしたら何か賢いテクニックがあるかと思ったんですが。

> かえって大げさになるだけだと思うが
みたいですねえ。速度が全く問題にならないので、もし中間コード生成が必要なければ
そっちの方がシンプルでいいと思ったんです。現にステートの保存が必要なければ再帰的な評価器で
済んでいるわけで。

> 再帰パーサをCPS変換してみたら幸せになれるかも
CPS に変換して末尾関数呼び出しをループに置き換えると >>227 と同じような感じになりませんか?
あとでもう少し考えてみます。

スタック毎保存したら？

スレッドにしちゃって、フラグを見たり一定時間経過でスリープに移行とかどうよ？

TXL の話題はここでいいのかな？

ttp://www.txl.ca/nabouttxl.html

面白いな

2007年ｗｗ

kikx 2007/12/04 23:23
>expression:
> expression relational-op additive-expression
> additive-expression
から下を LL(1) にするのは面倒ですよ。
LL(1)かどうかを考えるなら、こっちを問題にすべきなのではないでしょうか。

みずしま 2007/12/05 01:40

>>expression:
>> expression relational-op additive-expression
>> additive-expression
> から下を LL(1) にするのは面倒ですよ。

その辺は割と簡単に変形できませんか？こんな感じで。

（略）

kikx 2007/12/05 02:33
この式の文法を変換する方法は、たいていの文法の本に練習問題で載ってるので、
kmaebashiさんにちょうどいいんじゃないかなって思って書いたんだけど、
みずしまさんに答を書かれちゃった♪

http://d.hatena.ne.jp/kmaebashi/20071203

だれかxtextで簡単な言語を実装してみてよ

正規表現で*を連続で２回以上つけることは文法的に無意味だけれど
禁止してはいけませんよね？

アホなユーザーにも判るようにエラーにするべき
無意味なことを許してはいけない

>>238
意味は全く無いが処理コストは食うね
>>239
０回以上の繰り返しだから文法的にも間違ってはいないと思うが、エラー処理には賛成する

でも人間ならまだしも機械的に作られた正規文法にその形が無いことが保証されているんですか？

複数のパターンから合成する際に
(a*)* みたいになることはあるね

文法内で設計思想の整合性がないとおかしいよな
>>239のノリでエラーにすると(((a)))も文法的に無意味だから禁止になっちゃう

効率と柔軟さのバランス次第だね

あのなあ、機械的に生成したなら正規化するだろ普通の頭なら
>>243のようなアホがいるから仕事が増える

A = a*, AA = A* のような定義から機械的に生成してるとして、
どうやって機械的に正規化できるのかな？
ヒューリスティックでルールをいくつか適用することはできると思うが。

決定的にするんだろ
問題ない
出来ないなら適用する文法見直し

構文解析されるデータを作るのが人ならa**とか((a))は許した方がいい
構文解析されるデータを作るのがプログラムならa**とか((a))は許さなくてもいい

そうだな。

せやな

構文解析されるデータを作るのがプログラムなら
a**とか((a))はどう出力されるのか仕様を確認だな

LL(1)では((a))を許さない方が難しいな。
a**の場合はa**の形が出てこなければそう処理は変わらないな。
よってa**は許可した方がいいな。

構文論と意味論はごっちゃにしないほうがいいと思うんだけど

せやな

よいよいそれにしとけ

せやろうか？

そこは

　　もち論

と返すところだべ

そういうこと書くとスレが止まるからヤメロ

なんかスレ立ってるけど、立てるならせめて「パーサジェネレータ」って名前で立てろよ。
というわけで一旦放置して落とせ。

http://www.oreilly.co.jp/books/9784873115320/

新宿の大型書店に大量に置かれていたので見てきた。
理論よりも具体例で話を進めている感じで入門者には良さそうな感じ。動物本にありがちな冗長さも少なめ。

でも買わなかった

中田 育男って
日本のコンパイラの本書いた有名なやつだな。

ヒエログリフか。動物ですら無いな
ってかオライリーの本って特定のプログラム言語を扱うときだけ動物表紙なんだな

もともと言語実装パターンの原書はオライリーではなくPragmatic Bookshelfから出てる
原書のヒエログリフはカラーなのに紫と黒の二色刷りにしてくるあたりやらしい
あとプログラミング言語でなくても動物表紙なのはいっぱいあるよ

>>260
RubyのMatzは大学生のころ中田先生の研究室だったんでしょ。そのことが「推薦のことば」に
書いてある。

年末年始休みにこれ読んで１つくらいおれおれ言語つくってみっかな。

matzくすなんかどうでもいいよ

だれか言語実装バターンを試してみるブログ書かない？

言い出しっぺの法則

「じゃあ、俺やるよ」ﾉｼ

「いやいや、俺が俺が」ﾉｼ

「いやいやいや、俺が俺が俺が」ﾉｼ

「「どうぞどうぞ」」

>>269
どうぞどうぞw

C++のコンパイラの場合、作る側すら、仕様の全貌を理解しきれていない
ようだ。

Cなどは実装が先で仕様というか規格が後から追っていた歴史もなくはない

>>135
> a * b; // 掛け算ですか？　いいえ、変数宣言です

名前空間の違いで判断できるから、
名前空間に対応したbison作ればいいんでは。
名前空間での切り分けってほとんどの言語で使ってるでしょ。
C言語でもtypedefで同じ式になるし。

実装が先で仕様が後という意味では、JavaScriptやRubyなんかも同じだね

いやいやいや、
実装して使う人が増えたから規格で仕様を統一したんでしょｗ
規格が先なんてありえないっての

その昔、Adaという言語があって .....

EiffeleとかModula-3とか

lispとかaplとかコンピュータプログラミング用じゃなかったし

それは嘘

>>274
flexがやってます。
identifier, keyword, typenameをtable lookupで区別してる。

Adaと一緒で、PL/1も規格先行じゃなかったか。
Iswim, FPは実装は計画されてなかった。

>>278
Eiffel

G-machineとかlamda式を日本語で説明してる書籍ってないですかね

http://www.jaist.ac.jp/~kiyoshiy/writing/gmachine.pdf

>>284
ありがと。でもそれはもう見たけど分かりづらいので別のを探してるんだわ

>>285
君が既に見た分かりづらいのを列挙してくれないか？

こんな丁寧なのが分からないのだと、読む方に問題があると言わざるを得ない。
もっと基本的なところから勉強した方が良さそう。

>>284を分かりづらいと感じて＆技術系英語読解すらNGじゃ、まるでダメポ
背伸びする前に基本を勉強した方がいいと思われ

http://www.amazon.co.jp/dp/4320024931/
かなり古い本だけどこの辺から勉強するといいと思う。
G-machineは載ってないけど、この本の関数型言語処理系の仕組みを
基本的なところから解説している日本語の本は殆ど無いので。
理論寄りならλ計算の本はたくさんあるが。

>>259
「言語実装パターン」(Laguage Implementation Patterns)はでたけど
「DSL in Action」と「Domain Specific Languages」（Martin Fowler)の翻訳ってでないのかなあ？

>>276
多くのesolangは規格(というかネタ)先行な気もする

RPGを作るために、自作のスクリプト言語を
作ろうと思うんですけど、それほど大規模な物じゃなければ
yaccやlexを使わずに作っても、それほど大変じゃなく
作れそうですか？

それともやっぱり、yaccやlexを使わずに全部自前で
作るとなると、小規模の物でも大変ですかね？

>>292
まあやってみればいいんじゃね？
あまり勧めはしないけど

>292
構文解析しない言語がお勧め。
LispとかForthとか。

小規模大規模ってのはなにのことを言ってるの？
構文と関係あることなの？

手書きパーサならLL(1)でいいんじゃね
LALR(1)なら小規模な文法入力であっても状態数がSLR(1)と同じになるからやってられんよ。
それでも正準LR(1)に比べると圧倒的に少ないけど。

クラッシュ・バンディクーのシナリオは
LISPで書かれてたとかネットで見たような気がする

マーク・サーニーだっけ？
俺はクラッシュバンディクー1はフルアセンブリだったって聞いたけど。

これのこと？
ttp://otsune.tumblr.com/post/72504819/naughty-dog-lisp
元サイトだとURL長すぎるのでTumblrからでスマン。

URL短縮使え。
今ならリダイレクト先確認できる短縮サービスが沢山ある。
あとotsune死ね。

はい。リダイレクト先を確認するならURLの末尾に+を付けてね。
ttp://bit.ly/wDhQVh

hoshu

１．「２週間でできる！　スクリプト言語の作り方」　技術評論社
２．「明快入門　インタプリタ開発」　ソフトバンククリエイティブ
３．「言語実装パターン」　オライリージャパン

おまえらもう読んだ？

>>292
PEGが楽。yaccとかlexとか分かりづらすぎconflictとか意味分からん
一方PEGは人間でも順を追って解析できるし、表現できる集合も大きい

自前で書いても結局PEGみたいなことをすることになる。
関数から関数を呼んでっていう

その説明だとLL(1)の再帰降下とPEGとの違いがわからんぞw

PEGはpackratで実装することで本領を発揮するんだから。

>>303
本は雑食なんでなんでも買ったり図書館行ったりするけど3はともかく1,2はおもちゃだったぞ

delphi用のpegパーサ前に作ったのうｐしよっかな

peg -> パースしてパーサ作る
パーサ使う -> 構文木 -> 自分で辿っていろいろ実装

っていう奴。本当はパーサをコンパイルしちゃうのも考えてたけどそのまま放置

あとPEGの記述自体がパーサーになるわけだけど、論理的に最適化の余地があったりするんだよな
そういうの考えたけどやってないな

そういえば、次の一文字を見て飛ぶ関数をテーブルで持っておくとか考えたな
思い出してきた

同じ会社のエンジンオイルで5W30と10W30があることがありますが、 
10W30を選ぶ利点は何かありますか？

スレタイ末尾の「エンジン」だけ見てここに決めたのか

>>310
単なる誤爆かと思ったわ。

javacc使ってる人みないね。なんで？

コンパイラ系の良書はあるけど
インタプリタ系でそういうのってないのだろうか？

コンパイラの良書の参考文献でもみたら？

>>313
機械語に落とさないで実行すりゃいいだけじゃないの？
コンパイラ系の良書って構文解析からオプティマイズまで入ってるから基本は網羅されてるし
モダンなインタプリタ処理系は内部がVMだったりするから見かけ上インタプリタに見えるだけでやってることはコンパイラ処理系とかわらんよ。

SICP

スレッデッドコードについてのちゃんとした説明とか
あんまり見かけないんだよな

>>317
古いforthの本とかなら載ってると思う

スレデッドコードって C で書けないせいか、あまり使われないね。
GCC とかだったら

goto *ip++;

とかできるんだけど。

↑インダイレクト・スレデッドコードね。

ダイレクト・スレデッドコードなら、

void (*ip)();
....
*ip++;

でいいよね。

確かウェブページにあったんだが...
ダイレクト、インダイレクト、もう一種類なんだっけ。

サブルーチン・スレッディングかな？
単にサブルーチン呼び出しに展開する簡単な Forth コンパイラとかで使われてたね。

http://en.wikipedia.org/wiki/Threaded_code

void *なポインタは++できないから、void **とかにしてキャストするのが常道

Luaみたいな組み込み言語作ってる。
BNFも抽象構文木もわからず力押しでやってきたけど
なんとかトークン分割と文脈チェック・解析までできた。

でもバイトコードの生成・実行は難しそうだ。
たぶんこれができればあとはなんとかなるはず。
・メモリ管理（スタック、GC)
・goto(例外、if、switch、return)

無理だったら諦めて他言語のソース吐く。

>>324
マイ言語作ってみたいと思ってる口だけど、そもそも入り口の言語仕様をどうやって考えたか聞かせて

昔の処理系はワンパス（ないし少ないパス数）で頑張ろうといろいろやったわけで、
教科書見るとそういう話がいろいろあるけど、今時ならデータ構造を持って、
何パスでも走らせてかまわないのが普通よね。

GCはとりあえず本もあるし、ウェブには情報がたくさんあるからそれを見る。
gotoの処理は、コードを吐きながら、今吐いてるコードのアドレスを数えておく。
飛び先の候補とかならそのアドレスを覚えておいて、あとでgotoする所でその
アドレスを書き込む。順番が逆の場合（先にgotoが出てきて、あとからその
飛び先の場所が決まる）場合は、gotoのある場所を覚えておいて、一旦ダミーの
アドレスを付けてgotoを出力してから、あとで書き直す。

と、一応書いてみたけど、BNFも抽象構文木もわからんとすると、
if (...) {
　if (...) {
　} else {
　}
} else {
　if (...) {
　} else {
　}
}
みたいなネストをちゃんと処理できてる？

>>325
実用性とか考えてなくて、とりあえずなんでもいいから
Javaから文法削ったようなものが動けばいいと思ってる。

>>326
ネストは速度とメモリ犠牲に段階分ければ簡単。
バイトコードは時間かけて作れなかったら嫌だから
BCELとかツールでjvmとか.netを生成してもらおうと思う。

peg方式はマジで分かりやすい。言語が設計しやすい

PEG難しくて理解できない

世界一簡単に説明してるサイトない？
もちろん日本語で

日本語で＆世界一、てのはすごい注文だなw

>>327
バイトコードはある物使ったほうがてっとり早いね。
遅くてもいいならフロントエンド程の手間も掛からないけれど。
jvm や .net のエンジンの性能はほとんど芸術品だよ。

LALR(1)一筋でやってきた老害の俺から言わせてみればPEGは敵性構文クラス。

>>331
遅い、か。ゲームエンジンで使いたい人などは
LUAのように以下の条件を満たす必要があるもんね。

・Cとの連携にオーバーヘッドが小さい
・スクリプト・ランタイムの起動が早い
・JRE（一緒に配布できないようなランタイム）が必要ない

でも自分は動けばなんでもいいから、
簡単ツールに頼ってバイトコードの知識0で作る方法を選ぶよ。

>>333
ちょうど >322 で出てるスレデッド・コードの wikipedia の解説には
インタプリタの核となる内部ループの実装が一通り載ってる。
後はスタック・マシンにするかレジスタ・マシンにするかだけれど
スタック・マシンなら半日で骨組みは書けるんじゃないかな。

あ、逆に自分で書かずに流用するって話か。

LALR(1)を積極的に選ぶ理由って、yaccがあるから、以外に特にないと思うけどな。

CFGとPEGの比較ということなら、CFGでは曖昧な文法ということになるようなものが、
PEGでは全部許されちゃうのが嫌ってのはあるかもしれないけど。

別にyaccでなくとも自力でLALR(1)パーサジェネレータ書ければいいと思うけど。
そこまで理解が及んでいれば、何も困る事はないしPEG使うのだったらCFGに対する正確な理解も必要。
PEGは確かに行き当たりばったりで小さな言語を作るのには向いているかもしれないけど左再帰ができないし、
「終端記号や非終端記号の集合」としての非終端記号を構築するに当たってCFGはそこが「素朴な」集合で論理的に整理されているのに対して
PEGは「順々にマッチするかを試す」辺りが「純粋な」集合ではない。
だから人間の記述ミスに起因する構文を書いてしまった時、CFGはちゃんとエラーを出してくれるのに対してPEGはacceptされてしまう。
構文は大きくなればなる程シビアになっていくから、機械的にエラーを吐いてくれた方が人間の側としては嬉しい。
よってPEGは最初から完璧に構文が出来上がっている場合（更にCFGでいう左再帰も人間の手で予め左再帰でない構文に直しておく必要がある）に採用するべきで、
それ以外の比較的規模の大きな言語はCFGを採用するべき。

＞LALR(1)を積極的に選ぶ理由
ドラゴンブックに「SLRとオートマトン数が同じで表現能力がLRよりは低いけどLLよりは高いからお勧め」って書いてあったから

> 表現能力がLRよりは低いけどLLよりは高いから
当時は, LL から自動生成する理論的根拠が薄弱だっただけだと思う

LLは自動生成というより、簡単に表駆動できるから、特に理論とか広がらなかったんじゃない？
表駆動でなければ普通に再帰降下するだけだし、左再帰の除去とかはすぐに理論が確立しちゃったし。

アノテーション、複数の戻り値、例外とか
修飾子増えると一行にかなり詰め込む事になるよね。

public def hello ( @Size(min = 0, max = 100) int value)(int, int) throws IOException {
print("hello");
}

複数行にするのもタイプ量が増える。難しいな。

def hello {
-opt public
-arg (@Size(min = 0, max = 100) int value);
-ret (int, int);
-thw (IOException);

print("hello");
}

構文解析器のようなもの作ってる人に聞きたいんだけど
データ構造って自分で作ってる？
それともライブラリーのやつ使ってる？
俺は全部作りたいからテンプレートで標準ライブラリーのやつを使ってはじめに作って
あとで自作に戻すつもりだったけれど、
インターフェイスを標準のにあわせないといけないからそこで効率の悪さが発生しそうなので
テンプレートを使わずに０からまた作ることに決定しました。

C++使ってるけどstdのvectorとかmapとかannoodaado_mapは使ってるな。
それ以外は特に使ってない。
STLと同じかそれ以上の速度で完璧に書けるなら車輪の再発明してもいいんじゃね。

自分の興味が何処にあるかによるんじゃね？
実装すること自体や性能に興味があるなら自作するだろうし、
とにかく言語をパーズして役立てたいなら有り物使うし。

＞インターフェイスを標準のにあわせないといけないからそこで効率の悪さが発生しそうなので
まずC++の規格書を読んでポリシーを頭に叩き込まないとな。

>>342の言ってるテンプレートって、
C++のtemplateなのか？

STL のことだと思われ

>>342が何をやりたいのかよくわからんけど、
既にあるものを使わないのは効率が悪いと思う

template<typename Set=std::set<int>>
としておいて後から変えるということだろう。

そこまで動作効率気にするならアセンブリで書けと

いまどきアセンブリで書くよりコンパイラ様に最適化任せてしまったほうが巨大なプログラムでも高速化できるし。

STLに合わせるコストと、自前で用意するコストを比較して
少ないほうを取るだけやな
趣味なら好きなほうでいいけど、こっちは仕事で書いてんねん

Visual C++とかIntel C++の吐くアセンブラ見てみ
適わないって思うわ
特に浮動小数点をやらせたら、fadd fxch fmul・・・・って人間技では無理やからwww

局所的なやつとか、アルゴリズム的に特別な命令使うと速くなるやつとかは別な

>>343
unorderedな。

浮動小数点まわりの設計は元々ちょっと無理があっただけに、かえって芸術品になるのかw

人間が優位になりうるのは、ソースコードから読み取れる以上の
情報をプログラマが持ってる場合
別名とかが絡むとコンパイラは最適化を保守的にやらざるを得ない

RubyスクリプトをC言語に翻訳することできますか？

Rubyってevalあったっけ？
無理そう。

なんだこの名前欄ｗｗ

Shed Skin（Python to C++)とかあるよね。制限つきらしいけど

C++にevalを実装する変態もいるくらいだからどうにかなるんじゃないか？

新しい言語を作るのとほとんど同じくらいの手間がかかるんじゃね？

>>329
http://d.hatena.ne.jp/kmizushima/searchdiary?of=10&word=peg

Ruby拡張ライブラリを作るような感じかな。。。
IRBにRubyLexがあるから、それを利用してできるかも。

pythonはpypyみたいなよく維持されているメタ処理系の参照実装があるから、
そういう実験もしやすいだろうね。Shed Skinはまったくpypy使ってないとはいえ。

https://github.com/inakata/ruby_scala

lexとyaccは、自作しなくとも、フリーで転がっているので助かるな。

>>363
なかなか素晴らしいサイトだが、すまんけどもっと分かりやすく
説明してるサイト無いか？ｗ

いや、そのサイトも凄い分かりやすいけどねコードとか

正規表現に似たパターンとその適用順序を定義して
順々にマッチングしていくだけ

>>368
http://d.hatena.ne.jp/kmizushima/20100203/1265183754

pdos.csail.mit.edu/papers/parsing%3Apopl04.pdf

原文読むのが一番楽。英語の壁はあるんだけど

Bryan Fordさんの論文で、MITの修士論文の奴が、ボリュームがすごくあるので一見して
尻込みしがちだが、実は丁寧に書いてあって、一番すらすら読めると思う。

ちょっとスレ違いと言うかスレずれな気がするけど、自分で新しい言語を生み出すにはどんな本かサイトを見て勉強すればよいのか、お勧めない？
それとも「えい・やっ」で、これまでに知ってる言語からあとは思いつきでやるものなのかな？
OSの一般理論みたいに、プログラミング言語とはこういうものだ、みたいな考え方を知りたい。

今だとドラゴンブックかタイガーブック（ML）で各構文クラスを学習するのが一般論なんじゃない？
少なくとも自分はそういう道筋を辿っている。
あと最適化だったら中田本を当たった。

ちゃんとやるなら数学の話になってくるな
工学部って消費者。数学者からすればザコ

チューリングマシンで終了だな。

工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系
工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系工学部は文系

数学は物理学の端女

mather

なんかあらぬ方向に飛んで行ってるけどw
とりあえずタイガーブックってのを見ようと思って尼に行ったら★2つだったorz
ドラゴンブックいっとくかw

どんな言語を設計するかと、
それを言語処理系として実装する方法は違うんじゃないの

プログラミング言語のパラダイムの整理という点では
CTMCPが面白かった

うん。ドラゴンブックで良いと思うよ。タイガーブックの日本語版誤植多いし、中身薄いし、ドラゴンブックなら二版が出てるし。
ただ、ドラゴンブックに出てる最適化を本腰を入れてしたいなら、中田本の二版を買ったほうが良いと思う。
力不足だから。

シンプルなコードが欲しい人はタイガーがいいんじゃないか？

お師匠様には2つを組み合わせると良いと教わった
フロントエンドはドラゴンで、最適化部分はタイガーで

タイガーブックについてる★２は気にしないでいい
ただあの評価コメントも完全にハズレってわけでもなくて
１冊目に読む本じゃなかったってだけの話だ

pegとLL(∞)と同じだよな。

Rubyコンパイルまだ？

コンパイルって需要あんの？
スクリプト系が遅いのはライブラリを実行時に毎回読み込むから
でもあいつらはガチのオブジェクト志向だから、それは本質的に必要な処理

>>388
少なくとも私にある。字句解析と構文解析をすっ飛ばせば
それなりに早くなると思うんだけどね。

ついでに意味解析もすっ飛ばしちまえ

>>388
> でもあいつらはガチのオブジェクト志向だから、それは本質的に必要な処理

具体的にどういうこと？

ダイナミックリンクライブラリ：「…」

クラス定義と、実行するコードの区別が無いってこと
クラス定義も"実行"しないといけない。コンパイルで速くなるかもしれんが
C++とかはクラス定義をプリ実行できちゃってるから、そこには大きい差があるなって

まあ工夫すれば結構早くなるとは思うけどな
でもプロトタイプってどう最適化できるかな

あれかCopy on writeをうまくやれば、"ほとんど"のケースでC++並みに早くできるか
Ruby好きだからちょっと考えてみよっかな

クラス定義のプリ実行だけは本質的に無理だろうけど

それは動的な定義を許してるってだけの話。
オブジェクト志向とは直行してるし、
実行時構文解析も必要じゃない。

確かに実行時構文解析は無駄。Ruby作ってる人が速くしようと思ってるなら
糞プログラマだな。多分そもそも速くする必要が無いと判断してるんだろうけど

完全にトランスペアレントにできるならまだしも、コンパイル後をどこかにキャッシュしといて
それで"変な"バグが出たりするとストレス溜まるもんな
代償もでかい

調べたらだいたいJRubyが考えてることやってるような気が
萎えた

こういうの見る限り、Javaに協力したほうが汎用性があって良さそう。
p.tl/K7Ld
invokedynamicの速い実装方法を考える

その辺はJITなら問題ないんじゃないか。
それにLispは動的な言語なのに、昔からネィティブにコンパイルした
ライブラリのコードをプリロードした実行ファイルにしていたし。

>>399
JavaやJavascriptは人的リソースが豊富だからねえ。
JVMもproper tail callをサポートすればもっと言語屋の利用が増えるだろうに。

爆速で実装する方法思いついた。LLVMで作ってみよっと
perlだのphpだのぶっつぶしてRubyを主流にしたいってのもあるし

有言実行

三姉妹

調べたらまっさらから書くのはつらそうだわ。本家の拡張でやる

"メソッドを動的にインラインバージョンにすりかえる"ってのをまずやってみる
vm_call0ってところを書き換えればいいらしい

う〜ん、JNI？

火が着いた

アイデアの詳細
bugs.ruby-lang.org/issues/6289

調べたところ古くはYARVってのが高速Rubyで、Ruby1.9で本家にマージされたらしいが
最適化ぬるいわwww。だから俺がここらで締めてやる

最適化とか曖昧な話しは捨てて
関数のβ変換エイリアスを作ってくれや

>>404
どんだけおっさんだよ

>>407
Closedおつ

閉めてやる

ドラゴン本が届いたんだけど、これなんでこんな装丁なんだろうね。
小説じゃないんだから、もう少し大きい紙で1頁でもっとたくさん字が載るようにしてくれた方が使いやすいのに。
と思ったけど、英語版もこんななのか。

着くなり製本に対する文句書き込みかよw

>>413
そういうのは無視

>>412
> 小説じゃないんだから、もう少し大きい紙で1頁でもっとたくさん字が載るようにしてくれた方が使いやすいのに。
英語版はそうなっている。

hoshu

Rubyスクリプトコンパイラまだ？

コンパイラ作るのによく使われる代数学の分野はなんですか？

代数というか、従来（ドラゴン本とか）の定番ではオートマトン理論の解説に
力を入れるのが定番だったけど、ぶっちゃけコンパイラ作りというのは、
理学というより工学なので、代数学というのはそんなに大事じゃない。

中田本「コンパイラの構成と最適化」が亜麻で「出品者からお求めいただけます。」になってたんだけど、もしかして絶版？

新しい方？

新版が出たのに、旧版も刷られ続ける本というのは相当珍しいと思うけど。

紫と白っぽい表紙の第2版の方だよ

林晴比古のシリーズの本どうよ？

林晴比古の本、としか言いようがない

>>423
本屋でチラ見した程度ではそこそこ良かった

iOS 用の静的 Ruby コンパイラ
http://www.infoq.com/jp/news/2012/05/RubyMotion

>>426 ちっ、有料かよ。

自分自身を返す関数の型が書ける静的型言語ってあります?

ググってみたところ、Cでダメなのは有名な話らしく真っ先に出てきました。
OCamlもちょいと試した感じではなんかダメそう。

>>428
自分自身とは何を指しますか？

関数自身です。
Cで書くと(戻り値の型を書けないので仮にvoid*で代用したとして)
void *foo(int x) { return foo; }
みたいな。
OCamlで試したのは
let rec f x = f;;
とかです(エラーになりました)。

関数自身を返す関数の戻り値の型は静的に決められるのかって話になるのかな。

typedefを使わないのは何故？

typedefでもできないからでは

typedef foo (*foo)(int); とか書けてもいいと思うけど、通らないみたいね

こういうこと？（自信無し）
typedef void *(*foo_t)(int x);
foo_t foo(int x)
{
　return (foo_t)&foo;
}
int main(int argc, char *argv[])
{
　foo_t f1 = foo(123);
　foo_t f2 = f1(456);
　return 0;
}

それじゃダメ

>>428-430
無理だと思う。仮にできたとしても、返された関数は循環するだけで使い道がない。

Any型使えば万事OK

使い道の有無と出来る出来ないは独立した話だろ

意味的にどうかってことを考えないと
その関数の型と、返ってくる関数の型
これらは意味の上で同じなのかどうか

たまたま同じ形になってるだけじゃないのか

なんかおかしなのが涌いてきた

ある写像 f があって、f の定義域は {{}}、f の値域は {fのグラフ}。
ここで fのグラフは集合なん？

唐突にグラフと言い出した当人が考えればよろし

ここはプログラミングの中でも、コンパイラのスレ
そういう話出てきてしかるべきだろ

428です。
解決しましたのでご報告。

OCamlに-rectypesというオプションがあるのを教わり
それでやってみるとあっさりできてしまいました。
ダメそうとか書いておいてスミマセン。

# type foo_t = int->foo_t ;;
type foo_t = int -> foo_t
# let rec f x = f ;;
val f : 'b -> 'a as 'a = <fun>
# f ();;
- : unit -> 'a as 'a = <fun>
# f 1;;
- : int -> 'a as 'a = <fun>

>>442
ここでグラフというのは、関数を特徴付ける集合であるから、集合。
http://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%A9%E3%83%95_(%E9%96%A2%E6%95%B0)

>>6　のコンパイラ構成法のソース・正誤表のリンクが切れてるけど
ダウンロードできる場所しりませんか？

webarchiveに残ってるんじゃね？

>>447
http://akkera102.sakura.ne.jp/test/compiler.zip

>>449
入手できました、ありがとうございました。

>>445
この型推論ってどうやって解決してるんですか？

出現検査ってなにをすることですか？
無限に再帰するのを発見するものですか？

はい。

>>453
どのようにやるかなんてことは教えてくれませんか？

hoshu

保守お疲れ様です (｀･ω･´)ゞ

LL(1)の構文木が右結合になってしまうんですけど
どうしたらいいですか？
たとえばa+b+cがa+(b+c)になるということです。
最後の文字から入力することを思いついたけど、
文字の長さが決まってないとき困ります。

パーザが手書きなら自分でそう書けばいいし、
パーザジェネレータなら右結合に自然になるように文法を書けばいい。

ありがとうございます。
終端記号ってアスキー文字が一文字無駄になるんで無くしたいんですけど、
アスキー文字に使われていない数とか使えばいいですか？

そもそも曖昧性がなければ、
expr := term op expr か expr := expr op term のどちらかでしょ？

expr := expr op expr だったら、a + b + c が、(a + b) + c と a + (b + c) の
どちらなのか、構文規則から一意に決定できない。

あと LL だと expr := expr op term をそのまま実装すると無限ループに
なるから、左再帰の除去を適用する。

yaccだとBNFとは別に結合規則指定だ。

昔ここで話題になってたcaperっていうC++のLALR(1)パーサが吐けるパーサジェネレータを改良して
演算子の結合規則を指定する事によって曖昧さと衝突を避けられるようにしたんだけど
需要ある？

caperの使い方から教えてもらえるなら需要あるorz

残念ながら入力ファイルはcaperと互換ではありません。
ドキュメントがないので必要ならば今から書き始めますが…。

ドキュメントが整ってないようじゃ流行らない

最近はPEG？が流行ってるんだっけ？
誰か教えてくれw

caperはC#も吐けるから個人的に良いなと思ってるんだけど
ドキュメントにもサンプルにも、定義ファイル内でのコメントの書き方が載ってなくて
(結局//でいけたけど)
そういうあたりが色々惜しいなぁって感じるわ

しょうがないから今からドキュメント書きますね。
githubのマークダウン形式になるのですぐに終わると思いますが如何せん眠いのでどうだか分かりません。

眠くて変な文章になってるけど許して。
ttps://github.com/uwanosora/kp19pp

boostの使える環境でmain.cppをコンパイルすると実行ファイルができあがる。
とりあえず書式の導入だけでも書き上げたけど、生成されたhppファイルの使い方はcaperとほとんど同じだから
そっちも見て脳内補間してくれるとありがたいです。
最後に、構文を受理させる場合は「token_0」をpostしてね。
暇があったらまた書きなおすよ。

外人が書いた日本語みたいだな

caperから派生したんなら、caperと何が違うか書かなきゃダメじゃね？

何が違うかは>>462に書いてある通りだよ。
後は若干の高速化（漸近的には同じオーダー）。
それともリポジトリに何が違うかを書かないとダメってこと？

うん、リポジトリに書いてあるほうがいいと思うの。
あなたと同じようにcaperに不満を持った人が、これを見つけられるように。

PEGは、もうすでにいくつも実装がある、という段階なんだから、
なんでもいいから使ってみれ。
探せばたぶん、一般的なたいていの言語に実装があるから。

PEGいいな
個人的にBNFより好きかも

C++アプリケーションにスクリプトを搭載する際
C++のオブジェクトアクセスが楽なスクリプトエンジンってある？
その際スクリプトとして使う言語はJavascriptやPHPの様な
スクリプト用言語よりPerlやPython、Rubyみたいな汎用言語がよかです。

>>475
Luaとか、今ならmrubyの人柱になるとか。

オブジェクト指向はluaよりsquirrelのほうが、とか聞くけど

>>474
PEGをBNFと比較するのは間違いです。

PEGは不完全

あなたの言う「完全」の定義は？

C++のオブジェクトアクセスは、
スクリプトのランタイムもC++でないとまずい。
だから、LuaをC++でコンパイルしたものがおすすめ。
ちなみに、ビルド済みのバイナリでIDEに対応したやつは
たいていCでコンパイルしてるから要リビルド。

mrubyはC++でコンパイルできるのかな？
開発者はC++嫌いだからね。

Cのランタイム上で動作するスクリプトなら
直接オブジェクトの参照でなく
IPC機能を使わないと互換性で難儀する。

>>475
Krossどうよ?
en.wikipedia.org/wiki/Kross_(KDE)

>>481
kwsk
いまいちC++でコンパイルし直さなければならない理由がわからない。

>>478
Bryan FordさんのPOPLの論文でも
文脈自由文法との差異について頻繁に論じられていた気がするけど

>C++のオブジェクトアクセスが楽なスクリプトエンジンってある？

言っては駄目なんだろうが、C++のオブジェクトにアクセスしたいなら、
C++からアクセスするのが一番楽だわ。
GCC系とVC系の間でもアレなのに、スクリプト言語から呼び出しとか、果てしなくはまりそう。
ヘッダファイルに直接実装されてるインラインメソッド持ったクラスとか、どうするんだって感じだし。

>スクリプト用言語よりPerlやPython、Rubyみたいな汎用言語がよかです。

汎用言語でバリバリ制御したいなら、なおのことC++でプラグイン形式にした方が良いだろう。
汎用言語の上に別の汎用言語を載せて、
上位層から下位層にフレキシブルにアクセスしたいってのは、いろいろ不毛に思える。
そもそもが意味無いっつーか。その割りに技術的に難題だらけっていう。

そうか？boost::python使えばオブジェクト操作できるようだけど。

http://d.hatena.ne.jp/moriyoshi/20091214/1260779899

>>485
既にCOMってものが実現してるかならぁ
メンバー関数のポインターをラップしてテーブル化してアクセスしたり
仮想関数テーブル経由で操作するんなら処理系の壁はないぞ

>仮想関数テーブル経由で操作するんなら処理系の壁はないぞ

実際には仮想関数テーブルの何番目の関数ポインタが、どういった
・名前になっているか
・戻り値と引数の型は何か
を、スクリプト言語側が知る必要がある。
ここが大きな壁。

>>484
BNFと文脈自由文法は別のものです。
かたや記法、かたや文法。

boost::pythonはすごくいいよ。Krossも。
>>475の質問の趣旨を全く理解してない人がいるね。

COMみたいなメンドイもので時間浪費するより
スクリプトのソースがC++でビルドできるものを選んで
一緒にmakeするのがベストじゃん。
組み込み関数の作成にもboostとか使いたいしね。

http://d.hatena.ne.jp/moriyoshi/20091214/1260779899
これのどこが便利なんだか。
クラスのメソッドを全て手動で登録とか・・・。
C++からC++を呼び出すなら、全く必要のない手間だよ。
PythonからC++で作ったパーツを呼び出したいって需要なら分かるが、
その逆に、C++で作ったフレームワークをPythonから制御したいってのは
果たしてメリットあるのかねぇ。
C++もPythonも汎用言語だから同程度には複雑だし、
手動でコンバートを書かなくちゃならなかったり、速度面で不利だったり、
コンパイラの静的型チェックが死んだり、と、
何も良いことないように思えるが。

webkitpyとかすでに使えるようになってるのがあるよん。

PEGってどこが凄いのか分からん
だれか上手に教えてくれ orz

皆さん有り難うございました。
Krossとboost::pythonが気に入りました。
どの方法も直接C++のオブジェクトを操作ってのは難しそうですが
C++アプリの制御する分にはそれなりに楽に行けそうですね

SWIG は？
Lua は C でコンパイルしてあっても extern "C" でヘッダを読み込めば問題ないよ。

PL/SQLとかって文法的にどうなの？
データベースの使い方の事じゃなくて、プログラミング言語の文法として

制約が大きすぎてカタコトすぎるｗ
その制約で最適化が効くわけだけどね。

んでも
互換性の問題がないのなら新規設計で
もっと素晴らしいものが作れるように思う。

>>494
こういう言い方をすると怒られそうだが、
実用上はすげー強力な正規表現だと思っていい気がする
大きく違うのは非終端記号が使えることで、
例えば括弧対応の認識のような、正規表現じゃ書けないようなものも表現できる

e <- "(" e ")" / ε

理論的にはLR(k)より強力らしいから、人工言語を扱う限りは
非力さを感じることはそうそう無いはず

その他いろいろあるけど
・選択オペレータ/が優先度付きなので、曖昧な文法が生じない
　文法をいじってたらいつの間にかシフト-還元競合みたいな事は起きない
・先読みが使える
・*は貪欲マッチを行う

(" e ")

組み込み用だと思っていた言語がどんどん汎用的になっていく流れについていけません！

まさしくまさしく。汎用言語ならC++で間に合ってるわけで。
わざわざ組み込むのなら、出来ることに制限をかけたスクリプト的な物でなければ意味がない。

VIMScript・PostScript・各種シェルスクリプト。確かに最初から
スクリプト前提に作られた言語は便利じゃあるが、
Blenderみたいに汎用言語でも十分な場合は多い。
わざわざ新しい言語エンジン作るだけ無駄だよ。

それから、わざわざ作業を自動化したいだけなのに
メモリーやら最適化やら気にしながら書くのも煩わしい。
ましてや、ホビーグラマー程度のユーザーに使わせるものに
聖書バリのリファレンスが必要な言語を導入するなんてオーバースペックすぎる。

>>499
ありがとうございます
あとは処理形が安定してるかどうか、ですねぇ

どっかに言語処理形作るような仕事、ありませんかねぇ…

>聖書バリのリファレンスが必要な言語を導入するなんてオーバースペックすぎる。

まさに組み込み用と思われてた言語がどんどん汎用化して、
ほとんどCやC++やJavaやC#と変わらなくなってきてるのが問題なわけだが。
汎用用途じゃC++とかJavaに勝てるわけ無いし、
そっちの方向を追い求めても空しいっつーか。

汎用言語である必要はないけど、新たに言語エンジン作るのが手間だから
出来合いの汎用言語をスクリプトに使うんだろ。頭かてぇなぁ。

汎用言語を組み込むぐらいなら、
元がC++ならC++のDLLを、元がJavaならjarを、
プラグイン的に読み込めるようにすれば良いだろ。
スクリプト言語側へクラスや関数を公開したり型変換を提供するための、特別なコードも必要ないし、
標準的な言語と環境だから利用者の幅も広いし枯れてるし、
開発環境もデバッガも強力だし、実行速度も速いし、良い事尽くめじゃないか。
「出来合いの汎用言語をスクリプトに使う」というところまで思考が及んでいるのに、
どうして、お手元の出来合いの汎用言語(C++やJava)で十分な事を見落としてしまうのか不思議だ

もう、ユーザ自身にアプリ作らせろよwww

イラストレーターやらモデラーやらDTPやってるやつに
開発環境の使用を求めるのかよ。
描画エフェクトの順番制御のためだけにEclipseやらVSインスコしろとかw

範囲選択してスクリプト実行が指示されたら、
選択範囲の90度方向から40%の範囲にハイライト。
ハイライト完了後選択範囲全体にlog_[10]( 閾値 )でガウシアンぼかし。
数行で書けるコードのためにコンパイルとかパッケージ化とかやっとられんわ。

それは違うな。
VSやEclipseを自分のソフトに組み込んで配布することが出来るなら、
それがベストのはずだ。
イラストレータやモデラーだって、しょぼいエディタでプログラム書きたくないわ。
本来必要なのは、C++やJavaのフリーライセンスでアプリから呼び出し可能な統合開発環境。
ブラウザで言うところのIEコンポーネントに相当するもの。
そういうものが出てきたら、組み込み用汎用スクリプト言語は、いよいよ死ぬ。

Smalltalkか？

どう考えても大昔からあるものを、
「そういうものが出てきたら、組み込み用汎用スクリプト言語は、いよいよ死ぬ。（キリッ）」とかw

昔C++のインタプリタなるものを見たことがあるが
誰か使ってるのだろうか

>>511
>イラストレータやモデラーだって、しょぼいエディタでプログラム書きたくないわ。
そもそも絵描きの人たちがプログラムを書きたがるとは思えないんだが。
うちでもXSIのスクリプトは絵の人じゃなくてプログラマの人が書いてるよ。

Objective Cのインタプリタは少し使ったことある。
まだNeXT健在の頃の話ね

その辺の雑談はこのスレでやれば？

2011年のプログラミング言語シェア、Objective-Cが増加率1位…総合ではC#が3位・Objective-Cは5位
http://kohada.2ch.net/test/read.cgi/pcnews/1326714846/

>>511
大は小を兼ねるってのは迷信
無駄な機能を切り捨てないのは悪
一生使わない機能のために
セキュリティホールやリスクやアップデートの手間を増やすのは罪

実務でどれだけ便利かってことより、○○で3Dゲームが作れるようになったとか、JITを搭載したとか、そういう話題の方が人気あるよね。
ブランド大好きだなって冷ややかな目で見てる。

実務っつったらVBA最強…いや何でもない

別に人気が出ることが
単純に悪いわけではないでしょ

>>513
Root C++でググればいろいろ出てくるが、高エネルギー研究フレームワークの
一部として実装されてて、そういう分野じゃ基本技能として使われてる。

http://hep.planet-koo.com/index.php?g=root
http://www.quark.kj.yamagata-u.ac.jp/~miyachi/ROOT/index.html

凄いな。胸がときめいた

>>517
うん、だから、組み込み用言語がどんどん汎用言語化していく方向に難色しめしているんだよ。
汎用系はC++やJavaに任せていれば良い。

>>514
そうだね。
プログラマが書くんなら、プラグイン形式にしておいて、
VSとかでコード書けたほうが良いね。
強力なデバッガやインテリセンスがあって便利。

>>518
そうそう。DirectXで3Dゲームを作りたいなら、C++やC#を使えばよいだけなのにね。
マイクロソフトがヘッダを用意してくれてるから超楽チン。
わざわざ移植する必要ないよね。

汎用系の組み込み言語でも、Officeのマクロほどの開発環境が用意できるなら別だがなぁ。
でも、君らはそれがとても出来ないからって、どっかのフリーの組み込み用の汎用言語の処理系を
借りてくるっていうんだろ。そんな中途半端なこと。しないほうがマシ。
お互い無駄なことに時間を使う羽目になる。
プラグインの仕様とヘッダだけ公開しておけば、それで良いんだよ。
アプリ書く人も拡張する人もコンピュータも、皆が楽。

汎用系組み込み言語っておかしくないか？
特に、「組み込み用汎用スクリプト言語」とか書かれると気持ち悪くて仕方ない
このスレの流れで言うと、こういう感じだろ表現を統一してくれ。

スクリプト用言語 = ( 組み込み用言語 or 制御用言語 )
汎用言語 = スクリプト用言語以外
汎用言語を組み込む = 汎用言語をスクリプト用途で使う

>>524
所詮プラグインはプラグインで、スクリプトはスクリプトだよ。
エンドユーザーで実際にコード書ける人はいるし需要があるから
スクリプト搭載したソフトが出回ってる。特に、ここ数年は、
OOナニそれレベルだけどJavascriptで小細工できるって人が非常に増えた。
高機能なソフトだとスクリプトの需要は増えてる。

にわか対象への売りにはなると思うよ。でも騙しだね。ケレン味たっぷりのパズワード。
スクリプト言語へのインターフェースと型変換の提供は結構面倒。
がんばってシコシコ橋渡しの部分を書いても、
載っかるのはC++やJavaとそう変わりないほど複雑な汎用スクリプト言語。
しかも、VSやEclipseのような便利なエディタも無し。
デバッガなんか有るわけ無いし、運が悪ければ、printデバッグすら無理だったり。
そんな事実を知らない人への売りにならなるんじゃないかな。
Officeのマクロのような開発環境を一式ごっそり用意できるってんなら別だが。
どうせそんな余力無いんだから、大人しく「出来合いのもの」を使えって話。
「出来合いのスクリプト言語処理系」ではなく、「出来合いの開発環境」を使えるようにしろと。

>載っかるのはC++やJavaとそう変わりないほど複雑な汎用スクリプト言語。
そんなヤベー言語があるのか、…知らなかったぜ
メモリアライアメントがどうとかADLとか右辺値参照みたいなことを要求してくるのか、こりゃ地獄だな！

>>529
なんで希望・願望を垂れ流してんの？
スクリプトエンジン組み込んだソフトリリースして一度でもユーザーから
統合開発環境が欲しいとか要望あったか？

>>530
どう考えてもマトモなデバッガが無いほうが地獄だし、
大抵が動的型言語だったりするので、バグ取りはC++よりも複雑。
動的にしか型が決まらないのに、デバッガで追えないって最悪な組み合わせだな。

>>531
欲しいに決まってるだろJK。特にデバッガ。
スクリプト言語処理系を組み込むよりも、
まともな開発環境を提供するほうが余程大変だし、
しかも、開発効率は、言語仕様よりも開発環境によるところが
大きいわけだから、その辺よく考えないと。

だからそんな事言うユーザーがいたのかよ。
あくまでライトユーザー向けの機能でプラグインの代用品じゃないんだぞ。

>>532
そもそもバグで困るような数十行も書く用途じゃねぇんだよ

ライトユーザ向けってのはOfficeのマクロ開発環境のようなものの事を言うのであってだね。

>>532
「複雑な言語はやだね」 → 「まともなデバッガがない方が地獄」　んんん？
ステップ実行と変数内容の表示とかって実装しちゃいけないの？
あれ？存在しないプログラミングコンポーネントに対して存在しないデバッグコンポーネントを引き合いに出すのはOKなんだよね？

簡単なエディタが付いてて外部のファイルでも食わせられるようにしとけば十分。
そもそもユーザーは、できるだけ書かかないで済む方法さがすし、スクリプト機能の存在自体に
不満を言ってきたやつなんて見たことないわ。多少複雑な機能なら要望に応じてこっちが対応する。

ライトユーザー向けの
「コピペ改変がしやすいスクリプト言語」
という電波を受信した

>「コピペ改変がしやすいスクリプト言語」
保守するわけでもないに何か悪いのか？

>>532
>大抵が動的型言語だったりする
別に型推論ベースの静的型付けでいいんだが何かこだわる必要あんのか？

ユーザーがクラスなんか使ったらある意味奇跡
関数定義するだけでもよっぽど
引数に渡す型は、ほぼ文字か数値

そんな状態で型がどうのこうのとか・・・

>>541
ではやはり組み込み向けのスクリプト言語が汎用系に向かうのは間違いですよね。

お前の言う組み込み向けスクリプト言語ってなんだよ
スクリプト言語と何が違うんだ

>>542
スクリプト用言語を用意できるならそれに越したことはない。
既存の汎用言語エンジンをスクリプト用に使ったほうが現実的だから
大体の人はそうしてるだけ。

必ずしも汎用言語が多いわけでもないな
Javascriptの様にモジュールリンケージがなく
拡張しなきゃ単体で使えないスクリプト用言語を使う
ケースも増えてきてる

>既存の汎用言語エンジンをスクリプト用に

それがどんどん複雑化してきてるけど、その方向性どうなのって話なのだが。

だからどうしたとしか言いようがねぇだろ
自分のソフトは汎用言語エンジン使わず気に入るように作ればええがな
好きにしろよ

あれか、俺らに工数や経費、需要を無視してスクリプトに専用言語を使えといいたいのか。
他人に押し付けんなよ馬鹿馬鹿しい。

>だからどうしたとしか言いようがねぇだろ

シンプルって言う、スクリプト言語のメリットがなくなってきてるし、
かといって汎用ではC++やJavaに勝てるわけも無く。
どこへ向かっているんだろうね。

>>548
C++やJavaを使えばよいよ。
今時のスクリプト言語は機能豊富で煩雑さはC++やJavaと大差ないし、
そのくせ開発環境は貧弱だから、これなら、
VSやEclipseが使えるC++やJavaのほうがマシだよ。

使う側・実装する側が楽できて適度に妥協できる方向にむかうだけだろ

>>550
だから他人に自分の希望を押し付けんな。

C++やJavaを使うのが一番らくだね。
使う側はVSやEclipseが使えるし、
実装する側はヘッダファイル用意するだけ。

>>552
何でそんなに怒ってるの？当たり前のことを言っているだけなのに。

他人に意見を押し付けるのが当たり前とかどんな教育うけてきたんだ・・・
あれか名前がDQNネームだったりするのか

俺が何か言ったら、君はそのとおりにしなければならないのかい？
それとも既に後ろめたい気持ちにあって、事実を言われると気づかずにはおれないから困る人？

話が不毛なんだよ

スクリプト言語を組み込むことが不毛になりつつあるんだよ。

むしろどんどん使われてるが？
ミドルウェアは相変わらずC++, Javaが多いとはいえ。

たぶんそういう話じゃない

なんか複数の話題を一緒くたにしつつ、
各人がそれぞれの前提や想定に基づいて相手をやり込めようとしてる感じ。
そろそろ勝ち負け言い出すんじゃないの？

まあ全員で前提条件の合意が取れたら、でてくる結論はみんな同じこと言ってると思うよ。

>>1通り汎用言語使わずに、自前で処理系用意してる人いる？
自前の処理系使った時のメリットってどんなのがあった？
出来れば動機も教えてください。やっぱ組み込み機器向け？

>C++やJavaを使うのが一番らくだね。

わかりやすい例として

・ブラウザをActiveX通してC++で拡張
・ブラウザをJavaScriptで拡張

前者は淘汰されつつある方式です。

ブラウザは基本プラグインじゃなくてアドオン拡張だもんな
AutoCADとかあの辺もプラグインじゃなくてlispやvbaのスクリプト拡張だ
Photoshopも昔からプラグインが使えたが要望が多くて結局javascriptをスクリプトとして導入したし

用途・目的が違うからな。
スクリプトはプラグインにならんし
プラグインはスクリプトにゃならん。

ブラウザはセキュリティーの問題があるからな。
セキュリティー気にしないのなら、開発自体はActiveXの方が楽だ。

ランタイムの問題もある。
SRAのパワーグレスの関数がVCで書けるようになっていたが、
コンパイルオプションが/MTじゃダメだったなあ。
本体をバージョンアップしていなかったら
古いコンパイラを今でも用意しておかないとメンテできない。

>>567
NaCLやJavaAppletはまだしもActiveXは無いだろ。
本質的にどうでもいいことに掛ける作業量が多すぎる。
特にCOM周辺が糞めんどい。

みなさいどんな狙いで作ってます？
私はポストPHPを目指してます。

PostPHPかぐぐったけど見当たらなかった
俺も時代に取り残されてるなぁ

Web専用って意味だろ？

言語仕様とフレームワークが一体なら特化した強みもでるかもな

そんなんブログやWikiとかオンライショップ構築用のアレとかの方が良くね

単に言語仕様と環境が一体化してるならVisualWorksやPharoという前例があってな

言語処理系といいたかったのかな。
仕様と環境の一体化は無理だろ。

>575
つsmalltal...

統合環境が最高って言うのは、
付属のフレームワーク上で作業しているからであって、
そこから外れたら重いだけの糞環境って事になる。

VisualC++だってサードパーティーの
ライブラリで使うときはメリットを感じない。
というかviで作業したほうがラクｗ

viですか。へぇ

nanoがないと今日の日記も書けませんorz

>>577
Visual C++にフレームワークなんて付いてないだろATL/WTL/MFCってな
ファンデーションライブラリと、.Net Frameworkのクラスライブラリを間借りできるだけ。
必要な分だけ自分で書くようなのを目指すならQtとかまともなサードのツールキットが必要だ。

GoogleのV8エンジンっていいな。
だれか本格的にV8でスクリプト実装してる人いる？

V8を使った組み込みとかってどうしてやる必要あるの？
沢山の人に使われているプログラム以外、やる必要ないと思うけど

沢山の人に使われていないから、なるたけ利用者が多くて学習コストの低いJSにするのだ。

JSなどのメジャーな言語を使う理由でなく、
スクリプト自体をアプリに組み込む理由を聞いてるんだろ

>>581の言っているのは、Javascript以外の言語の実装に使う例なんじゃないの?

保守

保守

こんな感じのどう？


function parse(id1,id2) {
　var textarea1 = document.getElementById(id1);
　var textarea2 = document.getElementById(id2);
　var v = textarea1.value.match(/(\/\*|\*\/|\/\/.+|"[^"]*"|'[^']*'|((\+\+|\-\-|)[_a-zA-Z][_a-zA-Z0-9]*(\+\+|\-\-|))|[\+\-\*\/\=\|\>\<\!&%]\=|\<\<\<?|\>\>\>?|\|\||&&|[\+\*\/\=\-\.\[\]\(\)\|\?!\>\<\^\$~#&%{},;:'"]| +)/g);
　var t = '', i;
　for(i=0;i<v.length;i++) {
　　t += i + ' = "' + v[i] + '"\n';
　}
　textarea2.value = t;
}

訂正 数値が抜けてた
match(/(\/\*|\*\/|\/\/.+|"[^"]*"|'[^']*'|((\+\+|\-\-|)[_a-zA-Z][_a-zA-Z0-9]*(\+\+|\-\-|))|[\+\-\*\/\=\|\>\<\!&%]\=|([0-9]+(\.[0-9]+|))|\<\<\<?|\>\>\>?|\|\||&&|[\+\*\/\=\-\.\[\]\(\)\|\?!\>\<\^\$~#&%{},;:'"]| +)/g);

それぞれのトークンの種類も判別できるようにしよう

人がいないな

なにこれ？正規表現でトークン切り分けようとしてるの？
最初見たとき、構文解析してるのかと思って
「だからオートマトンで構文解析はできないとあれ程」とだけ書き込もうと思った。
どちらにしろ汚い。

何でもかんでも正規表現でやるのは気持ち悪いわ。

とりあえず可読性が悲惨なのは不味いんじゃないの
エスケープ一つとっても多すぎる

JavaScriptなのか

メンテしたくねえ

俺Lispコンパイラを作ろうと思うんだが、
コンパイルした後にeva相当のことを行うことはしたくない。

マクロってどういう場合にコンパイル時に解決できない場合があるか、
調べたいんだけど、その辺の議論ってどうやって調べればいいんだろう、

ゴーグルのでキーワードだけでもおしえてちょんまげ。

とりあえずcommon lispのdefine-compiler-macroを理解しといたほうがいいと思うけど。

>>598
ありがと、勉強する

後はhttps://engineering.purdue.edu/~qobi/software.htmlのstarlinやpartialとか

CでCのコンパイラを作ることに、メリットはあるかな。
車輪の再発明か、それとも、ハードの理解を深めるメリットがあると
見るべきか。

CでCのコンパイラを作るとか普通じゃん

既存のＣコンパイラってＣで作ってるんじゃないの？

VCはVCで作られましたってメッセージが出てたよな

新VCは旧VCで作られたって意味じゃないの？

IDEはVC#メインっぽい雰囲気だが
コンパイラは今でも当然VCだろうね

コンパイラの実用を目指すなら再発明だわな
目的次第

Cコンパイラでもどこが作ったコンパイラかでバイナリの性能やサイズが違うって言うし

まあでもこのスレに来てる大半はそのへんのところ
既存のバックエンドに投げるだけじゃないか

バックエンドは人海戦術

>バックエンドは人海戦術
雲海戦術なら昨今のcloud事情的にありそう

MS製のC関連品では、悲惨な目にあった奴もいるみたいだ。
C++の「仕様通りに動かない」とか...。

>>612
具体的に書かないとただの悪口だぞ。すべて伝聞体だしどの仕様だかわからない

むしろ仕様通りで、仕様が酷いことの方が多かったがw
WinsockでOSのバージョンごとに仕様が違う標準的な関数があるとか。

仕様を決めた奴が最後まで尻拭いしてくれる訳でもない

「BASICのコンパイラを作りたい！」
と述べたら、
「おまいは、高級レストランで、カップめんを注文するような奴かw」
と笑われてしまった(泣)...。

BASICコンパイラとか普通にあったと思うけど
笑うような事ではない

レストランの例えは、ちょっとずれてるよな
HDの8mmビデオ機を作りたいと言ってるような話。
しかもBASICは8mmビデオよりずっと古い。

うーん、どっちもどっち。
いずれにせよ現時点でBASICは仕様上すごいアイデアでもない限りありえない。

作るのが目的であって実用しないんでしょ

COBOLおばあちゃん
http://www.theregister.co.uk/2013/03/09/iwd_grace_hopper/

D言語の闇の力を借りれば、COBOLだって高速実行できる処理系ができそう。

D言語でCOBOLのランタイムを作ってさらにコンパイルタイムも作っちゃう。

そりゃ例えばバックエンドにLLVMとかを使えば
高速なコードは吐けるだろうけど

LLVMって仕組み上、CPUアーキテクチャ特化の最適化に勝てそうにないから
実際上、微妙なところがあるよね

COINSよりはまし

>>625
というと？

Low Level Virtual Machine - Wikipedia
http://ja.wikipedia.org/wiki/Low_Level_Virtual_Machine

これは面白いな

AutoHotKey のようなスクリプト言語、またはAutoHotKeyの移植版を
Linux 用に書こうかと思うんですが
どの言語で書けば協力者があらわれやすいと思いますか？
今頭にある候補はJava, C# , Python, C, C++　です

>>625
iccくらいにしか負けてないでしょ？

>>628
専用スレあるよ

【最速へ】LowLevelVirtualMachine【LLVM】
http://toro.2ch.net/test/read.cgi/tech/1211547655/

このスレの住民でLLVMを知らん人がいたのか

そりゃあ、ピンキリの世界だからな。

リフレクションの代わりにアノテーション・プロセッサで
クラスをバイナリ・XML・RDBに変換する言語つくりたいけど
考えただけで気が遠くなった。

君の周りでPEGって流行ってる？

"Mastering PEG" "PEG Cookbook" はまだか？

めもめも

java または jython　にシンタックスシュガーを加えた言語？　を作りたいです

(自作構文を含んだコード) →　[自作変換ソフト]　→（変換済みコード） →　[既成コンパイラ]

という構造にしたいんですが
この自作変換ソフトを書くためにはML系と　Haskellってどっちが簡単でしょうか？
MLはわかります。　パターンマッチの関係で他の言語は考えてませんが問題はないでしょうか？

小さくて読みやすい正規表現処理の実装ないですか……
できればC、C++、Javaあたりで

>>640
DFAエンジンで良ければ↓の１９章はどう？
ttp://www.context.co.jp/~cond/books/algo/

>>641
802行、短い! 見てみます。ありがとうございます。

逆コンパイラ作ってる人、居ますか？

はい。

>>644
逆汗を逆コンパにするのに必要な知識を教えて下さい。

つ [インラインアセンブラ]

パッと思いつくのは
・アドレスにラベルを割り付ける
・関数を切り分ける
・スタックフレームから関数引数・ローカル変数・戻り値を切り出す
・if/for/switchを抽出して構文化する
・DLLからロードされるシンボルを置き換える

解説しているサイトとかあるかは調べてないので知らん

どうせ defineされた定数をマクロ名に戻せないとか
構造体復元が難しいとかあるから大したことはできん

MinCaml(min-caml.sourceforge.net/)ってGC入ってる?

陽にGC入ってるって書いてないだけでGCのコード入ってる?

lua.vm.js
Scala.js
なんかJavascriptが中間言語として凄いことになってきた。

>>648
fdpe05.pptの18ページに実装してないリストがある。
GCも実装してないリストに含まれてる。

>649
最近のはやりはJSをネイティブとして扱ってJSコードをはき出す処理系ってのがあるのでその一環じゃないかと思う。
これとgoogle closureの組み合わせで効率的なJavascriptを生成する感じ

>>651
> 最近のはやりはJSをネイティブとして扱って

いやいやw

>>652
割とマジなんだけどなー
JSをプラットフォームとして扱う傾向にあるの

ネイティブじゃなくてターゲットと言いたいのか?

>>654
それでも違わないけど、Webブラウザ上のネイティブ言語としてのJSっていう扱いなんだよね。
様々なパーティがいろんな言語->JSへのコンパイルみたいな事してる。

なんだかなあ

寧ろ、生JS嫌われすぎだろ？とｗ

仕様が柔軟すぎてカオス

JS向けに最適化されたチップが安く売りだされたら考えてやる

>>655
このスレ的に正しい用語は
「Webブラウザ上の中間言語としての」
「いろんな言語->jsへのトランスレートみたいな事してる」
かな

コンパイルはまあいいと思うけどね。ネイティブはちょっとおかしい。

たぶんJSを目的言語として捉えてるからネイティブって書いたんだろうけど、
まあ気持ちは分からなくもないが……

名前付けを疎かにするとこのように問題がやまないのである

jsにトランスコードとかがこんなに流行るなら、いっそWebVMみたいなのを作ればいいのに

>>662
その通りなんじゃないの？
ブラウザ上で動かすプログラムだとJS以外ないし。(他にあったっけ？)
ClojureScriptのサイトとか読んでもそんな感じだし、Google closureとか通す処理系みてもなんかそんなニュアンスだし。

それをネイティブと表現するのは、わかりやすいようでかえってわかりにくい
Node.jsやWindows Script Hostだってあるし
そもそもネイティブって何だ？って話に

ChromeはNaCLあるしね。
ブラウザ限定でも分かりにくい用法。

> そもそもネイティブって何だ？って話に

いまどきだとx86プロセッサでもx86コードを直接実行してるわけじゃなかったりするしな

むしろなんでJSでやりたがるんだよ
いい加減捨てようぜアレ

Javascriptはブラウザ実装がフォークして混沌としてたけど、
言語自体はそれほど悪くない設計だから流行るのは当然。
人が集中して処理系実装も非常に優れたものが多い。

あれだけ処理系が進化しちゃうと
今更別の言語に変えるとかもう無理だからな…
別言語からの変換をするか、asm.jsみたいなアプローチをするか

>>671
別言語からの変換だけでも結構数でてるからもうしばらくは消えないんじゃないの？
というか2.0仕様だっけ？型導入されたやつとかすら出てきそうにないのが嫌な感じ。

EasyUOからOpenEUOへの変換プログラム作ったら
思いのほかうまく動いてしまったのだけど
これって論文にしたら怒られます？
どんな雑誌に投稿すればいいのかもわからないけど

コンパイラ作ってるんだけど、
字句解析器作ってる間に人生終わりそうなんですけど。
lexつかったほうが良いですか？

さすがにそんなにかかるはずはない
力技でも1週間もあれば作れると思うけど

本に乗ってる奴ならね・・・

>>674
字句なんて１〜２日でできるだろう。
できないとしたら、プログラミングの技能か字句解析アルゴの知識か他の何か、進め方のどこかに問題があるのだろう。そっちを明らかにした方がいい

はいはい、凄いね凄いね。
言って貰いたいんだろ・・・・

じゃあ、１つ質問して良い？
正規表現の構文解析木の段階で状態数を最小にする方法
知ってるか？

>>678
お前みたいな発想だから日本はダメなんだよ

字句解析器を手書きで作るなら正規表現とか使わないんじゃないの？

>>674
lexくらい、フリーで転がっているのがあるんじゃないの。
それとも、何か、特別なこだわりがあるとか。

自作できないなら、フリーで転がっているのを使うか、
周りの経験者に聞いた方が、早いと思うよ。
字句解析の次は、構文解析が待っている。

さらに、もっと面倒なファイル作りとか、最適化も必要なのだし。
「最適化のために、頭を使う」というレベルでないと、先は長いよ。
ファイルサイズを、極限まで小さくすることにこだわるか、あるいは、
ともかく、完成させることを目指して、最適化は、後の研究課題にするとか、
コンパイラ作りをする連中は、主に、その辺で頭をひねったり、悩んだり
しているのではないかと推測されるから。

>>674
自作言語なの？
・識別子・キーワード
・数値
・文字列
・コメント
・その他記号・演算子
※必要に応じて改行処理

こんだけじゃないの？

面倒くさければもう、一文字ずつかえして、
パーサで解析させちゃおうyo

そっちの方が大変だねぇ

>>674
どんな文法なのかでまるで苦労が違うぞ
字句解析と構文解析とが綺麗に切り分けできない言語だったりしてないか？
IF IF=THEN THEN THEN=IF ELSE ELSE=THEN END IF
だっけ?PL/Iで悪名高い文は

インラインアセンブラみたいに
文脈によってキーワードが変わったりするのか

なんか勘違いしている人多いけど
作っているのは字句解析器じゃなくて
字句解析器生成系っすよ

そうなのか？
>>674 には字句解析器作ってるって書いてあるから
言葉通りに字句解析器作ってるんだと思った

コンパイラーじゃなくて自分のアプリのマクロ機能の為に
スクリプトコンパイラーを作る位なんだけど
本格的な言語コンパイラー作ろうと思ったら
lexみたいな解析器生成プログラムとか自作するのが普通？

いまは言語仕様が小さいこともあって、オートマトンみたいなの
力業で手書き
言語仕様はJavaScriptもどきなんだけど、生成プログラムの作り方が
良く分かってないのと、ECMAScriptの仕様の範囲くらいなら
いまのまま力業で実装ってのもありかもって思ってるんだけど

規模よりも変更頻度とかだと思うよ
一度書けば終わりでもう二度と変更しないってんなら、どれだけ大きくてどれだけメンテしづらくても、まぁ、どうってことない
仕様変更がよくあるなら、なるべく変更しやすい形、そうするとlexみたいなのが一番手軽に変えられるから、そうなるんじゃない

字句系なんてそうそう変わるもんじゃない
エディタの構文？ハイライトに対応できる範囲で小さく作ればいい

thx
一応使わないかもだけどlex系の作り方みたいなのは
少し勉強しておきたいな
コンパイラー系は中田育男氏の本斜め読みしただけなんだけど
lex系の処理とかはやっぱりソース読むしか無いのかな？
細かい解説なしに理解出来る気がしない

まずはただの正規表現マッチの実装からやってみたら。
それがわかれば後は混ぜて炒めて塩ふるだけってぐらいに思えるだろう。

>>690
言語は素のJavaScriptにしておいて
どうしてもやりたいことだけJSとのインターフェースクラス作るのが
それを扱う第三者にとっては一番便利だよ

「スクリプトエンジン」って言葉の意味、よく噛み締めてみると
そういう結論になると思う

ちなみにJavaScriptエンジンはどれがおすすめ？

>>694
意外とできあがりに差がつきそうな工程だなｗ

字句解析を忘れていっそPEGで書いちゃうとか

lexの作り方はドラゴンに乗ってる。
ドラゴンのままじゃ遅くて使い物にならないから
改良してるけど。

Lexerは「言語実装パターン」とか参考になったような

参考になります
言語実装パターンは目次読んだらなんだかよさそうでした
電子版もあるし、翻訳技術書としてはかなり安めだし
これ読んでみようかな
ドラゴンは定番みたいだけど難しそうな印象、出版も少し古め？

ドラゴンは難しくないよ、むしろ分かりやすい

ろくにコメントの入ってない「ソース丸ごと掲載」ってのが
苦手な俺には特にありがたい

ttp://piumarta.com/software/peg/
このpeg/legっての触ったことある人いますか？
ちょっとだけ遊んでみたんだけど、トークンの位置を扱う方法が分からないんで教えて欲しいです
とりあえずアクションの中でyytextと一緒に行番号と列番号を表示したい

lex+yacc の仕組みを丸パクリしてるっぽいから
そっちの説明を探せばたくさん出てくるはず
flex+bisonでもいい

2年くらい前に見た時はポシャったプロジェクトと思っていたけど
しぶとく続いてたんだな

ドラゴンブック見て字句解析器生成プログラムを書いてみたんだけど、サイズが大きく
なりすぎる傾向があるので、手書きしたほうがいいような気がした。
もちろんいろいろ工夫する余地はあるんだけど、手書きする手間をかけても良い部分と感じる。
逆に構文解析器は自動生成でもいいかなと思う。

JavaScriptのV8エンジンの文字列処理の最適化について教えてください
例えば、
var s = "";
for(var i=0; i<1000; i++) {
s = "s" + s + i + "e";
}
のようなコードをCやほかの言語で実行しても
V8エンジンほど速くはならないのですが、
V8エンジンは内部でどういう最適化をしているのでしょうか？

文字列処理の最適化より
配列処理の最適化した方が良い

つーかスレ違い

V8はがべこれしてない

>>707
関係無けど、こういう原理的にはコンパイル時に決定できる最適化関係はV8エンジンは異様に強いよね

>>707
Cでどんなコード書いたのか気になるところ

Cのコード
#include <stdio.h>

char buf1[1000000];
char buf2[1000000];

char *bench(int n)
{
int flag = 0;
int i;
char *p1, *p2;
buf1[0] = '\0';
buf2[0] = '\0';

for(i=0; i<n; i++) {
if(flag) {
flag = 0;
p1 = buf2;
p2 = buf1;
} else {
flag = 1;
p1 = buf1;
p2 = buf2;
}

sprintf(p1, "s%s%de", p2, i);
}
return flag ? p2:p1;
}
続く

続き
int main()
{
int i;
for(i=0; i<2000; i++) {
printf("%s\n", bench(i));
}
return 0;
}

JavaScriptのコード
function bench(n) {
var s = "";
for(var i=0; i<n; i++) {
s = "s" + s + i + "e";
}
return s;
}

for(var i=0; i<2000; i++) {
print(bench(10));
}

環境
OS: Fedara 19
CPU: Core2 Duo T7500 (2.20 GHz)
gcc 4.8.1
glibc 2.17
v8 3.14.5.10
コンパイルオプション
gcc -O2 -march=native bench.c
結果
time ./a.out > /dev/null

real 0m12.917s
user 0m12.900s
sys 0m0.010s

V8結果
time d8 bench.js > /dev/null

real 0m0.063s
user 0m0.044s
sys 0m0.012s

こんなに違うのですがどういう最適化をしているのでしょうか

関数benchで副作用が(関数内で)閉じている事はコードを静的解析すれば分かるから、
V8処理系が自動的にメモ化しているのではないかと思われ

def bench(n)
　　s = ""
　　for i in 0..(n - 1)
　　　　s = "s" + s + i.to_s + "e"
　　end
　　s
end

MEMO_BENCH = Hash.new { |hash, key| hash[key] = bench(key) }　　# メモ化
def memo_bench(n)
　　MEMO_BENCH[n]
end


def run(n)
　　t0 = Time.new
　　for i in 1..n
　　　　yield
　　end
　　t1 = Time.new
　　p (t1 - t0)
end

N = 2000
run(N) { bench(10) }
# => 0.358945
run(N) { memo_bench(10) }
# => 0.016584

Cがbench(i)で
JSがbench(10)なのはここに書き込む際のミス?
bench()内のループの実効回数が100倍くらい違ってくるんだけど。

というか、sprintf() 使っている時点で勝負ありだろ

Cのsprintfもprintfも外部ライブラリの関数なので
インライン展開が効かない
2000回のループをひとまとめにすることは出来ないしdenchの
呼び出しのsprintfの引数に与える変数をコンパイル時に決定することも出来ない
対して、JavaScpiptのコードは組み込み関数なので
実質的に全てを展開可能で、最大限に最適化した場合に
print("s0e\ns1e\n......
のような一行だけ実行するかも知れない
Cで最適化が効くように書く事は可能かもしれない
ただ、言語に組み込まれた組み込み関数がある事は
最適化にとって有利なのは間違いないだろう
少なくとも例示された書き方は、Cの速度を評価するには
余りに不適切な書き方ではあるし、Cで意図した処理を
JavaScriptより高速に書くことは常に可能ではある
（手動最適化を含める必要がある場合はあるかも知れない）

>>720
>Cで意図した処理をJavaScriptより高速に書くことは常に可能ではある

Rubyにはクロージャとしてのブロックがあるので、
>>717で示したようにメモ化を用いた高速化は容易に実装できる

Cの場合にはクロージャが無いからRuby同様なメモ化は実装できないが、
代わりに「遅延データ構造」という手法を用いれば実装できる

ただし、遅延データ構造による実装が「常に可能である」か否かは知らない
おそらく対象が何らかの代数構造を満たす必要があるだろう
少なくとも今回のお題の(対象としての)文字列はモノイドなので、これを満たす

>>717
ではbench(10)をbench(i)になおした以下のコードもV8 Engineではメモ化されるのでしょうか。
これでも先ほどのC言語のコードより速くなった(0.462s)のですがどのような最適化によると思われますか？
function bench(n) {
var s = "";
for(var i=0; i<n; i++) {
s = "s" + s + i + "e";
}
return s;
}

for(var i=0; i<2000; i++) {
print(bench(i));
}

717じゃなくて悪いけど、逆順から呼び出してみ。
for(var i = 2000; i-- < 2000; ) { print(bench(i)); }
これで実行時間が変わらないなら事前計算された文字列をハッシュテーブルから
引いてるんじゃない?
大幅に遅くなるなら、実行結果をキャッシュして次の計算に使用してるんでしょ。
bench(10)の結果はbench(9)の結果を使って計算できるんだしさ。
そういう風にCで作ったら、bench()呼ぶ毎にmallocでメモリ確保しても
ゴミCPU(C-50)で853msだったし。

あ、ごめん。i-- < 2000 じゃなくて i-- != 0 で。

>>724
0.168sでした
事前計算というのはどういう手法なんでしょうか？

これで
http://codepad.org/CZldxktk

$ gcc -O2 -march=native main.c -o main
$ time ./main >/dev/null

real 0m0.001s
user 0m0.000s
sys 0m0.000s

こうだった

あぁ、ちょっと勘違いしてた
http://codepad.org/hiJz0zt5
こうだな
real 0m0.063s
user 0m0.061s
sys 0m0.001s
printf呼び出しが冗長だから、それを少なくするように書けば
いくらでも速くなると思う。（メモリーとの兼ね合い）
多分処理時間の大部分はIOで食ってると思う
これを取り除くとCPU時間はほとんど０に近くなるんじゃ無いかな

>>726
それ実行結果違わね?

>>725
むしろ速くなってるね。
コンパイル時に引数に対応した文字列のテーブルを作っておいて
bench内ではテーブル引いて返すだけって意味で事前計算って言った。
たぶん717のやってることだと思うんだけど、こういう言語
触ったことないからわからん。

>>727
[30, 40]行目をこれと交換して
char* p2;
p = buf;
p2 = buf + n;
for(i = 0; i < n; ++i) {
*p++ = 's';
_itoa(i , &p2);
*p2++ = 'e';
}
*p2++ = '\0';
puts(buf);

ごめん。これじゃだめだ。

あ、だめじゃなかった。ほんとごめん。

>729
thx
40行目のnullターミネィトだけ必要ですね
putsの方が速いか

>>729
人間が処理を理解して工夫すれば、
このようにとても早いアルゴリズムに直せると思うのですが、
V8のスクリプトエンジンなどは's'の並びがbufからbuf+nまで連続することに
あらかじめ気づくのでしょうか？

何とかJSの速度を超えられないかと思ってC++で
std::string s;
for(int i = 0; i < n; ++i) {
s = 's' + s;
std::ostringstream os;
os << i;
s += os.str();
s += 'e';
}
とかやってみたけどさ、全然遅いのよね。
速いアルゴリズムに代えられることに気付いているとしか思えない速さだと思うよ。
この分野さっぱりだからさ、アドバイスはできないんだけどね。ごめんね。

あぁこう言うことか
http://codepad.org/rSzsp8sE

これで良いんだよね？

V8 Engineはバッファの基点をbuf[0]にしないことで
for(...) {
s = S + s + E;
}
という文字列処理の最適化を行っているんでしょうか

V8エンジンってのはそんなに凄い物なの？
ちょっと聞いたことが無いんだけど
この程度の最適化を自慢してるくらい何だから
作ってる奴らは
どうせ口ばっかりでたいしたことない奴なんだよ
おれなら10倍高速に書けるのに

>>737
針デカ過ぎです

コピペかと思ったら違った

まぁ、そもそもコンパイラーなんて書く気も無い
ワナビーはそろそろ場違いなんでお引き取り願った方が良いのでは

ごく普通のBASIC的なスクリプトを作って実行するとHSPぐらいは行ってるな。べんちとると。

ポジショントークだよな。
>>734とか速いわけがないコード出して遅いっていう意味がわからないもの

あああ

http://katahiromz.web.fc2.com/mathai/mzcalc1.zip

これをC++のプログラムにしたいんだけど、どうすればいいかな？

lexとyacc通してcにすればいいんじゃないかな
そういう意味じゃないってんならlexはともかくyaccの方はコンパイラコンパイラでC++に落ちる奴使えばええんでないの？
あるいは文法規則をc++のtemplateで生成する奴使うとか

そこで具体的なツールの名前が出てくるのがこのスレなんじゃないの

>>746
前スレだか前々スレにcaparってのが紹介されてた
このスレでも>>462でちょろっと名前が出る
ただ文法規則は違うんだよね、移植は必須

やはりBison++は互換性に問題があるようだ。さらにWin32では新しいバージョンが用意されていない。

結論：Bison++は使えない

どのみちそんなもんラップして使うだろ
C++のライブラリに拘る意味がわからない

一つのプログラムでパーサーが２つ以上必要なときや、再入可能じゃないといけないときは、困るだろう

ドキュメントくらいしっかり読めよ
YYPARSE_PARAMなんて基本中の基本だぞ

その用途で解決策が乏しくて不満が出るのは普通はFlexの方だ

>>750
お題程度ならC++でゴリゴリ書いても良いじゃんよ
元の目的がはっきりしてないから質問の答えだって迷走すらぁね

staticにするなり、defineで別名にするなり、手で別名にするなり、どうとでもすればいい気が…
そのまんまC++に持ってって動くコードなら適当な名前空間などで括るとかどうにでもすればいい

lexer と parser の協調動作（parser 側から lexer のステートを切り替えるとか）が
必要な場合、何かお薦めの方法ある?
yacc とかが生成したパーザだと、先読みの可能性を考えながら文法書くのが辛すぎる。

先読みが問題になるって事はreduce以外のタイミングでlexer側のステートを切り替えたい要件？
それをyacc系でやるのは茨の道かな…切替タイミングをreduce時に絞れるなら何とでもなるけど
それ以外はケースバイケースでアクロバティックになる事も割と多かった気がする

LRパーサをやめてANTLRとかに走ってみるとか

keyword_or_identifierみたいなトークンに織り込んでしまえ
汚くなるけど一貫した方法で処理できるからスキャナの状態触るよりはマシ

>>755
LR パーザの動作をちゃんと理解している自信がないのだけど、
LR(0) でない限り、 reduce のタイミングでも次のトークンが
食われてる可能性はあるような。
先読みせずに reduce できることが一意に決まれば先読みされないはずだけど、
綱渡り感がすごい。

>>756
LL 系パーザでも、パーザジェネレータを使うと先読みのコントロールが
利用者から奪われるのは変わらない気がする。

>>757
過去、二回くらい試して挫折した。たぶん一番正しい方法なんだけど、
スキャナが余分なトークンを生成する（空白文字の取り扱いが変わるため）ことで、
文法が LR(1) に収まらなくなるという…。

> 先読みせずに reduce できることが一意に決まれば先読みされないはずだけど、
ごめん。これ嘘。
もちろん実装依存ではあるのだけど、現実的には常に先読みされていると
思っていいのかもしれない。

http://katahiromz.web.fc2.com/mathai/mzcalc2.zip
Boost.Spiritを使ってみた。変数への代入ができないよお。
助けてよお。

終端記号にトークンを必要としない文法ならreduceのタイミングでは先読みはないよ
Bisonなら吐かれた制御ロジックや表を理解しなくても詳細ファイルを出力させるだけで大体そこは読み取れる
ただし先読みを行う行儀の悪い実装が無いとは言えないし、
parser上の先読みは無くともlexer上の先読みの話は残るので文法によってはyyunput()等での調整は必須になる

終端記号にトークンを必要とする文法ではlexerへの干渉内容次第でyacc系での実装が無理筋なのはその通り
一応色々対策はあるけどそこまで来たら文法と手段の見直しが先決

Boost.Spiritは難易度高いよな。。。

スキャナアクセスが考慮されてるパーサジェネレータもあった気がする

%option reentrant と %pure-parser(再入)と
%glr-parser(LALRじゃなくGLRによる衝突遅延)と
%x (スキャナの状態)

Flex+Bison で何が不足か

Boost.Spirit V2は難解すぎ。アクションメソッドがconstで何ができるっつーんだよ。
BisonはGPLに汚染されていてC++への対応が悪い。
消去法でANTLRが良さそうなので使ってみるか

Bisonは大して不満ないけどFlexの足回りはやや進化が遅い気がする
前使った時に泥臭いなと思ったのは入力ストリームを一度割り当てて読み切った後に
他の入力ストリームに交換してクリーンリセットする正規の手段がない事と翻訳単位変数依存がある事

あの時は.l側にyy_init=1やyy_start=0等を実行する小さな関数を作って%initial-action他から
実行させて凌いだけど、最近のバージョンは正規の手段準備されたんかね

>>762
Caper使えよもう

Bisonが吐いたコードまでGPLに感染するわけじゃないだろ
C++はわからんな･･･結局Bisonが吐いたコードをC++のコンパイラが処理できれば足りるはず
アクションにどこまでC++を書けるかはやってみたこと無いからわからん

まあANTLRなら戦えるだろう

シェルを作ってみたい

一瞬で作れる

ANTLRWorks 1.5.2ゲットだぜ！

>>766
re2c 使うべし。

サンクス、こんな流れがあったのか、それも結構前から
個人的には近年のツールなのにきちんとCをサポートしてる所がいいな
Flex同様ドライバの一部にも多種の組み込みにも使える余地を残してると

Flexの長所と短所を踏まえて作られた流れみたいだしその内試してみる

ANTLRv3で!ってどういう意味？
v4でどう書けばいいのかわからん

ANTLR3でbacktrackが必要な文法だとFOLLOW_set_in_問題が
発生して死ぬ可能性あり。詳しくはFOLLOW_set_in_でググれ。

Cパーサーを作成中。

識別子の解析でreduce/reduce conflictが起こってしまうよ。助けて偉い人

とりあえず関数の中を全部捨てて一通りパースを通すのがいいんじゃまいか
関数の中はむずかしいｗ

あるいは typedefを捨てればチョー簡単になる

わかった。typedefにある識別子は型名と見なしていいんだな。

ああ、typedefがあるおかげで、識別子が型名に化けるという問題か。
Cだと確かアドホックにやるしかないんじゃなかった？

Javaの場合確か文脈によって区別できたと思うけど。

Javaにはポインタがないというさりげない工夫

それ、この話とどう関係が？

Javaは関係ないだろといいたいのか
何でポインタが出てくるのかわかんねーといいたいのか
コンフリクトが解消できません

識別子が型名に化けるので、文法がLALR(1)のようなシンプルな範囲に
厳密には収まっていない、ということと、Javaにはポインタがない、ということに
関連はありますか、ということ。

よくわからん話題だな。俺はchar[]を１文字ごと解析してる。

javaアプリに組み込むインタプリタを作りたいのだが、
それは諦めて、スクリプトを自作パーサでjavaソースに変換し、
javassistで実行中のjavaアプリに動的ロード＆実行しようと
計画を立てたものの、一向に進まないやｗ

>>785
LuaJava
luaj

>>785
思い切って機能を端折って、とにかく動くものをエイヤで作らないと、いつまでも進まないと思う。
ひとつめは捨てることになろうとも、とにかく作れ。

>>786
javascriptとかPHPみたいにcharも触れない言語は糞なの。

>>787
まずはクラスとか捨てて関数とプリミティブ型と文字列でコンソールにhello worldやな。

LispやForthみたいなParserなにそれ？みたいなのからAlgol系みたいなパーサが楽なのからやらないでいきなりC++みたいなキ印パーサとか正気とはおもえない。。

お前の書き込みは如何なるパーサーでも解析できない

C系は構文解析と意味解析が綺麗には分離出来ず、パーサからレキサへのフィードバックが
必ず必要になる(寿命管理のおまけつき)から目的を問わず最低開発コストは高いよ
原始的なC構文だけでもエラーや回復、構造体や共用体、ポインタの咀嚼までgdgdにならず完走するのは一仕事

でもこの辺一通り実装出来なきゃCパーサとしては使い物にならない

つかみんなCの新しい実装をつくりたいの？

楽しいよ？
C90ぐらいだとけっこう手ごろな規模だし

トークンを区切るところまでできた。
まずは関数単位でブロックに分けてみる。

関数の中から先にやるといっているのだろうか

>>785 の続きか。すまないわすれてくれ

Cパーサのプロトタイプができたよ！！！！
http://katahiromz.web.fc2.com/mathai/cparser2.zip

暇だったら見てやって下さい

>>796
うん。関数の中以外を分けてブロック化した。

do main : int {
return 0;
}

class A
{
do hello(){}
var i : int;
class B { enum C { a, b, c} }
}

こんな感じのものから、ソースファイル内にある
クラス名・メンバ関数名・メンバ変数名を全部抽出する。
冗長になるけど、関数宣言はdo, 変数宣言はvarを付けて分割しやすくした。

javassist練習中。スクリプトがmain()メソッドひとつで完結していれば
なんとかなりそうだけど、他の関数を呼んだりクラスを後に追加するに
あたってはまるで見当がつかないや

java (スクリプトロード前)

class ScriptRunner {
..void load(String script_file, String script_main){}
..void go(){
....// nothing
..}
..void unload(){}
}

script側

do main(){
..log <= "hello"+" & "+"world";
}

java(スクリプトロード後)

class ScriptRunner {
..void go(){
....Log.log("hello"+" & "+"world"); // changed
..}

..void load(){} void unload{}
}

__attribute__のパースに失敗する。reduce/reduce conflictが大量に発生する。大変難しい。

__attribute__を文法から除外することで解決した。

SLR文法であるような現実的なプログラミング言語って何か例ある？

なんでわざわざSLRにこだわるんだ？
SLRと状態数がほぼ同じで、より広い範囲の文法を扱えるLALRがあるのに

じゃあGLRの教科書教えてください。

GLRはamazonで検索すると出てくるよ

あんがとあんがと。

CD GLR385760 ハイドン弦楽四重奏曲選集/スコア&パートセット (2003/2/25)
現在お取り扱いできません

こんなのしかない・・・

「コンパイラ」とかで検索かけて商品説明で自然言語とか扱ってるのを買えばいいんじゃね

やあみんな、Scala開発者のための新しいopen-sourceのPEGパーサライブラリ−
"parboiled for Scala"を紹介しよう。Scalaのパーサコンビネータに似た内部DSLで
PEGパーサを作ることができ、以下の優位点を持つ。
　・パーサ規則作成と、入力の解析とがきれいに分かれているので、速度が速い
　・親切なエラー報告機能がある
　・シンタックスエラーがあってもエラーリカバリして、最後までパースできる

GLRって日本人が考えたんでしょ？
なんで日本語の本が無いの？

すげえ！まるでbisonだ！

PEGはメモリーを使いすぎることと、構文規則を書くときに左再帰が
許されないのが弱点だって。
左再帰は自動除去も考えられるけど、メモリーはどうなんだろな。

何百メガもあるようなソースを処理するのでなければ今時問題ない。

@jonigataさんのCaperが劇的に高速化されたらしいぞ！！！
github.com/jonigata/caper

PEG/Packratのメモリ使用量ってソース規模の関数？そうだっけ？

バックトラックで数百メガ使うことはないだろ
右再帰だと関数とかの単位でけつまで抱え込むみたいだが

メモ化で大量のメモリを消費する

テキストの長さに比例しただけのメモリの消費を、今時「大量」とか言う奴は、
物事の感覚がおかしい。

Packratはもちろん空間計算量O(n)ではあるんだけど
文法によっては入力テキストの100倍とかメモリを消費するので……
たかが比例する程度だから問題ないと言えるほどでもないと思う

このスレがワードの文字カウントで108881文字ある。
てことは、仮にUTF-8だった場合、300KB位じゃないの？
sjisだよとかそういう話じゃなくて。
PEGで書かれたHTMLパーサがCGIで使われていて、同時に100人がアクセスしてきたら
とか考え始めると、やっぱりメモリーも大事なんじゃないのかな。

あと、PEGの本紹介してください。
ドラゴンブックは読んで、自分でLALRパーサジェネレータまでは書いた。
100年かかった。
10年で出来るPEGの本があったら教えて！
メモリーを心配してるのは、字句解析器が吐くコードがやたら大きくなるので、
こりゃまずいと思ったから。

IDの所為か人がいなくなった。
地球には自分一人しかいないような気がしてきた。
みんなどこ行ったんだ。

元から人口はこんなもんだった気がする

2月3月の書き込み多いやん。このスレ的には。

>>814
ブログとgoogle codeしか見てなかったthx

GitHubのCaperって今の時点で2つしかwatch無いのね
watch入れてない自分が言うのもなんだけど。(だって入れなくてもcloneできるしー)

注視しているならwatchをonにした方がいい。作者にも情報が伝わるし気合いが入ると思うから

>>826
Pull request出してるのみたお
応援するお

何で突然設定変更？と思ったら勢い5以上のスレ限定で告知とかやってたのか
何かお前は板の住人じゃないって言われてるみたいでちょっともやっとするなー

全スレに貼る労力を考えたら仕方ないのかも知れんが

Caperって、コメントアウトしてあるけどLR文法を受理するパーサーも出力できるんだね。
ちょっとソースコードいじってみようかな。
いまどきLALRにこだわる理由もないし。

>>829

ごめん、そのアルゴリズム考えた人に「うまく動かないんだけど」って
連絡したら、「そのアルゴリズムバグってる」って言われたんで
潰した。手元のバージョンでは消してあります。

おお、お久しぶり、っていうかCaperを自己紹介した時以来？
あのときから時々ではありますが、パーサが必要なときにいつも使っているので感謝してます。

LRを考えた人って言ったらKnuthか！

結局、LispやForthのような構文解析が簡単な言語には
BASICのようなインタプリタは速度面で勝てないのだろうか。

>>833
構文解析なんか最初の一回きりだろう？
構文解析が原因で実行速度で追いつけてないのはインタプリタの設計で毎回パースするようなアホな事してるかじゃないの？

BASICは解析結果を別ファイルに保存しておく機能がよくあったじゃん。

>>831
ありがとう、使いづらいところがあったら教えて下さい！
今なら対応できるかもしれません。
（最近片山さんに煽られてエラーリカバリ実装するために
ソースほとんど全部読みなおしたところなので、把握出来てる）

>>832
david.tribble.com/text/honalee.html
これです！　うまく動かなかった！

>>830
返信と現状の情報ありがとうございます。
ドラゴンブック読んだら自分でもLRくらいなら実装できそうなのでがんばってみます。

Caper の FUTURE WORKS の項目に EBNF の対応が課題としてありますが、
kp19pp では (group) / ? / * / + による修飾に伴って型とセマンティックアクションを指定し、
内部処理ではそれらを一種の Lambda 的な扱いで解決しています。
これらを参考として Caper 組み込んで下さるといろんな方達が助かります。

>>838
じゃあ何でkp19ppを使わないの？

kp19pp を作った人が死亡したからです。

勝手にシンデレラ

死んでても使えませんか？

ちょっと良く覚えてないですが、
EBNFに対応するにはstd::vectorとか特定のデータ構造が必要になるなと思って、
セマンティックアクション側に特定の構造を期待しないcaperとしては
実現不可能だなと思ってやめた気がします。

今だったら、variadic template使えばいいかな？

いやvariadic template使っても難しいかな……
SemanticAction側の条件を厳しくする以外に
いい仕様が思いつかない

あ、次の引数を受け取る関数をセマンティックアクションに渡して、
セマンティックアクション側はテンプレートで受け取ればいいのか。

struct SemanticAction {
template <class F>
void SumList(F f) {
std::vector<Value*> a;
Value* v
while(f(v)) {
a.push_back(v);
}
}
};

こんな感じ

質問っす。

インタプリタのVMについてです。
明快入門　コンパイラ・インタプリタ開発を読み終えましたが、
バイトコード生成から命令実行のスイッチまでのあたりで、
あれよりいい方法はありませんか
また典型的にはどの様に実装されますか

規模と寿命と使われ方、他にもターゲットマシンの性格によって使い分けるんでその質問に的確に答えるのは難しいんじゃないかな？

>>845ですです。

プラットフォームは当分x86ですが、
場合によっては移植できるよう機種依存コードはできるだけ書きたくありません。

目的は、インタプリタの実装の学習とテストです。

「いい方法」とは具体的には、速度と拡張性のことです。
まだ、有名どころのコードを読むまでのスキルがなく、参考にすることができません。

参考書籍の紹介だけども助かるのでお願いします。

だけども->だけでも
です。

LR系のテーブル/オートマトン作成方法って調べれば調べるほど出てくるな。

>>847
VMの高速化技法っつってもJITもあれば言語が動的オブジェクトへのメッセージ送りもってれば辞書キャッシュとかVM命令の粒度変更とかいろいろある
学習が主題かつ他人のコードを読みこなせないのであれば数こなすとか、出てる本片っ端から(外れもあるんだけど)読むとかから手つけておくのが一番の近道だと思うぞ

ebnfブランチ github.com/jonigata/caper/tree/ebnf で
EBNFを実装してみた（C++ジェネレータのみ）ので暇な人いたら人柱募集。
使い方はsamples/cppのlist0, list1, list2, optionalを参考のこと。

list2のスラッシュオペレータは独特のやつで、
X/Yと書くと X Y X Y XにマッチしてYを捨ててXのリストを返す。
引数リストなどに使う目的で作った。
カッコは役に立つところが思いつかないので実装してない
（今のところ実装する気もない）。
というか実用的な言語ではスラッシュ以外ほとんど使うところないと思ってる。

出力されるパーサ・ジェネレータのソースはより読みやすくなったはず。

EBNFってCaperみたいな強い静的型付け言語の機能を利用したものだとYaccみたいに全てを諦めるしか実装方法ない様に思えるんだけどどうなの？

とりあえずイテレータ対とかboost::optional的なものを返すようにしてみたよ。
それをどう使うかはセマンティックアクション側で勝手にしてね、的な。

template <class S>
int Document(const S& x) {
for(typename S::const_iterator i = x.begin();i!=x.end();++i) {
}
return 42;
}

こんな感じで受ける。
なぜかrange-based forは使えなかった。
返すイテレータの実装が悪いのかな？
誰かに添削して欲しい。

あ、気のせいだった。普通に使えた。

template <class S>
int Document(const S& x) {
for (const auto& y: x) {
}
return 42;
}

これで受けれる。

マイクロソフトが、MS-DOSとWordのソースコードを一般公開したらしい。
サイズはなんと、300kb未満。(2014年3月26日)

「MS-DOS　ソース公開」で検索。これは参考になるかな?

アセンブラ読む気あるの？

アセンブリ

アセンブル

EX10

確かに、公開しても、あるいは昔のCPUで簡単としても、
解読する暇はないな。意外な盲点だった。

MS-DOSの頃なら大半はC記述じゃないか？
前身のMSX-DOSの頃ですらM80/L80/Cと一連の移植ツールセットを売ってたし、
いかにもCP/Mベタ移植っぽい効率の悪い動きしてたからな

> 前身のMSX-DOSの頃

単に事実誤認。
MS-DOS 2.0 のリリースと MSX の誕生が 1983 年。

関係ないけどjonigata氏を今まで20代後半くらいかなと思ってたら全然違った

>861
MSX-DOS出たときにMSDOSはとっくに存在しとるじゃないか。
PC98でMSDOS上のCross AssemblerとかカノープスのZ80ボード経由でMSXのソフトとか開発するの普通じゃん。

>>859
むせる方か、東芝の12ビットチップの方かどっちだ？

>>864の言ってるソフトの括りは偏ってる気がする

I/O直叩きや高速性が求められるゲームなんかは当時はほぼ機械語でゴリゴリ書くしかなかったが
DOS系コード(チップ制御以外)は違いますがな、性能より開発コスト重視で割と酷い動きしてたじゃん
システムコールのレコード長周りとか

MSXDOS.SYSやCOMMAND.COMのレジスタの使い方はコンパイラの匂いしてた記憶あるな。
MS-DOSもそうなってるかまでは知らんけど。

省メモリ最優先なんじゃないの？
COMMAND.COMは所詮オプションだからCで書けるかも知れんな

主要部分は640Kの最後のほうに置いて、下位アドレスに常に常駐するメモリ量は
最小限にするとか、COMMAND.COM だってけっこうエグいトリック使ってるよ。

>>865
そうなのか?,あの頃ってMSX単体開発するのにMSXDOS出るまでって相当厳しかったんじゃ？
ASCII編のアセンブラとかもMSXDOS前提な書籍とかあったし。
おいらは若松のCP/Mマシンに9918AとPSGつないでMSXのソフト作ってた
タイトル言うと即バレするので書かないけど2つ程ROMカセットで売って貰った、98でクロスアセムでもROMエミュ持ってたらそっちの方が楽かもしれないと思った。

っていうかこれスレ違いだなぁ orz

いらん話題持ち込んで糞スレと化したw

>>868
その手のCで書き辛い部分はDOSに関しちゃごく一部だから、そこだけ別ルーチンで書いてリンクすれば終わるよ
容量制限の厳しいROMBIOSなんかはMSも涙ぐましい努力してたけど、DOSにそこまでの対効果を見込んだかどうか…

まあここでゴチャゴチャ言うより誰かDLして確認すれば正確に分かると思う

>>869
ここで言ってるDOS系コードはDOSの構成要素である各種コード群や
その上で動くソフトの事で、それらはCを排除する絶対的な要件って無かったよなって話
単体開発とかMSX限定とかそういう話じゃないよ、それらで大半を機械語で書く必然性の話

ダウンロードして展開してみたけども、
msdos\v11source\ の中は *.ASM が7個と Tim_Paterson_16Dec2013_email.txt というテキストファイルが 1個。
msdos\v20source\ の中はファイル118個中 *.ASM が丁度100個、Cで書かれたソースコードは無し。
以上

>>873
今の時代でも、参考になりそうなテクニックは網羅されていたかな?

>>869
御冗談を
MSXでMSX-DOSのシステムコールが必要なソフトなんて
グラフサウルスくらいしかしらないんだが

MSX-DOSのシステムコールどころかBIOSすらほとんど使ってないはず
市販ソフトはほぼ自前で実装でしょ
MSX-DOSが無いと厳しいという話は聞いたことが無いなあ

ソフトの実行じゃなくて開発の事を言ってるんだと思う
DOSが必要だったというかメモリが64KB使える環境でないとメガROM以前の
16KB/32KBROMの開発すら無理だったと言いたいんじゃないかな

http://ascat.jp/tg/tgd3.htm

ただMSX-DOSには多分一般リリースされた日と一通り仕上がった日に結構な開きがある気はする

MSXはシステムコールの実体を全てFDC-ROMが供給という特殊な構成を取ってるから(なのでDOSが
無くとも全てのシステムコールが可能)、初期にFDD付きMSXを売ってたナショナルやヤマハ等の
ベンダー向けに出回った内製のMSX-DOSがあって、FDC-ROMの雛形と一緒に本体開発前に配られてたのでは
でないとROMのデバッグが相当面倒臭い事になる

いい加減にスレ違いと気づいて呉

まぁこういった話は正確なことを残しておかないと間違いが後に残る

残しておく価値もない

残すべきスレはここじゃない

シリコンコンパイラ作れる猛者はこんな所に居るかい？？？
居る訳ないよね？ とっくにカメラメーカーの研究所とかに就職してるよね？

つらそう

PEGとパックラットについて知りたいのですが、
オライリーの言語実装パターンっておすすめですか？
記述が少しあるようなのですが。

LLVMこそ至高
ならば全人類のためにLLVMのシリコンコンパイラを作ろうではないか

はい

シリコンコンパイラ、何かと思ったら…研究費ふんだくってくるためのネタみたいなやつやな

ハードウェア記述言語の言語処理系のことを昔はそう呼んでたと思うけど、
それとはまた違うものを最近はそう呼んでるの？

Caper更新ｷﾀーーーー！！！

test

［速報］米マイクロソフト、C#／Visual Basic次世代コンパイラ「Roslyn」を
オープンソースで公開。独自言語など開発可能に。Build 2014
ttp://www.publickey1.jp/blog/14/cvisual_basicroslynbuild_2014.html

MZたんがんがってるなぁ
mergeしてるjonigataさんも大変かも

シリカコンパイラ

>>890
開発部隊がバラバラだから、JavascriptもC++(/CLI)も含まれてないw
だせえ

アホか
Roslynは現在C++で書かれているC#とVBのコンパイラをブートストラップで書き直すことで
メタプログラミングに使いやすくするプロジェクトだ

何のために公開すると思ってんだという話

社内にはC++やJavascriptのプロジェクトはないんだろうな。
C#とVBとその二つへの埋め込みDSL以外はドキュメントでも触れてないから。

つうかc#もjavascriptもまだ未完成で
perl6とかmozilla tamarinとかdehydra gccとか
ウヤムヤプロジェクトになってもおかしくないレベル。

>>896-897
とりあえず完結した入力文法持ってる言語ってFORTHとLISP以外ないんじゃないの？

>>897
間違えた。
javascript→VB

未完成ってのは仕様が固まってないじゃなくて
実装が不十分ってことかい

仕様もないけど。
実装=仕様の状態だから。
AST, APIが不完全。

rubyでつね

roselyn APIのことね。
C#とVBのbindingがあってそれぞれの言語が対象になってる。

x86のintrinsicのまとまった情報が欲しい

この辺かい？

アセンブリ命令
http://www.intel.co.jp/content/www/jp/ja/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462.html?wapkw=x86+manual

Intrinsic
https://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/index.htm#GUID-28F49E4A-615D-4373-A36E-C8A92E913325.htm

>>905
ありがとう。助かった。

CaperにちょっとしたC言語ソースのパーサのサンプルを追加しました。
興味があったらご覧下さい。
https://github.com/jonigata/caper

lexerの自動生成って必要?
ANTLRみたいなタイプならともかく、flexみたいなのって
よほど単純な言語でない限りは余計に複雑になるしデバッグもしづらくなる気がする

必要ないものは使わなければいい。
parser generatorも同様。

そらまあ慣れてればパーサも手書きで十分だろうけど

LALR手書きできるスキルがあれば…orz

Caperにスマートポインタサポートを追加しました。

はいはいはいはーい質問でーす

処理系のVMについてですが
オペコードはスイッチ文(switch, if)で一つずつ分岐するのと
命令一つ一つを関数でつくりそれを実行するのではどちらが早いですか？
ちなみに処理系はCでできています

おながいします！

>>913
実測値を信じろ

名前どうしたw

>>914
大手スクリプト言語どっちなんじゃ？

>>913
タイトなとこだけ展開。
昔のJITじゃないVMの読むと結構出てくる。
https://sites.google.com/site/io/dalvik-vm-internals
ちょこまかとした書き換えがすごく効く。
gotoとかloadとか小さい命令で。

>>911
LALR(1) も変形すれば LL(2) くらいにはなるので
あとは再起下降でもなんでも好きなようにすればいい

(1)じゃないたいていの言語でも、たいていは(2)ぐらい、というのは真だが、
変形すればLL(2)ってことはない。

手書きするなら左再帰に注意してLL(1)で十分だと思うよ。

ていうか手書きなら自然にループとか書けるから、再帰使わなくても
<X> = a (b c)* d
みたいな拡張BNFをそのままプログラムにすると思えばいい。

文法が再帰的なのにか。

本質的に再帰的なのと実装の都合で再起を使ってるのは区別しようね

LL (1) で足りるかどうかの方が問題なんじゃね

パーザは本質的に再帰。

入力の読み取りを後戻りさせたくないとか、mallocとかしたくないという昔の事情が (1) を欲しただけで、
部分的にちょっと (2) になってる、とかなら今時のマシンと言語とライブラリならたいして問題ない。

本質的に再帰になってるものとしては、式の構文とかがあるけど、普通にループで書ける。

<EXPR> : <TERM> (('+'|'-') <TERM>)*
<TERM> : <FACTOR> (('*'|'/') <FACTOR>)*
<FACTOR> : num | '(' <EXPR> ')'

<FACTOR> のルールにある、「カッコ内の<EXPR>」みたいなのを「本質的に再帰」と言う、
と言えば、まぁそうなんだけど。

abcとaをはんべつするときは
文字を2こ戻す必要ありますよね。
abdとかabeを弾いてaにしなければならなのですから。

boost.spiritはLL(∞)です。

くわしく

LL(*)とか言ってるのはANTLRじゃなかったっけ
なんかPLDIの論文で見たような記憶が

LL(k) k:定数

みんなどんな言語つくってるの？

ひらがな電卓、作ったよ！！！

ひらがな電卓CalcH
http://katahiromz.web.fc2.com/calch/

片山博文MZさんはGithubというキーワードでぐぐると幸せになれる。

GitHubはバリバリ使ってるよ。リクエストはまだないけど

日本語は同音異義語が多い。人工言語に比べて、自然言語は多態性が問題となる。
そこでこれまで使われてきたのが形態素解析だが、
多態性が解消できれば人工言語の構文解析の手法がそのまま使える可能性が高い。
そのことをひらがな電卓で示そうと思う。

お前は何を言ってるんだ
そんなもんBrainfuckのオペを日本語に置き換えたネタと変わらんわ

>>936
lojban で示してくれ
生来 esiperantisto の俺も lojban に傾倒しつつある

日本文化には敢えて日本語の多態性をフル活用するカテゴリーがあるからねえ

自然言語から多態性を排除したモノをプログラム言語として使うというのはアリだけど

各非終端記号を囲むカッコが2つ以上あるとLL文法じゃなくなるな。

具体的にBNFで

B:=C|(C)
A:=B|(B)
こんな感じ？

A:=BC
B:=D|(D)
C:=E|(E)
こっちの方が分かりやすいな。

A:=B|C
B:=D|(D)
C:=E|(E)
違った。

その例なら、

A := BC
BC := '(' DE ')' | DE
DE := D | E

と、くくり出せる。

なるほど。

このスレのテンプレにCaperを追加しておくれ。
jonigataさんのパーサジェネレータCaperは充分に実用的になった。

Caper
https://github.com/jonigata/caper

>>947
アレは良い物ですな、つかなかなかここまで細かい事できるのに使い方が簡単なのってなかなか無いんだよね。
自分使うだけでアレだけど、MZはpullrequest結構出しててそれもとっても有り難かったです。

今作ってる言語でCaper組み込む予定だよ。
いいよね、Caper。

実行時に文法を動的に変えることできますか？

主語を明示してください

プログラムが実行時に解析する文法を動的に変えることできますか？

eval

>>952
たとえばオブジェクト指向言語であれば
Gof本のInterpreterパターンで実装することによって
「実行時に解析する文法」を動的に構成できます
関数型言語だとコンビネータやモナドを使った
構文解析器(パーザ)の動的な構成技法があります

>>954
わかった
ちょっとjonigataさんに相談してみる

解析実行時に文法を切り替えるっていうと
Boost::Spiritでruleインスタンスを差し替えるのを先に思いついた

caper、動的エンジンもともともってるよ。
caperの文法ファイルは動的エンジンで起動時に文法作って読んでる。