Falling back on the "numbers is strings, too" legacy: $a = 100; $b = "000"; $c = ($a _ $b) + 1;
# I'd expect $c == 100001. If I say: $a = 1 _ 000 _ 000; or $a = 1_000_000; DWIM (In scalar context, coerce arguments to strings). (Frankly, I think this is unlikely. But who knows?) If course, if I say: $a = $1_000_000; You can complain. WARNING: test.pm (line 4): Cannot assemble $1_000_000. =Austin --- Aaron Sherman <[EMAIL PROTECTED]> wrote: > On Fri, 2002-01-25 at 12:38, Bryan C. Warnock wrote: > > On Friday 25 January 2002 12:34, Simon Cozens wrote: > > > Should we be allowed to use _ to group numbers, now that _ is > concat? > > > If not _, then what? (if anything?) > > > > Sure, why not? '_' is still a valid character in an identifier. > You'd > > still simply need disambiguating whitespace for concatenation. > > Ok, so the concern is that > > 100_000 > > could be > > (100) _ (000) > > or > > 100000 > > It seems to me that the way around this is to change _ to space for > numbers. Is there ever a reason to have: > > 100 000 > > currently? I can't think of one. Such spaces could easily be noted > and > removed by the tokenizer early on. > > Then again, _ still bothers me as an operator. I think it's because > Perl > has trained me to think of _ as being very flexible and > context-sensitive (ala $_, @_, etc). And so, it seems odd that the _ > operator should have one fixed, narrow purpose. > > __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
