[#17881] Re: [ruby-list:35696] Re: サブクラスのオブジェクト生成時に、スーパークラスの初期化を行うには ? — nobu.nakada@...

なかだです。

14 messages 2002/08/02
[#17883] Re: [ruby-list:35696] Re: サブクラスのオブジェクト生成時に、スーパークラスの初期化を行うには ? — nobu.nakada@... 2002/08/02

なかだです。

[#17906] Re: [ruby-list:35696] Re: サブクラスのオブジェクト生成時に、スーパークラスの初期化を行うには ? — Takaaki Tateishi <ttate@...> 2002/08/03

At Fri, 2 Aug 2002 12:17:33 +0900,

[#17908] Re: [ruby-list:35696] Re: サブクラスのオブジェクト生成時に、スーパークラスの初期化を行うには ? — matz@... (Yukihiro Matsumoto) 2002/08/03

まつもと ゆきひろです

[#17909] Re: [ruby-list:35696] Re: サブクラスのオブジェクト生成時に、スーパークラスの初期化を行うには ? — Takaaki Tateishi <ttate@...> 2002/08/03

At Sat, 3 Aug 2002 23:32:39 +0900,

[#17887] next parser (Re: parenthesize argument(s) for future version) — Minero Aoki <aamine@...>

あおきです。スレッド切ります。

18 messages 2002/08/02
[#17895] Re: next parser (Re: parenthesize argument(s) for future version) — matz@... (Yukihiro Matsumoto) 2002/08/03

まつもと ゆきひろです

[#17898] Re: next parser (Re: parenthesize argument(s) for future version) — Minero Aoki <aamine@...> 2002/08/03

あおきです。

[#17904] Re: next parser (Re: parenthesize argument(s) for future version) — matz@... (Yukihiro Matsumoto) 2002/08/03

まつもと ゆきひろです

[#17920] Re: next parser (Re: parenthesize argument(s) for future version) — Minero Aoki <aamine@...> 2002/08/04

あおきです。

[#17933] Re: next parser (Re: parenthesize argument(s) for future version) — matz@... (Yukihiro Matsumoto) 2002/08/06

まつもと ゆきひろです

[#17889] ruby-bugs-ja incoming/277 — Takaaki Tateishi <ttate@...>

立石です.

15 messages 2002/08/02
[#17890] Re: ruby-bugs-ja incoming/277 — Takaaki Tateishi <ttate@...> 2002/08/02

At Sat, 3 Aug 2002 05:13:32 +0900,

[#17927] Re: import-module (Re: Re: scope-in-state) — keiju@... (石塚圭樹)

けいじゅ@日本ラショナルソフトウェアです.

13 messages 2002/08/05
[#17943] Re: import-module (Re: Re: scope-in-state) — Shin-ichiro HARA <sinara@...> 2002/08/06

原です。

[#17949] Re: import-module (Re: Re: scope-in-state) — keiju@... (石塚圭樹) 2002/08/06

けいじゅ@日本ラショナルソフトウェアです.

[#17955] Re: import-module (Re: Re: scope-in-state) — Shin-ichiro HARA <sinara@...> 2002/08/07

原です。

[#17954] Selection IPv4/IPv6 at TCPSocket — NISHI Takao <zophos@...9.com>

にし@おかやまです。

19 messages 2002/08/07
[#18120] Re: Selection IPv4/IPv6 at TCPSocket — "Akinori MUSHA" <knu@...> 2002/08/31

At Wed, 7 Aug 2002 13:23:37 +0900,

[#18121] Re: Selection IPv4/IPv6 at TCPSocket — GOTO Kentaro <gotoken@...> 2002/08/31

At Sun, 1 Sep 2002 03:31:01 +0900,

[#18127] Re: Selection IPv4/IPv6 at TCPSocket — "Akinori MUSHA" <knu@...> 2002/09/01

At Sun, 1 Sep 2002 04:00:33 +0900,

[#18128] Re: Selection IPv4/IPv6 at TCPSocket — "Akinori MUSHA" <knu@...> 2002/09/01

At Sun, 1 Sep 2002 12:37:05 +0900,

[#18130] Re: Selection IPv4/IPv6 at TCPSocket — GOTO Kentaro <gotoken@...> 2002/09/01

At Sun, 1 Sep 2002 13:00:46 +0900,

[#18131] Re: Selection IPv4/IPv6 at TCPSocket — Minero Aoki <aamine@...> 2002/09/01

あおきです。

[#17965] inferior-ruby-mode and irb — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

22 messages 2002/08/09
[#17971] Re: inferior-ruby-mode and irb — matz@... (Yukihiro Matsumoto) 2002/08/10

まつもと ゆきひろです

[#18008] Re: inferior-ruby-mode and irb — keiju@... (石塚圭樹) 2002/08/14

けいじゅ@日本ラショナルソフトウェアです.

[#17966] Hash has default block? — Tanaka Akira <akr@...17n.org>

ふと、ひさしぶりに(一年ぶりくらい?) AMarshal に手を入れていて気になっ

34 messages 2002/08/09
[#17967] Re: Hash has default block? — "K.Kosako" <kosako@...> 2002/08/09

Tanaka Akiraさんの<hvo8z3gnvr6.fsf@coulee.a02.aist.go.jp>から

[#17969] Re: Hash has default block? — Tanaka Akira <akr@...17n.org> 2002/08/09

In article <20020809121059.B6DC51560@helium.ruby-lang.org>,

[#17977] Re: Hash has default block? — "K.Kosako" <kosako@...> 2002/08/12

Tanaka Akiraさんの<hvo65yknitf.fsf@coulee.a02.aist.go.jp>から

[#17989] Re: Hash has default block? — Tanaka Akira <akr@...17n.org> 2002/08/13

In article <20020812052018.C7F9B1671@helium.ruby-lang.org>,

[#17990] Re: Hash has default block? — matz@... (Yukihiro Matsumoto) 2002/08/13

まつもと ゆきひろです

[#17991] Re: Hash has default block? — matz@... (Yukihiro Matsumoto) 2002/08/13

まつもと ゆきひろです

[#17998] Re: Hash has default block? — "K.Kosako" <kosako@...> 2002/08/13

Yukihiro Matsumotoさんの

[#17999] Re: Hash has default block? — Tanaka Akira <akr@...17n.org> 2002/08/13

In article <20020813075933.DBB611415@helium.ruby-lang.org>,

[#18000] Re: Hash has default block? — matz@... (Yukihiro Matsumoto) 2002/08/13

まつもと ゆきひろです

[#18004] allocation framework — Tanaka Akira <akr@...17n.org> 2002/08/13

In article <1029229143.399680.2549.nullmailer@picachu.netlab.jp>,

[#18021] Re: allocation framework — matz@... (Yukihiro Matsumoto) 2002/08/15

まつもと ゆきひろです

[#18022] Re: allocation framework — Tanaka Akira <akr@...17n.org> 2002/08/15

In article <1029423141.763951.25373.nullmailer@picachu.netlab.jp>,

[#18023] Re: allocation framework — matz@... (Yukihiro Matsumoto) 2002/08/16

まつもと ゆきひろです

[#18024] Re: allocation framework — Tanaka Akira <akr@...17n.org> 2002/08/16

In article <1029464034.601483.27585.nullmailer@picachu.netlab.jp>,

[#18074] source file name at -r option — nobu.nakada@...

なかだです。

30 messages 2002/08/24
[#18352] Re: source file name at -r option — nobu.nakada@... 2002/09/22

なかだです。

[#18662] Re: ENABLE/DISABLE_TRACE (was Re: source file name at -r option) — "NAKAMURA, Hiroshi" <nakahiro@...> 2002/11/06

なひです。

[#18663] Re: ENABLE/DISABLE_TRACE (was Re: source file name at -r option) — nobu.nakada@... 2002/11/06

なかだです。

[#18667] Re: ENABLE/DISABLE_TRACE (was Re: source file name at -r option) — matz@... (Yukihiro Matsumoto) 2002/11/06

まつもと ゆきひろです

[#18673] Re: ENABLE/DISABLE_TRACE (was Re: source file name at -r option) — nobu.nakada@... 2002/11/07

なかだです。

[#18076] Win32 signal, process etc — nobu.nakada@...

なかだです。

14 messages 2002/08/24

[#18103] autoload patch for ruby-1.7 — "Yoshinori K. Okuji" <okuji@...>

[ruby-dev:16180]でトップレベル以外の定数についてもautoloadができるよう

24 messages 2002/08/29
[#18132] Re: autoload patch for ruby-1.7 — Minero Aoki <aamine@...> 2002/09/01

あおきです。

[#18139] Re: autoload patch for ruby-1.7 — "Yoshinori K. Okuji" <okuji@...> 2002/09/01

At Sun, 1 Sep 2002 15:53:24 +0900,

[#18145] Re: autoload patch for ruby-1.7 — Minero Aoki <aamine@...> 2002/09/02

あおきです。

[#18109] mkmf.rb and extmk.rb — WATANABE Hirofumi <eban@...>

わたなべです。

24 messages 2002/08/30
[#18157] Re: mkmf.rb and extmk.rb — matz@... (Yukihiro Matsumoto) 2002/09/03

まつもと ゆきひろです

[#18159] Re: mkmf.rb and extmk.rb — WATANABE Hirofumi <eban@...> 2002/09/03

わたなべです。

[ruby-dev:17952] Re: next parser (Re: parenthesize argument(s) for future version)

From: Minero Aoki <aamine@...>
Date: 2002-08-06 19:39:32 UTC
List: ruby-dev #17952
あおきです。

  In mail "[ruby-dev:17937] Re: next parser (Re: parenthesize argument(s) for future version)"
    matz@ruby-lang.org (Yukihiro Matsumoto) wrote:

> まつもと ゆきひろです

> メール出した後考え直して、やっと理解できました。部分的にパー
> ズしてネストのレベルを知るとか、irb相当を実装するのいはスト
> リーム的なAPIが欲しいだろうということですね。もっともです。

そゆことです。
すみません、相変わらず言葉足らずで…。

ruby_dyna_vars うんぬんと言ったのは、

  [ruby-dev:17895] Re: next parser
  > yacc以外にもCのコードからグローバルアクセスをなくすことは無
  > 理なので、あちこちにロックを入れることになると思います。です

の部分を誤解してて、「いずれにしろパーサからはグローバル変数に
アクセスしているので、パース中はロックをかけなくてはいけない」
と受けとったからでした。でもよく考えると「Cのコードからは」と
あるのでパーサだけの話ではないわけですね。

なのでそこは忘れてください。


> でも、それはパーザのエラーコードの一部としてネストレベルとか
> の情報を含めばよいような気もします。で、毎回あたまからパーズ
> すると。

それでは別の視点で……。その構文木からは
「インデックス n から始まる長さ 3 のトークンが予約語 def である」
というような情報は取れますか? それと同等のなにかでもいいですが。
たとえば Ruby でエディタを書いたとして、いちいちパーサを書き直さずに
Ruby プログラムをリアルタイムで色付けできるくらいの速度と情報が
得られるのなら文句はありません。


> ||# いちおう対案も用意してはあるんですが、
> 
> 対案も聞いてみたいです、ぜひ。

んではぼくの案を。
これはストリーム系 API を提供することを核とした案です。


まずこれまで通り yacc ベースで作るのを前提とします。
ただしユーザの用意した yacc は使わず、byacc なり bison なりを
改造して同梱します。その改造の内容は……

  1. 常にマシンスタック上にパーサスタックを確保することで
     GC セーフにする。

  2. yyparse をリエントラントにする。

  3. アクションの内容を yyparse 埋め込みでなく関数に分離し、
     しかも関数ポインタテーブル (atbl と仮称) 経由で呼ぶようにする。

  4. atbl はパーサインスタンスごとに指定可能とする。

この結果、たとえば

  stmts		: none
		| stmt
		    {
			$$ = newline_node($1);
		    }
		| stmts terms stmt
		    {
			$$ = block_append($1, newline_node($3));
		    }

というコードは次のように書いたものとして実行されます。

  stmts		: none { $$ = (*parser->atbl[5])(parser); }
		| stmt { $$ = (*parser->atbl[6])(parser,$1); }
		| stmts terms stmt { $$ = (*parser->atbl[7])(parser,$1,$2,$3); }

(parser はパーサインスタンスごとの情報を格納した構造体です。)
あとは適切に atbl を作ってやれば C or Ruby レベルで好きなように
振舞いを変更できます。

ripper を書いたときは文字列埋め込み式のまわりをかなり改造しな
いとうまくイベントを拾えなかったんですが、こないだの仕様変更で
それがほとんど必要なくなり、自動化が非常に簡単になっていると思
います。


利点

  * いちいち手書きでイベントを起こす必要がないので
    (まつもとさんの) 手間が少ない。

  * 複数のパーサインスタンスを同時に動かせる。

  * 規則が多少変わっても atbl の先でアレコレすれば ruby とは
    独立に互換性を保てる。

  * すぐにでも実装できる。

欠点

  * 相変わらず yacc の先読みとスキャナの状態遷移の競合で
    苦しむことになる。

  * Rite が出たときに「コア全体をスクラッチから書き直しました!」
    という派手な宣伝文句が使えなくなる (笑)

-------------------------------------------------------------------
青木峰郎

In This Thread