Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > automatic number <-> string conversions

Reply
Thread Tools

automatic number <-> string conversions

 
 
Rainer Weikusat
Guest
Posts: n/a
 
      09-18-2013
Coming to think of this, I'd agree that automatically converting a
non-numerical string to a number with value zero is rarely useful and
likely to lead to unpleasnt surprises, eg

[rw@sable]/tmp#perl -e 'print "David" == "Nick", "\n"'
1

(although this could be referred to 'deeper insight')

That's consistent with how atoi/ strtol would behave,

-----------
#include <stdlib.h>
#include <stdio.h>

int main(void)
{
printf("%d\n", atoi("Salad") == atoi("Steak"));
return 0;
}
----------

but that's more likely to be an 1970s implemenetation shortcut than a
conscious semantic choice and in any case, someone who knows Perl won't
necessarily/ shouldn't need to know C as well.

OTOH, I think the so-called 'undefined value', at least insofar it is
used as default value of an uninitialized variable, should be an
exception here: A variable with 'no value' should behave as if it had
some 'neutral value' for the context it is used in: Explicit
initialization should only be necessary when something other like than
this 'neutral value' is needed. Forcing people to write

my $a;
$a = 0;
print($a + 1);

instead of

my $a
print($a + 1);

just clutters the code with a lot of 'self-evident' statements.

 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      09-18-2013
Rainer Weikusat <(E-Mail Removed)> writes:

[...]

> [rw@sable]/tmp#perl -e 'print "David" == "Nick", "\n"'
> 1
>
> (although this could be referred to 'deeper insight')


Silly joke I can resist ATM: This works even nicer in German because
"beides Nullen" (both zeroes) is colloquial for "guys who can't get
anything done because it is beyond them" :->
 
Reply With Quote
 
 
 
 
Charles DeRykus
Guest
Posts: n/a
 
      09-18-2013
On 9/18/2013 2:51 AM, Rainer Weikusat wrote:
> Rainer Weikusat <(E-Mail Removed)> writes:
>
> [...]
>
>> [rw@sable]/tmp#perl -e 'print "David" == "Nick", "\n"'
>> 1
>>
>> (although this could be referred to 'deeper insight')

>
> Silly joke I can resist ATM: This works even nicer in German because
> "beides Nullen" (both zeroes) is colloquial for "guys who can't get
> anything done because it is beyond them" :->
>


At least perl warns when "beides Nullen" is "beyond the pale":

perl -wE 'print "David" == "Nick"'
Argument "Nick" isn't numeric in numeric eq (==) at -e line 1.
....


--
Charles DeRykus

 
Reply With Quote
 
Charles DeRykus
Guest
Posts: n/a
 
      09-18-2013
On 9/18/2013 9:55 AM, Ben Morrow wrote:
>
> Quoth Rainer Weikusat <(E-Mail Removed)>:
> ...
>>
>> but that's more likely to be an 1970s implemenetation shortcut than a
>> conscious semantic choice and in any case, someone who knows Perl won't
>> necessarily/ shouldn't need to know C as well.

>
> atoi has no choice: it has to return some int or other to signal
> 'invalid input', and it's obviously going to return the same one for
> different invalid inputs. Since int doesn't have a NaN value, the return
> values are going to be equal.
>
>> OTOH, I think the so-called 'undefined value', at least insofar it is
>> used as default value of an uninitialized variable, should be an
>> exception here: A variable with 'no value' should behave as if it had
>> some 'neutral value' for the context it is used in: Explicit
>> initialization should only be necessary when something other like than
>> this 'neutral value' is needed.

>
> I agree. Uninit value warnings were much more useful in the pre-strict
> days when an unexpected undef often meant you had autocreated a variable
> without meaning to. These days "uninitiailisized" is the warning
> category I turn off most often (the next is probably "exiting").
>


But, IIUC, I'm not sure how Perl could thread the twisty-turny maze to
warn sanely but not annoyingly.

Sensibly in lvalue settings, it doesn't: 'my $x; say ++$x;'
or: 'my $x; $x .= "foo";

But, most of the time, it seems to me there's more likely a need for a
warning than not, eg,

'my $x; my $y = "Alice hates $x...and the Red Queen;"

If there were no warning because "nothing other than its neutral value
is needed for the context it is used in", it'd fail to alert the author
to expressions that had changed in havoc-wreaking ways computationally
(or semantically).

--
Charles DeRykus
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      09-19-2013
Charles DeRykus <(E-Mail Removed)> writes:
> On 9/18/2013 9:55 AM, Ben Morrow wrote:
>> Quoth Rainer Weikusat <(E-Mail Removed)>:


[...]

>>> OTOH, I think the so-called 'undefined value', at least insofar it is
>>> used as default value of an uninitialized variable, should be an
>>> exception here: A variable with 'no value' should behave as if it had
>>> some 'neutral value' for the context it is used in: Explicit
>>> initialization should only be necessary when something other like than
>>> this 'neutral value' is needed.

>>
>> I agree. Uninit value warnings were much more useful in the pre-strict
>> days when an unexpected undef often meant you had autocreated a variable
>> without meaning to. These days "uninitiailisized" is the warning
>> category I turn off most often (the next is probably "exiting").
>>

>
> But, IIUC, I'm not sure how Perl could thread the twisty-turny maze to
> warn sanely but not annoyingly.
>
> Sensibly in lvalue settings, it doesn't: 'my $x; say ++$x;'
> or: 'my $x; $x .= "foo";
>
> But, most of the time, it seems to me there's more likely a need for a
> warning than not, eg,
>
> 'my $x; my $y = "Alice hates $x...and the Red Queen;"
>
> If there were no warning because "nothing other than its neutral value
> is needed for the context it is used in", it'd fail to alert the
> author to expressions that had changed in havoc-wreaking ways
> computationally (or semantically).


Simple. Warn if a string without leading digits is implicitly converted
to a 0. Don't warn if 'an undefined value' is used as if somebody
thought he wasn't accessing some a C 'stack-allocated object' which was
left unitialized for performance reason because that's totally
ridicolous for perl, anyway, and not true. Not everything which has
always worked in this way since 1973 for reasons we've long stopped to
care about has to continue to work in this way. That's going to be a
good idea in certain cases and a bad idea in certain other cases and
*for me*, the benefits outweigh the drawbacks.

 
Reply With Quote
 
Charles DeRykus
Guest
Posts: n/a
 
      09-19-2013
On 9/18/2013 6:00 PM, Ben Morrow wrote:
>
> Quoth Charles DeRykus <(E-Mail Removed)>:
>> On 9/18/2013 9:55 AM, Ben Morrow wrote:

....

>
> IMHO with properly scoped variables an undef is no more likely to be a
> mistake than any other value. IME undef warnings cause more problems (in
> terms of unnecessary code to work around them) than they solve. A simple
> example would be something like this:
>
> my $verb = $conf{verbose} + $ENV{FOO_VERBOSE} + $opt{v};
>
> where silently treating a nonexistent setting as 0 is the right thing to
> do. With undef warnings turned on that line of code has to become a good
> bit more complex, to no real advantage.


Maybe it's a personal bias bordering on an OCD affliction, but I'd
rather see that as: my $verb = ... + ($ENV{FOO_VERBOSE} // 0) + ...

IMO not appallingly tedious and documenting clearly what's going on.

>
>> Sensibly in lvalue settings, it doesn't: 'my $x; say ++$x;'
>> or: 'my $x; $x .= "foo";
>>
>> But, most of the time, it seems to me there's more likely a need for a
>> warning than not, eg,
>>
>> 'my $x; my $y = "Alice hates $x...and the Red Queen;"
>>
>> If there were no warning because "nothing other than its neutral value
>> is needed for the context it is used in", it'd fail to alert the author
>> to expressions that had changed in havoc-wreaking ways computationally
>> (or semantically).

>
> In that particular case an empty string makes no more sense than an
> undef, but an empty string won't warn. In the general case, there are a
> great many possible wrong values in any given situation, and undef is no
> more likely to be one of them than anything else.
>


Right. But, IMO, particularly in early development, you're more likely
to forget to initialize and -w can really help. Then you graduate to
more refined types of mayhem and no one can help you.

--
Charles DeRykus

 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      09-19-2013
On 2013-09-19 01:00, Ben Morrow <(E-Mail Removed)> wrote:
>
> Quoth Charles DeRykus <(E-Mail Removed)>:
>> On 9/18/2013 9:55 AM, Ben Morrow wrote:
>> >
>> > I agree. Uninit value warnings were much more useful in the pre-strict
>> > days when an unexpected undef often meant you had autocreated a variable
>> > without meaning to. These days "uninitiailisized" is the warning
>> > category I turn off most often (the next is probably "exiting").

>>
>> But, IIUC, I'm not sure how Perl could thread the twisty-turny maze to
>> warn sanely but not annoyingly.

>
> IMHO with properly scoped variables an undef is no more likely to be a
> mistake than any other value.


I disagree with that estimation. Undef is much more likely to be a
mistake than any other value because it *means* "no value". So when I
expect a numerical value, 23 may or may not be a mistake, but undef is
certain to be one - because I expect a numerical value and undef isn't
that.

Of course that depends on your coding style. If you treat undef like 0
or an empty string, the warning is just annoying and not helpful at all.
But the way I code, an undef in a place where I didn't expect it almost
always means that there is an error in my logic.

That said, uninitialized is also the warning category I turn off most
often (and I probably mistype it just as often as you ), although
usually in a very tight scope and often around debug output.

Especially for debug output a way to replace it with something else than
"" would be handy, for example something like this:


my $foo = "bla";
my $bar;
{
local $^@ = "(undef)";
say "foo=$foo bar=$bar"
}

could print

foo=bla bar=(undef)



> IME undef warnings cause more problems (in
> terms of unnecessary code to work around them) than they solve. A simple
> example would be something like this:
>
> my $verb = $conf{verbose} + $ENV{FOO_VERBOSE} + $opt{v};


I think I would write that as

my $verb = $conf{verbose} // $ENV{FOO_VERBOSE} // $opt{v};

(or probably the other way around).

hp


--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | http://www.velocityreviews.com/forums/(E-Mail Removed) | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      09-19-2013
"Peter J. Holzer" <(E-Mail Removed)> writes:
> On 2013-09-19 01:00, Ben Morrow <(E-Mail Removed)> wrote:
>>
>> Quoth Charles DeRykus <(E-Mail Removed)>:
>>> On 9/18/2013 9:55 AM, Ben Morrow wrote:
>>> >
>>> > I agree. Uninit value warnings were much more useful in the pre-strict
>>> > days when an unexpected undef often meant you had autocreated a variable
>>> > without meaning to. These days "uninitiailisized" is the warning
>>> > category I turn off most often (the next is probably "exiting").
>>>
>>> But, IIUC, I'm not sure how Perl could thread the twisty-turny maze to
>>> warn sanely but not annoyingly.

>>
>> IMHO with properly scoped variables an undef is no more likely to be a
>> mistake than any other value.

>
> I disagree with that estimation. Undef is much more likely to be a
> mistake than any other value because it *means* "no value".


[...]

> Of course that depends on your coding style. If you treat undef like 0
> or an empty string, the warning is just annoying and not helpful at
> all.


If someone treats Perl like C (or C++ or Java, FWIW) with respect to not
otherwise initialized my variables, that is, assigning values to them
even although automatic conversion of 'undef' to a suitable type would
result in the same value, then, 'undef' being used instead of some
'defined value' should rarely[*] ever happen. But Perl isn't C and it
doesn't suffer from the 'bad habit' of making storage locations
available to code while leaking whatever value the most recent user of
this storage location happened to leave there: Variables created with my
are not uninitialized and I consider the fact that they will 'behave
themselves' according to the ways they're used in a feature (and a very
convenient one at that).
[*] There's still the issue that some builtin functions return undef as
'false value' and that using 0 and 1 in order to mean 'true' and 'false'
can be convenient because it is possible to do ordinary arithmetic with
'boolean values', eg (contrived example)

my $results;

$result = call_a();
$result |= call_b();
$result |= call_c();
print("Something worked!\n") if $result;
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      09-19-2013
Charles DeRykus <(E-Mail Removed)> writes:
> On 9/18/2013 6:00 PM, Ben Morrow wrote:
>>
>> Quoth Charles DeRykus <(E-Mail Removed)>:
>>> On 9/18/2013 9:55 AM, Ben Morrow wrote:

> ...
>
>>
>> IMHO with properly scoped variables an undef is no more likely to be a
>> mistake than any other value. IME undef warnings cause more problems (in
>> terms of unnecessary code to work around them) than they solve. A simple
>> example would be something like this:
>>
>> my $verb = $conf{verbose} + $ENV{FOO_VERBOSE} + $opt{v};
>>
>> where silently treating a nonexistent setting as 0 is the right thing to
>> do. With undef warnings turned on that line of code has to become a good
>> bit more complex, to no real advantage.

>
> Maybe it's a personal bias bordering on an OCD affliction, but I'd
> rather see that as: my $verb = ... + ($ENV{FOO_VERBOSE} // 0) + ...
>
> IMO not appallingly tedious and documenting clearly what's going on.


This would in itself warrant some 'clear documentation' a la

# silence 'undefined value' warnings

because on its own, it's just apparently useless code.
 
Reply With Quote
 
Charles DeRykus
Guest
Posts: n/a
 
      09-19-2013
On 9/19/2013 9:55 AM, Rainer Weikusat wrote:
> ...
>>
>> Maybe it's a personal bias bordering on an OCD affliction, but I'd
>> rather see that as: my $verb = ... + ($ENV{FOO_VERBOSE} // 0) + ...
>>
>> IMO not appallingly tedious and documenting clearly what's going on.

>
> This would in itself warrant some 'clear documentation' a la
>
> # silence 'undefined value' warnings
>
> because on its own, it's just apparently useless code.
>


If someone knows it's "useless code", I will wager he/she knows well
the dark kingdom of "uninitialized value". (if not, then some lessons
need to be experienced and having been so, you will not want to comment
on such things ever again

--
Charles DeRykus
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How Can I Increase the Speed of a Large Number of Date Conversions vdicarlo Python 7 06-09-2007 05:26 PM
fstream and number conversions Bill Wayne C++ 2 04-06-2006 05:19 PM
Pointer conversions and Data types conversions vb@gmail.com C Programming 10 08-05-2005 09:51 AM
Automatic build process + automatic NuNit (2 in 1 solution) ASP .Net 1 06-29-2004 04:15 PM
Automatic type conversions Aaron Javascript 1 04-01-2004 10:25 PM



Advertisments