Parent of TrueClass, FalseClass

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 :: Solar-Terrestrial Physics Data | NCEI
TRY :: for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done
===============================================================================

Here’s the solution I use:

module Boolean; end

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

hth,

···

On Fri, 2 Apr 2004 03:14:26 +0900 “Ara.T.Howard” Ara.T.Howard@noaa.gov wrote:

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

case arg
when Bool

end


Ryan Pavlik rpav@mephle.com

“I’m a mere Feather Fall spell away from safety.” - 8BT

“Ara.T.Howard” Ara.T.Howard@noaa.gov schrieb im Newsbeitrag
news:Pine.LNX.4.44.0404011006090.28079-100000@fattire.ngdc.noaa.gov

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

Hi,

···

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.

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

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

···

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:


Web: @jhr is virteal, virtually real
Phone: +33 (0) 4 92 27 74 17

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

···

On Fri, 2 Apr 2004, Yukihiro Matsumoto wrote:

Hi,

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.

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
URL :: Solar-Terrestrial Physics Data | NCEI
TRY :: for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done
===============================================================================

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? :expressionless:

···

On Fri, Apr 02, 2004 at 04:46:40PM +0900, Jean-Hugues ROBERT wrote:


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

Object#to_bool has been suggested quite often

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

···

On Sat, Apr 03, 2004 at 12:34:20AM +0900, Ara.T.Howard wrote:

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?


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

Hi,

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)

How about (untested)

Then it would be easy to add a Maybe class :wink:

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

···

On Fri, 02 Apr 2004 09:24:45 -0700, Ara.T.Howard wrote:

On Fri, 2 Apr 2004, Yukihiro Matsumoto wrote:

In message “parent of TrueClass, FalseClass” >> on 04/04/02, “Ara.T.Howard” Ara.T.Howard@noaa.gov writes:


Simon Strandgaard

How about this?

class Object
def is_truth_value?
true
end
end

In other words, every object is a truth value. Every object can go inside an ‘if’ statement, for example. Boolean operators will work on any ruby object, like `x && y’, and can evaluate to any ruby object. In fact, I find myself wishing that some methods which return true or false would return more broad ranges of truth values. For example, I’d love to see this:

if (4 <= x == y > z)

end

Chris

···

On Sat, 3 Apr 2004 00:34:20 +0900, Ara.T.Howard wrote:

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”

the “don’t care” (maybe) value is a valid value in boolean logic - it could
actually be useful…

-a

···

On Fri, 2 Apr 2004, Simon Strandgaard wrote:

How about (untested)

Then it would be easy to add a Maybe class :wink:

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

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
URL :: Solar-Terrestrial Physics Data | NCEI
TRY :: for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done
===============================================================================

Hi

RITE is a stack based VM like JVM or Register based like Parrot?

regards,
rolo

Well, this is true of integers as well, but surely you aren’t suggesting that we have some “value” of the Integer class which means “this is an integer, but we don’t care which one”. That’s not a “value”, it’s an unknown, a variable.

Clearly there are only two values in boolean logic, but there can be many variables, some of which we might not care about. However, you can easily have complex interactions between them, for example x and y are boolean variables (so them must be T or F, but maybe we don’t care which), however, we require that x and y be equal, but different from some other variable z…

Ruby doesn’t do symbolic computation. One could extend Symbol, I suppose…

:slight_smile:

Chris

···

On Sat, 3 Apr 2004 04:39:25 +0900, Ara.T.Howard wrote:

the “don’t care” (maybe) value is a valid value in boolean logic -
it could actually be useful…

Hi,

···

In message “is RITE stack based or register based VM?” on 04/04/05, “rolo” rohitlodha@hotwireindia.com writes:

RITE is a stack based VM like JVM or Register based like Parrot?

Stack based, as I believe.

						matz.

Hi,

RITE is a stack based VM like JVM or Register based like Parrot?

Stack based, as I believe.

Do you mean ‘I believe RITE is stack based’ or ‘RITE is stack based, as
it is the technology I believe in’?

···

Le 4 avr. 04, à 20:00, Yukihiro Matsumoto a écrit :

In message “is RITE stack based or register based VM?” > on 04/04/05, “rolo” rohitlodha@hotwireindia.com writes:

  					matz.

Hi,

Skip this msg unless theory about interpreters implementations matters to you.

Stack based… to what extend (speculations about RITE) ?

Two things:

  1. I guess we are not talking of the micro-processor’s stack (SP) here.
    Stack “less” interpreters are considered easier/better approach.
    See stackless Python. Anyway, Continuations make it tricky to use the
    processor’s stack. You need a SpaghettiStack.

  2. Regarding the “expression evaluation stack”. That is a different matter.
    Probably the one involved when talking about “stack based vs register
    based”.

    For this case, I may point out that sometimes the compiler can get some
    knowledge about “how deep” that stack most probably needs to be (I
    suppose it
    can never actually know the max depth, due to
    Continuation/Blocks/eval()).

    However, for the cases where the compiler knows about the stack depth,
    it is faster to perform absolute addressing instead of relative
    addressing
    with some SP (you avoid the ++SP/–SP house keeping, among others).

Example 1: Stack based imaginary VM. c = a + b
push b # Alloc stack slot, link to previous, put b’s value in it
push a # Alloc stack slot, link to previous, put a’s value in it
meth +, 2 # Invoke method, dealloc 1 stack slot
pop c # Mov top-of-stack to c, dealloc 1 stack slot.

Example 2: Precomputed stack accesses
stack 2 # Alloc stack slots, done once when
ActivationRecord is created.
mov b, 0 # put b’s value in first slot
mov a, 1 # put a’s value in second slot
meth +, 0, 2 # Invoke method, args in first & second slots
mov 0, c # Mov first slot’s value to c

Benefit:
- Speed ! One allocation only
Drawback:
- Compiler must compute @stackDepth of each method definition.
- Efficient allocation of stacks requires some pool management for
most frequent stack sizes.

Considering that Rite’s main purpose is speed, stack management probably
deserve to be as efficient as possible.

I don’t know wether the result should be called stack based or register
based, because there still is a variable depth stack yet you most of the
time use it as an array of registers.

Yours,

Jean-Hugues Robert

See also:
http://www.c2.com/cgi/wiki?ActivationRecord
http://www.c2.com/cgi/wiki?StacklessPython
http://www.c2.com/cgi/wiki?ContinuationExplanation
http://www.c2.com/cgi/wiki?SpaghettiStack

···

At 09:00 05/04/2004 +0900, you wrote:

Hi,

In message “is RITE stack based or register based VM?” > on 04/04/05, “rolo” rohitlodha@hotwireindia.com writes:

RITE is a stack based VM like JVM or Register based like Parrot?

Stack based, as I believe.

                                                    matz.

E is a stack based VM like JVM or Register based like Parrot?

Stack based, as I believe.

                                                    matz.

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

Hi,

···

In message “Re: is RITE stack based or register based VM?” on 04/04/05, Guillaume Marcais guslist@free.fr writes:

Stack based, as I believe.

Do you mean ‘I believe RITE is stack based’ or ‘RITE is stack based, as
it is the technology I believe in’?

Hmm, ambiguity in the English language is interesting. I meant the
former, but I’d say “both”.

						matz.

For this case, I may point out that sometimes the compiler can get some
knowledge about “how deep” that stack most probably needs to be (I
suppose it
can never actually know the max depth, due to
Continuation/Blocks/eval()).

[rolo] Do you mean that based on the information that max depth is unknown, a stack based RITE would not be as efficient as it can be using registers?

Hi,

  For this case, I may point out that sometimes the compiler can get some
  knowledge about "how deep" that stack most probably needs to be (I

suppose it
can never actually know the max depth, due to
Continuation/Blocks/eval()).

[rolo] Do you mean that based on the information that max depth is
unknown, a stack based RITE would not be as efficient as it can be using
registers?

I don’t know about that. What I do know is that when the
evaluation stack max depth can be determined by the compiler,
it is more efficient to allocate that stack once (per ActivationRecord)
and use the stack as an array with absolute indexes, instead of
computing some SP at runtime.
I would have to investigate more about what “register” means in modern
interpretor, because the understanding I have is based on some work
done by C compilers twenty years ago :wink: I may do that to see if the
optimization I did implement in an interpretor a while ago is related
in anyway to “registers”, even thought at this point I think it is
not and is more like an optimized stack based scheme.

When the stack size cannot be pre-determined, I guess that the only
solution is to allocate more chunks of stack slots as needed (kind
of catching stack-overflow as is done by some OS). The only optimization
I can think of here is to allocate bigger chuncks versus one slot at
the time.

Yours,

Jean-Hugues

···

At 02:48 06/04/2004 +0900, you wrote:


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