Re: Primitive Boolean type?

2002-11-03 Thread Michael Lazzaro

Larry wrote:
 $z = 0 but true;
 I'm not even particularly upset by this:
 my bool $x = $z;# $x == 1

Yep, that's all I mean.  I just want things like:

 my bool $lit = ($light eq on);
 if $lit { ... }

to work such that (1) 'bool' always stores the truth of the
expression, _never_ the value of the expression, and (2) it does so in
whatever Perl decides is the most compact possible way.

It can resolve to 1 or 0 numeric, 1 or 0 string, so we don't need
true and false words at all.  They're not even terribly useful in
this context.

 But the moment anyone says
 my bool $true = 1;
 if x(1,2,3) == $true {...}
 they're just asking for a world of hurt.

Agreed: the value of comparing a boolean with anything else is not
particularly sensible in *any* language.  Anyone who does it deserves
what they get.  ;-)

MikeL



Re: Primitive Boolean type?

2002-11-03 Thread Smylers
Michael Lazzaro wrote:

 Agreed: the value of comparing a boolean with anything else is not
 particularly sensible in *any* language.

It isn't particularly unsensible in PHP.

PHP only has one equality operator.  If its operands are of different
types then it casts one operand to match the other, choosing these types
in order of preference:

  bool
  int
  float
  string

That means that comparing a bool with something else first casts the
something else to a bool, so the comparison works:

  $int = 3;
  if ($int == true) { echo 'This gets printed.'; }

However I am certainly _not_ suggesting this should be done in Perl.

In particular the automatic casting of strings to integers can get
'awkward':

  $x = 'cat'
  $y = 0;
  if ($x == 'cat') { echo 'This gets printed.'; }
  if ($y == 'cat') { echo 'So does this!'; }

The 'solution' offered by PHP is the equivalence operator, which only
returns true if its operands have the same type and same value:

  if ($y === 'cat') { echo This doesn't print.; }

However that then breaks other things:

  $a = '2';  # strings, because have been read from a user
  $b = '3';
  $total = '5';

  if ($a + $b === $total) { echo But this doesn't print either.; }

 Anyone who does it deserves what they get.  ;-)

Exactly.

Smylers



Re: Primitive Boolean type?

2002-11-01 Thread Michael Lazzaro

On Friday, November 1, 2002, at 08:02  AM, Mark J. Reed wrote:

When someone asks what's the boolean type in Perl? I'd rather 
answer bit than Perl doesn't have one, if for no other reason 
than the latter answer will completely freak them out.  :-)
Why?  Plenty of languages get along just fine without a Boolean type.
BASIC, C, LISP, Perl5, Python, TCL . . .


In langs that do not recognize boolean as a type, the convention is 
either to use an untyped thing or the littlest possible thing as a 
boolean type.  (The latter has more possibilities for efficiency, 
obviously.)  Let's look at a presumably common Perl6 construct:

If boolean is not a type, smart people are going to use the smallest 
possible thing, e.g. bit, to declare boolean true/false vars and 
attributes.

has bit $.is_plugged_in;

They're going to do it whether we want them to or not (at least, I know 
I would), because they want to store a true/false value, and they want 
it to be enforced, and they want it to be small.  So the above is the 
closest to DWIM that we have in Perl6 if you want to store a boolean 
value in a very compact form, correct?  If not, how better would we say 
it?

Since a bit can't even have properties (tho a Bit can), it really 
is, for all practical purposes, a boolean value, and can be treated as 
such.  Fine and dandy, that's OK.

But is that WYM?  No.  We've declared that a bit is _not_ a boolean, 
so the above is just a hack.  It's not WYM it all, it just happens to 
do the right thing for all possible cases.  And for proof that it's 
wrong, we have Bit.  Bit can be 1 but false, or 0 but true, 
etc.  Bit is therefore much more clearly not a boolean: it's a 1 or 
0, not a true or false.  The usage of bit as a boolean breaks down if 
you think of it as the primitive of Bit.  It's not WYM anymore.

So what is the official way to efficiently store the result of a 
boolean expression, for example?  If not as a bit, then what?

If anything, I would suggest a primitive type, bool, that has no 
promoted type Bool.  It can just be a placeholder -- a bit alias -- 
but I still don't understand the compelling reason for saying:

has bit $.is_plugged_in;

when WYM is, unambiguously:

has boolean $.is_plugged_in;

It's an excruciatingly common case, and yet we're making it into 
something that takes more than one sentence to explain.  We're ignoring 
the feathers and the quacking: is this a case of being Too Smart For 
Our Own Good, here?

MikeL



RE: Primitive Boolean type?

2002-11-01 Thread David Whipp
David Wheeler [mailto:david;wheeler.net] wrote:

 The problem with this is that you have explicitly introduced true and 
 false into the language, and have therefore destroyed the utility of 
 context:
 
my boolean $bool = 0; # False.
my $foo = ''; # False context.
if ($foo eq $bool) {
# Oops!
}

If I am not mistaken, we already have explicitly introduced
true and false into the language:

  my $bar = 0 but true;
  my $bas = 0 but false;

A boolean type is therefore not quite as big a stretch as
you imply.

But we still have to deal with the expression issue:

  if ($bar eq $bas) {} # true
  if (?$bar eq ?$bas) {} # false

  my $bool = true;
  if ($bool eq $bar) {} # ???

Presumably, there exist rules for implicit casting when
comparing objects of different types. If we have a rule
that says that if either operand is a boolean, then both
are compared as booleans, then things would work just
fine (except the the things I haven't considered ;-)).

The question of what is Ctrue is really an implementation
issue. It could be a superposition of all true values; or it
could just be a predefined value, that has some special magic
associated with it. Perhaps its just a keyword, whose context
determines whether it is a value, or a property.


Dave.



Re: Primitive Boolean type?

2002-11-01 Thread Michael Lazzaro

On Friday, November 1, 2002, at 01:38  PM, David Whipp wrote:

Presumably, there exist rules for implicit casting when
comparing objects of different types. If we have a rule


My initial assumption is that nothing would change.  Namely, == 
compares numerically, eq compares strings, and '?' enforces 
booleanness.  In numeric context, bool evaluates to 1 or 0; in string 
context, 1 or 0:

	my bool $t = 1;

	($t ==  1)  true
	($t ==  5)  false
	($t == ?5)  true

 ($t eq  '') false
 ($t eq '0') false
 ($t eq '1') true
 ($t eq  'foo')  false
 ($t eq ?'foo')  true

 which is the exact equiv of bit behavior, I believe.  It's just a 
more descriptive name for a common usage.

But here's where things get more interesting.  If say $t is a numeric 
bit, not a true boolean:

 ($t ==  (0 but true ))   (1 != 0, so false) ***
 ($t ==  (1 but false))   (1 == 1, so true ) ***
 ($t == ?(0 but true ))   (1 == 1, so true )
 ($t == ?(1 but false))   (1 != 0, so false)

Which may or may not be surprising.  But if you say you can store true 
booleans as a bool type, and '==' knows how to deal with them:

 ($t ==  (0 but true ))   (true == true,  so true ) ***
 ($t ==  (1 but false))   (true != false, so false) ***
 ($t == ?(0 but true ))   (true == true,  so true )
 ($t == ?(1 but false))   (true != false, so false)

Whether that is an argument for or against a non-numeric 'bool' type 
depends on your point of view.  In any event, if I want to store the 
result of a boolean expression:

	my $lit = ($lights == on);

What type do I declare $lit as, in order for it to do what I mean?

MikeL



Re: eq Vs == Vs ~~ ( was Re: Primitive Boolean type?)

2002-11-01 Thread Sean O'Rourke
See

http://archive.develooper.com/perl6-internals;perl.org/msg11308.html

for a closely-related discussion.

/s

On Fri, 1 Nov 2002, David Whipp wrote:
 In Perl6, everything is an object. So almost everything is
 neither a number nor a string. It probably doesn't make sense
 to cast things to strings/ints, just to compare them. We
 probably want a standard method: .equals(), that does a
 class-specific comparison.

 The question is, will we be modifying the definnitions of ==
 and eq, so that one will call the .equals method explicity. And
 what does the other do? Do we want to define them in terms of
 identity vs equality? Then, is identity a class-specific thing
 (i.e. a .identical() method); or is it an address-in-memory
 kind of thing?

 Did I miss a previous discussion of this?


 Dave.





Primitive Boolean type?

2002-10-31 Thread Michael Lazzaro

While writing documentation: a trivial question on the boolean type, 
Cbit:

my bit $light_switch;

Q: Can bits/bools be undefined?

Perl conventions would indicate yes.  Does that mean that an array of 
bits:

   my bit bitfield;

takes up, at minimum, two bits per, um, bit?

Sorry if this question is as stupid as it looks.  I'm just worried that 
maybe it isn't.

MikeL



Re: Primitive Boolean type?

2002-10-31 Thread David Wheeler
On Thursday, October 31, 2002, at 02:43  PM, Michael Lazzaro wrote:


Q: Can bits/bools be undefined?

Perl conventions would indicate yes.


IIRC, native data types, which are all lowercase (e.g., int, bit, long, 
etc.) cannot be undef. However, their class equivalents (e.g., Int, 
Bit, Long, etc) can be undef.

HTH,

David

--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]



Re: Primitive Boolean type?

2002-10-31 Thread Larry Wall
On Thu, 31 Oct 2002, Michael Lazzaro wrote:
: While writing documentation: a trivial question on the boolean type, 
: Cbit:

Please don't think of Cbit as a boolean type.  There is no boolean
type in Perl, only a boolean context.  Or looking at it from the
other direction, *every* type is a boolean type.

: Does that mean that an array of bits:
: 
: my bit bitfield;
: 
: takes up, at minimum, two bits per, um, bit?

Just one per.

Larry