Re: definitions of truth
Paul Hodges wrote:
--- Jonadab the Unsightly One [EMAIL PROTECTED] wrote:
Consider this test in Perl:
if \0 {...}
Its equivalent in C is this:
if () ...
That can't be right. If anything it's got the two languages
flipped, but that's still not quite right either. Apples and
orange leotards.
lol
if(!strcmp(\0Apples\0, \0orange leotards\0))
printf(I see no difference here\n);
Re: definitions of truth
[EMAIL PROTECTED] (Paul Hodges) writes: Do note that I realize I can check it. It's just that for no reason I can quite define, my C background wants a null byte to be FALSE without any special chicanery on my part when checking. I can live with the fact it isn't going to be, it just seems odd to me. Has this problem ever bitten you in Perl coding so far? I don't think I've ever seen a bug in code that turned out to be because of 0.0 being true, either; I'm sure someone can find an example, but it's extremely rare. -- Do you associate ST JOHN'S with addiction to ASIA FILE? - Henry Braun is Oxford Zippy
Re: definitions of truth
Paul Hodges wrote:
Do note that I realize I can check it. It's just that for no reason I
can quite define, my C background wants a null byte to be FALSE without
any special chicanery on my part when checking. I can live with the
fact it isn't going to be, it just seems odd to me.
If that seems odd to you, the implications of Perl's being an
expression-based rather than a statement-based language will
probably give you nightmares (strange nightmares about void
context...)
I believe, from the way you asked your question, that you don't have
the right mental map to make it comfortable. As I see it, at least,
with respect to what you're asking about testing, Perl has strings
and integers, but not 'characters'.
Perl has scalars, and they can be any of the above.
No. A Perl scalar can't store a character per se. It can store
the ordinal value of the character as a number, or it can store a
string of length one, but neither of those is the same thing as
storing a character directly...
Consider this test in Perl:
if \0 {...}
Its equivalent in C is this:
if () ...
That can't be right. If anything it's got the two languages
flipped, but that's still not quite right either. Apples and
orange leotards.
But it isn't. The perl is passing a zero -- just a fairly obscure one.
No, \0 isn't zero. It may become zero if you translate it from
certain character sets (e.g. ASCII) to its numeric collating code
(and this is what ord does, but ord is not one of the more
frequently-used builtins, because that's just not something you
need to do very much in Perl; 90% of the times I've seen ord used
were in deliberatly obfuscated code), but otherwise it's a character,
not a number. Under more normal conditions it would numerify to
zero only for the same reason C would also numerify to zero.
I just thought that the special value of an ASCII 0 fit well into that
~arbitrary~ set, just as the special value of an ASCII 48 does. It's
just a mindset, as several folk have said, but hey, I'd be ok if 0 was
true because it wasn't the explicit boolean value of FALSEthough
I'm REALLY glad Perl doesn't do that. :)
Lisp does this -- anything that's not nil is effectively true (err, t).
It works for lisp, but it wouldn't play nicely in Perl due to some
other differences.
lol -- C doesn't have strings, but Perl does?
As a fundamental data type, he meant. C doesn't have strings in the
same sense that Perl doesn't have characters. Some languages have both,
you know, and so the character A is not the same thing as the string
A and would be stored in a variable with a different type. (I'm
thinking here of Pascal.) A C variable can store a character directly,
such that afterward the answer to what is in this variable is such
and such a character. In Perl the answer would be a string. Going
the other way around, Perl can store Hello, World in a scalar, and
if you then ask the question, What's in $hello ? the answer is
The string 'Hello, World', whereas, in C the answer would really be
A pointer to a character.
You can say that each is capable of emulating the functionality of
the other, and you'd be right insofar as that you'd be talking about
Turing equivalence, but there are still important differences in
terms of paradigm; the way data are stored and handled has major
implications for how we think in the language. One of the implications
of Perl's way of doing things is that the ASCII character corresponding
to decimal 0 is not special in any particular way. If I'd been doing
something with split// to process some binary data, I'd have known to
check for 0, but if any *other* character (including binary null)
had tested false and prematurely ended my loop (or whatever) I'd have
been highly weirded out and probably made a comment to the effect of,
In the name of all that is sane, WHY?
Yes, Perl's strings are cleaner and more prettily wrapped, because they
are an interpretive subset of scalars and the way they're defined. Perl
was written in C, and uses the same internal bits at some point.
That's an implementation detail. A good rule of good design is
that implementation details don't show through generally.
Now, with all of that said, it should also be noted that in Perl 6 it
will probably be possible to create a pragma that will cause things
to work rather differently, so that you can have \0 evaluate to
false in boolean context in your lexical scope. I'd advise against it.
Re: definitions of truth
Paul Hodges wrote: --- Spider Boardman [EMAIL PROTECTED] wrote: You need ord() for character/grapheme/byte/whatever testing that's equivalent to what C does. Since C doesn't really have strings, and Perl does, this is just one of those differences between the languages where (essentially, and perhaps abusing some linguistics theory and terminology) you've run into a 'false cognate'. lol -- C doesn't have strings, but Perl does? He's absolutely correct. C does not have a string type, just as Perl does not have a character type. In C you can *represent* a string as an array of characters, just as in Perl you can *represent* a character as an integer. But there's no built-in, native type for either of these. You could write your own data structure to represent a string (Parrot, Perl 6's runtime engine, does this), but it's still not a first-class, built-in type the way an int or float or char is. You wouldn't be able to compare it with or have it behave rationally as the condition of an if() or copy it with =. (You could do all of these things with C++, though--but it still wouldn't be a built-in type.) Similarly, you could write a class to represent a character in Perl 6, but it wouldn't be built-in like Int, Num and String are. It could come very close--it could work correctly (for some value of correctly) in boolean context, for example, unlike C strings--but it would still require a use statement to get at, and people often wouldn't design their modules to use it the way they do for Int, Num and String. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: definitions of truth
--- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Paul Hodges) writes: Do note that I realize I can check it. It's just that for no reason I can quite define, my C background wants a null byte to be FALSE without any special chicanery on my part when checking. I can live with the fact it isn't going to be, it just seems odd to me. Has this problem ever bitten you in Perl coding so far? Only the once. Once I realized that a null byte was boolean true (and passed that info around the office, to many confused looks and remarks about it) then I knew thereafter, and coded accordingly. But yes, I wrote a program that was parsing data, and if the null had been false as expected, I'd've been happier. As it was I just had to rethink the logic a bit, but it was still disconcerting. I don't think I've ever seen a bug in code that turned out to be because of 0.0 being true, either; I'm sure someone can find an example, but it's extremely rare. No argument -- but I think I've done that as well. :) __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Re: definitions of truth
--- Jonadab the Unsightly One [EMAIL PROTECTED] wrote:
Paul Hodges wrote:
Do note that I realize I can check it. It's just that for no reason
I can quite define, my C background wants a null byte to be FALSE
without any special chicanery on my part when checking. I can live
with the fact it isn't going to be, it just seems odd to me.
If that seems odd to you, the implications of Perl's being an
expression-based rather than a statement-based language will
probably give you nightmares (strange nightmares about void
context...)
lol -- strangely enough, I like that. ;o)
I believe, from the way you asked your question, that you don't
havethe right mental map to make it comfortable. As I see it,
at least, with respect to what you're asking about testing, Perl
has strings and integers, but not 'characters'.
Perl has scalars, and they can be any of the above.
No. A Perl scalar can't store a character per se. It can store
the ordinal value of the character as a number, or it can store a
string of length one, but neither of those is the same thing as
storing a character directly...
Ok, I'll give you that. And that's largely the reason for the true
null. I know. In the above statement I was actually thinking about
splitting strings into characters, but your point is absolutely
correct. I stand corrupted. I mean corrected. :)
Consider this test in Perl:
if \0 {...}
Its equivalent in C is this:
if () ...
That can't be right. If anything it's got the two languages
flipped, but that's still not quite right either. Apples and
orange leotards.
lol
But it isn't. The perl is passing a zero -- just a fairly obscure
one.
No, \0 isn't zero. It may become zero if you translate it from
certain character sets (e.g. ASCII) to its numeric collating code
(and this is what ord does, but ord is not one of the more
frequently-used builtins, because that's just not something you
need to do very much in Perl; 90% of the times I've seen ord used
were in deliberatly obfuscated code), but otherwise it's a character,
not a number. Under more normal conditions it would numerify to
zero only for the same reason C would also numerify to zero.
Sorry, I was thinking in C, where every data bit is a number. A
character in C is just a very small number, one byte wide. A null is a
zero; a '0' is a 48. In perl, there's an entire hat full of magic
swinging around under every scalar, which is, again, why it surprised
me that null wasn't assumed to be false when it was a single byte in a
boolean context. (Hm...I'm starting to sound a little redundant here, I
think)
I just thought that the special value of an ASCII 0 fit well
into that ~arbitrary~ set, just as the special value of an ASCII
48 does. It's just a mindset, as several folk have said, but hey,
I'd be ok if 0 was true because it wasn't the explicit boolean
value of FALSEthough I'm REALLY glad Perl doesn't do that. :)
Lisp does this -- anything that's not nil is effectively true (err,
t). It works for lisp, but it wouldn't play nicely in Perl due to
some other differences.
No comment. :)
lol -- C doesn't have strings, but Perl does?
As a fundamental data type, he meant. C doesn't have strings in the
same sense that Perl doesn't have characters. Some languages have
both, you know, and so the character A is not the same thing as the
string A and would be stored in a variable with a different type.
(I'm thinking here of Pascal.) A C variable can store a character
directly, such that afterward the answer to what is in this
variable is such and such a character. In Perl the answer would
be a string. Going the other way around, Perl can store Hello,
World in a scalar, and if you then ask the question, What's in
$hello ? the answer is The string 'Hello, World', whereas, in C
the answer would really be A pointer to a character.
I know, and I apologize for the roundabout. It wasn't that I didn't
know what he meant, but rather that I was demonstrating a different
mindset. I won't say again something about my expectations, because I
think that poor horse has been beaten enough.
My point is merely about the principle of least surprise, and
apparently I'm in the minority in my opinion of what's surprising and
what's not. I find that odd, since *everyone* at my office was of the
same mind, but they really aren't Perl programmers. It's a C thing.
I don't want Perl trying to emulate C; I like Perl better than C.
I was just expressing an opinion and asking a question.
You can say that each is capable of emulating the functionality of
the other, and you'd be right insofar as that you'd be talking about
Turing equivalence, but there are still important differences in
terms of paradigm; the way data are stored and handled has major
implications for how we think in the language.
And that was pretty much where i was going.
One of the implications of Perl's way of doing things
Re: definitions of truth
--- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote: Paul Hodges wrote: --- Spider Boardman [EMAIL PROTECTED] wrote: You need ord() for character/grapheme/byte/whatever testing that's equivalent to what C does. Since C doesn't really have strings, and Perl does, this is just one of those differences between the languages where (essentially, and perhaps abusing some linguistics theory and terminology) you've run into a 'false cognate'. lol -- C doesn't have strings, but Perl does? He's absolutely correct. [snip] lol remind me not to get so abstract when trying to make a point (especially when sleepy and disorganized) on a board for programmers. :) Right, ok, agreed. I knew what he meant when I said it, and played Devil's Advocate to make a point which got lost in translation, and wasn't that important in the first place. Good night, all. :) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: definitions of truth
Jonadab the Unsightly One skribis 2004-06-24 22:11 (-0400): No, what's really special is the ability to return entirely different things in string versus numeric context, like the magic $! does in Perl5. That too already works in Perl 5. See dualvar in Scalar::Util. Perl 6 is very neat, but try to appreciate what Perl 5 can do. It's not a stupid, old language now that Perl 6 is being designed. It is still the powerful programming language with lots of quirks and handy exceptions. Juerd
Re: definitions of truth
On Thu, Jun 24, 2004 at 12:43:30PM -0700, Scott Bronson wrote: So, in summary, though 0==false appears to work, it leads to a number of strange boundary conditions and, therefore, bugs. It's hard for new programmers to grasp and even old hacks are still sometimes tripped up by it. It just feels inconsistent. That's why I'd love to see this straightened out for Perl6. Interestingly, the very first use of the properties system that I remember seeing on this list was 0 but true. Although no one explicitly said so, it seems to me that the entire idea of properties was created to deal with this problem...which it doesn't do particularly well, since you still have to remember to tag the property on. As it turns out, properties are (at least apparently, until we have a significant Perl6 codebase) very useful for other things. FWIW, I also don't particularly like dealing with the edge cases that 0 causes. Unfortunately, I don't have a good solution. --Dks
Re: definitions of truth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Hodges wrote:
| --- Luke Palmer [EMAIL PROTECTED] wrote:
|
|Paul Hodges writes:
|
|So, in P6:
|
| if 0 { print 0\n; } # I assume this won't print.
| if '0' { print '0'\n; } # I assume this won't print.
| if ''{ print ''\n;} # I assume this won't print.
| if undef { print undef\n; } # I assume this won't print.
|
|But my question is, will this:
|
| if \0 { print null\n; } # Is this going to print, or not?
|
|As far as things are currently defined, yes, it will print. And your
|syntax is perfect... well, maybe not:
|
|if undef { print undef\n; }
|
|Might be interpreted as:
|
|if undef( { print undef\n; } ) # syntax error, expecting {
|
|But close enough anyway.
|
|
| Maybe I should have been more specific:
|
| if undef() { whatever(); }
|
| But it's a moot point, since only a moron would test what he knowks the
| answer to -- unless it's one of those wierd cases, and then he could
| just use 0 instead..
|
| So, putting it back into the context of real things.
|
|
|If you must check for a null byte, it's as simple as:
|
|unless $chr { print 0, '', or '0' }
|unless ord $chr { print null byte }
|
|
| So a null byte is still Boolean true.
| Ugh, yarf, ack, etc.
|
| But as long as I know -- easy enough to check explicitly.
|
| But just tell me thisam I the only guy who thinks this *feels*
| wierd? Understanding the reason doesn't make it any more ~comfortable~.
I think it feels fine. The weirdness comes from the difference between
string context and numeric context I think - like with '0' being false
and '0.0' being true in string context, but if you converted them both
to numbers they'd both be false.
This is why Perl 6's explicit typing will be such a Good Thing.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA2/4E0UvYjCBpIlARAor4AKCjsHZBmLqnKwDt2kMINwAS0ZMBFQCeIup3
20Jlgv0D/WQt+sRjHhGuAbQ=
=Tl+q
-END PGP SIGNATURE-
Re: definitions of truth
On Thu, Jun 24, 2004 at 08:23:39PM -0700, Paul Hodges wrote: --- Luke Palmer [EMAIL PROTECTED] wrote: So a null byte is still Boolean true. Ugh, yarf, ack, etc. But as long as I know -- easy enough to check explicitly. But just tell me thisam I the only guy who thinks this *feels* wierd? Understanding the reason doesn't make it any more ~comfortable~. In C it would be weird, but in Perl there is nothing special about the null byte - it is just a character like any other because strings know how long they are without depending upon an inline terminator character. For some particular glue purposes, detecting null explicitly and using the result as boolean is useful - but other character values are used as a boolean flag in a string (comma, linefeed, space, quotes, etc.) far more often than null, so giving null special status in the language seems wrong to me. --
Re: definitions of truth
Paul Hodges wrote: So a null byte is still Boolean true. Ugh, yarf, ack, etc. But as long as I know -- easy enough to check explicitly. But just tell me thisam I the only guy who thinks this *feels* wierd? It doesn't feel weird to me, but my previous languages of choice were fairly high-level (GW-BASIC, Pascal, Inform, QBasic, and Emacs lisp). I never really got very deeply into C. But explain something to me: under what circumstances would you be checking for any data at all _except_ a binary null? What are you writing, a disassembler?
Re: definitions of truth
Paul Hodges wrote:
So a null byte is still Boolean true.
But just tell me thisam I the only guy who thinks this *feels*
wierd? Understanding the reason doesn't make it any more ~comfortable~.
I think you are. Perl considers null to be data--it's that simple.
Remember, while Perl can work with binary, it's really designed for text.
Incidentally, if you really want to, you can always define your own
string that does what you want:
class BinaryString is String {
method prefix:? () {
if($_ eq \0) {
return 0;
}
else {
next METHOD;
}
}
}
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: definitions of truth
At some point in history, Paul Hodges wrote (in part):
ph So a null byte is still Boolean true. Ugh, yarf, ack, etc.
No. And it never has been (at least in my world view). However, asking
that question explains some things. See below for more.
ph But as long as I know -- easy enough to check explicitly.
ph But just tell me thisam I the only guy who thinks this *feels*
ph wierd? Understanding the reason doesn't make it any more
ph ~comfortable~.
I believe, from the way you asked your question, that you don't have the
right mental map to make it comfortable. As I see it, at least, with
respect to what you're asking about testing, Perl has strings and
integers, but not 'characters'. (And see another p6l thread about
graphemes and language-dependence and bytes, etc., for why that's a Good
Thing(TM).)
For example, take this test in C:
if ('\0') ...
It corresponds to this in Perl:
if ord \0 {...}
Consider this test in Perl:
if \0 {...}
Its equivalent in C is this:
if () ...
You need ord() for character/grapheme/byte/whatever testing that's
equivalent to what C does. Since C doesn't really have strings, and Perl
does, this is just one of those differences between the languages where
(essentially, and perhaps abusing some linguistics theory and terminology)
you've run into a 'false cognate'.
Hope this helps,
--s.
--
Spider Boardman (at home) [EMAIL PROTECTED]
The management (my cats) made me say this.http://users.rcn.com/spiderb/
PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
Re: definitions of truth
--- Spider Boardman [EMAIL PROTECTED] wrote:
At some point in history, Paul Hodges wrote (in part):
ph So a null byte is still Boolean true. Ugh, yarf, ack, etc.
No. And it never has been (at least in my world view).
A valid point, though I reply:
my $x = \0;
print true if $x;
However, asking that question explains some things.
See below for more.
ph But as long as I know -- easy enough to check explicitly.
Do note that I realize I can check it. It's just that for no reason I
can quite define, my C background wants a null byte to be FALSE without
any special chicanery on my part when checking. I can live with the
fact it isn't going to be, it just seems odd to me.
ph But just tell me thisam I the only guy who thinks this
ph *feels* wierd? Understanding the reason doesn't make it any
ph more ~comfortable~.
I believe, from the way you asked your question, that you don't have
the right mental map to make it comfortable. As I see it, at least,
with respect to what you're asking about testing, Perl has strings
and integers, but not 'characters'.
Perl has scalars, and they can be any of the above.
(And see another p6l thread about graphemes and language-dependence
and bytes, etc., for why that's a Good Thing(TM).)
Read it till I got a headache. :)
For example, take this test in C:
if ('\0') ...
It corresponds to this in Perl:
if ord \0 {...}
Not exactly. In C, the only thing the if() is testing is whether or not
the value is a zero. Anything else is true. The Perl ord is checking
for the numeric value of the first byte of the given string, and then
the if() is testing to see whether the result that got passed back was
either 0 or '0' or '' or undef, with anything else being true. I just
thought it felt natural (at least to me) for \0 to have been in that
list, though I can live with it either way.
Consider this test in Perl:
if \0 {...}
Its equivalent in C is this:
if () ...
No, because the Perl is passing back the actual zero value null byte,
whereas the C is passing back the address pointer of the location in
memory where the enpty string literal was stored. If it were the above
situation, I'd say Ok! and shut up -- which I may do anyway. :)
But it isn't. The perl is passing a zero -- just a fairly obscure one.
It's still received as a scalar, which is not a number, and so is
treated as a string. It's length is one instead on zero, so it isn't
perl's '', and it isn't character ASCII 48, so it isn't '0', and it
isn't a number, so it isn't 0, and it is defined, so it isn't undef,
and so since all these things have been counted out, it isn't any of
the known FALSE values, so it must be true.
But to me, the fact that Perl will let you use 0 or '0' is great. The
fact that '' is a valid string that is still false is great. The fact
that all these are defined and still false is great.
I just thought that the special value of an ASCII 0 fit well into that
~arbitrary~ set, just as the special value of an ASCII 48 does. It's
just a mindset, as several folk have said, but hey, I'd be ok if 0 was
true because it wasn't the explicit boolean value of FALSEthough
I'm REALLY glad Perl doesn't do that. :)
You need ord() for character/grapheme/byte/whatever testing that's
equivalent to what C does. Since C doesn't really have strings, and
Perl does, this is just one of those differences between the
languages where (essentially, and perhaps abusing some linguistics
theory and terminology) you've run into a 'false cognate'.
lol -- C doesn't have strings, but Perl does?
Ok, that's a bad case of perspectivitis.
A string is just not as neatly packaged in C, but in either I can take
the string coordinates and extract ordinate from it with a function
call. If I'm using offset and length for both, then the sentinel null
byte that C usually uses to denote a string isn't even relevant, though
once again, I much prefer Perl's way of doing things.
Yes, Perl's strings are cleaner and more prettily wrapped, because they
are an interpretive subset of scalars and the way they're defined. Perl
was written in C, and uses the same internal bits at some point.
But yes, if by 'false cognate' you mean I've taken a point of view that
doesn't mesh with the commonly accepted norm, then I'm apparently
guilty, and will accept the answer that a null byte in a default scalar
context without typing will still evaluate to a boolean true in Perl 6.
But my intuition still tells me ASCII 0 is as good a candidate for
false as ASCII 48, no matter what sort of structure and niceties you
wrap it in. :)
Hope this helps,
--s.
--
Spider Boardman (at home) [EMAIL PROTECTED]
The management (my cats) made me say this.
http://users.rcn.com/spiderb/
PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C
AB 1F DC
__
Do you Yahoo!?
Yahoo! Mail - You care about
Re: definitions of truth
On Thu, 2004-06-24 at 08:04, Jonadab the Unsightly One wrote: In Perl5, the following values are FALSE: undef, '0', 0, and ''. ... The really special case is '0', which is false for arcane (but very sensible) reasons. I don't agree that '0' being false is sensible. This, plus less than vigilant programmers, has led to a great '0' hole, where many Perl programs correctly handle all possible input except for one: a string consisiting of a single 0. To ensure that your program doesn't suffer from the '0' hole, you need to use frob($k) if defined($k) length($k); anywhere you would normally just say frob($k) if $k. This somewhat strange incantation has become idiomatic in Perl5. As a related question, why is 0 false, but 0.0 is true? Floats are second-class citizens? As I understand it, the addition of properties in Perl6 (See the Apocalypse 12 article) allows for even undefined values to be true if you choose to make them so. That's the way I understand it too. You can also do the same in reverse, making it so your function can return, say, Failure! but evaluate to false. However, it seems that because Perl is finally getting a typing system, this hack can be fixed in Perl itself! No programmer intervention needed. Undef and '' can be false for strings, undef and 0 can be false for integers, undef, 0, and 0.0 can be false for floats, etc. Unfortunately, so that machine-converted Perl5 code still works, I think that untyped variables will probably still need to follow this oddball rule. Am I understanding correctly? Thanks, - Scott
Re: definitions of truth
On Thu, 2004-06-24 at 10:44, Scott Bronson wrote: I don't agree that '0' being false is sensible... I don't mean to imply that I think it's senseless. Just that, to me, it smells suspiciously like a hack. :) - Scott
Re: definitions of truth
Scott Bronson skribis 2004-06-24 10:44 (-0700): However, it seems that because Perl is finally getting a typing system, this hack can be fixed in Perl itself! No programmer intervention needed. Undef and '' can be false for strings, undef and 0 can be false for integers, undef, 0, and 0.0 can be false for floats, etc. I think this makes sense: string: undef, number: undef, 0 (implies 0.0) other: convert to number and then decide. Anything that can't naturally be converted to a number (i.e. would be invalid syntax if unquoted) is true. /me wanted to write this in Perl 6, but couldn't think of a good way to represent true and false when returning from is_true :) Perhaps having real true and false values (where true cannot be false and false cannot be true) would make a lot of things much easier. I, for one, would like return true; (where true is undef-ish: a keyword that always returns the same value). Juerd
Re: definitions of truth
On Thu, Jun 24, 2004 at 08:04:10PM +0200, Juerd wrote: : Scott Bronson skribis 2004-06-24 10:44 (-0700): : However, it seems that because Perl is finally getting a typing system, : this hack can be fixed in Perl itself! No programmer intervention : needed. Undef and '' can be false for strings, undef and 0 can be false : for integers, undef, 0, and 0.0 can be false for floats, etc. : : I think this makes sense: : : string: undef, : number: undef, 0 (implies 0.0) : other: convert to number and then decide. Anything that can't : naturally be converted to a number (i.e. would be invalid syntax if : unquoted) is true. Nope, various user-defined types will want to define their own version of truth. That's precisely what you're doing when you say 0 but true, for instance. : /me wanted to write this in Perl 6, but couldn't think of a good way to : represent true and false when returning from is_true :) 0 and 1 works pretty well, according to Professor Boole... :-) : Perhaps having real true and false values (where true cannot be false : and false cannot be true) would make a lot of things much easier. I, for : one, would like return true; (where true is undef-ish: a keyword : that always returns the same value). This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. (The optimizer is free to optimize the method call away for known types within known conditionals, of course. It had better, or evaluating the truth of .boolean will end up calling .boolean again... :-) It's likely that untyped scalars will still treat the string 0 as false, but that any kind of explicitly typed string will treat only the null string as false. (The special 0 rule will not pose as much trouble for Perl 6 as for Perl 5, because most iteration will be done with Cfor rather than Cwhile, and a Cfor terminates when its iterator runs out, not when the data becomes false. Plus we'll have the // operator.) Larry
Re: definitions of truth
Scott Bronson writes: On Thu, 2004-06-24 at 08:04, Jonadab the Unsightly One wrote: In Perl5, the following values are FALSE: undef, '0', 0, and ''. ... The really special case is '0', which is false for arcane (but very sensible) reasons. I don't agree that '0' being false is sensible. But you're fine with 0 being false? 0 and '0' are pretty much interchangeable in Perl 5 -- wherever you can use one, you can use the other and it gets coerced to it. So it really wouldn't make sense to have them being treated differently for truth purposes. As a related question, why is 0 false, but 0.0 is true? Floats are second-class citizens? '0' is the string representation of zero. 0.0 is also zero. But 0 and 0.0 (and 0x, and 2 - 2, and ...) are all the same zero, and all stringify to '0'. '0.0' is not a representation of that same zero; it's a string that would evaluate to zero if converted to a number, but it isn't interchangeable with the other zeros. If you think '0.0' should be false, what about '0x' or '2 - 2' or '$x - $x'? Smylers
Re: definitions of truth
Larry Wall skribis 2004-06-24 11:29 (-0700): This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. (The optimizer is free to optimize the method call away for known types within known conditionals, of course. It had better, or evaluating the truth of .boolean will end up calling .boolean again... :-) I didn't know about the (to-be) existence of .boolean. It makes things fun and easy, though. However, is the name boolean final? I would prefer true, perhaps with a corresponding false. That is, assuming that there will be $foo.defined and $foo.empty. Hm. I wonder where (and if) I read about .empty. Can't find it. not when the data becomes false. Plus we'll have the // operator.) I'll be wanting a length-or. Perl 6 will make coding it easy enough to not need it in the core. But the operator needs a symbol. I'm assuming infix: will work. But will there be a way to ask Perl if syntax can be used without introducing possible ambiguity? A circumfix ++ operator won't work for several reasons. What will Perl do if you try defining one? Please don't say that picking a random sequence of at least 5 different unicode dingbats will be the best way to be sure :) Juerd
Re: definitions of truth
On Thu, Jun 24, 2004 at 08:44:45PM +0200, Juerd wrote: : Larry Wall skribis 2004-06-24 11:29 (-0700): : This is Perl 6. Everything is an object, or at least pretends to be one. : Everything has a .boolean method that returns 0 or 1. All conditionals : call the .boolean method, at least in the abstract. (The optimizer is : free to optimize the method call away for known types within known : conditionals, of course. It had better, or evaluating the truth of : .boolean will end up calling .boolean again... :-) : : I didn't know about the (to-be) existence of .boolean. It makes things : fun and easy, though. : : However, is the name boolean final? I would prefer true, perhaps : with a corresponding false. Well, the type/property name doesn't have to be boolean--it could be truth, instead. But we mustn't confuse the type (false, true) with either true or false. In general, the name of a property is a type, so the truth property is something like boolean or truth, with an underlying base type of bit. According to A12, you can use a value of an enumerated type as a shorthand, so if you say $x.true it's short for something like $x.boolean == boolean::true And when you say 0 but true a whole bunch of magic happens that creates a type with a .boolean method that returns the value true. : That is, assuming that there will be $foo.defined and $foo.empty. Hm. I : wonder where (and if) I read about .empty. Can't find it. I'm afraid .empty was just a p6l speculation. But .defined is a real property/method. : not when the data becomes false. Plus we'll have the // operator.) : : I'll be wanting a length-or. Perl 6 will make coding it easy enough to : not need it in the core. What do you mean by length? Length is not a generic concept in Perl 6, and there is no .length method. You'll have to be more specific about what *kind* of length you're talking about: byte length, codepoint length, grapheme length, element length, etc. However, for most types possessing one or more kinds of length, it works out that the boolean value will be true if there is any length and false otherwise. (Untyped scalars still have the caveat about string 0 though.) So you don't need a length-or at all. (Or if you do, you need it less than Perl 5 did, and we've gotten by without it for quite a while now there.) : But the operator needs a symbol. I'm assuming : infix: will work. But will there be a way to ask Perl if syntax can be : used without introducing possible ambiguity? Good question. I expect we can manage to give an optional warning if one operator completely hides another. On the other hand, it might be intentional. (However, infix: wouldn't necessarily hide anything, since it would only be looked for where an operator is expected. prefix: is another matter... But it's probably a bad idea anyway since you'd screw up the lookahead that determines whether you can drop the parens on a method call.) : A circumfix ++ operator won't work for several reasons. What will Perl : do if you try defining one? Probably depends on whether Perl decides the initial circumfix + is indistinguishable from a unary +. While it's theoretically possible to attempt to parse as circumfix and then backtrack to prefix if that doesn't work, it's probably a bad plan from a human understandability point of view. Backtracking is a wonderful concept till you have to do it. On the other hand, if you declare your circumfix:++ with is forced or some such, then maybe it just hides prefix:+ without a warning. : Please don't say that picking a random sequence of at least 5 different : unicode dingbats will be the best way to be sure :) Oh, I'd never say that. The Perl Way is that the computer always tries insanely hard to serve your needs. In Soviet Russia (and similar places) the computer is served by you. However, visual distinctions might well be the best way to keep the *human* reader clued to his terminal, so you might want to keep those five random dingbats close to hand... Larry
Re: definitions of truth
On Thu, 2004-06-24 at 11:34, Smylers wrote: Scott Bronson writes: But you're fine with 0 being false? 0 and '0' are pretty much interchangeable in Perl 5 -- wherever you can use one, you can use the other and it gets coerced to it. Let's back up... Strings and numbers are meant to be interchangeable in Perls 1 through 5. You should not care if a varaible is represented internally using a string or an int or a float or a bignum or... The problem is, how should Perl compare two values when it doesn't know what they are? Larry solved this by creating a whole new set of operators to explicitly force a context: num str ==vs. eq vs. lt etc. OK, comparison is handled. But what about evaluating to true or false without comparison? The representation problem still exists. If Larry had solved this problem the same way he did comparison, he would have created even more operators and control structures: num str ! vs. not ifvs. sif while vs. swhile For whatever reason, he chose to solve this problem differently. Instead of creating stringy evaluation, he decided to have 0 evaluate false. On the surface, and in practice, this trick seems to work pretty well. Unfortunately, it leaves a lot of weird behavior lying around the edges. What about 0.0? Or 00? And your example, 0x00? Those are all perfectly valid ways of reperesenting 0. If strings and ints truly were interchangeable, all of these strings would be false, woudln't they? And what about when you KNOW an expression should be evaluated as a string? You need to remember to use defined($s) length($s), otherwise you will suffer from the '0' hole (where the string 0 is handled differently from all other strings in your program). So it really wouldn't make sense to have them being treated differently for truth purposes. OK, name another language that does this. Well, other than PHP, whose string handling is even screwier than Perl's. :) I think that Ruby is an example of a scripting language that has solved this problem very well (and I think Python is similar...?). So, in summary, though 0==false appears to work, it leads to a number of strange boundary conditions and, therefore, bugs. It's hard for new programmers to grasp and even old hacks are still sometimes tripped up by it. It just feels inconsistent. That's why I'd love to see this straightened out for Perl6. - Scott
Re: definitions of truth
Larry Wall skribis 2004-06-24 12:24 (-0700):
Well, the type/property name doesn't have to be boolean--it could
be truth, instead.
I understand that 'true' and 'false' can't be used.
However, truth is in the same category as definedness, and
$foo.definedness looks awful :)
Perhaps for conversion to a certain type, simply the type name can be
used as a method. Then $foo.int and $foo.bool make the same kind of
sense. (Or $foo.Int and $foo.Bool, but then int $foo would be strange
(I assume int $foo returns a fully functional scalar integer))
[length-or]
What do you mean by length? [bytes, graphemes, etc]
Good question. Probably byte length. If there is one byte, that has to
represent at least one of the other length-units, right?
Not having 'length' will be hard to get used to. Perhaps I'll try to
make it easier (and thus harder in the longer term) for myself by
defining something that does .isa('Str') ? .chars : .isa('str') ? .bytes
: .isa('Hash') ? .keys : .isa('Array') ? .elements : 1.
Synopsis 6 describes 'str' as 'native string'. Is my assumption that
such a string is one that doesn't have multi-byte characters correct?
Juerd
Re: definitions of truth
Larry Wall wrote: What do you mean by length? For a string, it obviously either means number of bytes or number of characters. Pick one, document it, and let people who want the other semantic use a pragma. I don't think it matters which one you pick as default, as long as it's clearly documented.
Re: definitions of truth
On Thu, Jun 24, 2004 at 04:19:25PM -0400, Jonadab the Unsightly One wrote: : Larry Wall wrote: : : What do you mean by length? : : For a string, it obviously either means number of bytes or number : of characters. Pick one, document it, and let people who want the : other semantic use a pragma. What do you mean by character? Do you mean codepoint or grapheme? And if grapheme, language dependent or language independent? (Leaving aside the fact that ten years ago character generally meant byte.) : I don't think it matters which one you pick as default, as long : as it's clearly documented. Documentation has not kept people from saying length(@array) over and over in Perl 5. In such cases it's better not to have a default, as long as it's not too onerous to be specific. In Perl 6 you never ask for the length(). You ask for things like bytes(), codepoints(), graphemes(), or elems(). This is an area where clarity must be enforced. Muddy concepts like characters and length will only produce muddy programs. Larry
Re: definitions of truth
Scott Bronson writes: On Thu, 2004-06-24 at 11:34, Smylers wrote: But you're fine with 0 being false? 0 and '0' are pretty much interchangeable in Perl 5 -- wherever you can use one, you can use the other and it gets coerced to it. Let's back up... Strings and numbers are meant to be interchangeable in Perls 1 through 5. You should not care if a varaible is represented internally using a string or an int or a float or a bignum or... Uh-huh. But what about evaluating to true or false without comparison? The representation problem still exists. If Larry had solved this problem the same way he did comparison, he would have created even more operators and control structures: num str ! vs. not ifvs. sif while vs. swhile For whatever reason, he chose to solve this problem differently. Because the above would've been insane: saying that Csif ($x) treats $x as a string would be pretending that Cif always treats its arguments as numbers, but something such as Cif ($x eq 'frog') doesn't have any numbers in it. Instead of creating stringy evaluation, he decided to have 0 evaluate false. On the surface, and in practice, this trick seems to work pretty well. Well, not always, as you point out -- often input of 0 is an edge-case that doesn't do the right thing; it's just that in many programs it's an edge-case that doesn't matter. Larry's plan to drop this in Perl 6 for things explicitly typed as strings sounds sensible to me. I wasn't claiming that having '0' be false is unquestionably a good thing; merely that it makes sense from 0 being false. Unfortunately, it leaves a lot of weird behavior lying around the edges. What about 0.0? Or 00? And your example, 0x00? Those are all perfectly valid ways of reperesenting 0. If strings and ints truly were interchangeable, all of these strings would be false, woudln't they? No; none of the above strings are interchangeable. All of those strings have the numeric value of zero when treated as a number, but then so does the string crumpet. Being interchangeable involves swapping them either way round. If you want to emit the string '0' then you can either use that string or the number zero, and that number can be calculated from an expression or be a constant in your program that is typed in your Perl source code as 0 or 0.0 or 0x00. But if you want to emit the string '0.0' then you have to have that exact string; there is no numeric value at all which is interchangeable with '0.0' such that printing it will yield exactly that output. So 0, 0.0, 0x00, 2 - 2, and '0' _are_ all different ways of representing the same thing; '0.0' is a different thing, which isn't interchangeable with any of the first lot. And what about when you KNOW an expression should be evaluated as a string? You need to remember to use defined($s) length($s), I've honestly never used that; I hadn't even considered it to be an idiom till you mentioned it. For cases when Cif ($s) doesn't apply I've always found Cif (defined $s) to be adequate. What I am looking forward to is the Perl 6 C// operator: when writing Perl 5 I keep finding places where I want to use it and either have to write uglier code or just use C|| and accept that a value of 0 won't be recognized. So it really wouldn't make sense to have them being treated differently for truth purposes. OK, name another language that does this. I'm not really familiar with any other programming language where numbers and strings are used interchangeably, where it isn't necessary to use some explicit conversion function or cast syntax to convert from one to the other. I'm not claiming that Perl 5's way is _the_ definitive right way of doing things, but it is consistent with other aspects of Perl 5. 'MySQL' kind-of blurs the boundaries between numbers and strings. It treats things as false if the evaluate to zero in a numeric context, so '0.00' is false but so is 'stottie'. That is also consistent ... but I get the feeling that defining all non-numeric strings as false wouldn't actually be to your liking either? 'Bash' goes the other way and treats all non-empty strings as true, therefore '0' is true, but so is 0. I think that Ruby is an example of a scripting language that has solved this problem very well I don't know Ruby; could you elaborate how this has been done. Smylers
Re: definitions of truth
Larry Wall [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. My reading of A12 leads me to expect this to be defined as a coercion, using the as operator, not dot: $foo as boolean What am I missing? Dave.
Re: definitions of truth
--- Dave Whipp [EMAIL PROTECTED] wrote: Larry Wall [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. My reading of A12 leads me to expect this to be defined as a coercion, using the as operator, not dot: $foo as boolean What am I missing? This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. :) =Austin
Re: definitions of truth
On 0, Juerd [EMAIL PROTECTED] wrote: However, is the name boolean final? I would prefer true, perhaps with a corresponding false. I want an okay. Routines should be able to return okay to indicate an ambivalent degree of success. okay would be defined as true | false, so: some_routine() == true or die; # I just knew everything would be fine! some_routine() == false and die; # I just knew everything would be go wrong! Or I suppose I could just use any() ;) -scott
Re: definitions of truth
Austin Hastings skribis 2004-06-24 14:29 (-0700): $foo as boolean This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. If I understand the current design correctly, having both .boolean and casting via as would mean that $foo.boolean and $foo as Bool and $foo as Bit mean the same in boolean context, but the first literally is 1 or 0, the second is true or false and the third is 1 or 0 again. But all this only by default, because every one of these three can be overriden. And actually, I don't think I understand it correctly. It's been a while since I had a feeling of understanding Perl 6 :) Is this complexity really needed? Juerd
Re: definitions of truth
--- Juerd [EMAIL PROTECTED] wrote: Austin Hastings skribis 2004-06-24 14:29 (-0700): $foo as boolean This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. If I understand the current design correctly, having both .boolean and casting via as would mean that $foo.boolean and $foo as Bool and $foo as Bit mean the same in boolean context, but the first literally is 1 or 0, the second is true or false and the third is 1 or 0 again. I don't think so. Specifically, I'd expect $x = 0 but true; print $x.boolean; # 1 print ($x as Bit); # 0 # (I don't know about 'Bool') Is this complexity really needed? I'd say yeah, it is. 0-but-true is pretty nice to have. (Finally the system calls can return something other than -1.) Juerd =Austin
Re: definitions of truth
Austin Hastings skribis 2004-06-24 15:54 (-0700): I'd say yeah, it is. 0-but-true is pretty nice to have. (Finally the system calls can return something other than -1.) That we already have. 0 but true. (perldoc -f fcntl) It's 1 but false that's really special :) Juerd
Re: definitions of truth
On Thu, Jun 24, 2004 at 03:24:25PM -0700, Scott Walters wrote: : I want an okay. Routines should be able to return okay to indicate : an ambivalent degree of success. okay would be defined as true | false, Some messages want to be simultaneously Warnocked and not Warnocked... Larry
RE: definitions of truth
-Original Message- From: Dave Whipp [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 5:22 PM To: [EMAIL PROTECTED] Subject: Re: definitions of truth Larry Wall [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. My reading of A12 leads me to expect this to be defined as a coercion, using the as operator, not dot: $foo as boolean What am I missing? Why not just use say ?$foo Isn't the prefix ? operator designed specifically for this use? Joe Gottman
Re: definitions of truth
On Thu, 2004-06-24 at 14:17, Smylers wrote: Because the above would've been insane: saying that Csif ($x) treats $x as a string would be pretending that Cif always treats its arguments as numbers, but something such as Cif ($x eq 'frog') doesn't have any numbers in it. Doesn't it? perl -e '$x = frog; print(($x eq frog) . \n);' No; none of the above strings are interchangeable. All of those strings have the numeric value of zero when treated as a number, but then so does the string crumpet. Being interchangeable involves swapping them either way round. Erm, we're talking about boolean context, right? All those strings evaluate to true. I'm asking about being interchangeable when used in a conditional statement; of course they're not interchangeable with each other. :) Larry's plan to drop this in Perl 6 for things explicitly typed as strings sounds sensible to me. That's the plan? Happy day! I was not aware of that. Because I didn't see anything about this in Perl 6 Essentials, I just figured that Perl5's '0'==undef was being brought forward into Perl6. The horror! Sorry for the bad assumption. :) - Scott
Re: definitions of truth
I seemed to have opened a can of worms, lol
But did anybody see the one that had something to do with my question
crawling around? (I've obviously missed a couple of messages. They're
probably hanging out down at the router in the cyberspace equivelent of
teenagers ogling girls on the street corner smoking cigs.)
So, in P6:
if 0 { print 0\n; } # I assume this won't print.
if '0' { print '0'\n; } # I assume this won't print.
if ''{ print ''\n;} # I assume this won't print.
if undef { print undef\n; } # I assume this won't print.
But my question is, will this:
if \0 { print null\n; } # Is this going to print, or not?
And if the answer is because I've somehow botched my syntax, please
correct it and answer the question I obviously *meant* to ask as well?
=o)
Paul
--- Hodges, Paul [EMAIL PROTECTED] wrote:
Every now and then I have this discussion with people at work that
involve Perl's ideas of boolean truth. I usually break it down like
this:
In Perl5, the following values are FALSE: undef, '0', 0, and ''.
Anything not in that list is considered TRUE in a boolean context.
That means that Perl5 has some notions of truth that confuse some
folk. I mean, I can understand 00 being true, even if it seems a
little odd to me personally, but \0??? How is a single null byte
*true*?
Okay, so it's binary data. So is 0 and 0, if you look at it that
way. I realize the internal representations are different, but the
programmer shouldn't have to care about that. I just figure that if
my bit of $data contains one byte, and I'm checking that $data for
boolean truth, I'd expect a null to be false, as would ba-zillions of
C programmers (from which backgroud I came). I know we aren't trying
so hard to imitate C behavior anymore, but still, doesn't this
violate the principle of least surprise?
So my question is this, with apology for the ramble
aside from P6's other changes, is a single null byte of binary data
still going to register as TRUE, or will it now be what seems to me
the more sensible FALSE?
Paul
__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Re: definitions of truth
Paul Hodges writes:
I seemed to have opened a can of worms, lol
But did anybody see the one that had something to do with my question
crawling around? (I've obviously missed a couple of messages. They're
probably hanging out down at the router in the cyberspace equivelent of
teenagers ogling girls on the street corner smoking cigs.)
So, in P6:
if 0 { print 0\n; } # I assume this won't print.
if '0' { print '0'\n; } # I assume this won't print.
if ''{ print ''\n;} # I assume this won't print.
if undef { print undef\n; } # I assume this won't print.
But my question is, will this:
if \0 { print null\n; } # Is this going to print, or not?
And if the answer is because I've somehow botched my syntax, please
correct it and answer the question I obviously *meant* to ask as well?
=o)
As far as things are currently defined, yes, it will print. And your
syntax is perfect... well, maybe not:
if undef { print undef\n; }
Might be interpreted as:
if undef( { print undef\n; } ) # syntax error, expecting {
But close enough anyway.
If you must check for a null byte, it's as simple as:
unless $chr { print 0, '', or '0' }
unless ord $chr { print null byte }
Luke
Re: definitions of truth
Juerd wrote: That we already have. 0 but true. (perldoc -f fcntl) It's 1 but false that's really special :) No, what's really special is the ability to return entirely different things in string versus numeric context, like the magic $! does in Perl5. That, or interesting values of undef :-)
Re: definitions of truth
--- Luke Palmer [EMAIL PROTECTED] wrote:
Paul Hodges writes:
So, in P6:
if 0 { print 0\n; } # I assume this won't print.
if '0' { print '0'\n; } # I assume this won't print.
if ''{ print ''\n;} # I assume this won't print.
if undef { print undef\n; } # I assume this won't print.
But my question is, will this:
if \0 { print null\n; } # Is this going to print, or not?
As far as things are currently defined, yes, it will print. And your
syntax is perfect... well, maybe not:
if undef { print undef\n; }
Might be interpreted as:
if undef( { print undef\n; } ) # syntax error, expecting {
But close enough anyway.
Maybe I should have been more specific:
if undef() { whatever(); }
But it's a moot point, since only a moron would test what he knowks the
answer to -- unless it's one of those wierd cases, and then he could
just use 0 instead..
So, putting it back into the context of real things.
If you must check for a null byte, it's as simple as:
unless $chr { print 0, '', or '0' }
unless ord $chr { print null byte }
So a null byte is still Boolean true.
Ugh, yarf, ack, etc.
But as long as I know -- easy enough to check explicitly.
But just tell me thisam I the only guy who thinks this *feels*
wierd? Understanding the reason doesn't make it any more ~comfortable~.
Paul
__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
Re: definitions of truth
Scott Bronson wrote:
That's the plan? Happy day! I was not aware of that. Because I didn't
see anything about this in Perl 6 Essentials, I just figured that
Perl5's '0'==undef was being brought forward into Perl6. The horror!
Sorry for the bad assumption. :)
Perhaps not as happy as you think:
my $foo = '0';
my String $bar = '0';
if $foo { say 'foo true' }
if $bar { say 'bar true' }
Would print 'bar true', but not 'foo true'. (In other words, variables
of type Any keep the Perl 5 behavior, but variables of type String have
the behavior you want.)
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
