From: Jean-Hugues ROBERT <jean_hugues_robert@...>
Date: 2004-04-02T16:46:40+09:00
Subject: Re: parent of TrueClass, FalseClass

Skip this msg unless you enjoy prospective/theoretical thinking about the
future of interpreted/scripting languages.

At 09:02 02/04/2004 +0900, you wrote:
>In message "parent of TrueClass, FalseClass"
>     on 04/04/02, "Ara.T.Howard" <Ara.T.Howard@noaa.gov> writes:
>|any good reason these would not have a common parent Bool or something?
>
>Is there any good reason to have a common parent Bool, where true and
>false are only representations values of truth.
>                                                         matz.

I can't think of a good reason *now*. I do think of a good reason *tomorrow*.

In some remote future, one may hope ruby speed could be improved thanks
to user providing "hints" about parameters/returned-value types.
"hints" like #pragma register in C (with a better syntax of course).

Thanks to knowledge about types, a ruby compiler could optimize generated
code for speed. With some additional type inferencing, we would get
kind of a C++ templating system, but with a very different spirit and
syntax: compiler "infers" the applicable templates, instead of user
explicitly defining them. JIT compilers could infer at run time.

When that day comes, if ever, if would be necessary to provide hints
about parameters that are boolean value objects.

Example:
flag = xxxx?
large_collection.each do
   if flag then
     some_thing
   else
     some_thing_else
   end
end
Here compiler cannot assume that flag will always be a boolean, it
could be anything, like nil for example (that ? methods return a
boolean is a convention in ruby, not a mandatory behavior). As
a result code generated for "if flag" must check both false and
nil.

Example (with user provided "hint" about flag's type):
hint
   Bool flag = xxxx # Tell the compiler that flag should always be a Bool
end
large_collection.each do
   if flag then
     some_thing
   else
     some_thing_else
   end
end
Here, an optimizer can generate faster code, it knows that flag
will always be either true or false. Code for "if flag" needs to
check for false only, not nil.

Example (with type inferencing)
def xxx?()
   hint
     Bool xxx # Tell the compiler that returned value is always a bool
   end
   some_other_thing
end
Here, an optimizer can generate faster code, where ever xxx? is
called, because it knows that the result will always be a Bool.

I believe that user provided "hints" and "type inferencing" is a way
for scripting languages to become general purpose languages that
can match the speed of statically typed languages.

Kind of "constraintable dynamic typing". A way to end
the "static typing" versus "dynamic typing" war and get the
benefits of both.

Yours,

Jean-Hugues Robert


-------------------------------------------------------------------------
Web:  http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17