Boolean literals

[Autrijus Tang]

Just a quick question. The prettyprinter of Pugs (the thing that
handles the ".perl" method) currently prints out boolean true and
false as #t and #f, which is obviously not correct.

pugs> (1 > 2, 2 > 1)
(#f, #t)

What should I do, though? Inventing two primitives, "true" and
"false"? Or is there a way to annotate values with types, similar
to Haskell's "::" construct?

pugs> (1 > 2, 2 > 1)
(0 as Bool, 1 as Bool)

Thanks,
/Autrijus/

[Larry Wall]

On Wed, Feb 16, 2005 at 02:29:36PM +0800, Autrijus Tang wrote:
: Just a quick question. The prettyprinter of Pugs (the thing that

The latest S12 has it as bool::true and bool::false. (In general,
you can print out any enum as "role::identifier".) When unambiguous,
bare "true" and "false" can be used, but in any event the use of
symbolic booleans is somewhat discouraged in Perl because it leads
people to write stupidities like

while foo() == true {...}

Instead, we try to make sure all types know how to behave in boolean
context directly. Any object that does the "bool" role has an
attribute of type "bit", which will return 0 if the object is false,
and 1 if the object is true. (The optimizer is free to optimize away
the method call if it can, of course. Native integers and floats
are always true if non-zero, for instance. But object types can always
be derived from, or have "but true" mixed into them.)

Larry

[Markus Laire]

We already have +^ ~^ ?^ +| ~| ?| etc..

Why not allow data-type prefix for the comparison operators also, so
we'd get, to mention a few, ~== (same as 'eq') ~< (same as 'lt') ~<=
(same as 'le') - and of course boolean versions ?== and ?!= (The others
really don't have use with just 2 possible values.)

Then a programmer could write

while foo() ?== true {...}

and it would be ok. After all, perl is all about giving more than one
way to do it.

--
Markus Laire
<Jam. 1:5-6>

[Juerd]

Markus Laire skribis 2005-02-16 13:32 (+0200):

> We already have +^ ~^ ?^ +| ~| ?| etc..

We have unary lc, int, etc...

> Why not allow data-type prefix for the comparison operators also, so
> we'd get, to mention a few, ~== (same as 'eq') ~< (same as 'lt') ~<=
> (same as 'le') - and of course boolean versions ?== and ?!= (The others
> really don't have use with just 2 possible values.)

Why not allow lc~== (case insensitive string comparison) and int!=
(integer values differ)? What about $foo length== $bar? :)

> Then a programmer could write
> while foo() ?== true {...}

if $foo lc~== $bar { ... }

> and it would be ok. After all, perl is all about giving more than one
> way to do it.

Yes, but I fear that if we turn every unary op into a metaop, things
very quickly become very ugly. A little redundancy isn't a problem here,
I think.

if ?$foo == ?$bar { ... }
if lc $foo eq lc $bar { ... }

Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

[Patrick R. Michaud]

On Tue, Feb 15, 2005 at 11:03:09PM -0800, Larry Wall wrote:
> On Wed, Feb 16, 2005 at 02:29:36PM +0800, Autrijus Tang wrote:
> : Just a quick question. The prettyprinter of Pugs (the thing that
> : handles the ".perl" method) currently prints out boolean true and
> : false as #t and #f, which is obviously not correct.
> :
> : pugs> (1 > 2, 2 > 1)
> : (#f, #t)
> :
> : What should I do, though? Inventing two primitives, "true" and
> : "false"? Or is there a way to annotate values with types, similar
> : to Haskell's "::" construct?
> :
> : pugs> (1 > 2, 2 > 1)
> : (0 as Bool, 1 as Bool)
>
> The latest S12 has it as bool::true and bool::false.

S03 still indicates that boolean operators return "a standard
boolean value (either 1 or 0)". Are we continuing with 1 and 0
as the standard boolean values, or bool::true and bool::false?

More to the point, what's the return type of something like
&infix:«>» ?

Pm

[Larry Wall]

On Wed, Feb 16, 2005 at 11:02:25PM -0600, Patrick R. Michaud wrote:

Yes. :-)

True boolean values are bits. bool::true and bool::false are just
convenient names for certain values of small, 1-bit integers.

: More to the point, what's the return type of something like
: &infix:�>� ?

Type "bit", which is just a rather small subtype of int. The bit type
is really an alias for "uint1". If you're asking what it actually
returns internally, it's perfectly fine to store a tiny integer subtype
into a normal int.

So to stop evading your question, it returns 0 or 1. :-)

But I buy into the whole subtype/type distinction that Ada made.
A compiler is always free to store a subtype value in a type location.
You can keep a uint4 in an int. It's only when you assign an int value
into a uint4 location that you have to worry about the subtype constraints.
(And the compiler is free to optimize the subtype storage based on
the constraint, so an array of bits really can be stored compactly.)

But boolean context in Perl 6 doesn't enforce that it gets a uint1
subtype. It only enforces that it requires a type that knows how to
play the boolean role, either because it has the .bit method, or because
it's some low-level type we've hardwired to bypass the .bit method for
speed.

Larry

[Matt Diephouse]

On Wed, 16 Feb 2005 23:02:25 -0600, Patrick R. Michaud
<pmic...@pobox.com> wrote:
> > The latest S12 has it as bool::true and bool::false.
>
> S03 still indicates that boolean operators return "a standard
> boolean value (either 1 or 0)". Are we continuing with 1 and 0
> as the standard boolean values, or bool::true and bool::false?

I believe bool::true and bool::false are enums (so they are 1 and 0,
respectively).

--
matt diephouse
http://matt.diephouse.com