15

数日前、私はブログ エントリ ( http://ayende.com/Blog/archive/2008/09/08/Implementing-generic-natural-language-DSL.aspx ) を読みました。 .NET を使用した一般的な自然言語 DSL パーサー。

私の意見では、彼のアイデアの素晴らしい部分は、テキストが解析され、文と同じ名前を使用するクラスと照合されることです。

例として、次の行を取り上げます。

電子メール test@email.com とパスワード test でユーザー user1 を作成します
user1 にログイン
user1 を T シャツのカテゴリに移動します
user1 にアイテムをカートに追加させる
user1 をチェックアウトに連れて行く

解析の結果を取得する「既知の」オブジェクトのコレクションを使用して変換されます。オブジェクトの例は次のとおりです (私の例では Java を使用しています)。

public class CreateUser {
    private final String user;
    private String email;
    private String password;

    public CreateUser(String user) {
    this.user = user;
    }

    public void withEmail(String email) {
    this.email = email;
    }

    public String andPassword(String password) {
        this.password = password;
    }
}

したがって、最初の文を処理するとき、CreateUser クラスは一致し (明らかに「ユーザーの作成」の連結であるため)、コンストラクターでパラメーターを受け取るため、パーサーはユーザー パラメーターとして「user1」を受け取ります。

その後、パーサーは次の部分「with email」もメソッド名と一致することを識別し、そのメソッドはパラメーターを受け取るため、「test@email.com」を email パラメーターとして解析します。

もうお分かりだと思いますよね?少なくとも私にとっては、アプリケーション テスターが自然言語で「テスト スクリプト」を作成し、その文を JUnit を使用してアプリの動作をチェックするクラスに解析できるようにするという非常に明確なアプリケーションの 1 つです。

Java を使用してそのようなパーサーをコーディングできるツールまたはリソースに関するアイデア、ヒント、意見を聞きたいです。複雑な字句解析器や ANTLR のようなフレームワークの使用を避けることができればなおさらです。これはハエを殺すためにハンマーを使用することになると思います。

それ以上に、そのためのオープンソース プロジェクトを開始する人がいれば、私は間違いなく興味があります。

4

6 に答える 6

25

字句解析と構文解析の複雑さを考えると、これらすべてを手作業でコーディングするかどうかはわかりません。 ANTLRをピックアップするのはそれほど難しくありません。問題に基づいて検討する価値があると思います。 解析文法を使用して入力から構文ツリーを構築および抽象化する場合、その AST をツリー文法で処理するのは非常に簡単です。ツリー文法は、説明したプロセスの実行を簡単に処理できます。

まず、Eclipse、Groovy、Grails など、多くの場所で ANTLR を見つけることができます。 The Definitive ANTLR Referenceを使用すると、基本的なことをすぐに理解できるようになります。

今年の初めに、ユーザーが生成したクエリ テキストを処理する必要のあるプロジェクトがありました。手動で処理する道を歩み始めましたが、すぐに圧倒されました。ANTLR の速度を上げるのに数日かかり、文法とプロセッサの初期バージョンを数日で実行しました。要件に対するその後の変更と調整は、カスタム バージョンを無効にしていたでしょうが、ANTLR 文法を起動して実行すると、調整に必要な労力は比較的少なくなりました。

幸運を!

于 2008-09-27T20:17:09.093 に答える
10

それを「自然言語」と呼ぶなら、あなたは自分自身を欺いています。それは依然としてプログラミング言語であり、自然言語を模倣しようとするものにすぎません。実装の詳細に取り掛かると、失敗するのではないかと思います。曖昧さをなくすためには、構文に制限を設けて、「英語」で書いていると思い込まされたユーザーを混乱させる必要があります。

DSL の利点は (少なくともそうあるべきです)、シンプルで明確でありながら、問題のドメインに関して強力であることです。自然言語を模倣することは二次的な問題であり、実際にはこれらの主要な目標に対して逆効果になる可能性があります。

誰かが愚かすぎるか、プログラミングに必要な正式に厳密な思考能力を欠いている場合、自然言語を模倣したプログラミング言語は魔法のように彼らをプログラマーに変えることはありません。

COBOLが発明されたとき、COBOLは「英語のように」、ソフトウェアを必要とする人は誰でもそれを自分で書くことができたので、10年以内にプロのプログラマーの需要がゼロになるだろうと真剣に信じていた人もいました. そして、私たちは皆、それがどのように機能してきたかを知っています.

于 2009-03-25T11:07:05.993 に答える
10

内部で ANTLR を使用し、DSL のエディターを自動生成するなどの優れた機能を実行するXtextを検討することをお勧めします。

于 2008-09-28T00:31:06.097 に答える
4

DSL について初めて耳にしたのは、IntelJ Idea の作成者である Jetbrains でした。

彼らはこのツールを持っています: MPS (メタプログラミングシステム)

于 2009-01-28T00:26:47.943 に答える
1

私がAntlrを使用して行ったこのマルチパートのブログシリーズは、出発点として役立つかもしれません。Antlr 2を使用しているため、Antlr3ではいくつかの点が異なります。

http://tech.puredanger.com/2007/01/13/implementing-a-scripting-language-with-antlr-part-1-lexer/

Antlrに関するMarkVolkmanのプレゼンテーション/記事も非常に役立ちます。

http://www.ociweb.com/mark/programming/ANTLR3.html

同じく優れているDefinitiveANTLR本についての提案を2番目にします。

于 2008-09-28T01:10:27.657 に答える
0

「少なくとも私にとっては、その非常に明確なアプリケーションの1つは、アプリケーションテスターが自然言語で「テストスクリプト」を作成し、JUnitを使用してアプリの動作をチェックするクラスに文を解析できるようにすることです。」

ここで話していることは、ツールFitNesseとまったく同じように聞こえます。あなたが説明しているとおり、クライアントは受け入れテストの「スクリプト」を自分にとって意味のあるある種の言語で記述し、プログラマーはテストに合格するシステムを構築します。あなたが話している実装でさえ、FitNesseがどのように機能するかとほぼ同じです。スクリプトで使用される語彙は連結されて関数名などを形成するため、FitNesseフレームワークは呼び出す関数を認識します。

とにかく、それをチェックしてください:)

于 2009-03-25T10:46:17.650 に答える