Dan Sugalski wrote: > At 01:27 PM 10/11/2001 +0200, RaFaL Pocztarski wrote: > >David Nicol wrote: > > > > > RaFaL Pocztarski wrote: > > > > > > > > First this thread tells me that "123foo" will be 123 in numeric > > > > > context. Now I find myself wondering what "123indigo" evaluates > > > > > to! > > > > > > Also 123. I think that complex numbers, if happening automatically, > > > would only match > > > > > > ($realpart, $imaginarypart) = /^\b(\d*\.?\d+)\+(\d*\.?\d+)i\b/ > > > > > > and "123indigo" does not match that. > > > >I'm not sure how strings like "123indigo" should be handled, but I think > >that imaginary numbers should also be recognized as complex written 10i > >and not only 0+10i. > > Sure. 5 + 10i will probably evaluate to "5" + "10i" and just get > constant-folded at compile time. ;)
That's good to know. :) > >I don't think that imaginary numbers should have > >their own class, like real ones have. > > If we support imaginary numbers, it'll be via a beefed up number type. > Basically the numeric bits will be expanded to have a real and an imaginary > type. (Support for generating imaginary numbers will probably be lexically > scoped. As Hugo's pointed out, suddenly generating imaginaries where we > used to throw errors will probably trip up the unwary) > As for more complex string literals evaluating to numbers, I think that's > something best left to either a user-written sub, or user-written fancy > parser hacks. Up to Larry whether it goes in the base language, but I think > I'd prefer not. If it will be easily possible to run some sub in the place where (with -w) 'Argument "x" isn't numeric in addition (+) at -e line 1.' would be produced, than I can try to write such sub, or a whole module. - RaFaL Pocztarski, [EMAIL PROTECTED]
