From: ichimal@...
Date: 2003-02-05T18:37:20+09:00
Subject: Re: Local variables & blocks

Hi,

In message "Re: Local variables & blocks"
    on 03/02/04, matz writes:

>Hmm, this is interesting issue.  If you're OK, shall we discuss at the
><ruby-list@ruby-lang.org> list in Japanese?

  I'm Okay.

>|>What's wrong with that?
>|
>|  Is it meaning that Scheme is just Scheme, Ruby is just Ruby?
>
>Maybe.  Scheme is not an excuse for me.  I'm interested in whether
>there's any other reason to "separate false and nil".

  I think, nil in Ruby is representative value of "{unavailable|invalid|
no effect} in this context" rather than "not initialized".

  I think, following representation is valid:
    a variable points to nil.

  But following representation is not good:
    a variable points to non-initialized value.
It should be: a variable is not initialized. 
  
# But, we can initialize a variable with non-initialized value
# explicitlly by tricky way s.t. (set! x (if #f #f)) in scm, and it
# should not be forbidden. It's programmer's responsibility.
## Note for reader who don't know scm:
## (set! x (if #f #f)) => #<unspecified>,
## (set! x #<unspecified>) => error.
## It may be great policy. This is why I said "tricky way".

  Then, the semantics "nil is also false" restricts the meaning of
{unavailable|invalid|no effect}. It's default value of the default
value for {unavailable|invalid|no effect} but the default^2 shuold
belong to programmer, not to PL, I think.

  e.g.
  def questionnaire
    print_somewhat_Q
    str = gets
    parse_answer(str) if str
  end

  This method should return nil as "non-effective answer" or somewhat
effective answer including boolean. When a programmer sets the default
answer to false, the programmer may save an extra test because "nil is
also false" :-P



Thanks.

---- 
1002.(ichimal)
SUZUKI Shingo.