From: Robert Klemme <bob.news@...>
Date: 2004-11-01T02:48:52+09:00
Subject: Re: New Ruby conditional semantics thoughts


I have some questions and remarks which you will find below.

"Brian Mitchell" <binary42@gmail.com> schrieb im Newsbeitrag 
news:fcfe4170041030145875869cd6@mail.gmail.com...
>    The basic background was begun by someone asking a question about
> boolean expressions and _why_ Ruby treats expression results nil and
> false as a *false* path in a boolean conditional. Some just explained
> that nil is like empty so it is nice to treat is like false.
>    Someone then pointed out how one could use the methods false? and
> true? on the object to test its value. This immediately reminded me of
> smalltalk conditional design and possible ways one could implement
> something similar in Ruby. For example, here are smalltalk
> conditionals implemented in Ruby:
>
> module Kernel
>  def _if(exp, &block)
>    else_block = callcc { |cont|
>      @condition = cont
>      return exp.true? &block
>    }
>    @condition = nil
>    exp.false? &else_block
>  end

Using instance variable @condition is likely to break in multithreaded 
applications.  Also, I don't understand why you use a continuation here. 
Why is that?

<snip/>

>    Now this is just for if and unless. case and other conditions
> could be made also but this is enough to give a basic idea (and save
> me time). I will explain why this is a good thing. As I explained how
> this whole thread started, there was a question as to why nil and
> false were treated as "boolean false". Here we use duck typing (which
> is right along side most ruby design) rather than just say that these
> values to this.

I'd say you use polymorphism instead of duck typing because you rely on 
different behavior of certain methods.  At least that's the important 
mechanism in this context IMHO.

> This also allows change in behavior and more false
> types to be added to ruby. This will help the with implementation of
> DSLs using ruby.

Hmm...  I'm not sure whether I understand this: where exactly does it help 
to have more "false" values when implementing DSL's?

> The implementation of conditionals as methods brings
> up another pro. conditions can be hooked, changed, and treated like
> any other ruby internal. This has been usually noted to be a good
> thing but a good use is hard to come up with... just as the argument
> goes with callcc ;) .

I'm not sure whether I like the idea to be able to mess with such a 
fundamental thing as boolean values.  Currently I can't see what we would 
gain.  OTOH, Ruby allows us to modify a lot internal behavior.

> The other good note is the use of blocks. While
> blocks now must be called (slower? I haven't bench marked yet),  the
> block can be passed around now or even come from a different binding.

Note that this might interfere with changed block semantics in R2 and could 
break compatibility more than you'd like.  Currently "if then" does not 
introduce a new scope, this is legal and prints "bar":

if true
  foo = "bar"
end
puts foo

<snip/>

> the adoption of blocks is
> a large jump and would probably require some syntax sugar to use
> regularly. It also break compatibility with current code. Which might
> not be as great of a thing.

Could even be a showstopper...

<snip/>

Currently I'm not convinced that we do indeed gain as much as to justify the 
cost of change.  Personally I'm completely happy with booleans as they are 
in Ruby today.  The syntactic differences aren't really that big, are they? 
And I'm really not certain whether we'll gain something by having the option 
to change interpretation of boolean truth values.  And *if* you need that, 
you can do it today:

class Object
  def to_b() self end
end

class SpecialBoolHandling
  def to_b ... end
end

if x.to_b
  ...
else
 ..
end

I believe I've read a comment of Matz about this (implicitely calling to_b 
or somethig similar) where he mentioned performance as the reason why not to 
do it, bI'm not 100% sure.

Nevertheless interesting thoughts.

Kind regards

    robert