Front page | perl.perl6.language |
Postings from October 2001
From: RaFaL Pocztarski
October 11, 2001 14:16
Message ID: 3BC60C67.CD22807@rfl.pl
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
'Argument "x" isn't numeric in addition (+) at -e line 1.' would be
than I can try to write such sub, or a whole module.
- RaFaL Pocztarski, firstname.lastname@example.org