Re: definitions of truth
In Perl5, the following values are FALSE: undef, '0', 0, and ''. What you fail to note is that each of these is false for a reason. undef is false so that you can test an object for truth; if it is undef it obviously contains no data, so it's false. 0 is false so that you can test numbers for truth. '' is false so that you can test strings for truth. The really special case is '0', which is false for arcane (but very sensible) reasons. Okay, so it's binary data. So is "0" and 0, if you look at it that way. The difference here is that there is no normal circumstance wherein you would get a binary null if there's no data. The only situation I can think of that even comes close would be if you were reading null-terminated strings from a C or Assembler program out of some kind of binary file, and in that case you'd almost certainly split on binary null, so you'd get "" if there were no data in a given string, and that would be false as per the existing rules. Perl is a pragmatic language; things are true (or false) for good reasons, so that you can do various things easily. I realize the internal representations are different, but the programmer shouldn't have to care about that. When are you going to run into binary nulls if you're NOT mucking about with internal representations? > I just figure that if my bit of $data = contains one byte, and I'm checking that $data for boolean truth, You can always check the number of bytes (or characters), and it'll be false in boolean context if it's zero: mumblefrotz(\$data) while length $data; 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? 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.
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 C rather than C, and a C 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 C treats $x as a string would be pretending that C always treats its arguments as numbers, but something such as C 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 C doesn't apply I've always found C 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 C treats > $x as a string would be pretending that C always treats its > arguments as numbers, but something such as C 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.
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
On Thu, 2004-06-24 at 21:45, Brent 'Dax' Royal-Gordon wrote: > 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'. Frankly, I love it. Since I plan on using explicit typing a lot, I can just assume '0' is true in my code. However, machine-converted Perl5 code will also work reliably, easing the transition from 5 to 6. The only catch that I see is that it's pretty weird to change your program's behavior simply by changing an untyped variable to a String... That might have to go in a FAQ. :) - Scott
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 > __
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 thi
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
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");