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 > if vs. sif > while vs. swhile > > For whatever reason, he chose to solve this problem differently. Because the above would've been insane: saying that C<sif ($x)> treats $x as a string would be pretending that C<if> always treats its arguments as numbers, but something such as C<if ($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 C<if ($s)> doesn't apply I've always found C<if (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
