Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 06:05 PM 12/12/00 +0000, David Mitchell wrote: > >Also, some of the standard perumations would also need to do some > >re-invoking, eg > >($int - $num) would invoke Int->sub[NUM](sv1,sv2,0), which itself would > >just fall > >through to Num->sub[INT](sv2,sv1,1) - the 0/1 paramter indictating whether > >args > >have been swapped. > >???? > > Nope. int->sub[num](sv1, sv2) would have a function body that would look > something like: > > return(Num->new((NV)sv1->int - get_num(sv2))); > > Basically the integer subtraction routine knows that when passed a numeric > arf that it needs to return a number rather than an integer. The function > will probably be a little more complex than that, but that's the gist of it. Hmm, the problem with this is that all built-in numeric types need to be able to handle all other built-in numeric types. Consider for example if we decide Perl has a builtin arbitrary-precision bigint type. Then the sub[bigint] function within the int vtable needs to know how to perform multiple-precision arithmetic. In this case surely it is better to forward the request to the module that knows about it, and so better preserve encapsulation? > >1. Does the Perl 6 language require some explicit syntax and/or semnatics to > >handle multiple and user-defined numeric types? > >Eg "my type $scalar", "$i + integer($r1+$r2)" and so on. > > Gack. No, not unless we're forced to. This sort of thing should be > invisible. (This isn't C, after all...) I wasnt suggesting that such extra syntax should be part of day-to-day usage (by all means allow perl to automagically 'do the right thing'), but rather I was wondering whether explicit language features should be available to give users fine-grained control when the need it; eg perl5 provides 'use integer', and 'int()' which provide crude control over IVs vs NVs, and if we suddenly have lots of *Vs, do we also need similar but more gernealised syntax????
