目次

  1  イントロダクション
  2  JFlexのインストール
  3  JFLexの使用法 ― 例
  4  レキサの仕様書
4.1  ユーザコード
4.2  オプションと宣言
クラスオプションとユーザクラスコード
スキャニングメソッド
ファイルの終端(EOF)
スタンドアロンスキャナ
CUPとの適合性
コードの生成
文字集合
行数、文字数、桁数の計測
もはや使われないJLexのオプション
状態の宣言
マクロの定義
4.3  字句規則
構文
意味論
どのようにして入力はマッチされるか
アクションでアクセス可能なスキャナメソッドと変数
  5  性能について二言三言
  6  JLexからの移植
  7  協調動作：JFlexとCUP
  8  バグ
  9  参考文献
10  権利とライセンス

1 イントロダクション

JFlexの主要な設計上の目標は以下の通りである：

• 完全なUnicodeのサポート
• 生成されたスキャナ(scannar)が高速（手書きやこれらをJLexで生成したものよりも高速）
• スキャナの生成が高速
• 便利な仕様書の構文
• プラットホーム非依存
• JLexとの互換性

version 1.1 の新機能

• 正規表現における空白文字 " "（スペース）や "\t"（タブ） ― セクション ［構文］ を参照
• flex形式の繰り返し表現 r{n} と r{n,m} ― セクション ［意味論］ を参照
• 大文字か小文字かに依存しないスキャナのための %caseless スイッチ
• ファイルの終端で自動的に入力ストリームを閉じるための %eofclose スイッチ
• 入力ストリームを閉じるためのメソッド void yyclose()
• 現在の字句状態(lexical state)のためのメソッド int yystate()
• マッチしたテキストの再読み込み部分に関するメソッド void yypushback(int number)
• 生成の処理で上書きされるファイルのバックアップ
• よりよいエラー報告(error reporting)
• ファイル名がコマンドラインで指定されないときのGUI

このマニュアルについて

このマニュアルの次のセクションは、JFlexの［インストールの方法］を記述する。もしあなたがJLexを使って作業をしたことがないか、JLexとJFlexのスキャナの仕様書を比較したいのであれば、セクション3 ［JFlexを使った作業 ― 例］ を読むべきである。全てのオプションと完全な仕様書の構文は、セクション ［レキサの仕様書］ に示される。もしあなたが性能の考察やJLex/JFlexの速度の比較に関心があるなら、［性能について二言三言］ はまさに当を得たものとなるであろう。それらの古いJLexの仕様書を使おうとする人々は、JFlexでは修正されたポータブルではない、または標準的ではない、JLexのふるまいについて起こり得る問題を避けるために、［JLexからの移植］ を調べるべきである。［バグ］ は現在知られているバグの一覧を与える。マニュアルはJFlexを書くために使われた［参考文献］に続き、［権利とライセンス］ についての記述で結論づける。

2 JFlexのインストール

1. あなたがダウンロードしたファイルを、JFlexをインストールしたいディレクトリに（Unixなら tar/unzip を、W95/98ならWinZipを使って）展開します。
   たとえば C:\ に展開したなら、以下のようなディレクトリ構造が作られているはずです（カッコ内はそのディレクトリの内容を表します）：

     C:\JFlex\                          
           +--bin\                     (スタートスクリプト) 
           +--doc\                     (FAQとこのマニュアル)
           +--examples\ 
                    +--java\           (完全なJava 1.1用のレキサの仕様書) 
                    +--simple\         (簡単なスキャナ)
                    +--standalone\     (簡単なスタンドアロンスキャナ) 
           +--lib\                     (コンパイル済みのクラス) 
           +--src\ 
               +--JFlex\               (JFlexのソースコード) 
               +--JFlex\gui            (JFlexのUIクラスのソースコード)
               +--java_cup\runtime\    (java_cup.runtimeクラスのソースコード) 
   

2. Unixなら bin/jflex を、W95/98なら bin\jflex.bat を編集します（上の例では、C:\JFlex\bin\jflex.bat になります）。そして、
• JAVA_HOME は、JavaのJDKがインストールされているディレクトリを表します

（たとえば C:\java であれば、C:\java\lib\classes.zip が標準Javaクラスのファイルです）そして、
• JFLEX_HOME は、JFlexのあるディレクトリ（例では：C:\JFlex）です
 
3. あなたのパスに、JFlexの bin/ ディレクトリを追加します。 （そのディレクトリにはスタートスクリプトが入っています。例では C:\JFlex\bin です）。

jflex <inputfile>

java JFlex.Main <inputfile>

3 JFlexの使用法 ― 例

/* JFlex example: part of Java 1.0/1.1 language lexer specification */
import java_cup.runtime.*;

%%

%class Lexer
%unicode
%cup
%line
%column

%{
  StringBuffer string = new StringBuffer();

  private Symbol symbol(int type) {
    return new Symbol(type, yyline, yycolumn);
  }
  private Symbol symbol(int type, Object value) {
    return new Symbol(type, yyline, yycolumn, value);
  }
%}

LineTerminator = \r|\n|\r\n
InputCharacter = [^\r\n]
WhiteSpace = {LineTerminator} | [ \t\f]

/* comments */
Comment = {TraditionalComment}|{EndOfLineComment}|{DocumentationComment}

TraditionalComment = "/*" [^*] {CommentContent} "*"+ "/"
EndOfLineComment = "//" {InputCharacter}* {LineTerminator}
DocumentationComment = "/**" {CommentContent} "*"+ "/"

CommentContent = ( [^*] | \*+ [^/*] )*

Identifier = [:jletter:] [:jletterdigit:]*

DecIntegerLiteral = 0 | [1-9][0-9]*

%state STRING

%%

/* keywords */
<YYINITIAL> "abstract"           { return symbol(sym.ABSTRACT); }
<YYINITIAL> "boolean"            { return symbol(sym.BOOLEAN); }
<YYINITIAL> "break"              { return symbol(sym.BREAK); }
 
<YYINITIAL> {
  /* identifiers */ 
  {Identifier}                   { return symbol(sym.IDENTIFIER); }
 
  /* literals */
  {DecIntegerLiteral}            { return symbol(sym.INTEGER_LITERAL); }
  \"                             { string.setLength(0); yybegin(STRING); }

  /* operators */
  "="                            { return symbol(sym.EQ); }
  "=="                           { return symbol(sym.EQEQ); }
  "+"                            { return symbol(sym.PLUS); }

  /* comments */
  {Comment}                      { /* ignore */ }
 
  /* whitespace */
  {WhiteSpace}                   { /* ignore */ }
}

<STRING> {
  \"                             { yybegin(YYINITIAL); return symbol(sym.STRINGLITERAL, string.toString()); }
  [^\n\r\"\\]+                   { string.append( yytext() ); }
  \\t                            { string.append('\t'); }
  \\n                            { string.append('\n'); }

  \\r                            { string.append('\r'); }
  \\\"                           { string.append('\"'); }
  \\\\                           { string.append('\\'); }
}


/* error fallback */
.|\n                             { throw new Error("Illegal character <"+yytext()+">"); }

JLexと同様に、仕様書は %% で分割された３つの部分から成り立っている：  ユーザコード、 オプションおよび宣言、 字句規則。

ユーザコード

オプションと宣言

• %class Lexer は、生成されたクラスに "Lexer" という名前を与え、"Lexer.java" というファイルにコードを書き込むことをJFlexに知らせる。
• %unicode は、スキャナがその上で動作する文字の集合を定義する。
• %cup は、CUPで生成されたパーザとのインタフェースを行うCUP適合モードに切り替える。
• %line は、行数の計測をonにする（現在の行数は、変数 yyline によってアクセスできる）。
• %column は、桁数の計測をonにする（現在の桁数は、yycolumn によってアクセスできる）。

仕様書はマクロ宣言に続く。マクロは、レキサの仕様書を理解しやすくするための、正規表現の省略形である。マクロの定義は、マクロの識別子とそれに続く '='、その識別子を表す正規表現、によって成り立っている。この正規表現は、それ自身マクロの使用を含んでいてもよい。これは仕様書スタイルのような文法を可能にするが、マクロはただの省略形であって非終端ではない ― 繰り返しや相互再帰はできない。マクロ定義の中のサイクルは、JFlexによる生成時に発見され報告される。

ここで、例のマクロをいくつか詳細にする：

• LineTerminator は、ASCII CRか、ASCII LFか、CRに続くLFにマッチする正規表現を表す。
• InputCharacter は、CRかLFではないすべての文字を表す。
• TraditionalComment は、"/*"、'*' ではない文字、マクロ CommentContent にマッチするすべてのもの、任意の数の "*"、"/" という連続した文字列にマッチする表現である。
• CommentContent は、"*" を除く0個以上の任意の文字か、任意の数の "*" に続く "/" でない文字にマッチする。
• Identifier は、"jletter" クラスの文字で始まり、それに続く0個以上の "jletterdigit" クラスの文字である各文字列にマッチする。"jletter" と "jletterdigit" は前もって定義された文字のクラスである。"jletter" は、Javaの関数 Character.isJavaIdentifierStart が true を返すすべての文字を含み、"jletterdigit" は、Character.isJavaIdentifierpart が true を返すすべての文字を含む。もしUnicode対応のスキャナを生成するのであれば、それらのクラスはかなり大きくなり、生成過程をかなり減速するだろう ― 生成されたスキャナの速度は、しかしながら、影響を受けない。この話題についてより多くの情報については、セクション [predefined character classes] を参照。

字句規則

正規表現のマッチに加えて、仕様書を定式化(formulate)するために字句状態を使うことができる。字句状態は開始条件(start condition)のような働きをする。もし、スキャナが字句状態 STRING にあるなら、開始条件 <STRING> を前に持つ表現のみがマッチされる。ある正規表現の開始条件は、１つ以上の字句状態を含むことができる。字句状態 "YYINITIAL" は前もって定義されており、レキサがスキャニングを開始するときの状態でもある。もしある正規表現が開始条件を持たないのであれば、それは すべての 字句状態にマッチする。

同じ開始条件を持った表現の一群を持つことがよくあるので、JFlexではUnixツールの flex と同様の省略形が可能である：
<STRING> {
  expr1   { action1 }
  expr2   { action2 }
}
は、expr1 と expr2 の両方が開始条件 <STRING> を持つことを意味する。

私たちの例の最初の３つの規則は、開始条件 <YYINITIAL> を前に持つ正規表現の構文の実例である。

<YYINITIAL> "abstract"           { return symbol(sym.ABSTRACT); }
は、スキャナがその開始条件 "YYINITIAL" にあるときのみ、入力 "abstract" にマッチする。文字列 "abstract" がマッチされたとき、スキャナ関数はCUPのシンボル sym.ABSTRACT を返す。もしあるアクションが値を返さないのであれば、スキャニングの処理は、アクション実行後、ただちに再開される。

<YYINITIAL> {
...
}
に囲まれた規則は、省略構文の実例であり、状態 YYINITIAL においてのみマッチされる。

これらの規則の、特に興味深いのは
  \"                             { string.setLength(0); yybegin(STRING); }
である。

もし、スキャナが状態 YYINITIAL でダブルクォーテーションにマッチするならば、私たちは文字列リテラルの開始を認識する。それゆえに、その文字列リテラルの内容を保持する StringBuffer をクリアし、字句状態 STRING に切り替えることを yybegin(STRING) を使ってスキャナに知らせる。パーザに値を返していないため、スキャナーはすぐに処理を続行する。

字句状態 STRING では、マッチした入力を参照するためのもう一つの規則を例示している：
  [^\n\r\"\\]+                   { string.append( yytext() ); }

表現 [^\n\r\"\\]+ は、次のバックスラッシュ（\n のようなエスケープシーケンスを意味する）、ダブルクォーテーション（文字列の終りを意味する）、もしくは行の終端(line terminator)（文字列リテラルの中で起こってはいけない）までの入力ですべての文字にマッチする。入力のマッチされた部分は、yytext() を使って参照され、解析された文字列リテラルの内容に追加される。

例の仕様書の最後の字句規則は、エラーフォールバック(error fallback)として使われる。それは、もう一つの規則でマッチされなかったすべての状態ですべての規則にマッチする。それは、最も低い優先順位を持ち（最後の規則であるため）、ただ１文字だけとマッチするため、他のいかなる規則とも衝突しない。
 

How to get it going:

• JFlexをインストール（セクション [Installing JFlex] を参照）
• もしあなたが仕様書ファイルを書いた（もしくは examples ディレクトリから選択した）のであれば、それをセーブする（たとえば java-lang.flex という名前で）
• 以下のようにしてJFLexを実行する
jflex java-lang.flex
 
• JFlexは、スキャナの生成について進行状況を報告し、あなたの仕様書ファイルのディレクトリに生成されたコードを書き出すはずである
• 生成された .java ファイルとあなたのクラスをコンパイルする（もしCUPを使うなら、まず最初にパーザクラスを生成する）
• これでおしまい。

4 レキサの仕様書

ユーザコード
%%
オプションと宣言
%%
字句規則

仕様書のすべての部分において、/* コメント文 */ という形式のコメントと、// で始まるJava形式の行末コメントが考慮されている。JFlexのコメントは入れ子になる ― そのため、/* の数と */ の数はつり合わせるべきである。

ユーザコード

オプションと宣言

%class "classname"

クラスオプションとユーザクラスコード

• %class "classname"

は、生成されたクラスに名前 "classname" を与え、生成されたコードをファイル "classname.java" に書くことをJFlexに知らせる。そのコードは、仕様書のファイルが存在するディレクトリに書かれるだろう。もし仕様書に %class 命令が一つも存在しなければ、生成されたクラスは "Yylex" という名前を得て、"Yylex.java" というファイルに書かれるはずである。仕様書内の %class 命令は1つだけでなければならない。
 
• %implements "interface 1"[, "interface 2", ..]

は、記述されたインターフェイス(interface)を生成されたクラスに実装(implements)する。もし、１つ以上の %implements 宣言が存在するのであれば、記述されたすべてのインターフェイスが実装されるだろう。
 
• %public

は、生成されたクラスをpublicにする（デフォルトでは、そのクラスはそれ自身のパッケージの中だけでアクセス可能である)。
 
• %{

...
%}
%{ と %} で囲まれたコードは、生成されたクラスにそのままコピーされる。ここで、生成されたスキャナの中に、あなた自身のメンバ変数と関数を定義することができる。すべてのオプションのように、%{ と %} の両方とも、仕様書の行頭になければならない。もし１つ以上のクラスコード命令 %{...%} が存在するなら、そのコードは仕様書の中に現れる順番で連結される。
 
• %init{

...
%init}
%init{ と %init} で囲まれたコードは、生成されたクラスにそのままコピーされる。ここで、%{...%} 命令の中で宣言されたメンバ変数を初期化することができる。もし１つ以上の初期化オプションが存在するなら、そのコードは仕様書の中に現れる順番で連結される。
 
• %initthrow{

"exception1"[, "exception2", ...]
%initthrow}
は、記述された例外をコンストラクタの throws 節で宣言されるようにする。もし１つ以上の %initthrow{...%initthrow} 命令が仕様書の中に存在するなら、記述されたすべての例外が宣言されるだろう。

スキャニングメソッド

• %function "name"

は、スキャニングメソッドが記述された名前を得るようにする。もし仕様書の中で %function 宣言が与えられなければ、スキャニングメソッドは "yylex" という名前を得る。
 
• %integer

は、スキャニングメソッドがJavaの型 int として宣言されるようにする。仕様書の中のアクションは、そのため、トークンとして int の値を返すことができる。この設定のもとでデフォルトのEOF(end of file)の値は YYEOF であり、それは生成されたクラスの public static final int メンバである。
 
• %intwrap

は、スキャニングメソッドがJavaのラップ(wrapper)型 Integer として宣言されるようにする。仕様書の中のアクションは、そのため、トークンとして Integer の値を返すことができる。この設定のもとでデフォルトのEOFの値は null である。
 
• %type "typename"

は、スキャニングメソッドが記述された型の値を返すように宣言されるようにする。仕様書の中のアクションは、そのため、トークンとして typename 型の値を返すことができる。もし typename が java.lang.Object のサブクラスでなければ、あなたは %eofval{...%eofval} 命令を使って別のEOFの値を記述しなければならない（訳註：Javaのすべてのクラスは、言語仕様上 java.lang.Object の（直接、あるいは間接の）サブクラスである。だから、実際にはこのような状況は起こりえないはずだが……）。%type 宣言は、%cup スイッチの設定を上書きする。
 
• %yylexthrow{

"exception1"[, "exception2", ... ]
%yylexthrow}
%yylexthrow{...%yylexthrow} の内側にリストされた例外は、スキャニングメソッドのthrows節で宣言されるだろう。もし仕様書に１つ以上の %yylexthrow{...%yylexthrow} 節が存在するなら、記述されたすべての例外が宣言されるだろう。
 

ファイルの終端(EOF)

EOFのデフォルト値は、スキャニングメソッドの戻り値型に依存する：

• %integer では、スキャニングメソッドは値 YYEOF を返すだろう。それは、生成されたクラスの public static final int メンバである。
• %intwrapでは、あるいは、
• どこにも型の記述がないか、あるいは、
• %type を使って宣言されたユーザ定義型では、その値は nullである。
• %cup を使ったCUP互換モードでは、その値は new java_cup.runtime.Symbol(sym.EOF) である。

• %eofval{

...
%eofval}
%eofval{ ... %eofval} に含まれるコードは、スキャニングメソッドにそのままコピーされ、EOFに到達したときに 毎回 実行される。（これは、EOFに到達した後に、ふたたびスキャニングメソッドが呼ばれるときも可能である）。そのコードは、パーザにEOFを表す値を返すことができる（返すべきである）。仕様書の %{eofval ... %eofval} 節は１つだけにすべきである。%{eofval ... %eofval} 命令は、%cup スイッチの設定を上書きする。
 
• %eof{

...
%eof}
%{eof ... %eof} に含まれるコードは、確実に一度は実行されるはずである。そしてそのとき、EOFに到達している。そのコードは、メソッド void yy_do_eof() に含まれ、どのような値も返すべきではない（この目的のために、%eofval{...%eofval} を使う）。もし１つ以上のEOFコード命令が存在するとき、そのコードは仕様書に現れる順番で連結される。
 
• %eofthrow{

"exception1"[,"exception2", ... ]
%eofthrow}
%eofthrow{...%eofthrow} の内側にリストされた例外は、メソッド yy_do_eof() のthrows節で宣言される。メソッドの中に含まれる（そのメソッドについては %eof{...%eof} も参照）。もし１つ以上の %eofthrow{...%eofthrow} 節が存在するなら、記述されたすべての例外が宣言されるだろう。
 
• %eofclose
  は、JFlexがEOFで入力ストリームを閉じるようにする。コード yyclose() はメソッド yy_do_eof() に（%eof{...%eof} に記述されたコードとともに）追加され、例外 java.io.IOException は、このメソッドのthrows節で（%eofthrow{...%eofthrow} のそれらとともに）宣言される。
   

スタンドアロンスキャナ

• %debug

は、生成されたクラスのメイン関数を作成する。それは、コマンドライン上で入力ファイルの名前を期待(expect)し、EOFに到達するまで返された各トークンをJavaコンソール上に表示することによって、この入力ファイル上でスキャナを実行する。
 
• %standalone

は、生成されたクラスのメイン関数を作成する。それは、コマンドライン上で入力ファイルの名前を期待(expect)し、この入力ファイル上でスキャナを実行する。スキャナによって返された値は無視される。しかし、任意のマッチしなかったテキストは、その代わりに、Javaコンソール上に表示される。

CUPとの適合性

• %cup

%cup 命令は、CUP適合モードを可能にし、以下の命令の集合と同等である：
%type java_cup.runtime.Symbol
%eofval{
  return new java_cup.runtime.Symbol(sym.EOF);
%eofval}
%eofclose
 

コードの生成

• もし命令が与えられなければ、JFlexは入れ子になったswitch文の中にハードコードされたDFAを持つスキャナを生成するだろう。このメソッドは、コンパイルされた .class ファイルのサイズの点から大量の圧縮を与えるだけでなく、かなり良い性能を提供する。けれども、もしあなたのスキャナが大きくなるのであれば（だいたい200状態以上）、性能がはなはだ悪化するため、%table 命令か %pack 命令のどちらか一つを考慮すべきである。もしあなたのスキャナがそれよりもさらに大きくなるのであれば（およそ300状態）、Javaのコンパイラ javac は破損したコードを生成する可能性があり、実行時にクラッシュするか、仮想マシンによってチェックを受けたときに java.lang.VerifyError を報告するかもしれない。これは、Java仮想マシンの仕様書 [9] に記述されたように、Javaのメソッドの64KBのサイズ制限によるものである。この場合、デフォルトのコード生成方法は、ふつう、%table 命令よりも高圧縮のDFA表を提供するため、あなたは %pack 命令の使用を強いられるであろう。

 
• %table

%table 命令は、JFlexが古典的な表駆動スキャナを提供するようにする。それは、そのDFA表を2次元配列にエンコードする。このモードでは、JFlexは少量の表圧縮だけを行い（表圧縮の問題についての詳細については [6],[10],[1],[11] を参照）、JLexがバージョン1.2.2まで行っていたのと同じ方法を使用する。これらの方法を比較するために、このマニュアルのセクション ［性能について二言三言］ を参照のこと。上と同じ理由で（メソッドの64KBのサイズ制限）、同じ問題が発生する。それは、スキャナが大きすぎるときである。これは、仮想マシンが標準の方法として、配列の静的な初期化子を処理するように思われるからである。あなたは、この場合でも、その問題を避けるために %pack 命令の使用を強いられるだろう。
 
• %pack

%pack は、JFlexが生成されたDFA表だけを圧縮するようにする。そしてそれは、最初のスキャナオブジェクトが作成される（そしてその結果、初期化される）とき、展開される必要がある。展開後、DFA表への内部アクセスは、%table オプションを使うのとまったく同じである ― 唯一の余分な仕事は、拡張されたDFA表のサイズに比例した時間計算量においては非常に高速な、展開処理である。すなわち、それはある特定のスキャナクラスに対して１回だけ行われる ― それが何回インスタンス化されるかは問題にならない。また、これらのスキャナが実行時にどのようにふるまうかについては、セクション［性能について二言三言］をもう一度参照のこと。%pack を使えば、スキャナのサイズには事実上制限がないと考えるべきである。
 

文字集合

• %7bit

は、生成されたスキャナが７ビットASCIIの入力ファイル（文字コード0〜127）を期待するようにする。これはJLexにおけるデフォルト値であるため、JFlexも7ビットのスキャナをデフォルトとする。もし、127より大きいコードの入力文字が実行時に入力に現れたら、スキャナは ArrayIndexOutofBoundsException を投げるだろう。このためだけではないが、あなたは %full 命令か %unicode 命令の１つを使うことを考慮すべきである。
 
• %full
• %8bit

両方のオプションは、生成されたスキャナが８ビットASCIIの入力ファイル（文字コード0〜255）を期待するようにする。もし、255より大きいコードの入力文字が実行時に入力に現れたら、スキャナは ArrayIndexOutofBoundsException を投げるだろう。
 
• %unicode
• %16bit

両方のオプションは、生成されたスキャナが16ビットUnicodeの入力ファイル（文字コード0〜65535）を期待するようにする。この入力文字の集合を使えば、実行時オーバフローはないだろう。８ビットASCII入力の処理は、８ビットスキャナよりわずかに遅いかもしれない。
 
• %caseless

このオプションは、それらが大文字と小文字の両方の形式で記述されていたとしても、JFlexが仕様書ですべての文字と文字列を処理できるようにする。これは、大文字か小文字かによらないキーワードで言語に対するスキャナを記述する簡単な方法を可能にする。たとえば、仕様書の中の文字列 "break" は、表現 ([bB][rR][eE][aA][kK]) のように処理される。%caseless オプションは、マッチしたテキストを変化させず、文字クラスに影響しない。そのため、[a] は文字 a にだけマッチし、A にもマッチすることはない。どの文字が大文字でどの文字が小文字であるかは、Unicode標準によって定義され、Javaのメソッド Character.toUpperCase と Character.toLowerCase を使ってJFlexによって決定される。
 

行数、文字数、桁数の計測

• %char

は、文字数の計測をonにする。int のメンバ変数 yychar は、入力の先頭から現在のトークンの先頭までの（0から始まる）文字数を持っている。
 
• %line

は、行数の計測をonにする。int のメンバ変数 yyline は、入力の先頭から現在のトークンの先頭までの（0から始まる）行数を持っている。
 
• %column

は、桁数の計測をonにする。int のメンバ変数 yycolumn は、現在の行の先頭から現在のトークンの先頭までの（0から始まる）文字数を持っている。

 

もはや使われないJLexのオプション

• %notunix

このJLexのオプションは、まだ有効な命令として認識されるが、もはや使われない。それは、W95とUnixの間で正規表現の $ 演算子に対する改行文字(line terminators)の種類（\r\n と \n）を切り替えるために使用した。JFlexは両方の形式のプラットホーム依存の改行文字を常に認識する。
 
• %yyeof

このJLexのオプションは、まだ有効な命令として認識されるが、もはや使われない。それは、メンバ定数 YYEOF をpublicとして宣言するために使うべきであった。JFLexはいずれにしてもそれをpublicで宣言する。
 

状態の宣言

%state "state identifier"[, "state identifier", ... ]

連続した

%state STATE1
%state STATE3, XYZ, STATE_10
%state ABC STATE5

マクロ定義

macroidentifier = regular expression

各マクロは１つの行に収めなければならない。

右辺の正規表現は、よく形式化されて(well formed)いなければならず、^ 演算子や $ 演算子を含んでいてはならない。JLexとは違い、マクロは単なる一片のテキストではなく、コピーすることによって拡張される ― それらは構文解析され、よく形式化されていなくてはならない。

これは特徴である。それは、字句仕様の中のバグを見つけるためのいろいろな苦労を削除する（より複雑なマクロを囲む丸カッコを持たないようなこと ― JFlexではその必要がない）。JLex形式のマクロの問題のより詳細については［JLexからの移植］を参照のこと。

マクロ定義においてマクロの使用が可能であるため、要求される字句構造を記述するための表記のような文法を使うことが可能である。マクロは、しかしながら、それらを表す正規表現の単なる省略形のままである。それらは文法の非終端ではないし、どのような方法でも再帰的に使うことはできない。JFlexは、生成時にマクロ定義の中のサイクルを見つけ、それらを報告する。JFlexはまた、定義されているが仕様書の“字句規則”セクションで使われないマクロについても警告する。
 

字句規則

構文

PredefinedClass ::= '[:jletter:]'
                  | '[:jletterdigit:]'
                  | '[:letter:]'
                  | '[:digit:]'
                  | '[:uppercase:]'
                  | '[:lowercase:]'
                  | '.'

文法は以下の終端記号を使用する：

• JavaCode
Java言語仕様書 [7] の14.2節で記述されたような BlockStatements の連続。
• Number
負でない10進整数。
• Identifier
文字 [a-zA-Z] に続く、０文字以上の文字、数字、または下線 [a-zA-Z0-9_] の連続。
• Character
これらのメタ文字の一つではない、エスケープシーケンスまたは任意のUnicode文字：
 |  (  )  {  }  [  ]  <  >  \  .  *  +  ?  ^  $  /  .  "
• StringCharacter
これらのメタ文字の一つではない、エスケープシーケンスまたは任意のUnicode文字：
 \  "
• エスケープシーケンス
• は、以下の中の１つ

  \n  \r  \t  \f  \b
• \x に続く、２桁の16進数 [a-fA-F0-9]（標準ASCIIエスケープシーケンスを意味する）、
• \u に続く、４桁の16進数 [a-fA-F0-9]（Unicodeエスケープシーケンスを意味する）、
• バックスラッシュに続く、000から377までの３桁の８進数（標準ASCIIエスケープシーケンスを意味する）、
• バックスラッシュに続く、その文字を意味する任意の他のUnicode文字。

JFlexバージョン1.1においては、空白文字 " " (space) と "\t" (tab) は、正規表現の読みやすさを改良するために使うことができる。それらはJFlexによって無視されるだろう。しかしながら、文字のクラスと文字列では、空白文字は空白そのものを表すだけである（そのため、文字列 " " は、正確な１つのスペース文字とマッチし、[ \n] はASCII LFまたはスペース文字とマッチする）。

JFlexは以下の標準的な演算子の優先順位を適用する（最上位から最下位の順）：

• 単項演算子 ('*','+','?', {n}, {n,m})
• 連結 (RegExp::= RegExp Regexp)
• 共通部分 (RegExp::= RegExp '|' RegExp)

意味論

以下のものから構成されるものだけが正規表現である。

• Character はこの文字にマッチする。
• 文字クラス '[' (Character|Character'-'Character)+ ']' は、そのクラスの任意の文字にマッチする。もしそのクラスにリストされているか、そのコードがリストされた文字の範囲 Character'-'Character の中にあれば、ある Character はあるクラスの要素と考えられるものである。そのため、例えば [a0-3\n] は、文字 a 0 1 2 3 \n のいずれかとマッチする。
• 文字列 '"' StringCharacter+ '"' は、ダブルクォーテーションで囲まれた正確なテキストにマッチする。\ と " 以外のメタ文字は、文字列の中ではそれらの特別な意味を失う。
• マクロの使用 '{' Identifier '}' は、"Identifier" という名前を持ったマクロの右辺にマッチされる入力にマッチする。
• 前もって定義された文字クラスは、そのクラスのどのような文字にもマッチする。前もって定義された文字クラスには以下のようなものがある：
.                は、\n 以外のすべての文字を含む。

その他のすべての前もって定義された文字クラスは、java.lang.Character クラスのJava関数によって定義される。
[:jletter:]      isJavaIdentifierStart()
[:jletterdigit:] isJavaIdentifierPart()
[:letter:]       isLetter()
[:digit:]        isDigit()
[:uppercase:]    isUpperCase()
[:lowercase:]    isLowerCase()

それらは特に、Unicodeの文字集合を使った動作のときに有用である。スキャナジェネレータは、これらのクラスがUnicode文字の集合とともに使用されるとき、非常に大量の異なった文字を考慮しなければならないため、それらが生成処理を大幅に減速させるだろう。

a|b

(union) は正規表現である。それは、a または b にマッチされるすべての入力にマッチする。

ab

(concatenation) は正規表現である。それは、a にマッチされる入力とそれに続く b にマッチされる入力にマッチする。

a*

(kleene closure) は、a にマッチされる入力の０回以上の繰り返しにマッチする。

a+

は、aa* と等しい。

a?

は、空の入力、または a にマッチされる入力にマッチする。

a{n}

は、a の n 個の連結に等しい。そのため、たとえば a{4} は表現 a a a a に等しい。10進整数 n は正の数でなければならない。

a{n,m}

は、少なくとも n 個、最大 m 個の a の連結に等しい。そのため、たとえば a{2,4} は、表現 a a a? a? に等しい。n と m の両方は非負の整数であり、m は n よりも小さくてはいけない。

(a)

は a と同じ入力にマッチする。

字句規則において、正規表現 r にはその後に（行末演算子）'$' が続くことがある。r は、入力中の行の最後にのみマッチする。行の最後は、正規表現 \r|\n|\r\n によって示される。行の最後は、消費されず、マッチされたテキストの範囲に含まれない。
 

入力はどのようにマッチされるのか

字句状態は、現在の入力にマッチする正規表現の集合を、さらに制限するために使うことができる。
 

• 正規表現は、関連づけられた字句状態の集合がスキャナの現在のアクティブな字句状態を含むとき、もしくは、関連づけられた字句状態の集合が空であるならば、そのときに限りマッチされる。

 
• スキャナの現在のアクティブな字句状態は、正規表現のアクションの中で、メソッド yybegin() を使って変更することができる。

 
• スキャナは字句状態 YYINITIAL で始まる。それは、常にデフォルトで宣言される。

 
• 正規表現に関連づけられた字句状態の集合は、以下のように計算される。

 
以下の形式の規則の字句状態の集合
StateList RegExp Action
は、StateList にリストされたすべての状態の集合と、囲んでいる StateGroup の字句状態の集合との共通集合、もしくは、囲んでいる StateGroup がなければ、StateList にあるすべての状態の集合のみ、である。

以下の形式の状態グループの字句状態の集合

StateList "{" Rule+ "}"
は、StateList にリストされたすべての状態の集合と、囲んでいる StateGroup の字句状態の集合との共通集合、もしくは、囲んでいる StateGroup がなければ、StateList にあるすべての状態の集合のみ、である。

要するに：字句状態とは StateGroups を累積(cumulate)したものである。


 
• 字句状態は、それらが仕様書の中で使われるのと同じ名前のもとで、生成されたクラスのJavaの int 定数のように宣言され、使われる。

 

アクションでアクセス可能なスキャナメソッドと変数

• String yytext()
は、マッチされた入力テキストの範囲を返す。
• int yylength()
は、マッチされた入力テキストの範囲の長さを返す（作成すべき String オブジェクトを必要としない）。
• void yyclose()
は、入力ストリームを閉じる。スキャニングメソッドの呼び出し後はいつも、EOFの値を返す。
• int yystate()
は、スキャナの現在の字句状態を返す。
• void yybegin(int lexicalState)
は、字句状態 lexicalState に遷移する。
• void yypushback(int number)
は、マッチしたテキストの number 個の文字を入力ストリームに押し戻す(pushback)。それらのテキストは、スキャニングメソッドの次の呼び出しで読まれるだろう。再び読まれるための文字数は、マッチしたテキスト（の文字数）よりも大きくてはいけない。 その押し戻された文字は、yypushback の呼び出しの後では、yylength と yytext() には含まれないだろう。Javaでは文字列は変更できないことに注意する。すなわち、以下のようなアクションコード

String matched = yytext();
yypushback(1);
return matched;
 
は、マッチしたテキスト全体を返すだろう。しかし一方

yypushback(1);
return yytext();
 
は、マッチしたテキストから最後の文字を差し引いたものを返すだろう。
• int yyline
は、入力における現在の行数を持っている（０から始まる、%line 命令を使ったときのみ有効）
• int yychar
は、入力における現在の文字数を持っている（０から始まる、%char 命令を使ったときのみ有効）
• int yycolumn
は、現在の行の現在の文字数を持っている（０から始まる、%column 命令を使ったときのみ有効）

5 性能について二言三言

Scanners generated by the tool JLex are quite fast: It was however possible to further improve the performance of generated scanners using JFlex. The following table shows the results that were produced by the scanner specification of a small toy programming language (it was in fact the example from the JLex website). The scanner was generated using JLex and all three different JFlex code generation methods. Then it was run on a W95 system using JDK 1.1.6 with  a sample input of about 5000 lines of code of that toy programming language. The values presented in the table denote the time from scanner object creation to returning the EOF value.
 

	JLex	JFlex (default)		JFlex (%table)		JFlex (%pack)
5000 lines, JIT	0,94 sec	0,88 sec	6,8% faster	0,83 sec	13,2 % faster	0,83 sec	13,2 % faster
5000 lines, no JIT	1,65 sec	1,43 sec	15,4% faster	1,48 sec	14,9 % faster	1,49 sec	10,7 % faster

 
Since the scanning time of the lexical analyzer examined in the table above includes lexical actions that often need to create new object instances, another table shows the execution time for the same specification without lexical actions. A larger input file (about 15000 lines) has been used to reduce noise in the time measuerments.
 

	JLex	JFlex (default)		JFlex (%table)		JFlex (%pack)
15000 lines, JIT	0,55 sec	0,44 sec	25,0 % faster	0,38 sec	44,7 % faster	0,38 sec	44,7 % faster
15000 lines, no JIT	2,52 sec	2,09 sec	20,5 % faster	2,14 sec	17,8 % faster	2,14 sec	17,8 % faster

 
It is however very difficult to optimize Java programs aggressivly, because execution time of single instructions depend on the platform and the implementation of the Java Virtual Machine the program is executed on. Therefore the tables above can not be used as a reference to which code generation method of JFlex is the right one to choose in general. The following table was produced by the same lexical specification and the same input on a Linux system using JDK 1.1.5.
 

	JLex	JFlex (default)		JFlex (%table)		JFlex (%pack)
5000 lines,  with actions	4,25 sec	3,77 sec	12,7 % faster	3,83 sec	11,0 % faster	3,81 sec	11,5 % faster
15000 lines,  with actions	1,33 sec	1,20 sec	10,8 % faster	1,23 sec	8,1 % faster	1,21 sec	9,9 % faster
5000 lines,  without actions	2,53 sec	2,09 sec	21,0 % faster	2,15 sec	17,7 % faster	2,16 sec	17,1 % faster
15000 lines,  without actions	0,86 sec	0,75 sec	14,7 % faster	0,76 sec	13,2 % faster	0,77 sec	11,7 % faster

Although all JFlex scanners were faster than those generated by JLex, it shows slight differences between JFlex code generation methods when compared to the relations obtained on the W95 system.

It should also be stated here, that DFA based scanners like those generated by JFlex are usually faster than handwritten ones.
 
The following table compares a handwritten scanner for the Java language obtained from the website of CUP with the JFlex generated scanner for Java that comes with JFlex in the examples directory. They were tested on two different .java files on a W95 system using JDK 1.1.6.
 

	handwritten scanner	JFlex generated scanner
7473 lines, JIT	2,42 sec	1,04 sec	132,6 % faster
5045 lines, JIT	1,71 sec	0,88 sec	94,3 % faster
7473 lines, no JIT	5,88 sec	1,86 sec	216,1 % faster
5045 lines, no JIT	4,01 sec	1,21 sec	231,4 % faster

 
As you can see, the generated scanner is up 230% faster than the handwritten one. The alert reader surely has noticed that execution times for the JFlex generated scanner differ only very little for a run with JIT compiler and without. With very large scanners and small input files this may even lead to the somewhat strange effect, that the scanner is faster without a JIT compiler than with the JIT switched on.

As Angelo Schneider pointed me: This is because the generated scanners are so good :-) What? Yes. Letｴs take a look at the characteristics of a scanner: A scanner uses only a certain percentage X of its time for recognizing symbols, executing actions and the like. The rest of the time is spent with IO. An optimal scanner has a very small percentage X for the actual scanning and spends almost all of its time with IO. A bad scanner has a high value of X. A JIT compiler can only improve the X part of the scanner and can improve almost nothing of the IO time. So if the JFlex scanner has a low X value and is large (so it takes long for the JIT to compile it) and the input is small (so the small X that is improved can't pay off) the scanner gets slower with JIT than without (but it should still be faster than handwritten).

One example of a handwritten scanner that is considerably slower than the equivalent generated one is surely no proof for all generated scanners being faster than handwritten.It is clearly impossible to prove such a thing since you could always write the generated scanner by hand. From a software engineering point of view however, there is no excuse for writing a scanner by hand since this task takes more time, is more difficult and therefore more error prone than writing a compact, readable and easy to change lexical specification.
 

How to write a faster specification

• Avoid rules that require backtracking
From the C/C++ flex manpage: "Getting rid of backtracking is messy and often may be an enormous amount of work for a complicated scanner." Backtracking is introduced by the longest match rule and occurs for instance on this set of expressions:
 
  "averylongkeyword"
  .
 
With input "averylongjoke" the scanner has to read all charcters up to 'j' to decide that rule ´.´ should be matched. All characters of "verylong" have to be read again for the next matching process. Backtracking can be avoided in general by adding error rules that match those error conditions
  "av"|"ave"|"avery"|"averyl"|..
While this is impractical in most scanners, there is still the possiblity to add a "catch all" rule for a lengthy list of keywords
   "keyword1"     { return symbol(KEYWORD1); }
   ..
   "keywordn"     { return symbol(KEYWORDn); }
   [a-z]+         { error("not a keyword"); }

 
• Match as much text as possible in a rule.
One rule is matched in the innermost loop of the scanner. Doing most of the work there gains performance.

 
• Avoid the beginning of line operator '^'
It costs one additional comparison per input character.

 
• Avoid line and column counting
It costs one additional comparison per input character.

 
• Avoid the unicode character set
It costs one additional comparison per input character.

 
• Avoid the end of line operator '$'
It costs one additional comparison per action.

It should be mentioned, that some of these tips contradict to a readable and compact specification style. When in doubt or when requirements are not (yet) fixed: don't use them - the specification can always be optimized in a later state of the development process.

6 JLexからの移植

これは、すべての「よく形式化された(well formed)」JLexの仕様書上で、 予想されるような動作をする。

上の記述がいくぶん絶対的(absolute)であることから、ここでは "well formed" が何を意味するかをちょっと調べてみよう。あるJLexの仕様書がwell formedであるのは、その仕様書が以下のようになっている場合である

• JLexによって実際のスキャナを生成する
• '^' 演算子を含まない
行頭演算子は、JLexでは標準的ではないふるまいをする：それは直前の文字 \n を消費する。これは、JFlexが生成したスキャナでは起こらない。その問題は、「新しい」文字 \n にマッチする余分なルールをあちこちに書くことによって解決できる。
• '$' 演算子を含まない
行末演算子は、JLexではプラットホーム非依存ではない。それは、デフォルトでは \n にマッチし、%notunix 命令が与えられたときは \r\n にマッチする。JFlexでは行末として表現 \r|\n|\r\n にマッチし、%notunix 命令を無視する。これは他のプラットホームでもまた受理すること以外には、あなたの古い仕様書でもふつうは何ら問題はないだろう。
• %cup スイッチを含まない
%cup スイッチはJLexでは何の意味も持たない。JFlexではそれは［CUPとのインターフェイス］として使われる。
• マクロ定義において丸カッコによって囲まれる完全な正規表現のみを持っている
これはちょっと厳しく聞こえるかもしれないが、重大な問題になることがある ― それは、仕様書の中にある、最初の状況では目立たなかったいくつかのいやらしいバグを見つける事態をなるべく避ける。JLexでは、マクロの右辺はただの一片のテキストであり、それはマクロが使用される場所にコピーされる。これによって
macro1 = ("hello"
macro2 = {macro1})*
のようなわけのわからない素材は（macro2 を ("hello")* に展開することで）可能になる。これはJFlexでは許されないことであり、あなたはこの定義を変更しなければならないだろう。しかしながら、JLexのマクロによって導入できる、もっと難解な種類のエラーが存在する。
macro = a|b
のような定義と
{macro}*
のような使用を考えてみよう。これはJLexでは
a|b*
と展開され、おそらく意図的に
(a|b)*
とは展開されない。JFlexは常に後者の展開法を使用する。これが正規表現に対する省略形について自然な考え方だからである。

ほとんどの仕様書は、しかしながら、この問題によって苦しむことはないだろう。というのは、マクロはしばしば

alpha = [a-zA-Z]
のような（悪意のない）文字クラスや
ident = {alpha}({alpha}|{digit})*
のようなもう少し危険な定義を含んでいるからである。それらは
{ident}        { .. action .. }
のような規則を書くためにだけ使われ、上で示された種類のエラーがきわだたせられる
          {ident}*
のようなもっと複雑な表現ではない。

7 協調動作：JFlexとCUP

もしあなたが、このように始まるスキャナの仕様書を持っているのであれば：

parser code {:
  Lexer lexer;

  public parser (java.io.Reader input) {
    lexer = new Lexer(input);
  }
:};

scan with {: return lexer.yylex(); :};
..

パーザはこのようなメインルーチンで開始されることがある：

もしあなたが、生成されるスキャナの名前に依存しないパーザの仕様書を求めているのであれば、代わりにインターフェイス Lexer を書くことができる

parser code {:
  Lexer lexer;

  public parser (Lexer lexer) {
    this.lexer = lexer;
  }
:};

scan with {: return lexer.yylex(); :};

..

そして最後に、次のようになるようにメインルーチンを変更する

もしCUPが生成したパーザが提供するエラーメッセージを利用したいのであれば、CUPの仕様書の "parser code" セクションの中の report_error や report_fatal_error メソッドを上書き（オーバライド）することもできる。新しいメソッドは、例えば、ユーザに対してもっと便利にエラーの位置を報告するために yyline や yycolumn（クラス java_cup.runtime.Symbol のメンバ変数 left および right に格納されている）を使うことができる。このJFlexの配布(distribution)の examples\java\ ディレクトリの中にあるJava言語用のレキサとパーザは、この形式のエラー報告(error reporting)を使用している。これらの仕様書は、アクションの中で上のテクニックの実演も行っている。

8 バグ

If you find new ones, please report them to Gerwin Klein <kleing@informatik.tu-muenchen.de>.

Please check the FAQ and currently known bugs at the JFlex website before reporting a new bug.
 

9 参考文献

10 権利とライセンス

There is absolutely NO WARRANTY for JFlex, its code and its documentation.

The code generated by JFlex inherits the copyright of the specification it was produced from. If it was your specification, you may use the generated code without restriction.

See the file COPYING for more information.