はじめに

数日前、私はすばらしいClojure YPを発見しました。これは、マルチスレッドツールの適切な実装、jvmバイトコードへのコンパイル、javaライブラリの使用、jitコンパイルなどの機能を備えた、最新のLisp方言の1つです。 たとえば、 ここで Clojureについて読むことができます 。 ただし、この記事ではメタプログラミングについて説明します。 Lispは、その中のデータとコードが同一になるように設計されています。 関数宣言、マクロ、関数呼び出し、マクロ展開-Lispでは、これらはすべて単なるリストであり、ネストされている可能性があります。

(defn square [foo] (* foo foo)) (defmacro show-it [foo] `(println ~foo))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなコードとデータの統一は、メタプログラミングの強力な機会を提供します。コードを書くコード、コードを書くコード、コードを書くコードなどです。 -これは、Lispでのプログラミングの最も一般的なケースです。 コンパイル時に、言語のすべての機能に完全にアクセスできます。関数を呼び出したり、マクロを展開したりできます。 たとえば、このマクロを定義する場合：

 (defmacro recurs [foo bar] (println "hello from compiler" foo) (case (<= bar 0) true `(defn foo [] ~foo) false `(recurs ~(- foo 1) ~(- bar 1))))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、コードに式を挿入します

 (recurs 2 1)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、コンパイル中に表示されます

 hello from compiler 2 hello from compiler 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、この場合のマクロは、アリティ1の関数fooの定義に展開され、値1を返します。

 (def user/foo (clojure.core/fn ([] 1)))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（3 1を繰り返す）と書くと、関数fooは値2を返します。 Lispのマクロは、複雑なロジックや制御構造を単純な構文の背後に隠し、それに応じて言語自体の表現手段を拡張するための優れたツールです。 実際には、「defn」、「->>」、「->」などの多くの言語構成要素も単なるマクロです。



Lispマクロは通常の関数ですが、コンパイル時に実行されるという唯一の例外があり、それらを記述するテクニックを習得するには、原則として次の4つの「特殊形式」がどのように機能するかを知るだけで十分です。

 `(expr) '(expr) ~(expr) ~@(expr)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

詳細については、 こちらをご覧ください 。 一言で言えば-引用符（ 'と `）の構成は、コンパイラーへの単なる表記です："この式は試されるべきではありませんが、そのまま返されるべきです。 コードの形式で」、および引用符なしの構成（〜および〜@）は、「指定された式を実行し、コードのこの場所に結果を貼り付ける」ことをほぼ意味します。 当然、unqouteコンストラクトは、クォートコンストラクト内でのみ意味があります。 したがって、マクロは、引数として引用構造を取り、値として引用構造を返し、コンパイル時に実行される関数です。

パイプマッチングが必要な理由

Lispマクロの力を示すために、Lispのパイプマッチング実装を書きます。 パイプマッチングとは 名前が示すように、これは2つの制御構造の組み合わせです。パイプとパターンマッチングです。



Clojure PLのパイプは、引数としてn番目の式を取り、特定の方法でこれらの式の構成に展開する単なるマクロです。簡単に言えば、次のようになります。

（-> expr1 expr2 expr3 ...）ここで、パイプ "->"はexpr1をexpr2の最初の引数として挿入し（他のすべての引数は右に1ポジション移動します）、結果のexpr12はexpr3の最初の引数として挿入します。 例

 (-> (func1 "foo") (func2 "bar") (func3 123))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 (func3 (func2 (func1 "foo") "bar") 123)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの2つの式は、まったく同じものです。 コードの読みやすさの問題は好みの問題ですが、パイプが必要であることは個人的に明らかです。 他のパイプもあります。たとえば-->>は推測するのが難しくなく、同様に機能します->が、最初の引数ではなく最後の引数を挿入します。 一般に、あらゆる種類のパイプを記述できますが、原則としてこれら2つが最もよく使用されます。



パターンマッチングは明らかなことです。たとえば、アーラン/エリキシル、haskell、mlは開発者ですが、簡単に言えば説明するのは簡単ではなく、むしろ感じるべきです。 非常に遠く、pmは割り当てと比較の構成として定義できます。 初心者はウィキペディアに行くか、以前の記事を参照してください。エリクサー/アーランYPでのpmの使用について簡単に説明しました。 Clojureにはネイティブパターンマッチングはありませんが、ご想像のとおり、erlangのpmとほぼ同じpmマクロを使用して実装するライブラリがあります。 このプロジェクトでは、車輪を再発明せず、一致マクロライブラリを使用します。



さて、質問に戻ります-なぜpmとpipeを1つのパイプ一致エンティティで接続する必要があるのですか？ すべての機能がクリーンである「hello world」レベルのプログラムを作成する場合、副作用はなく、すべてが非常に決定的です。おそらくこれはあまり意味がありません。 しかし、実際の生産では、汚い機能なしではできません。 たとえば、ソーシャルネットワークVKのアルバムに写真をアップロードする必要があります。 このドキュメントによると、アルバムID、アクセスキー、およびダウンロードする必要がある実際のデータが必要です。 一般的な読み込みアルゴリズムは次のとおりです

    url  (get-http ,  json)   (post-http ,  json)    (get-http ,  json)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルの読み取り、jsonの解析、httpリクエストはすべてダーティな関数です。 呼び出し中、何でも起こり得ます-指定されたアドレスにファイルがありません、無効なjson、必要なフィールドのない有効なjson、切断、サーバーは200ではなく他のものなどと応答しました。 これらの各機能では、すべてが非常に悪いです。 そして、すべてがうまくいきますが、次の各機能は前の機能からの正しい結果を必要とします。 個々の関数ごとに、不良ケースの句を記述して実行を回避することができますが、これらすべてを連携させる必要があります。何か問題が発生した場合、何がどこで何が正確に発生したかを知りたいのです。 おそらく読者の多くは、このようなものを書きたいと思うでしょう。







しかし、これは残念です）これは、サポートおよびディベースするだけでなく、単に読み取り/書き込み/理解するのが難しいです。 このような状況（常に同意します）では、パイプマッチングにより、すべての複雑なロジックが非表示になり、コードが非常に単純になります。 マクロの例pipe_matchingおよびpipe_not_matching

 (defn nested_process foo bar baz (pipe_matching {:ok some_data} (simple_func1 foo) (simple_func2) (simple_func3 bar) (simple_func4 baz)))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで何が起こるか：nested_process関数は引数foo、bar、およびbazを受け入れます。 そして、ダーティな可能性のある関数simple_func1をアリティ1で、simple_func2をアリティ1で、simple_func3をアリティ2で、simple_func4をアリティ2で連続呼び出ししますが、通常のパイプのように、前の式の結果は次の式の最初の引数です。 そして今、最も重要なこと-パターン{：ok some_data}をpipe_matchingマクロの最初の引数として設定します。 このパターンの場合、キーが存在するmapが適切です。任意の値でOKです。 そしてsimple_func関数はこのパターンに適した値を返しますが、次の関数が呼び出されます（通常のパイプのように）。 ただし、simple_func関数の一部がこのパターンに適合しない値を返すとすぐに、nested_process関数の値として返され、チェーンに渡されません。 たとえば、simple_func3が{：error "on simple_func3 server ans 500"}を返す場合、simple_func4関数はまったく呼び出されず、nested_processは{：error "on simple_func3 server ans 500"}を返します。 同様のマクロpipe_not_matchingを作成することもできます。これは次のように使用できます

 (defn nested_process foo bar baz (pipe_not_matching {:error some_error} (simple_func1 foo) (simple_func2) (simple_func3 bar) (simple_func4 baz)))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はそれがどのように機能するかを考えます-それは文脈から明らかです。 ここでsimple_func3が{：error "on simple_func3 server ans 500"}を返し、1番目と2番目の関数が前のパターンに適合しない値を返す場合、結果は前の例と同じになります。 実際には、pipe_not_matchingを好みます。 その結果、if / else / elseif / case / switchなどを使用せずに、タスクロジックをほぼリテラルにコードにシリアル化できます。 一般に、FPが大好きなものすべて-コードは、不必要な抽象エンティティのないタスクそのものです。 かっこいい さて、ほんの数行でLispでそのようなマクロを書く方法を見てみましょう。

Lispのパイプマッチングの記述

まず、ライブラリの名前空間の依存関係を記述します。「一致する」マクロは1つだけです。

 (ns pmclj.core (:use [clojure.core.match :only (match)]))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般に、目標である2つのマクロを定義します

 (defmacro pipe_matching [pattern init_expression & other_expressions ] (pipe_matching_inner {:pattern pattern, :result init_expression, :expressions other_expressions, :continue_on_match true})) (defmacro pipe_not_matching [pattern init_expression & other_expressions ] (pipe_matching_inner {:pattern pattern, :result init_expression, :expressions other_expressions, :continue_on_match false}))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マクロは最初の引数としてパターンを取り、残りの引数はpm自体の式です。少なくとも1つの式が必要であるため、init_expressionを呼び出して必要な2番目の引数を設定します。 ＆記号に注意してください-ここでは、other_expressionsは、可能な引数（3番目、4番目など）で構成される任意の長さ（おそらく空）のリストであることを意味します。 したがって、マクロは、1を超える任意の数の引数で展開できます。



次に、便宜上、引数をシリアル化してキー：pattern ,: result ,: expressions :: continue_on_matchでマップします。 ここでの結果は、前のステップで得られた結果です。式は、結果のマクロコードに展開されない残りの式です。continue_on_match-true / false：結果がパターンに一致した場合の処理​​-呼び出しチェーンを継続するか、値を返します。



結果のマップはpipe_matching_inner再帰関数に渡され、必要なコードが返されます。 はい、これはLispの美しさです。関数が呼び出し時にすでにコンパイルされている場合にのみ、コンパイル時に関数を呼び出すことができます。 機能は次のとおりです。

 (defn pipe_matching_inner [{pattern :pattern, result :result, expressions :expressions, continue_on_match :continue_on_match}] (case (or (= expressions nil) (= expressions ())) true result false (let [to_pipe (first expressions) rest_expr (rest expressions)] `(let [~'res ~result] (case (= ~continue_on_match (check_match ~'res ~pattern)) true ~(pipe_matching_inner {:pattern pattern, :result `(-> ~'res ~to_pipe), :expressions rest_expr, :continue_on_match continue_on_match}) false ~'res)))))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、マクロ本体で生成したマップを受け入れます。 ここで、ちなみに、Clojureのネイティブpmが何らかの形式でかなり奇妙な構文を持っていることがわかります。[{パターン：パターン、結果：結果、式：式、continue_on_match：continue_on_match}]。

ケース-ここの式は次のことを言っています。すべての式をすでに処理している場合、結果を返す以外に何もする必要はありません。 それ以外の場合は、処理します。 次に、Lisp言語の非常に重要な特別な形式、letがあります。 ここにはグローバル変数と割り当てはなく、ありえませんが、式=>シンボルの精神でローカルバインディングを行うことができます。 first関数とrest関数は、実際にはリストの最初の要素を除く最初とすべてを返します。ここではすべてが透過的です。処理するために次の式を取得します。

さらに、最も興味深いのは、コンパイル時に動的に生成される実際のコードです。 ここでは、何が起こっているのかを理解するために、すでに少し精神的な努力をしなければなりません。 前の式の結果をresシンボルにローカルにバインドします（実行時にこの式が複数回実行されないようにします）。 〜に注意してください-これは、コンパイル中に文字が対応する名前空間にアタッチされるという事実のための小さなハックであり、組み合わせ〜 'はそれらをデタッチします。つまり、このコンテキストでは、これらの問題を掘り下げません。 以下は、実行時に正直に実行される式であるケースです。resがパターンpatternと一致するかどうかを確認します。 check_match-実際には、ライブラリマクロの一致に基づいた非常に単純なマクロ

 (defmacro check_match [obj pattern] `(match ~obj ~pattern true :else false))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、check_match式が予想されるかどうかに応じて、true-pipe_matchingおよびfalse-pipe_not_matchingの場合、呼び出しのチェーンが継続するか、resが戻ります。 後続の一連の呼び出しも、pipe_matching_inner関数の再帰呼び出しによって美しく描画されます。



実際にどのように見えるか見てみましょう。

これは美しいパイプのマッチングです

 (pipe_matching {:ok some} (func1 "foo") (func2 "bar") (func3 123))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際には、それはそのような地元の地獄に変わります

 (clojure.core/let [res (func1 "foo")] (clojure.core/case (clojure.core/= true (pmclj.core/check_match res {:ok some})) true (clojure.core/let [res (clojure.core/-> res (func2 "bar"))] (clojure.core/case (clojure.core/= true (pmclj.core/check_match res {:ok some})) true (clojure.core/-> res (func3 123)) false res)) false res))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パイプマッチングなしで同じロジックを構築するには、この地獄をすべて自分の手で書かなければならないという事実に注意を喚起したいです）



完全なコードはこちらにあります 。



結論として、一見したところ、Lisp構文は確かにユーザーフレンドリーではありませんが、大規模/複雑なシステムの構築には適しています。 もちろん、アーラン/エリキシルの後、あなたはotpなしで手を使わないように感じますが、それは時間の問題だと確信しています。 とにかく、これはjvmの私の最初の経験であり、私はそれが非常に成功すると思います）

UPD：

いくつかのリファクタリングを行った後、マクロ自体はそれほど怖く見えません。 彼はヒントに耳を傾け、さらに4つのマクロを追加しました。



pred_matching / pred_not_matchingは同じで、最初の引数としてアリティ1のラムダのみを取ります。

key_matching / key_not_matchingは同じです。キーを最初の引数としてのみ受け入れ、実行時に指定されたキーの値の呼び出し結果を調べます。nilまたはabsentの場合、これはfalseです。それ以外の場合はtrueです。



使用例

 (defn func1 [arg] {:ok arg}) (defn func2 [arg1 arg2] {:fail (+ (get arg1 :ok) arg2)}) (defn func3 [arg1 arg2] {:ok (+ (get arg1 :ok) arg2)}) (defn example_pred [] (pred_matching #(contains? % :ok) (func1 1) (func2 2) (func3 3))) (defn example_pm [] (pipe_matching {:ok some} (func1 1) (func2 2) (func3 3))) (defn example_key [] (key_matching :ok (func1 1) (func2 2) (func3 3)))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ちなみに、前の関数から正しい戻り値が必要なサンプルコードを次に示します。場所（+（get arg1：ok）arg2）には、たとえばget関数がnilを返す場合など、実行が含まれる可能性があります。

予想どおり、この場合、3つのサンプル関数はすべて同じ値を返します。

 (example_pred) {:fail 3} (example_pm) {:fail 3} (example_key) {:fail 3}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、rkey_matching / rkey_not_matchingマクロも追加しました。同様に機能し、構造内のキーエントリのみを再帰的に検索し、見つかった場合は呼び出しチェーンを終了し、見つかったエラーを返します。 実践が示しているように、これは使いやすさ/汎用性の点で最も便利なオプションです。



制御構造の普遍性は、当然pred_matching> pipe_matching> rkey_matching> key_matchingです。 どちらを使用するかは、個人の好みと、扱うデータの複雑さに依存します。



結果のコードはこちらです。