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

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 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?"

Just a matter of what you expect. Null wouldn't have surprised me,
there. 

I have a friend whose psychiatrist tells him that the reason humans are
unhappy is usually because of unreasonable expectations. I'm not
unhappy, just surprised. *shrug*
 
> > 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.

lol -- yes, and I obviously was too blasted sleepy to make my point,
which was basically what you're saying here most of the time.

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

I don't intend to change the language just for me without a better
reason than this. I'll just remember what's false. 


                
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Reply via email to