[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl6-language
Subject:    Re: Int/Rat max precision (was Re: r28882 - docs/Perl6/Spec)
From:       Darren Duncan <darren () darrenduncan ! net>
Date:       2009-10-27 22:55:23
Message-ID: 4AE77A5B.3020704 () darrenduncan ! net
[Download RAW message or body]

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
> direction.
[prev in list] [next in list] [prev in thread] [next in thread]