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: UTF-8 and Unicode FAQ, demos
Matthew Zimmerman wrote in perl.perl6.language : > > So let me make my original question a little more general: are Perl 6 source > files encoded in Latin-1, UTF-8, or will Perl 6 provide some sort of > translation mechanism, like specifying the charset on the command line? I expect probably something similar to Perl 5's encoding pragma. (But hopefully lexically scoped.)
Re: labeled if blocks
On Mon, 2002-10-28 at 14:41, Larry Wall wrote: > And maybe: > > A bitwise operator is just a logic operator scoped to a set of bits. Hypo-operators. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Flexops as information preserving Bitops
Damian Conway <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > >> So, on the train this morning, I had a moment of Satori. What's wrong >> with doing what we think of as bitwise operations using the flexops >> and adding a 'bitwise' context? So, a bitwise op becomes: >>bitwise ( $a | $b | $c & $d ); >> And the superposition will collapse in a 'mash everything together in >> bitop fashion' way. > > Yes. This was more-or-less the solution I proposed last week in > http://archive.develooper.com/perl6-language%40perl.org/msg11835.html D'oh! And I read that too. Must have wormed its way into my subconscious 'til I thought it was original with me. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
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?
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: 3 Nov 2002 14:58:52 -
> From: Smylers <[EMAIL PROTECTED]>
> 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 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
Unicode Checker
For all you Mac OS X fans out there: http://www.earthlingsoft.net/UnicodeChecker/ Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Unifying invocant and topic naming syntax
I read Allison's topicalization piece:
http://www.perl.com/pub/a/2002/10/30/topic.html
I started with a simple thought:
is given($foo)
seems to jar with
given $foo { ... }
One pulls in the topic from outside and
calls it $foo, the other does the reverse --
it pulls in $foo from the outside and makes
it the topic.
On its own this was no big deal, but it got
me thinking.
The key thing I realized was that (naming)
the invocant of a method involves something
very like (naming) the topic of a method,
and ultimately a sub and other constructs.
Thus it seems that whatever syntax you pick
for the former is likely to work well for
the latter.
Afaik, the syntax for invocant naming is:
method f ($self : $a, $b) { ... }
But whatever it is, I think one can build
on it for topic transfer / naming too in a
wide range of contexts.
With apologies for talking about Larry's
colon, something that really does sound
like it is taboo for good reason, I'll
assume the above invocant naming syntax
for the rest of this email.
So, perhaps:
sub f ($a, $b) is given($c) { ... }
sub f ($a, $b) is given($c is topic) { ... }
sub f ($a, $b) is given($_) { ... }
could be something like:
sub f ($c : $a is topic, $b) { ... }
sub f ($c : $a, $b) { ... }
sub f ($_ : $a, $b) { ... }
where the first arg to be mentioned is the
topic unless otherwise specified.
(The first line of the alternates is not
semantically the same as the line it is a
suggested replacement for, in that the
current scheme would not set the topic --
its value would be the value of $_ in
the lexical block surrounding the sub
definition. It's not obvious to me why
the current scheme has it that way and
what would best be done about it in the
new scheme I suggest, so I'll just move on.)
Anyhow, the above is my suggestion for an
alternate to 'is given' in a sub definition.
The obvious (to me) thing to do for methods
is to have /two/ colon separated prefixes of
the arg list. So one ends up with either one,
two, or three sections of the arg list:
# $_ is invocant:
method f ($a, $b) { ... }
# $_ and $self are both invocant:
method f ($self : $a, $b) { ... }
# $_/$self are invocant, $c caller's topic
method f ($self : $c : $a, $b) { ... }
One could have incantations such as:
method f ($self : $c : $a is topic, $b) { ... }
method f ($self : $c is topic : $a, $b) { ... }
method f ($self : $_ : $a, $b) { ... }
which all clobber the invocant being 'it',
but if that's what a method author wants,
then so be it.
One question is what happens if one writes:
method f (: $c : $a, $b) { ... }
Is the invocant the topic, or $c, ie what
does a missing invocant field signify?
Jumping to a different topic for one moment,
I think it would be nice to provide some
punctuation instead of (or as an alternate
to) a property for setting 'is topic'. Maybe:
method f ($self : $c : $a*, $b) { ... }
or maybe something like:
method f ($self : $c : $aT, $b) { ... }
(Unicode TM for Topic Marker? Apologies if I
screwed up and the TM character comes through
as something else.)
Anyhow, a further plausible tweak that builds
on the above colon stuff is that one could
plausibly do:
sub f ($bar : $a, $b) {
...
}
and then call f() like so:
f (20 : 30, 40)
as a shortcut for setting $_ before calling f(),
ie to set $_ in the body of f to 20, $a to 30.
Unfortunately that conflicts with use of colon
as an operator adverb. Conclusion: if y'all
end up using a different syntax for specifying
the variable name of the invocant for a method,
and go with the extension I suggested earlier
for replacing 'is given', then maybe the above
can still work, and maybe it would be a good
idea to allow it.
And if you do, I can see a further trick being:
given $foo {
# $_ = $foo here, hiding outer topic
}
given $c : $foo {
# $_ = $foo here, hiding outer topic
# $c = outer $_
}
And likewise for other topicalizers.
--
ralph
