(sorry, I posted it before I finished...) Dan Sugalski wrote:
> 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. I see. So there are two main basic types, real and imaginary, and complex is made of both, and not the imaginary being implemented as complex with zero as real part, as I thought before. I'm a little bit confused, so I'm not sure if I get it right.. :) > As Hugo's pointed out, suddenly generating imaginaries where we > used to throw errors will probably trip up the unwary) Right, but there should be a way to easily process imaginary and complex numbers in strings, however not by default. > 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...' would be produced, than I can try to write such sub, or a whole module. I'm not saying that it should be in the core language, or turned on by default, I'd just like it to be easy to turn on and to use. Now I don't know how exactly to do that, but I would like to, at least, help with the implementation. - RaFaL Pocztarski, [EMAIL PROTECTED]
