Re: Primitive Boolean type?
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?
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?
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?
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?
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?)
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?
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?
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?
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
