--- 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 this....am 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 FALSE....though
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 security. So do we.
http://promotions.yahoo.com/new_mail
