parent of TrueClass, FalseClass

[Ara.T.Howard]

any good reason these would not have a common parent Bool or something?

case arg
when Bool
...
end

options = {
:mosaic => ['--mosaic=[mosaic]','-m', Bool],
...
}


-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
| URL :: http://www.ngdc.noaa.gov/stp/
| TRY :: for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done
===============================================================================

 

[Ryan Pavlik]

any good reason these would not have a common parent Bool or something?

case arg
when Bool
...
end

Here's the solution I use:

module Boolean; end

class TrueClass; include Boolean; end
class FalseClass; include Boolean; end

hth,

 

[Robert Klemme]

any good reason these would not have a common parent Bool or something?

case arg
when Bool
...
end

options = {
:mosaic => ['--mosaic=[mosaic]','-m', Bool],
...
}

I guess it's only of limited usage since any value can be used as boolean
value.

Your case can easily be covered by

case arg
when TrueClass, FalseClass
end

or maybe even

case arg
when true, false
end

robert

 

[Yukihiro Matsumoto]

Hi,

In message "parent of TrueClass, FalseClass"

|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.

 

[Jean-Hugues ROBERT]

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

In message "parent of TrueClass, FalseClass"
|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

 

[Mauricio Fernández]

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.

If you have a real constraint propagation engine, the hint is unneeded.
I'm not sure it makes sense to add something w/ potential for abuse and
which doesn't seem to solve any problem now, for the sake of a future
optimization that could be done differently anyway.

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.

Yes, type inference and partial evaluation are cool; isn't it a pity
that we have yet to start working on the the stuff lisp (or more
recently self) implementors solved so long ago? :-|

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Yes I have a Machintosh, please don't scream at me.
-- Larry Blumette on linux-kernel

 

[Ara.T.Howard]

Hi,

In message "parent of TrueClass, FalseClass"

|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.

well - no, except that i'm sure alot of code would break if we pulled out
TrueClass and FalseClass. i guess you surely could have something like

class Bool
TRUE = new
FALSE = new
...
end

if done from the start this would make some sort of sense. i just find it a
bit suprising that true and false, which are both representations values of
truth, are not related in anyway (duck type, module inclusion, parent class,
etc) and it is difficult (verbose) in ruby code to ask

"is this a truth value"

i realize ruby is moving more towards duck typing. but considering that - how
to you duck type a truth value? i mean, which method must something
respond_to? in order to be a bool? could it be useful if there was one?

class Foo
include Truth

def initialize arg
@bar = true if arg == 42
end

def truth # all logical operations derived from this
true unless @bar
end
end

xor = Foo.new(0) ^ Foo.new(42)


-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
| URL :: http://www.ngdc.noaa.gov/stp/
| TRY :: for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done
===============================================================================

 

[Mauricio Fernández]

i realize ruby is moving more towards duck typing. but considering that - how
to you duck type a truth value? i mean, which method must something
respond_to? in order to be a bool? could it be useful if there was one?

Object#to_bool has been suggested quite often

see
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/12094

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Computers are like air conditioners. Both stop working, if you open windows.
-- Adam Heath

 

[Simon Strandgaard]

well - no, except that i'm sure alot of code would break if we pulled out
TrueClass and FalseClass. i guess you surely could have something like

class Bool
TRUE = new
FALSE = new
...
end

if done from the start this would make some sort of sense. i just find it a
bit suprising that true and false, which are both representations values of
truth, are not related in anyway (duck type, module inclusion, parent class,
etc) and it is difficult (verbose) in ruby code to ask

"is this a truth value"

i realize ruby is moving more towards duck typing. but considering that - how
to you duck type a truth value? i mean, which method must something
respond_to? in order to be a bool? could it be useful if there was one?

class Foo
include Truth

def initialize arg
@bar = true if arg == 42
end

def truth # all logical operations derived from this
true unless @bar
end
end

xor = Foo.new(0) ^ Foo.new(42)

How about (untested)

Then it would be easy to add a Maybe class ;-)

server> cat a.rb
module Boolean
class Base
include Singleton
end
class True < Base
def to_s; "true" end
end
class False < Base
def to_s; "false" end
end
end # module Boolean

TRUE = Boolean::True.instance
FALSE = Boolean::False.instance
server>

 

[Ara.T.Howard]

How about (untested)

Then it would be easy to add a Maybe class ;-)

server> cat a.rb
module Boolean
class Base
include Singleton
end
class True < Base
def to_s; "true" end
end
class False < Base
def to_s; "false" end
end
end # module Boolean

TRUE = Boolean::True.instance
FALSE = Boolean::False.instance
server>

the "don't care" (maybe) value is a valid value in boolean logic - it could
actually be useful...

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
| URL :: http://www.ngdc.noaa.gov/stp/
| TRY :: for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done
===============================================================================