Brian Mitchell
10/31/2004 8:04:00 PM
On Mon, 1 Nov 2004 02:48:52 +0900, Robert Klemme <bob.news@gmx.net> wrote:
>
> 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?
>
I am simple avoiding using method chaining. Note that I put this
together in a few minutes also ;) . And yes I do not plan continued
use of instance variables in this case. I will probably look at a
clean ruby only way and possibly a Ruby patch (for benchmarking).
> <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.
>
I say duck typing out of slight mistake (you are right there). I made
this word choice because that is how boolean *type* can be deduced.
Not Ruby *type*. Its just a matter of how you look at things.
> > 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?
>
If I were to implement a simulation program it is sometimes more
beneficial to say something domain specific. And as far as behavior
goes it falls right in. "false" itself means nothing but that. In DSLs
you purposely tailor everything possible to fit your application's
domain. Its not a huge deal but I think Ruby has become flexible
enough to do things like this (HTML builders are a good example -- see
the old entries on onestepback.org for how a loose syntax and flexible
keywords make document building very easy).
> > 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.
>
Its for peace of mind. Actually, its for control of more things and
making more things fundamental rather than just-another-feature. If
you examined Ruby as a set of axioms which the language was built off
of before and after this you would notice that the base mechanics of
the language have become simpler while retaining most (or more?)
capability. It may also have further ramifications in future things we
may want to change but needed something like this to get to that
change to work well. (If that made any sense)? I see that as we work
on this project pros and cons will become more apparent. We are on
step one or many. You are right though. If it were __just__ to change
behavior of booleans then it may not be worthy of an RCR at all.
> > 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...
>
Yes, but part of the idea is, IF we can present this as a positive
change even in the face of incompatibilities then it would be worthy
of an RCR. Ruby 2.0 will change a lot. The question is, "Is it worth
the break in functionality or do we even need the functionality?"
I am currently tyring to think of ways to get it to work w/o drawbacks
of 2.0 block semantics.
> <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.
>
I appreciate the feed back. Thanks and I will work on this either way.
It is a good educational experience.
Brian Mitchell.
---
"Just remember, it all started with a mouse."
-- Walt Disney