On Tue, Mar 15, 2005 at 08:35:54AM -0700, Luke Palmer wrote: > Autrijus Tang writes: > > Currently Pugs numifies hexadecimal and octal strings as if they > > are literals; that means "0x123" and "0o456" all work as expected. > > Is that an acceptable treatment? What about "Inf" and "NaN" in > > numeric context? > > If we follow Perl 5's lead, they all numify to zero (generalizing for > "Inf" and "NaN").
In absence of anything to the contrary in the synopses/apocalypses, string numification should work as it does in Perl 5. In other words, all of the above are zero, and we only numify leading digits as decimal numbers. FWIW, I ran into a similar problem with "Inf" in some PHP programming I did a year or so ago. The question is, how does the string "Information" numify? Just as "8abcde" numifies to 8, PHP took the approach that "Information" numifies to Inf. (Actually, it was worse than this, as someone decided that "Inf" should not numify, so they did a string comparison for "Inf" and had it return zero, thus "Inf" returned zero while "Info" returned Inf. Sigh.) Perl 5's approach, while somewhat controversial, does at least have the advantage of being consistent and reducing the number of surprises. And from a compiler writing perspective, we'll follow the spec as it's written until/unless p6l changes them. > Of course, we could afford to get stricter about numeric prefix > numification, and if we did that, then we could make them work > correctly. Personally, I'd like to see C<+"345abc"> be an error, and > allow a function that extracts a numeric prefix. Instead of an error, how about a warning? Pm
