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 FALSE....though
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.

Reply via email to