Re: Beating string numerification to death [Was: Re: the handiness of undef becoming NaN (when you want that)]
On Thu, Oct 25, 2001 at 11:30:00AM +1000, Damian Conway wrote: > > Glenn wrote: > >> > Have I missed anything? >> >> Perhaps you've missed one thing. >> >>[snip] >> >> Perl 6 could provide a pragma to produce a warning on the first >> run-time auto-numerification (compile time would be really hard to >> do), together with a selection of different string numerification >> methods for extracting the numeric values, for a variety of types >> of numeric values. > > I believe this would be covered by the ability to lexically redefine > C. Hmm... this seems dangerous. In general a "numeric context" was imposed in Perl5 by the function that needed it by calling SvNV. The overhead that I see from externalizing that, and forcing: $x + $y To implicitly be: +($x) + +($y) is rather large (three times the stack management, type checking, etc) Is this really what we want? -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF "Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew." -Queen/_'39_
Re: Beating string numerification to death [Was: Re: the handiness of undef becoming NaN (when you want that)]
Aaron Sherman writes: : On Thu, Oct 25, 2001 at 11:30:00AM +1000, Damian Conway wrote: : > : > Glenn wrote: : > : >> > Have I missed anything? : >> : >> Perhaps you've missed one thing. : >> : >>[snip] : >> : >> Perl 6 could provide a pragma to produce a warning on the first : >> run-time auto-numerification (compile time would be really hard to : >> do), together with a selection of different string numerification : >> methods for extracting the numeric values, for a variety of types : >> of numeric values. : > : > I believe this would be covered by the ability to lexically redefine : > C. : : Hmm... this seems dangerous. In general a "numeric context" was imposed : in Perl5 by the function that needed it by calling SvNV. The overhead : that I see from externalizing that, and forcing: : : $x + $y : : To implicitly be: : : +($x) + +($y) : : is rather large (three times the stack management, type checking, etc) : Is this really what we want? That depends on whether operator:+ is truly identified with the internal numerifying function. In the first one, the internal numerify might only be called if numerification is actually needed. In the second one, it would potentally be forced. There are a number of internal functions that may or may not be identified with a particular operator. Some of these show up as non-operator keys in Perl 5's overloading scheme, but there could be others. Even some that are identified with particular operators are called intrinsically in places that don't use the operator in question. In any event, we need to realize that lexically scoped overrides might interfere with overloading. What will you do if $x or $y has its own ideas of what unary + ought to do? Seems to me that we have to make overloading override the lexically scoped operator, if the lexically scoped operator is pretending to be the built-in default numerify. Larry
Re: Beating string numerification to death [Was: Re: the handiness of undef becoming NaN (when you want that)]
Larry Wall wrote: > Aaron Sherman writes: > : On Thu, Oct 25, 2001 at 11:30:00AM +1000, Damian Conway wrote: > : > > : > Glenn wrote: > : > > : >> > Have I missed anything? > : >> > : >> Perhaps you've missed one thing. > : >> > : >>[snip] > : >> > : >> Perl 6 could provide a pragma to produce a warning on the first > : >> run-time auto-numerification (compile time would be really hard to > : >> do), together with a selection of different string numerification > : >> methods for extracting the numeric values, for a variety of types > : >> of numeric values. > : > > : > I believe this would be covered by the ability to lexically redefine > : > C. > : > : Hmm... this seems dangerous. In general a "numeric context" was imposed > : in Perl5 by the function that needed it by calling SvNV. The overhead > : that I see from externalizing that, and forcing: > : > : $x + $y > : > : To implicitly be: > : > : +($x) + +($y) > : > : is rather large (three times the stack management, type checking, etc) > : Is this really what we want? > > That depends on whether operator:+ is truly identified with the > internal numerifying function. In the first one, the internal numerify > might only be called if numerification is actually needed. In the > second one, it would potentally be forced. > > There are a number of internal functions that may or may not be > identified with a particular operator. Some of these show up as > non-operator keys in Perl 5's overloading scheme, but there could be > others. Even some that are identified with particular operators are > called intrinsically in places that don't use the operator in question. > > In any event, we need to realize that lexically scoped overrides might > interfere with overloading. What will you do if $x or $y has its own > ideas of what unary + ought to do? Seems to me that we have to make > overloading override the lexically scoped operator, if the lexically > scoped operator is pretending to be the built-in default numerify. > > Larry So then the lexically scoped operator:+ wouldn't be able to achieve the goal of my suggested implicit numerification warning... the goal being the ability to ensure that there are no implicit numerifications, that all numerifications are done via a selected conversion methed. That sounds like something that would be nice to ensure, in many programs, kind of like -w or use strict, or undef, it helps find things that might be overlooked. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: Beating string numerification to death [Was: Re: the handiness of undef becoming NaN (when you want that)]
On Thu, Oct 25, 2001 at 10:42:15AM -0700, Glenn Linderman wrote:
> So then the lexically scoped operator:+ wouldn't be able to achieve
> the goal of my suggested implicit numerification warning... the goal
> being the ability to ensure that there are no implicit numerifications,
> that all numerifications are done via a selected conversion methed.
That's fine, though. You've already got the warning in perl5:
/* from Perl_sv_2nv in sv.c */
if (SvPOKp(sv) && SvLEN(sv)) {
if (ckWARN(WARN_NUMERIC) && !SvIOKp(sv) && !looks_like_number(sv))
not_a_number(sv);
return Atof(SvPVX(sv));
}
So, you don't need operator:+ to do it.
% perl -wle '$x="x";print sprintf("%d",$x), abs($x)'
Argument "x" isn't numeric in sprintf at -e line 1.
00
Note that once the conversion to number has happened once, it's cached,
and you won't see the warning again. This may or may not meet your
criteria
If you want to warn on conversions even if the number looked numeric, you
could simply add another warning type (e.g. WARN_VERBOSE_NUMERIC) and
then have:
if (SvPOKp(sv) && SvLEN(sv)) {
if (ckWARN(WARN_NUMERIC) && !SvIOKp(sv) &&
(ckWARN(WARN_VERBOSE_NUMERIC) || !looks_like_number(sv)))
not_a_number(sv);
return Atof(SvPVX(sv));
}
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
"Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew." -Queen/_'39_
Re: Beating string numerification to death [Was: Re: the handiness of undef becoming NaN (when you want that)]
Aaron Sherman wrote:
> On Thu, Oct 25, 2001 at 10:42:15AM -0700, Glenn Linderman wrote:
>
> > So then the lexically scoped operator:+ wouldn't be able to achieve
> > the goal of my suggested implicit numerification warning... the goal
> > being the ability to ensure that there are no implicit numerifications,
> > that all numerifications are done via a selected conversion methed.
>
> That's fine, though. You've already got the warning in perl5:
snip
> If you want to warn on conversions even if the number looked numeric, you
> could simply add another warning type (e.g. WARN_VERBOSE_NUMERIC) and
> then have:
>
> if (SvPOKp(sv) && SvLEN(sv)) {
> if (ckWARN(WARN_NUMERIC) && !SvIOKp(sv) &&
> (ckWARN(WARN_VERBOSE_NUMERIC) || !looks_like_number(sv)))
> not_a_number(sv);
> return Atof(SvPVX(sv));
> }
This is the sort of thing I was suggesting, albeit with little knowledge of the
internals you are showing here. And I'm not sure if that takes care of the
case of only reporting the first one (under the theory that you don't need
10,000 warnings per run to help you eliminate all of the implicit
conversions)... so if you write a bunch of code, turn on the warning, the idea
is you are trying to make the code "clean" with respect to implicit string to
numeric conversions.
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Perl 6 - Cheerleaders?
Piers Cawley has written a nice article entitled: "Perl 6 : Not Just For Damians". If the hair on the back of your neck rises when thinking about Perl 6, or even if it doesn't... give it a read. http://www.perl.com/pub/a/2001/10/23/damians.html
Re: Perl 6 - Cheerleaders?
> "GG" == Garrett Goebel <[EMAIL PROTECTED]> writes: GG> Piers Cawley has written a nice article entitled: "Perl 6 : Not GG> Just For Damians". GG> If the hair on the back of your neck rises when thinking about GG> Perl 6, or even if it doesn't... give it a read. GG> http://www.perl.com/pub/a/2001/10/23/damians.html please, just make sure ensign cawley doesn't wear a red shirt. :-) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
