Re: Synopsis 02: Range objects

2009-08-31 Thread TSa

HaloO,

Jon Lang wrote:

'' and '=' numify their arguments before comparing them.
'lt' and 'le' stringify their arguments before comparing them.
'before' compares its arguments without any coercion.  Note that
there's no equivalent to '='.


This last one is !after and !before is '='.

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


Re: Synopsis 02: Range objects

2009-08-31 Thread Jon Lang
On Mon, Aug 31, 2009 at 12:42 AM, TSa thomas.sandl...@vts-systems.de wrote:

 HaloO,

 Jon Lang wrote:

 '' and '=' numify their arguments before comparing them.
 'lt' and 'le' stringify their arguments before comparing them.
 'before' compares its arguments without any coercion.  Note that
 there's no equivalent to '='.

 This last one is !after and !before is '='.

Only when total ordering is involved.

--
Jonathan Dataweaver Lang


r28146 - docs/Perl6/Spec

2009-08-31 Thread pugs-commits
Author: lwall
Date: 2009-08-31 21:56:55 +0200 (Mon, 31 Aug 2009)
New Revision: 28146

Modified:
   docs/Perl6/Spec/S02-bits.pod
Log:
[S02] remove fossil noticed by pmichaud++


Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-08-31 19:55:44 UTC (rev 28145)
+++ docs/Perl6/Spec/S02-bits.pod2009-08-31 19:56:55 UTC (rev 28146)
@@ -13,8 +13,8 @@
 
 Created: 10 Aug 2004
 
-Last Modified: 24 Aug 2009
-Version: 174
+Last Modified: 31 Aug 2009
+Version: 175
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -633,10 +633,11 @@
 is not required to unless we can do so portably and efficiently.  CNum
 must support the largest native floating point format that runs at full speed.)
 
-CRat supports arbitrary precision rational arithmetic.  However,
-dividing two CInt objects using C infix:/  produces a
-fraction of CNum type, not a ratio.  You can produce a ratio by
-using C infix:div  on two integers instead.
+CRat supports arbitrary precision rational arithmetic.
+Dividing two CInt objects using C infix:/  produces a
+a CRat, which is generally usable anywhere a CNum is usable, but
+may also be explicitly cast to CNum.  (Also, if either side is
+CNum already, C infix:/  gives you a CNum instead of a CRat.)
 
 Lower-case types like Cint and Cnum imply the native
 machine representation for integers and floating-point numbers,



Re: r28113 - docs/Perl6/Spec

2009-08-31 Thread Darren Duncan

pugs-comm...@feather.perl6.nl wrote:

Author: lwall
Date: 2009-08-29 21:06:40 +0200 (Sat, 29 Aug 2009)
New Revision: 28113

Modified:
   docs/Perl6/Spec/S03-operators.pod
Log:
[S03] some tidying of /, %, div, and mod

snip

@@ -699,7 +699,16 @@
 
 $numerator / $denominator
 
-If either operand is of CNum type, converts both operands to CNum

+Performs division of real or complex numbers, returning a real or complex
+number of appropriate type.
+
+If both operands are of integer type, the operator returns the
+corresponding CRat value.

snip


 $numerator div $denominator

snip

-Use of Cdiv on two CInt values results in a ratio of the CRat type.
+Use of Cdiv on built-in integer types is equivalent to taking the
+floor of a real division:
 
+$x div $y == floor($x/$y);

snippage

This is a great move; thanks for this change.

So now writing things like 5/43 in code will DWIM and produce a Rat which 
maintains the intended value exactly, with no floating-point imprecision; and so 
plain 5/43 is now a plain Rat literal, same as 1.23 is.


Similarly its good that by default 'div' can be counted on to result in values 
of the same type as its operands, such as Int,Int--Int.


Generally speaking, the simpler/terse looking numeric operators like / should 
produce exact results from exact inputs where possible, and leave the inexact 
(float) results from exact inputs to more complex/verbose looking operators.


Much appreciated.

-- Darren Duncan


Re: r28113 - docs/Perl6/Spec

2009-08-31 Thread Patrick R. Michaud
On Mon, Aug 31, 2009 at 01:28:08PM -0700, Darren Duncan wrote:
 This is a great move; thanks for this change.

 So now writing things like 5/43 in code will DWIM and produce a Rat which 
 maintains the intended value exactly, with no floating-point imprecision; 
 and so plain 5/43 is now a plain Rat literal, same as 1.23 is.

FWIW, presently the specification somewhat implies that 1.23 is a Num 
literal, and doesn't say anything about it producing a Rat.  
(Yes, conversations on #perl6 have indicated that it may be otherwise, 
but nothing is currently in the spec about it.)  

S02:401 :
One consequence of all this is that you may no longer write a Num as
C42. with just a trailing dot.  You must instead say either C42
or C42.0.

Pm


Re: r28113 - docs/Perl6/Spec

2009-08-31 Thread Darren Duncan

Patrick R. Michaud wrote:

On Mon, Aug 31, 2009 at 01:28:08PM -0700, Darren Duncan wrote:

This is a great move; thanks for this change.

So now writing things like 5/43 in code will DWIM and produce a Rat which 
maintains the intended value exactly, with no floating-point imprecision; 
and so plain 5/43 is now a plain Rat literal, same as 1.23 is.


FWIW, presently the specification somewhat implies that 1.23 is a Num 
literal, and doesn't say anything about it producing a Rat.  
(Yes, conversations on #perl6 have indicated that it may be otherwise, 
but nothing is currently in the spec about it.)  


S02:401 :
One consequence of all this is that you may no longer write a Num as
C42. with just a trailing dot.  You must instead say either C42
or C42.0.


My understanding of Perl 6 to date is that:

Num is effectively a wrapper type that represents a real number some-how and 
that internally its representation could either be an Int or a Rat or something 
that does IEEE floating-point or something else.


That is, any Int or Rat could be exactly matched by a Num but a Num could also 
represent other values that neither an Int nor a Rat can, or that Num can do 
approximate (eg, IEEE float) math while Int and Rat would only do exact math 
(and so not support certain ops that might result in an irrational).


And so, any context that expects a Num will accept any Int or Rat, but the 
reverse may not be true without coersion.


That is, Num will support both exact and inexact numbers, but Int/Rat don't.

Therefore, any literal such as 42.0, because it is exact, should be interpreted 
as a plain Rat, same as 42 is interpreted as a plain Int, but they would still 
work with any context wanting a Num.


I also don't think this interpretation would harm type-based routine dispatch 
since using Rat ops on Rat-compatible inputs would still produce results 
suitable for use in Num contexts, I would think.


-- Darren Duncan


r28150 - docs/Perl6/Spec

2009-08-31 Thread pugs-commits
Author: lwall
Date: 2009-09-01 01:42:06 +0200 (Tue, 01 Sep 2009)
New Revision: 28150

Modified:
   docs/Perl6/Spec/S03-operators.pod
Log:
[S03] steal ::= for readonly binding ala sigs


Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod   2009-08-31 21:06:36 UTC (rev 28149)
+++ docs/Perl6/Spec/S03-operators.pod   2009-08-31 23:42:06 UTC (rev 28150)
@@ -14,8 +14,8 @@
 
 Created: 8 Mar 2004
 
-Last Modified: 29 Aug 2009
-Version: 170
+Last Modified: 31 Aug 2009
+Version: 171
 
 =head1 Overview
 
@@ -1465,14 +1465,28 @@
 
 =item *
 
-C infix:::= , compile-time binding
+C infix:::= , bind and make readonly
 
 $signature ::= $capture
 
-This does the same as C:= except it does it at compile time.  (This implies
-that the expression on the right is also evaluated at compile time; it does
-not bind a lazy thunk.)
+This does the same as C:=, then marks any destination parameters as
+readonly (unless the individual parameter overrides this with either
+the Crw trait or the Ccopy trait).  It's particularly useful
+for establishing readonly context variables for a dynamic scope:
 
+{
+my $*OUT ::= open($file, :w) || die $!;
+doit(); # runs with redirected stdout
+}
+doit(); # runs with original stdout
+
+If Cdoit wants to change C$*OUT, it must declare its own
+contextual variable.  It may not simply assign to C$*OUT.
+
+Note that the semantics of C::= are virtually identical to
+the normal binding of arguments to formal subroutine parameters
+(which also default to readonly).
+
 =item *
 
 C infix:{'='} , Pair constructor



r28151 - docs/Perl6/Spec

2009-08-31 Thread pugs-commits
Author: lwall
Date: 2009-09-01 02:09:52 +0200 (Tue, 01 Sep 2009)
New Revision: 28151

Modified:
   docs/Perl6/Spec/S02-bits.pod
   docs/Perl6/Spec/S06-routines.pod
Log:
[S02,S06] make 'is context' implicit on $*foo variable declarations
orthogonalize readonly semantics to rely on ::= initialization


Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-08-31 23:42:06 UTC (rev 28150)
+++ docs/Perl6/Spec/S02-bits.pod2009-09-01 00:09:52 UTC (rev 28151)
@@ -14,7 +14,7 @@
 Created: 10 Aug 2004
 
 Last Modified: 31 Aug 2009
-Version: 175
+Version: 176
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -2091,7 +2091,8 @@
 user-defined variable from you.  In fact, that's the default, and a
 lexical variable must have the trait Cis context to be
 visible via CCALLER.  (C$_, C$! and C$/ are always
-contextual.) If the variable is not visible in the caller, it returns
+contextual, as are any variables whose declared names contain a C* twigil.)
+If the variable is not visible in the caller, it returns
 failure.  Variables whose names are visible at the point of the call but that
 come from outside that lexical scope are controlled by the scope
 in which they were originally declared as contextual.
@@ -2100,13 +2101,11 @@
 it happens to be declared).  Likewise C CALLER::CALLER::$x 
 depends only on the declaration of C$x visible in your caller's caller.
 
-Any lexical declared with the Cis context trait is by default
-considered readonly outside the current lexical scope.  You may
-add a trait argument of C rw  to allow called routines to
-modify your value.  C$_, C$!, and C$/ are C contextrw 
-by default.  In any event, the declaring scope can always access the
-variable as if it were an ordinary variable; the restriction on writing
-applies only to access via the C* twigil.
+User-defined contextual variables should generally be initialized with
+C::= unless it is necessary for variable to be modified.  (Marking
+dynamic variables as readonly is very helpful in terms of sharing
+the same value among competing threads, since a readonly variable
+need not be locked.)
 
 =item *
 
@@ -2128,26 +2127,25 @@
 semicolons as appropriate to the current operating system.  Usage of
 the C%*FOO form is currently undefined.
 
-Unlike CCALLER, CCONTEXT will see a contextual variable that is declared in
-the current scope, however it will not be writeable via CCONTEXT unless
-declared C is contextrw , even if the variable itself is
-modifiable in that scope.  (If it is, you should just use the bare
-variable itself to modify it.)  Note that C$*_ will always see
-the C$_ in the current scope, not the caller's scope.  You may
-use C CALLER::$*foo  to bypass a contextual definition of C$foo
-in your current context, such as to initialize it with the outer
-contextual value:
+Unlike CCALLER, CCONTEXT will see a contextual variable that is
+declared in the current scope, since it starts search 0 scopes up the
+stack rather than 1.  You may, however, use C CALLER::$*foo 
+to bypass a contextual definition of C$*foo in your current context,
+such as to initialize it with the outer contextual value:
 
-my $foo is context = CALLER::$*foo;
+my $*foo ::= CALLER::$*foo;
 
-The Ctemp maybe used on a contextual variable to perform a similar operation:
+The Ctemp maybe used without an initializer on a contextual variable
+to perform a similar operation:
 
 temp $*foo;
 
 The main difference is that by default it initializes the new
-C$*foo with its previous value, rather than the caller's value.
-The temporized contextual variable takes its read/write policy from
-the previous C$*foo container.
+C$*foo with its current value, rather than the caller's value.
+Also, it is allowed only on read/write contextual variables, since
+the only reason to make a copy of the outer value would be
+because you'd want to override it later and then forget the
+changes at the end of the current dynamic scope.
 
 The CCONTEXT package is primarily for internal overriding of contextual
 information, modelled on how environmental variables work among

Modified: docs/Perl6/Spec/S06-routines.pod
===
--- docs/Perl6/Spec/S06-routines.pod2009-08-31 23:42:06 UTC (rev 28150)
+++ docs/Perl6/Spec/S06-routines.pod2009-09-01 00:09:52 UTC (rev 28151)
@@ -15,8 +15,8 @@
 
 Created: 21 Mar 2003
 
-Last Modified: 24 Jul 2009
-Version: 112
+Last Modified: 31 Aug 2009
+Version: 113
 
 
 This document summarizes Apocalypse 6, which covers subroutines and the
@@ -2669,9 +2669,9 @@
 
 C CALLER::$varname  specifies the C$varname visible in
 the dynamic scope from which the current block/closure/subroutine
-was called, provided that variable is declared with the Cis context
-trait.