Primitive Boolean type?
Michael Lazzaro
While writing documentation: a trivial question on the boolean type,
C<bit>:
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
David Wheeler
> 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
da...@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: The...@jabber.org
Larry Wall
: 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.
That is correct. It probably throws an exception if you try to assign
an undefined value to a lowercase type. (Though an IEEE num might
well set itself to NaN instead.)
Larry
Larry Wall
: While writing documentation: a trivial question on the boolean type,
: C<bit>:
Please don't think of C<bit> 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
Michael Lazzaro
> Please don't think of C<bit> 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.
Er... dang. While I certainly agree with the concept in principle, I'm
having a hard time sticking to it when I'm writing beginner-level docs.
Suppose I'm declaring something like:
class Appliance {
has bit $.is_plugged_in;
has bit $.is_turned_on;
has bit $.has_ul_approval;
}
I'm declaring three attributes that are specifically always either true
or false. They can *only* be true/false, or yes/no, or 1/0 -- they have
no other possible values, and I want to declare them in such a way as to
clearly enforce that behavior. C<$.is_plugged_in> is never "5" or
"timmy" -- only true or false, period! By definition, my _intention_ is
therefore to declare these three attributes as containing "boolean" values.
The problem I'm having is that there are few good ways to describe the
above behavior without using the word "boolean". The word is
conspicuous in its absence; it's like someone trying to describe Daffy
Duck to you without using the word "duck". Perhaps boolean is spelled
bit (or type bool ::= bit), but the associated value is unambiguously
"boolean", which makes the attribute logically "boolean" in type.
Similarly I would assume that we want the capability to refer to boolean
context by name (just as we can refer to scalar, list (array?), numeric,
string, and other contexts) if for no other reason than to be able to
make declarations like:
sub foo (int $i; str $s; bool $y) { ... }
which, from appearances, seems to strongly _imply_ to the user that
there is indeed a 'bool' type, just as there is an 'int' type and a
'str' type. (They may be wrong, but that's intuitively what the above
signature _appears_ to say.)
So while I understand the philosophical/semantic reasons for the absence
of a true boolean type, I wonder how easy it will be to describe the
principle to newcomers, and if it's worth it. 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. :-)
Feedback? What am I missing?
MikeL
Luke Palmer
> Date: Thu, 31 Oct 2002 22:36:58 -0800
> From: Michael Lazzaro <mlaz...@cognitivity.com>
> X-Accept-Language: en,pdf
> Cc: perl6-l...@perl.org
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Larry Wall wrote:
> > Please don't think of C<bit> 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.
>
> Er... dang. While I certainly agree with the concept in principle, I'm
> having a hard time sticking to it when I'm writing beginner-level docs.
> Suppose I'm declaring something like:
>
> class Appliance {
>
> has bit $.is_plugged_in;
> has bit $.is_turned_on;
> has bit $.has_ul_approval;
> }
>
> I'm declaring three attributes that are specifically always either true
> or false. They can *only* be true/false, or yes/no, or 1/0 -- they have
> no other possible values, and I want to declare them in such a way as to
> clearly enforce that behavior. C<$.is_plugged_in> is never "5" or
> "timmy" -- only true or false, period! By definition, my _intention_ is
> therefore to declare these three attributes as containing "boolean" values.
I suppose, since anything can have the "true" or "false" properties,
you could roll your own boolean type like so:
class bool { }
Then
my bool $electricity;
Can contain nothing at all. But it can be true or false, since
"everything is a boolean." I like that idea. You would use it (a tad
awkwardly) as such:
$electricity but= true if $plug;
$electricity but= false if $short_circuit;
Luke
David Wheeler
> So while I understand the philosophical/semantic reasons for the
> absence of a true boolean type, I wonder how easy it will be to
> describe the principle to newcomers, and if it's worth it. 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. :-)
How do you answer that question when it's asked of Perl 5?
Mark J. Reed
> 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. :-)
BASIC, C, LISP, Perl5, Python, TCL . . .
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
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. :-)
> 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
David Wheeler
> 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;
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!
}
Regards,
David Whipp
> 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 C<true>" 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.
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
Austin Hastings
--- Michael Lazzaro <mlaz...@cognitivity.com> wrote:
>
> 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:
Umm, this just ain't so. 'C' uses the int type as its basic boolean.
You may be inclined to store the values in a char or a bitfield, but
(a==b) is an int.
> 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.
I don't recall the terminology, but I believe that "0 but true" is a
value with a "fillintheblank" (attribute?). What happens when you stick
"0 but true" into a bit?
> So what is the "official" way to efficiently store the result of a
> boolean expression, for example? If not as a "bit", then what?
The boolean-ness is a property of the evaluation of a value: if ($a)
....
If the $a value has a 'but false' or 'but true' then that wins. If the
$a value is a number, then 0 is false and everything else is true. If
the value is a string, then ..yada yada yada..
> If anything, I would suggest a primitive type, "bool", that has no
> promoted type "Bool". It can just be a placeholder -- a "bit" alias
Of course, a "bool" type would imply true/false values in the language.
And THAT, in turn, implies that it's possible to say:
$.is_plugged_in = true but false;
Maybe this should be an option only for female programmers? (Hoping my
GF isn't reading this... :-)
Frankly, I don't have a problem using a numeric value as a boolean. I'm
used to it. If there were a boolean primitive type, I probably wouldn't
use it correctly sometimes -- too much C/assembly work. But what's
wrong with defining Boolean as a subtype of bit?
On a vaguely-related note:
It's possible to say
$result = $value but true;
Is it possible to use a variable in that expression?
$result = $value but $bool;
If so, does it dwim? How do I use it?
$bool = "true"; ?
$bool = true; ?
$bool = (1 == 1); ?
=Austin
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Unknown
> I don't recall the terminology, but I believe that "0 but true" is a
> value with a "fillintheblank" (attribute?). What happens when you stick
> "0 but true" into a bit?
$z = 0 but true;
my bit $x = $z; # $x == 0
my bit $x = ?$z; # $x == 1
my bit $x = true $z; # $x == 1
I'm not even particularly upset by this:
my bool $x = $z; # $x == 1
But the moment anyone says
my bool $true = 1;
if x(1,2,3) == $true {...}
they're just asking for a world of hurt. I am overstating the case
when I say there's no boolean type in Perl. What I really mean is that
there is no such thing as a single true "true" value.
> > So what is the "official" way to efficiently store the result of a
> > boolean expression, for example? If not as a "bit", then what?
>
> The boolean-ness is a property of the evaluation of a value: if ($a)
> ....
>
> If the $a value has a 'but false' or 'but true' then that wins. If the
> $a value is a number, then 0 is false and everything else is true. If
> the value is a string, then ..yada yada yada..
>
> > If anything, I would suggest a primitive type, "bool", that has no
> > promoted type "Bool". It can just be a placeholder -- a "bit" alias
>
> Of course, a "bool" type would imply true/false values in the language.
> And THAT, in turn, implies that it's possible to say:
>
I don't mind a bool type. But you'll notice I've grabbed the keyword true()
to be a unary function. It will not default to "true". Perhaps it should
default to "undef". :-)
> $.is_plugged_in = true but false;
So that probably won't even parse.
Larry
Damian Conway
> I am overstating the case
> when I say there's no boolean type in Perl. What I really mean is that
> there is no such thing as a single true "true" value.
Curiously, junctions do get us quite close to the possibility of
canonical true and false values:
my $false is constant = any(0,"0","",undef);
my $true is constant = none(0,"0","",undef);
Unfortunately, both list context and the handy new C<but false>
property undermine those cunning scalar-value-based definitions.
> I don't mind a bool type. But you'll notice I've grabbed the keyword true()
> to be a unary function. It will not default to "true". Perhaps it should
> default to "undef". :-)
<grin>
Surely it won't be an issue, since we won't be able to call unary C<true>
or C<false> without an argument and that argument will always be either
true or false (or some junction thereof).
>>$.is_plugged_in = true but false;
>
> So that probably won't even parse.
Thank goodness!
Of course, this *will* parse:
$perplexing = false "true" but false;
>;-)
Damian
Michael Lazzaro
Larry wrote:
> $z = 0 but true;
> 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
Smylers
> 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
Luke Palmer
> From: Smylers <Smy...@stripey.com>
> X-Posted-By: 193.237.84.140
>
> 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.'; }
Perl has a much finer solution. So, it's possible to express "if
three is equal to two plus one," obviously:
if 3 == 2 + 1 {...}
But few languages can express "if it is true that three is equal to
two plus one" (though the statements are, in fact, equivalent).
However, Perl can:
if (3 == 2 + 1) ~~ true {...}
Even more support for making C<true> a unary function. It's almost
possible to transliterate via markup English logic statements into
Perl:
"if 'two plus two equals three' is not true..."
if (2 + 2 == 3) ~~ {not true} {...}
How's that for self-documentation? :)
(I wrote this to remind people that Perl 6 is still beautiful, in
spite of the line-noise that has been so frequent recently.)
Luke