From: keiju@... (=?ISO-2022-JP?B?GyRCQFBETTc9PHkbKEI=?= )
Date: 1998-06-18T00:25:23+09:00
Subject: [ruby-dev:2902] Re: what type are true and false

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

In [ruby-dev :2900 ] the message: "[ruby-dev:2900] Re: what type are
true and false ", on Jun/17 18:20(JST) Yukihiro Matsumoto writes:

>|えーと. コンパイル時ではなくて動的にローカル変数を決めるのは, 
>|
>|* 実装が難しい
>|* 静的に解釈する方が良い仕様
>|
>|どっち?
>
>既に「現に静的に解釈していて仕様がそれに依存している」です．
>具体的には引数なしの識別子がローカル変数にもメソッドにもなる
>部分です．他にもあったような…．

そうすると. 

NameError: undefined local variable or method `ffoo'

というエラーが出ますが, は実はそうじゃないんですね. この段階では`ffoo'
は, メソッドであると決まっているんですね.

>なお，効率の問題もありますから静的に解決できることは静的に解
>決したいという思いはあります．

うーん. なるほど....

>|  (proc {foo = 10}).call       # ブロック中なのでブロック内ローカル変数
>|
>|これは, やはり静的な構文上で初出かつ入れこのブロック中なのでその入れこ
>|のブロックのローカル変数になるのでは?
>
>ここで「rubyの変数にネストはない」というルールが出て来ます．
>つまり，ローカル変数にはブロック内変数かそうでないかの2種類
>しかなく，それらは名前が同じなら外側のものを使います．
># 例外は[ruby-list:8378]だけです．

>つまり，proc{foo=10}.callが実行される時点ですでにevalによっ
>てfooというブロック内変数が定義されてしまっているので，そち
>らの値を変更してしまいます．

つまり, proc{...}内の変数の共有はprocを実行する時に決まり, 静的に決ま
るわけではないってことですね?

と思ったけども,

1.times do
  eval "foo = 0"
  (proc{foo = 10}).call
  eval "p foo"
end
--
10

ですから, ブロックの実行時に決まっているのかな?

あ. でも,

proc {
  p = proc{}
  foo = 1
  eval "foo = 10", p
  p foo
}.call
--
1

なんですね. 実行中に{}が現れた時点での, コンテキストってことになるのか
な?

でも.

  proc {
    eval "bar = 0"
    (proc{p bar}).call
  }.call

は. NameErrorなんですね....

現象としては理解できたとしても, 何で完全に静的に解釈していない. つまり,

def zz
  eval "foo = 0"
  (proc {foo = 10}).call
  eval "p foo"
end

zz

と同じ結果にならないのか今1つなっとくがいきません.

>ここで「rubyの変数にネストはない」というルールが出て来ます．

があろうとなかろうと, 静的に解析してそこで変数を共有するかしないか決め
ても良いような気がするんですけど?

>evalが絡むとこのようなネストしたローカル変数が出て来るのでい
>やらしいですね．ひとつひとつのルールは合理的なようでも，全体
>の動作は良く分からなくなると．まるでperlのようだ．^^;;;

うーん. 最近, なんとなくはまっていますよね(^^;;;

>私としても，evalも絡んでどのようにあるべきかということについ
>て，決定的な見解を持っているわけではありませんので，提案など
>は大歓迎します．

というか良く分かってないのかも...

__
................................石塚 圭樹＠日本ラショナルソフトェア...
----------------------------------->> e-mail: keiju@rational.com <<---