Re: Int/Rat max precision (was Re: r28882 - docs/Perl6/Spec)
HaloO, 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. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
r28921 - docs/Perl6/Spec
Author: lwall Date: 2009-10-27 19:38:55 +0100 (Tue, 27 Oct 2009) New Revision: 28921 Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] make 1 2 3 literals more allomorphic Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-10-27 18:09:45 UTC (rev 28920) +++ docs/Perl6/Spec/S02-bits.pod2009-10-27 18:38:55 UTC (rev 28921) @@ -13,8 +13,8 @@ Created: 10 Aug 2004 -Last Modified: 22 Oct 2009 -Version: 185 +Last Modified: 27 Oct 2009 +Version: 186 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -2787,6 +2787,19 @@ To force a single value to become a list object in item context, you should use C ['a'] for clarity as well as correctness. +For any item in the list that appears to be numeric, the literal is +stored as an object with both a string and a numeric nature, where +the string nature always returns the original string. It is as if +the item is converted to an appropriate numeric type, then a CStr +conversion is mixed in that reproduces the original string (if normal +stringification would produce something else). Hence: + + 1 1/2 6.02e23 1+2i # Int/Str Rat/Str Num/Str Complex/Str + +The purpose of this would be to facilitate compile-time analysis of +multi-method dispatch, when the user prefers angle notation as the +most readable way to represent a list of numbers, which it often is. + The degenerate case C is disallowed as a probable attempt to do IO in the style of Perl 5; that is now written Clines(). (C STDIN is also disallowed.) Empty lists are better written with
Re: Int/Rat max precision (was Re: r28882 - docs/Perl6/Spec)
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.
