[#16708] includedir — nobu.nakada@...
なかだです。
[#16732] sharing sub-regexp — Tanaka Akira <akr@...17n.org>
Oniguruma についてひとつ要望があります。
Tanaka Akiraさんの<hvopu1hxfyd.fsf@coulee.a02.aist.go.jp>から
まつもと ゆきひろです
In article <1017890618.302241.17865.nullmailer@ev.netlab.jp>,
Tanaka Akiraさんの<hvo7knn93ug.fsf@coulee.a02.aist.go.jp>から
In article <20020405044506.D4784349@helium.ruby-lang.org>,
Tanaka Akiraさんの<hvopu1e4omy.fsf@coulee.a02.aist.go.jp>から
In article <20020410025054.C8DF0915@helium.ruby-lang.org>,
In article <hvor8lnchak.fsf@coulee.a02.aist.go.jp>,
前田です。
In article <87pu15z80q.wl@studly.priv.netlab.jp>,
前田です。
In article <87g01x1e6m.wl@studly.priv.netlab.jp>,
西山和広です。
In article <20020416180631.988E.ZN@mbf.nifty.com>,
前田です。
In article <87u1qaj0xe.wl@studly.priv.netlab.jp>,
前田です。
まつもと ゆきひろです
In article <1019116103.420173.12691.nullmailer@picachu.netlab.jp>,
前田です。
なかだです。
In article <200204181023.g3IANgM21124@sharui.nakada.kanuma.tochigi.jp>,
まつもと ゆきひろです
In article <1019140164.869863.14833.nullmailer@picachu.netlab.jp>,
[#16757] === — "Akinori MUSHA" <knu@...>
Array, Hash, Proc などで、 === が以下のように定義されていると
[#16761] StringIO — tadf@...
ふなばです。
なかだです。
ふなばです。
なかだです。
ふなばです。
青山です。
まつもと ゆきひろです
In article <1022740594.117106.6073.nullmailer@picachu.netlab.jp>,
前田です。
In article <874rgqdt3x.wl@studly.priv.netlab.jp>,
青山です。
まつもと ゆきひろです
青山です。
まつもと ゆきひろです
青山です。
まつもと ゆきひろです
青山です。
[#16776] Ruby 1.7.2 segfault — takuma ozawa <metal@...>
小澤といいます。
なかだです。
[#16790] Ruby Shim — "Akinori MUSHA" <knu@...>
1.7 early access kit という仮称で提案した構想ですが、先ほど
新井です。
At Tue, 9 Apr 2002 02:12:27 +0900,
なかだです。
[#16816] remove_const: cannot remove constant — Koji Arai <JCA02266@...>
新井です。
[#16833] math.c 1.10 — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
まつもと ゆきひろです
さくです。
なかだです。
まつもと ゆきひろです
[#16868] make error on debian potato — Wakou Aoyama <wakou@...>
青山です。
[#16869] Makefiles dependency — nobu.nakada@...
なかだです。
わたなべです。
なかだです。
わたなべです。
なかだです。
わたなべです。
なかだです。
[#16894] compile failure in process.c, setpgrp() & setpgid() — Ryo HAYASAKA <ryoh@...>
早坂@北陸先端です.
[#16923] Module::new with block is useful? — "Shin'ya Adzumi" <adzumi@...>
あづみです。
[#16978] Re: [rubyist:1343] Re: another sample for the Method — Koji Arai <JCA02266@...>
新井です。
[#16989] making Proc in C (Re: [rubyist:1356] Re: another sample for the Method) — nobu.nakada@...
なかだです。
[ruby-dev:16863] Re: sharing sub-regexp
In article <hvor8lnchak.fsf@coulee.a02.aist.go.jp>,
Tanaka Akira <akr@m17n.org> writes:
> うぅむ。ここはなかなか悩みどころです。
> ちょっと考えてみたいと思います。
考えてみました。
まず、パターン複製はいらないのではないかと思います。理由は 2つあります。
* パターンのソースを文字列として #{} で展開することにより、同等の効果
が得られる。
# #{} の中に Regexp オブジェクトがきたらソースを shy group で括って
# 展開して欲しいという話は別の話としてある。
* パターン共有とパターン複製は速度とメモリ使用量が異なるものの、機能と
しては同じであり、プログラマに直接選択させるべきものというよりも、
(コンパイラによる関数の inlining のように)optimization ととらえた方
がいいのではないか。
というわけで、とりあえずパターン複製はなくして、必要ならサブパターン内
部を全部展開するオプションをヒントとして導入するのがいいのではないかと
思います。
で、私は(確保する文字は一つで十分なので)大文字小文字の対を確保する必要
はないという立場になるわけですが、* を使って (?*name) あるいは
(?*<name>) を推します。この * というのは C のポインタの dereference に
由来しています。
また、後方参照については、置換と形式をあわせるといいんじゃないかと思います。
現在は後方参照と置換で \1 という形式は共通しているわけで、名前を使う時
も双方が同じものであるとプログラマにとっての混乱が少ないのではないか、
というわけです。
そして、先のメールに書いた通り、置換のテンプレートに $ という新しいメ
タキャラクタを導入するのはちと野心的過ぎると思うので、\ ではじまる、
Python の置換の \g<name> ないしは
.NET の後方参照の \k<name>
のどちらかをRuby の置換と後方参照で使えると良いのではないかと思います。
g と k とどちらがいいかというと、私は group の g ということで g を推し
ます。
あと、{} よりも <> のほうが、既存のと似ていて良いと思うので、
1. 名前定義: (?<name>...) (pattern, capture)
2. 名前定義: (?<:name>...) (patternのみ、captureなし)
3. 後方参照: \g<name>
4. 置換: \g<name>
5. パターン共有: (?*name) or (?*capture-number)
というのがいいかな、と思うんですが、どうでしょうか?
あ、パターン展開を示すのオプションを、Inline の I とすれば
6. パターン展開オプション: (?I)
もかな。なくてもいいと思いますが。
あと、(前にいらないと書いたのに)再帰的な定義も扱えるようにして欲しいと
かいったら呆れちゃいますか? これができると括弧の対や、一般に BNF が書
けるようになるんですが。
/...(?*non-terminal-1)... (?# start )
|[^\s\S] (?<non-terminal-1>...(?*non-terminl-2)...)
|[^\s\S] (?<non-terminal-2>...(?*non-terminl-1)...)
...
/x
とか書けると、一般に BNF みたいなものが書けるわけです。たとえば、
/(?<contents) (?*data) ( (?<paren>) (?*data) )*
|[^\s\S] (?<paren> \( (?*contents) \) )
|[^\s\S] (?<data> [^()]* )
/x
というように対になった括弧を書けるとか。
# [^\s\S] というのは決してマッチしないパターンのつもりです。[] って書
# けるといいんですけどね。歴史的に []] というのが許されてるから難しい
# んでしょうが。
ただ、再帰的な定義があると、あるサブパターンの先頭に現れる文字の集合を
求めるのが難しくなる(ボトムアップには求められなくて、不動点に到達する
まで繰り返す必要がある)し、左再帰なものを素朴に動かすと無限ループにな
るなど、実装は厄介になるだろうなぁ、と想像しています。なので、別に強く
は求めません。
なお、ここでさらに、stack 状のデータ構造が扱えると(上記の \( と \) の
かわりに <(?<tag>\w+)> と </\g<tag>> のようなパターンを使うことにより)
整形式の XML を扱えるようになるのでそういうものも欲しいような気がして
います。
# .NET の Balancing group definition をちゃんと調べなければ...
まぁ、私の要望はかなり特殊だと思うので面倒なら聞き流して下さい。
--
[田中 哲][たなか あきら][Tanaka Akira]
「ふえろ! わかめちゃん作戦です$(C⊇」(Little Worker, 桂遊生丸)