Ken Fox <[EMAIL PROTECTED]> wrote:
> > use complex;
> > my $c = 2__3; # 2 + 3i
>
> That's really gross. 2 + 3i is just add(integer(2), complex(0,3)) with
> compile-time constant folding eliminating the add(). I would even go so
> far as to say that 3i is just syntactic sugar for
multiply(integer(3),sqrt(-1))
> with constant folding doing the simplification. The only rules we need are
> the standard ones we must have for constant folding and *one* additional
> macro that says bareword "i" used after a scalar should be re-written as
> "* sqrt(-1)".
Yes I agree that it was a quite gross suggestion! However, this was
just a throw-away comment embedded in part of a more general discussion
about how to handle literals in user-defined numeric types. Now of
course if we have the luxury of deciding that core perl 'knows' about
complex numbers, then of the parser can be made to recognise a pretty
syntax like 3i; however, I was discussing how to handle the more
general case of someone adding a 3rd party scalar numeric type (be it
bigint, bigrat, complex or whatever), not known to the core perl parser,
and how to sensibly handle numeric literals in that case.
It seemed to me that there were two main options.
Firstly, the parser could attempt it's own conversions,
which would (IMHO) be a *bad* thing:
use bigreal;
$x = 1e999999999999999999;
might cause '1e999999999999999999' to be initally converted to a double,
and thus $x probably gets assigned the value Infinity.
On the other hand, the tokeniser/lexer/parser/optimiser or whatever
could be made *not* responsible for literal converations, but instead
just extracts the string of legal numerical constant
characters, and passes it it to some newliteral() class method
associated with the current numeric type in lexical scope (as
specificed by "use xxxxx;"), then it would be up to that numeric type
to make what it will of that type, including possible bodged sematics
like 2__3.
ie the perl code above gets evaluated as
assign(x, bigreal->newliteral("1e999999999999999999")) or thereabouts.
In summary: Perl shouldn't do interpetation of numeric literals, but
should instead delegate it to the numeric class currently in scope.
A similar agument might apply to string literals, meaning that people
can add their own UFTX/UNICODE-XX string types, and still handle literals
sensibly.
An extension of this idea would be for numeric (and string) classes
to provide their own tokeniser routine for literals - assuming appropriate
hooks are available in the main tokeniser. Then within the scope
of 'use complex', the definition of a numeric literal could be locally
extended to allow a trailing 'i' or whatever, without the Perl authors
ever needing to know about it.
On the other hand, some people might think that this way lies madness ....
Dave.
* Dave Mitchell, Operations Manager,
* Fretwell-Downing Facilities Ltd, UK. [EMAIL PROTECTED]
* Tel: +44 114 281 6113. The usual disclaimers....
*
* Standards (n). Battle insignia or tribal totems
