Aaron Sherman writes: : On Thu, Oct 25, 2001 at 11:30:00AM +1000, Damian Conway wrote: : > : > Glenn wrote: : > : > > > Have I missed anything? : > > : > > Perhaps you've missed one thing. : > > : > > [snip] : > > : > > Perl 6 could provide a pragma to produce a warning on the first : > > run-time auto-numerification (compile time would be really hard to : > > do), together with a selection of different string numerification : > > methods for extracting the numeric values, for a variety of types : > > of numeric values. : > : > I believe this would be covered by the ability to lexically redefine : > C<operator:+($)>. : : Hmm... this seems dangerous. In general a "numeric context" was imposed : in Perl5 by the function that needed it by calling SvNV. The overhead : that I see from externalizing that, and forcing: : : $x + $y : : To implicitly be: : : +($x) + +($y) : : is rather large (three times the stack management, type checking, etc).... : Is this really what we want?
That depends on whether operator:+ is truly identified with the internal numerifying function. In the first one, the internal numerify might only be called if numerification is actually needed. In the second one, it would potentally be forced. There are a number of internal functions that may or may not be identified with a particular operator. Some of these show up as non-operator keys in Perl 5's overloading scheme, but there could be others. Even some that are identified with particular operators are called intrinsically in places that don't use the operator in question. In any event, we need to realize that lexically scoped overrides might interfere with overloading. What will you do if $x or $y has its own ideas of what unary + ought to do? Seems to me that we have to make overloading override the lexically scoped operator, if the lexically scoped operator is pretending to be the built-in default numerify. Larry
