On Tue, Jan 02, 2007 at 11:22:22AM -0700, Doug McNutt wrote:
: See FORTRAN conventions to continue.
Well, I don't think FORTRAN implicit conventions will fly anymore,
but basically I think I agree with you that different contexts will
want to warp what they mean by "numeric". Leaving aside the whole mess
of coercion before/after, OO and MD will mostly drive the decision of
which operators to use for existing objects, so the warpage in a given
context would be to select how you want new numeric objects created
(possibly extended to select otherwise tied multis on the basis of
their return type, but this can be viewed as an extension of creation
semantics (unless it also picks coercion)).
Anyway, there's already implicit in Perl 6 that a short name like
Num is really an alias to a longer name like Num-6.0.3-STD. We could
go slightly farther and say that by default Num is an alias to Flt,
and Flt is the alias to the "largest convenient" floating point
representation on this architecture. However, a given lexical scope
could alias Num to anything else it likes, and while that would not
influence the dispatch of any existing objects that came in from
elsewhere, it would influence the operator used to create any new
"Num" objects in the current context. So you could alias Num to Rat
or Fix or Dec or whatever if you like in a given lexical scope.
What this tells me, though, is that we need to be more explicit about
the meaning of type names that are mentioned within role definitions.
When a given role says "this method returns Num" it probably wants
to be generic; that is, it wants to mean the Num defined at the time
the role is composed, not the Num defined where the role is defined.
Whether that policy should be in effect for all type names by default
is a good question. (This is much like the virtualization of type
names within methods that we already mandate, actually.) If so,
then we need to decide the proper notation for "no I really do mean
the Num type in scope where the role is defined". Or the default can
go the other way, and then we'd need some way of saying that we do want
Num to be implicitly parametric without having to pass it every time
to the role composer.
Well, that's mostly just a bunch of thinking out loud. Others should
feel free to do likewise. But at some point it would be nice if the
optimizer can figure out what the user actually expects to happen,
which leads me to think that Num should eventually be mappable to a
less-abstract type at compile time, as long as it matches the desired
constraints of the user. I have this almost-tongue-in-cheek vision
of a numeric type selector that works like modern font selection,
where you say you want
use Num :where<-15-3-*-*-fast-*-*->;
and it gives you a numeric type with the appropriate constraints,
and you don't care whether it's actually implemented as decimal strings,
scaled integers or scaled floating point, as long as you get 15 digits
altogether, 3 exact digits after the decimal point, and it's fast. :)
Larry
