Shiro Kawai
shiro****@lava*****
2002年 12月 9日 (月) 06:44:37 JST
regexpは [a-z] やら [[:alpha:]] やら \w やらを読むと、 内部的に<char-set>オブジェクトを作成しています。このルールに ユーザがフックを噛ませられれば、ユーザ定義の文字セットは 容易に実現できそうです。 APIに関しては二つの方法が考えられます。 (1) 実行時にregexpを生成する方法。これは本質的にはregexpを 表現する文字列を実行時に生成してstring->regexpするのと等価で、 単にそれにどれだけsyntax sugarをまぶせるか、ということになります。 SREも同じことで、ただ向こうはS式を使っているのでquasiquoteが 素直に使えます。Gaucheは既にstring interpolationというdirty hack があるので、毒喰わば皿までで #`/^,|*hiragana*|+$/ をやってしまう、とか。 (ここで、#`/.../ 構文は自身がregexpを解釈していることを知っているので、 *hiragana* の評価値がchar-setになればそれを文字列に変換せずとも 直接埋め込むことが出来るでしょう) ;; ただ、現在のstring interpolation のsyntax #`"... ,expr ..." ;; には色々不満もあって、 #"... ~expr ..." にしようかな、等と考えて ;; いたところだったので悩ましいですね。 (2) #/.../ 構文はread時に解釈されるので、quoteされた式中や データファイル中でも使えるという利点があります。この利点を残したまま pre-definedな文字セットをプログラマが拡張できるようにするのも 使いでがあるかもしれません。例えば lang.ja.charset みたいな モジュールを読んでおくと [:hiragana:] というような文字クラスが 使えるようになる、とか。 但し、readは変数のスコープは解釈しないので、そのような文字セット 定義はグローバルなものにならざるを得ませんが。 (define-character-class hiragana #[ぁ-ん]) #/^[[:hiragana:]]+$/ という感じでしょうか。 ;; しかし、POSIXの [:...:] 表記は見づらいですね。 ;; Perl 6がこのへんをばっさり捨てたのは正解かも。 --shiro
