I agree with TSa's comments in general. Make "Int" and "Rat" the roles, and
people who don't care about precision-affected semantics can invoke those. Let
the longer names be for the implementing classes, invoked directly by people who
do care about precision-affected semantics. -- Darren Duncan
TSa (Thomas Sandlaß) wrote:
On Friday, 23. October 2009 02:27:00 Darren Duncan wrote:
Thinking further, my interpretation of what you said above is that the
Rational role is now basically saying that a number is represented in terms
of numerator/denominator and that certain operators are supported, but now
it is sounding like the details of whether the operators will produce
Rational results or Num results is now determinable on a per-class basis,
so we may end up working with types like "Rat32", "Rat64", "BigRat" (just
this one being unlimited precision), etc after all.
I believe that the thing people that don't care about the precision
should use in sigs and variable declarations is the Rat role. That is
I think that Rat should be the role that is currently named Rational.
More specific instantiations of that role are then written in my proposed
type signature invocant slot syntax as Rat[Rat64:]. Note that this is
no problem because e.g. 'my Rat $x = 3/4' doesn't require Rat to be an
instantiable class. Actually the class that implements Rat is chosen
by the compiler to be e.g. Rat64. Then there need to be installation time
defaults, command line switches and lexical pragmas to influence this
choice. The second thing that needs to be hookable to different classes
is the handling of overflow and underflow of e.g. Rat64 to either upgrade
to BigRat or wrap the offending value back into Rat64 or switch over
to Num. Then there is the problem of mixed precision cases etc.
Presumably then with the Integer role we'll also have types like "Int32",
"Int64", "BigInt" that do the role and also convert to a Num when their
bounds are exceeded?
Does that sound about right?
Yes. I think there should be an Int role and classes implementing it.
The Int role must be a subrole of Rat. E.g. it adds the bit manipulation
operators which are difficult to define for rationals if not outright
meaningless. This subroling is needed for calling Rat routines with an
Int, of course.
From a Huffman POV the roles for generic integers and rationals must be
short, so the Numeric and Rational roles in S32 are going in the wrong