From: Kazuhisa Yanagawa <katze@...>
Date: 1997-12-11T11:21:26+09:00
Subject: [ruby-dev:1045] Re: Regexp#operators (Re: ruby 1.1b1 released)

in message-id: <199712100935.SAA15854@picachu.netlab.co.jp>
matz@netlab.co.jp (Yukihiro Matsumoto) writes:

> まつもと ゆきひろです
> 
> In message "[ruby-dev:1033] Re: Regexp#operators (Re: ruby 1.1b1 released)"
>     on 97/12/10, Shin-ichiro HARA <sinara@blade.nagaokaut.ac.jp> writes:
> 
> |原です。
> 
> |確かに。(^^; 本来はコンパイル後のオブジェクト（？）自身の演算
> |が出来れば理想的だけどいくらなんでもそれは無理なんでしょうね。
> 
> いやあ，regex.cの内部構造にべったりでそういうコードを書くこ
> とは不可能ではないでしょうけど，将来別のregexルーチンに乗り
> 換えたい気持もあるので，それは避けたいですねえ．

  効率を気にしないなら単にオートマトンを二つつくって, selection なら並
  列に, concatenation なら直列に並べるだけなわけですが....

  # でも後方参照入るとオートマトンにできないという話も見たような. それ
  # に後方参照の実装が異常に面倒になるような.

> |まあ、そんな数学の先生みたいな事を言ってもしょうがない。(^^;
> 
> 爆笑

  やっぱり NAND 一つつくって「これで完全」とか言うんでしょうか (^^;

> |ある程度便利に使える演算子ならいいんで、さっきは (?=) と (?!)
> |を使った例をあげたのです。
> 
> これで妥協できるんなら，そんなに難しくないんですが，なんか積
> や商という言葉(あるいは演算子)か想像できない動作のような気が…．

  そもそも正則表現の積や商と言うのはここで始めて見ました.

  # 商があるなら剰余もある?

> Iconの場合は言語の条件判定のモデルそのものが違うので，あんま
> り可能だといわないと思います．

  ちなみにどんなモデルなんでしょう?

===========================================================================
  柳川 @ 情報システム学研究科 . 電気通信大学
  katze@yuba.is.uec.ac.jp                            December 11th, 1997.  
# 絶対に負けない方法を教えてあげよう....戦わないことだ