ToDo:
色々有るけど、現時点で致命的なのは
辺りかな...
PTCはどんな加速器でも記述できると言う人がいるが、 Front-end processorにMADXを使う限り MADXよりも 記述能力が低い罠 Orz
Frank Schmidtに、 「matrixは擬似エレメントだ、PTCに対応するエレメントは無い」と 言われた。と言う訳で、SAD->MADXP変換は終了〜〜〜
文法上、構文要素が省略可能かつ省略時に暗黙のうちに仮定される 構文要素がある場合、単純にOptional記述で文法を書き下すと PEGパーサーが組み立てる抽象構文木(AST)は、省略が有った場合と 露に記述された場合とで異なるものになる。 特に再帰の無い文法要素(例えば、SADの CompoundExpression)では、 AST評価器で逐一リーフノードの型を検査する必要がある。
具体的な例としては、
Compound <- (Expr? OpCompound)+ Expr?
な文法では、CompoundのASTの枝にはExprと OpCompoundが順不同に現れる。 ここで、Exprが省略された時に、そこに暗黙のExprが 仮定される場合、次の文法を使うことでAST評価器を単純化できる。
Compound <- ((Expr / Null) OpCompound)+ (Expr / Null) Null <- &.?
ポイントはNullの定義で、これは入力を消費せずに 常に真となるルールである。つまり、Exprがマッチしなければ ASTへNullノードを挿入して次のルールの評価に進む。 完成したCompoundのASTでは、OpCompoundとOpCompoundの間には、 常にExprかNullが挟まれるので、 OpCompoundであるかどうかの検査が不要になる。
トレードオフは、ASTがNullノードを含む分肥大化することと、 構文解析器が余計な状態を持つことかな?
メリットとしては、AST評価器でリーフノードをたどるループが 単純化することと、省略時に仮定する暗黙の構文要素の種別を 文法に露に表現できること。
取り合えず、CompoundExpressionと Consルールで動作を実証したので、 こいつを使って Alternativesとかでのオペランド省略時に仮定される 暗黙のNullシンボルをサポートする予定。
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記