言語での言語またはScalaでのXPathの埋め込み

Scalaは素晴らしい言語です。 あなたは彼に恋をすることができます。 コードは簡潔ですが、理解できる場合があります。 柔軟ですが、強く型付けされています。 徹底的に考え出されたツールを使用すると、言語と戦うのではなく、言語でアイデアを表現できます。

しかし、これらの同じツールを使用すると、非常に複雑なコードを作成できます。
scalazスタイルのスマートバランシングまたは不定型コンピューティングを使用すると、ユニットがコードを理解することが保証されます。

この記事では、何をするべきかについて話します。
Scalaに異なる言語を埋め込む方法を説明します。

XPathと私は埋め込みますが、説明した方法は、構文ツリーを構築できるすべての言語に適しています。

理由

Scalaには、Javaにあるxmlを操作するためのすべてのツールを使用する機能があります（多くのツールがあります）。 しかし、コードは古き良きJavaコードを思い出させます。 あまり幸せではない見通し。

言語構文に組み込まれたネイティブxmlがあります。

scala> <root> | <node attr="aaa"/> | <node attr="111"> text</node> | </root> res0: scala.xml.Elem = <root> <node attr="aaa"/> <node attr="111"> text</node> </root> scala> res0 \\ "node" res1: scala.xml.NodeSeq = NodeSeq(<node attr="aaa"/>, <node attr="111"> text</node>) scala> res1 \\ "@attr" res2: scala.xml.NodeSeq = NodeSeq(aaa, 111) 

それは幸せのようですが、違います。 リモートでのみXPathに似ています。 少し複雑なクエリは面倒で読みにくくなりますが。

しかし、scalaをある程度知った後、作成者が根拠なくscalaをスケーラブルな言語と呼んでいないことが明らかになりました。 そして、何かが欠けている場合、これを追加できます。

言語への便利な統合により、タスクを可能な限りXPathに近づけます。

結果

ここでのすべての開発： https : //github.com/senia-psm/scala-xpath.git

何とどのように

目標を達成する方法は、目標自体によって一意に決定されます。
XPathをDSLとして埋め込むことは明らかに失敗します。 そうしないと、XPathではなくなります。 scalaのXPath式は文字列としてのみ配置できます。
つまり：

1. パーサーコンビネーター 。 検証のために文字列を解析する必要があります。
2. ストリング補間 。 XPathに変数と関数を埋め込むため。
3. マクロ コンパイル段階での検証用。

オブジェクトモデルを準備します。

XPath 1.0仕様を取り上げて、 scalaで書き直してください。
ほとんどすべてのロジックは、型システムとscalaの継承メカニズムによって表現されます。 例外は、requireを介した制限のいくつかの場所にあります。
ここでは、このファイルの外部でクラスを継承する（またはインターフェイスを実装する）ことを禁止する「sealed」キーワードに注目する価値があります。 特に、サンプルと比較する場合、「シール」を使用すると、コンパイラはすべての可能なオプションが考慮されていることを確認できます。

Parsim XPath

パーサーの組み合わせ（およびw3c仕様のリテラシー）により、ためらうことなくパーサーを作成できます。
実際、仕様を2回書き換えています。 唯一の大きな違いは、再帰的な定義を「循環」定義（repおよびrepsep）に置き換えたことです。

例：

仕様：

  [15] PrimaryExpr :: = VariableReference	
                                       |  '（' Expr '）'	
                                       | リテラル	
                                       | 数	
                                       | 関数呼び出し 

パーサー ：

  def primaryExpr: Parser[PrimaryExpr] = variableReference | `(` ~> expr <~ `)` ^^ { GroupedExpr } | functionCall | number | literal 

唯一の条件は、最も「厳密な」パーサーが「|」を介してユニオンに入ることを保証する必要があることです。 残りの前に。 この例では、関数の名前の解析に成功しただけで、functionCallが成功した場合にリテラルが明らかに成功します。したがって、リテラルを先に配置すると、単にfunctionCallに到達しません。
パーサーのセット全体が150行に収まり、オブジェクトモデルの定義よりも大幅に短くなります。

ミックス変数

式に変数を追加するには、バージョン2.10で登場した文字列補間メカニズムを使用します。
メカニズムは非常に簡単です。有効なメソッド名である前の行（スペースなし）に遭遇すると、コンパイラは単純な変換を実行します。

 t"strinf $x interpolation ${ obj.name.toString } " StringContext("strinf ", " interpolation ", " ").t(x, { obj.name.toString }) 

文字列は、変数と式の出現によって断片に分割され、StringContextファクトリメソッドに渡されます。 文字列の前の名前はメソッドの名前として使用され、すべての変数と式はパラメーターとしてこのメ​​ソッドに渡されます。
これが「s」や「f」などのメソッドで終わる場合、StringContextにないメソッドについて、コンパイラは暗黙的なクラス、つまり目的のメソッドを含むStringContextのラッパーを探します。 このような検索はscalaの一般的なメカニズムであり、文字列補間には直接適用されません。
最終コード：

  new MyStringContextHelper(StringContext("strinf ", " interpolation ", " ")).t(x, { obj.name.toString }) 

しかし、パーサーはどうですか？ 連続した文字列はなくなりました。 そして、文字のシーケンスと何か他のものがあります。
すべての作業は排水されていますか？
これは、文字のシーケンスだけでなく解析する機能の有用性が明らかになる場所です。
一連の文字と他のものがあります（これについては後で説明します）。 これは、どちらかの概念で説明されています。 ハブには、シグルラミのいずれかに関する いくつかの 記事が翻訳されています 。
パーサーの能力を最大限に活用するには、いくつかの補助ツールを作成するだけです。 特に、Char、String、Regexから対応するパーサーへの変換。
必要なすべてのツールは次のとおりです： BothParsers 。 抽象型Rに注意を払う価値があります。これについては想定されていないため、このツールキットは変数を表すための以前は未知の方法に適しています。

編集に干渉する

私の意見では、マクロに関するドキュメントと妥当な例はほとんどありません。 しかし、だからといって、マクロとは何か、またマクロが何を食べるのかを網羅的に説明するつもりはありません。
まず、マクロキーワードを使用して実装されたメソッドをコンパイラが検出したときにマクロが呼び出され、マクロ実装が新しく作成された構文ツリーを返す必要があることを知っておく必要があります。
最も単純な例のためにどのようなツリーを与えるべきか見てみましょう：

 scala> import scala.reflect.runtime.universe._ import scala.reflect.runtime.universe._ scala> showRaw(reify( "str" -> 'symb )) res0: String = Expr(Apply(Select(Apply(Select(Ident(scala.Predef), newTermName("any2ArrowAssoc")), List(Literal(Constant("str")))), newTermName("$minus$greater")), List(Apply(Select(Ident(scala.Symbol), newTermName("apply")), List(Literal(Constant("symb"))))))) 

このような自分を構築するには、わずかな欲求はありません。
scalaが手作業なしでタイピングを保存できることを見てみましょう。
一方で、多くではありません：リテラルメソッド。これは、いくつかの限られた「基本型」のセットを構文ツリーに変換し、すべての手動作業を行うreifyを可能にしますが、同じツリーの形式で外部から変数を追加する場合のみ次に、このツリーのspliceメソッドを使用します。このメソッドは、結果のタイプTを持つ新しいツリーの一部として、タイプExpt [T]の式を埋め込むという要望を具体的に通知するために設計されています。
一方、これらの方法で十分です。 追加は利用可能なものに基づいて書くことができます。

マクロ自体によって処理される補間を追加することは非常に簡潔です。

  implicit class XPathContext(sc: StringContext) { def xp(as: Any*): LocationPath = macro xpathImpl } 

マクロ処理関数は次のように宣言されます。

 def xpathImpl(c: Context)(as: c.Expr[Any]*): c.Expr[LocationPath] 

どこから変数を取得するかは明確ですが、文字列を取得する方法は？
これを行うには、コンテキストを使用して関数を「見る」ことができます。 つまり、周りを見てください。
より正確には、ターゲットXPメソッドが呼び出される式を見てください。
これはc.prefixを使用して実行できます。
しかし、そこには何が見つかりますか？ StringContext（ "strinf"、 "interpolation"、 ""）の形式の式が必要であることが以前に述べられました。
対応するツリーを見てみましょう：

 scala> import scala.reflect.runtime.universe._ import scala.reflect.runtime.universe._ scala> showRaw(reify(StringContext("strinf ", " interpolation ", " "))) res0: String = Expr(Apply(Select(Ident(scala.StringContext), newTermName("apply")), List(Literal(Constant("strinf ")), Literal(Constant(" interpolation ")), Literal(Constant(" "))))) 

ここからわかるように、すべての行を明示的な形式で取得できます。

  val strings = c.prefix.tree match { case Apply(_, List(Apply(_, ss))) => ss case _ => c.abort(c.enclosingPosition, "not a interpolation of XPath. Cannot extract parts.") } val chars = strings.map{ case c.universe.Literal(Constant(source: String)) => source.map{ Left(_) } case _ => c.abort(c.enclosingPosition, "not a interpolation of XPath. Cannot extract string.") } 

しかし、入り口だけが変わったわけではありません。 パーサーの結果はオブジェクトモデルのオブジェクトではなくなります。値ではなくc.Expr [Any]の形式のパラメーターに基づいて構築することはできません。

それに応じてパーサーを変更します。 その結果、外部変数が少なくとも何らかの形で出現する可能性がある場合、パーサーはTを返すことはできませんが、c.Expr [T]を返す必要があります。 非基本型から対応するExprへの変換のために、使用可能なものに基づいて補助リテラルメソッドを作成します。次に例を示します。

  def literal(name: QName): lc.Expr[QName] = reify{ QName(literal(name.prefix).splice, literal(name.localPart).splice) } 

このようなすべての関数の原理は非常に単純です。引数をかなり基本的な部分に解析し、reify内で再構成します。

これには機械的な作業が必要ですが、パーサーはそれほど変わりません。

最後のステップは、入力で変数を解析できるいくつかのパーサーの導入です。
以下は、変数を埋め込むためのパーサーです。

  accept("xc.Expr[Any]", { case Right(e) => e } ) ^? ({ case e: xc.Expr[BigInt] if confirmType(e, tagOfBigInt.tpe) => reify{ CustomIntVariableExpr(VariableReference(QName(None, NCName(xc.literal(nextVarName).splice))), e.splice) } case e: xc.Expr[Double] if confirmType(e, xc.universe.definitions.DoubleClass.toType) => reify{ CustomDoubleVariableExpr(VariableReference(QName(None, NCName(xc.literal(nextVarName).splice))), e.splice) } case e: xc.Expr[String] if confirmType(e, xc.universe.definitions.StringClass.toType) => reify{ CustomStringVariableExpr(VariableReference(QName(None, NCName(xc.literal(nextVarName).splice))), e.splice) } }, e => s"Int, Long, BigInt, Double or String expression expected, $e found." ) 

最初のパーサー "accept（" xc.Expr [Any] "、{case Right（e）=> e}）"は非常に単純です-ツリーを持つRightコンテナを受け入れ、このツリーを返します。
さらに変換を行うと、この変数を3つの目的の型のいずれかとして使用できるかどうかが判断され、そのような使用に変換されます。

その結果、次の動作が発生します。

 scala> val xml = <book attr="111"/> xml: scala.xml.Elem = <book attr="111"/> scala> val os = Option("111") os: Option[String] = Some(111) scala> xml \\ xp"*[@attr = $os]" // Option[String]    <console>:16: error: Int, Long, BigInt, Double or String expression expected, Expr[Nothing](os) found. xml \\ xp"*[@attr = $os]" ^ scala> xml \\ xp"*[@attr = ${ os.getOrElse("") } ]" //   String   res1: scala.xml.NodeSeq = NodeSeq(<book attr="111"/>) 

また、エラーメッセージをさらに改善する必要がある場合、変数は既に非常に便利に組み込まれています。

関数を埋め込むには多くのコード（23のオプション、0から22のパラメーターのオプション用）が必要であり、Anyのみを受け入れる必要があるため、あまり便利ではありませんが、基本的にNodeListが来ます（ただし、行が来るか、Doubleになる可能性があります）：

 scala> import org.w3c.dom.NodeList import org.w3c.dom.NodeList scala> val isAllowedAttributeOrText = (_: Any, _: Any) match { // - ,       | case (a: NodeList, t: NodeList) if a.getLength == 1 && t.getLength == 1 => | a.head.getTextContent == "aaa" || | t.head.getTextContent.length > 4 | case _ => false | } isAllowedAttributeOrText: (Any, Any) => Boolean = <function2> scala> val xml = <root attr="11111" ><inner attr="111" /><inner attr="aaa" >inner text</inner> text </root> xml: scala.xml.Elem = <root attr="11111"><inner attr="111"/><inner attr="aaa">inner text</inner> text </root> scala> xml \\ xp"*[$isAllowedAttributeOrText(@attr, text())]" res0: scala.xml.NodeSeq = NodeSeq(<root attr="11111"><inner attr="111"/><inner attr="aaa">inner text</inner> text </root>, <inner attr="aaa">inner text</inner>) 

ここでは、XPath構文から最初の混乱を取得しました（変数の代わりに$ {任意のコード}の形式の式を記述する可能性を除く）-実装された関数の前にドルを付ける必要があります。

メソッドの実装

当然、scala.xml.NodeSeqのメソッド「\」と「\\」自体は魔法によって現れたのではなく、モデルのパッケージオブジェクトの暗黙クラスを使用して追加されます 。

同様のメソッドがorg.w3c.dom.NodeおよびNodeListに組み込まれています 。

また、結果のXPathを適用すると、特定の問題が発生します。

未解決の問題

java.lang.System.setSecurityManager（null） を取り除きます。 com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImplの実装から判断すると、カスタム関数ハンドラーを追加する他の方法はありません。

コンパイル段階でのエラーは改善が必要です。
関数が正しく指定されていない場合、エラーメッセージは完璧です（コンパイラの妥当性に対する別の賛辞）：

 scala> xml \\ xp"*[$isAllowedAttributeOrText(@attr)]" <console>:1: error: type mismatch; found : (Any, Any) => Boolean required: Any => Any xml \\ xp"*[$isAllowedAttributeOrText(@attr)]" ^ 

その後、他のすべてのエラーについては、標準のメッセージ形式は尊重されず、位置は行の始まりを示します。
前の問題とは異なり、この問題は完全に解決できます。

scala.xmlを使用するときのパフォーマンスには、多くの要望があります。 実際、scala.xmlからw3c.domへの変換は、最初に文字列を介して行われ、次に逆に行われます。
唯一可能な解決策は、XPathを自分で処理することです。
同時に、これはあまり便利ではない関数のタイピングを取り除きます。

w3c.domのパフォーマンスはわずかに改善できます。 XPathは現在、文字列からコンパイルされていますが、既製のオブジェクトモデルがあります。 オブジェクトモデル間で変換すると、XPathの作成が多少速くなります。

おわりに

XPathは深刻な問題や制限なしにscalaに統合できます。
現在のスコープの変数と関数は、仕様で許可されている限り有効です。
w3c.domで使用し、いくつかの改善を加えた場合、コンパイル中に式を解析するため、わずかな加速も可能です。

すべてがはるかに簡単です。 一見すると思われます。
最初は、コンパイルに埋め込むというアイデア自体が地獄を引き起こします。 結果は最小限の労力で達成されます。
はい、コンパイラAPIはメインライブラリよりもはるかに悪いドキュメントですが、論理的で理解しやすいです。
はい、IDEAはパス依存型をよく理解していませんが、コンパイラAPIを含む非常に便利なナビゲーションを提供し、暗黙的な変換を考慮します。