r26922 - docs/Perl6/Spec/S32-setting-library
Author: lwall Date: 2009-05-23 21:04:56 +0200 (Sat, 23 May 2009) New Revision: 26922 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [Temporal.pod] prefer Rat from time() Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-05-23 14:08:51 UTC (rev 26921) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-05-23 19:04:56 UTC (rev 26922) @@ -17,8 +17,8 @@ Daniel Ruoso dan...@ruoso.com Dave Rolsky auta...@urth.org Date: 19 Mar 2009 extracted from S29-functions.pod and S16-IO.pod - Last Modified: 19 Feb 2009 - Version: 2 + Last Modified: 23 Feb 2009 + Version: 3 The document is a draft. @@ -28,11 +28,14 @@ =head2 Time +Note that CNum + =over =item gmtime - our Temporal::DateTime multi gmtime ( Num $epoch? = time() ) + our Temporal::DateTime multi gmtime ( Num $epoch = time() ) + our Temporal::DateTime multi gmtime ( Rat $epoch = time() ) Identical to: @@ -40,7 +43,8 @@ =item localtime - our Temporal::DateTime multi localtime ( Num $epoch? = time() ) + our Temporal::DateTime multi localtime ( Num $epoch = time() ) + our Temporal::DateTime multi localtime ( Rat $epoch = time() ) These functions take an epoch value and return a CTemporal::DateTime object. For Clocaltime the time zone is taken from the local @@ -50,7 +54,7 @@ =item time - our Num time() + our Rat time() Returns an epoch value for the current time.
Re: Array variables as formal parameters ???
On May 22, 2009 06:55:49 pm John M. Dlugosz wrote:
Please take a look at
http://www.dlugosz.com/Perl6/web/passing_examples.html.
I think that in your Example 1, that you may be making too making too much
of a distinction between $a and @a. That is:
sub f2(@y) {...}
has exactly the same signature as
sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type Array.
Hence, @y and $x work the same beneath the surface and there is no extra
level of indirection.
Now that we are viewing parameters as providing constraints rather than
contexts, we get a different view on your Example 2. I made your example
more concrete and ran it through rakudo, yielding:
sub f1 ($x) {say $x.WHAT}; f1(Nil);
Nil()
sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
See, no problems with f2().
Regards,
Henry
I started working through how the detailed behavior of the Capture and
passing rules need to work, and I ran into something that startled me.
There's no examples in S06 of formal parameters, other than the special
*...@slurp form, that is declared with a sigil other than a $. For example,
sub f1 ($x, @y, @z) { ... }
Before I get any farther with this line of thought, I want to know if
I'm missing something important.
Thanks,
--John
--
Henry Baragar
Instantiated Software
416-907-8454 x42
r26923 - docs/Perl6/Spec/S32-setting-library
Author: lwall Date: 2009-05-23 21:10:15 +0200 (Sat, 23 May 2009) New Revision: 26923 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [Temporal.pod] finish previous patch, urgh Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-05-23 19:04:56 UTC (rev 26922) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-05-23 19:10:15 UTC (rev 26923) @@ -28,13 +28,11 @@ =head2 Time -Note that CNum - =over =item gmtime - our Temporal::DateTime multi gmtime ( Num $epoch = time() ) + our Temporal::DateTime multi gmtime ( Num $epoch ) our Temporal::DateTime multi gmtime ( Rat $epoch = time() ) Identical to: @@ -43,7 +41,7 @@ =item localtime - our Temporal::DateTime multi localtime ( Num $epoch = time() ) + our Temporal::DateTime multi localtime ( Num $epoch ) our Temporal::DateTime multi localtime ( Rat $epoch = time() ) These functions take an epoch value and return a CTemporal::DateTime
Re: Array variables as formal parameters ???
Hi,
Little clarification...
Henry Baragar wrote:
I think that in your Example 1, that you may be making too making too much
of a distinction between $a and @a. That is:
sub f2(@y) {...}
has exactly the same signature as
sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type Array.
@y just means the argument must do the Positional role, so it's a
looser constraint than is Array. Equivalent is more like:
sub f2(Positional $x) { }
Thanks,
Jonathan
Re: Array variables as formal parameters ???
Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
I think that in your Example 1, that you may be making too making too much
of a distinction between $a and @a. That is:
sub f2(@y) {...}
has exactly the same signature as
sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type Array.
Hence, @y and $x work the same beneath the surface and there is no extra
level of indirection.
But... $x has an Item container, and @y doesn't !
Now that we are viewing parameters as providing constraints rather than
contexts, we get a different view on your Example 2. I made your example
more concrete and ran it through rakudo, yielding:
sub f1 ($x) {say $x.WHAT}; f1(Nil);
Nil()
sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
Why doesn't +...@y produce 0, not 1? It's an empty list.
And if the argument types are viewed as constraints only, denoting
whether the call is acceptable but not changing anything about it, and
f2 is written as way above, the two functions would produce the same
output. Clearly they're not.
See, no problems with f2().
Good. Thanks.
Re: Array variables as formal parameters ???
On May 23, 2009 04:10:49 pm John M. Dlugosz wrote:
Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
I think that in your Example 1, that you may be making too making too
much of a distinction between $a and @a. That is:
sub f2(@y) {...}
has exactly the same signature as
sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type
Array. Hence, @y and $x work the same beneath the surface and there is
no extra level of indirection.
But... $x has an Item container, and @y doesn't !
From whence did it get its Item container?
Now that we are viewing parameters as providing constraints rather than
contexts, we get a different view on your Example 2. I made your
example
more concrete and ran it through rakudo, yielding:
sub f1 ($x) {say $x.WHAT}; f1(Nil);
Nil()
sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
Why doesn't +...@y produce 0, not 1? It's an empty list.
From rakudo:
sub f2 (@y) {say @y[0]}; f2(Nil);
Nil()
Henry
And if the argument types are viewed as constraints only, denoting
whether the call is acceptable but not changing anything about it, and
f2 is written as way above, the two functions would produce the same
output. Clearly they're not.
See, no problems with f2().
Good. Thanks.
--
Henry Baragar
Instantiated Software
416-907-8454 x42
Re: Array variables as formal parameters ???
Jonathan Worthington jonathan-at-jnthn.net |Perl 6| wrote:
Hi,
Little clarification...
Henry Baragar wrote:
I think that in your Example 1, that you may be making too making
too much of a distinction between $a and @a. That is:
sub f2(@y) {...}
has exactly the same signature as sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type
Array.
@y just means the argument must do the Positional role, so it's a
looser constraint than is Array. Equivalent is more like:
sub f2(Positional $x) { }
Thanks,
Jonathan
I'm finding a difference in how a Positional is bound to a plain item
variable.
If the paramter-argument bond is shown as:
my $x := @A;
how can the Item variable really bond _directly_ to the Positional
object? It doesn't have STORE and FETCH methods. The item variable
forwards methods to the contained item, and a directly-bonded Array does
not.
I think I'm assuming more is (can be) happening at compile time.
The delegation would have to be handled at run-time, rather than as
something the compiler knows about?
Thanks,
--John
Re: Array variables as formal parameters ???
On May 23, 2009 04:19:53 pm John M. Dlugosz wrote:
@y just means the argument must do the Positional role, so it's a
looser constraint than is Array. Equivalent is more like:
sub f2(Positional $x) { }
Thanks,
Jonathan
I'm finding a difference in how a Positional is bound to a plain item
variable.
If the paramter-argument bond is shown as:
my $x := @A;
how can the Item variable really bond directly to the Positional
object? It doesn't have STORE and FETCH methods. The item variable
forwards methods to the contained item, and a directly-bonded Array does
not.
If you think of parameters as being slots and the type information as being
conditions on the objects being put into the slot, then an object is allowed
to be put into a slot only if it meets those conditions. Once the subroutine
starts to run, then it uses the passed in object directly (e.g. the @A), but
with its own name (e.g. $x): no additional containers.
I think I'm assuming more is (can be) happening at compile time.
The delegation would have to be handled at run-time, rather than as
something the compiler knows about?
Defining the constraints happens at compile time, but everything else happens
at run time (including checking the constraints). For example (from rakudo):
sub f1(@y) {say @y.WHAT}; my $x = 1, 2, 3; f1($x); $x = 5; f1($x)
Array()
Parameter type check failed; expected something matching Positional()
but got
something of type Int() for @y in call to f1
in sub f1 (unknown:1)
called from Main (unknown:1)
Regards,
Henry
Regards,
Henry
Thanks,
--John
--
Henry Baragar
Instantiated Software
416-907-8454 x42
Re: Array variables as formal parameters ???
From whence did it get its Item container?
OK, my brain made a wrong turn some time on Tuesday.
Let me review the basics.
From S02:
|$x| may be bound to any object, including any object that can be bound
to any other sigil.
Perl variables have two associated types: their value type and their
implementation type.
Value type = of, implementation type is the type of the container itself.
my $spot is Scalar; # this is the default
From S03:
A new form of assignment is present in Perl 6, called /binding/, used in
place of typeglob assignment. It is performed with the |:=| operator.
Instead of replacing the value in a container like normal assignment, it
replaces the container itself. For instance:
my $x = 'Just Another';
my $y := $x;
$y = 'Perl Hacker';
From S12:
Method calls on mutable scalars always go to the object contained in the
scalar (autoboxing value types as necessary):
$result = $object.doit();
$length = mystring.codes;
Method calls on non-scalar variables just calls the |Array|, |Hash| or
|Code| object bound to the variable:
$elems = @array.elems;
@keys = %hash.keys;
$sig = sub.signature;
Use the prefix |VAR| macro on a scalar variable to get at its underlying
|Scalar| object:
if VAR($scalar).readonly {...}
||
So, if you say
my $x;
then $x is bound to a newly-created Scalar (not worrying about
conflating the name the Role and the concrete type at this point).
my $x = 'Just Another';
Now the item assignment operates on the container, storing the Str
instance within it. $x is bound to a container, and the container
contains (only) one Str instance.
Basically, I was thinking that scalar variables always are bound to item
containers which contain the actual value. In fact, this was originally
drilled into me: containers vs values! That variables always directly
hold some kind of container. I suppose that's been changed at some
point, perhaps long ago, but the synopses didn't dissuade me from that
early belief.
Anyway, as for your (Henry) example from Rakudo:
my $x = 1, 2, 3;
According to the synopses, this should be analogous to the previous
example, where $x now is bound to an item that contains a Capture
containing 3 Ints.
Assuming Capture vs Array is simply out of date implementation, just
focus on the parameter passing. $x is bound to a Scalar. But What I
Mean is for the formal parameter @y to get bound to the item in the
container, the list of Ints.
===How does that happen?
Now back to straightening out my misconceptions about scalars _always_
holding item containers. If $x is bound to an Array, for example, the
compiled code can't be doing the indirection innately.
So it follows that the method forwarding is a property of the object
that the method is originally called on. That is, the Scalar (and any
tied item container implementations) are written to forward all
methods to the contained object. The compiler sees $x.foo() and doesn't
know anything about $x other than that it's some object, so it codes a
message dispatch to it. If $x holds a normal object, the foo method
gets called via the normal dispatching rules. But Scalar implements
something that catches all methods and forwards them to the contained item.
===Right?
That would imply that if a scalar happened to contain another scalar, e.g.
my $x = Scalar.new;
($x is bound to a Scalar which contains a Scalar which contains undef)
then any method called on $x would trigger the same behavior when the
contained object gets it, and be forwarded all the way down, no matter
how many Scalars I nested in this manner.
So how does VAR work? It can't just wrap another level around the
original object to cancel out the automatic indirection. It can't tell
the compiler to generate different code, since the code knows nothing
about this interesting property of scalars. Instead it must return a
proxy that knows how to trigger the actual methods on the scalar,
avoiding the forwarding behavior of normal method calls.
=== Is that right?
Thanks for your help everyone. I hope to give back just as much, once
I've caught back up. In any case, what I learn I will document for all
who come later.
--John
Re: Array variables as formal parameters ???
Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
Why doesn't +...@y produce 0, not 1? It's an empty list.
From rakudo:
sub f2 (@y) {say @y[0]}; f2(Nil);
Nil()
Henry
Uh, @y is an Array of one item, that one item being Nil.
I think the intent was to be an empty list. Nil is not supposed to go
into lists, but to become nothing when used in such a way. Wrapping Nil
into a list when it wasn't a list at all to begin with is totally
missing the point. And where did the wrapping Array come from? At its
simplest, Nil is an object whose Positional personality shows an empty
list, and that's what the @ variable uses.
--John
r26925 - docs/Perl6/Spec
Author: jdlugosz
Date: 2009-05-24 06:26:41 +0200 (Sun, 24 May 2009)
New Revision: 26925
Modified:
docs/Perl6/Spec/S06-routines.pod
Log:
add C tags, fix typos, fix out-of-date \$args to |$args, use Callable (not
Code or others) for the role, change .wrap to return a cookie object to unwrap,
remove the only use of := that wasn't in a declaration (hoping for
single-assign semantics) and show regular assignment for Routine to replace its
do property without changing the Routine object's identity.
Modified: docs/Perl6/Spec/S06-routines.pod
===
--- docs/Perl6/Spec/S06-routines.pod2009-05-24 03:15:01 UTC (rev 26924)
+++ docs/Perl6/Spec/S06-routines.pod2009-05-24 04:26:41 UTC (rev 26925)
@@ -13,8 +13,8 @@
Maintainer: Larry Wall la...@wall.org
Date: 21 Mar 2003
- Last Modified: 9 Apr 2009
- Version: 108
+ Last Modified: 23 May 2009
+ Version: 109
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -144,7 +144,7 @@
sub swap (*...@_ is rw, *%_ is rw) { @_[0,1] = @_[1,0]; %_status =
Q:S; }
-Note: the rw container trait is automatically distributed to the
+Note: the Crw container trait is automatically distributed to the
individual elements by the the slurpy star even though there's no
actual array or hash passed in. More precisely, the slurpy star
means the declared formal parameter is Inot considered readonly; only
@@ -164,8 +164,8 @@
Raw blocks are also executable code structures in Perl 6.
-Every block defines an object of type CCode, which may either be
-executed immediately or passed on as a CCode object. How a block is
+Every block defines an object of type CBlock (which Cdoes Callable), which
may either be
+executed immediately or passed on as a CBlock object. How a block is
parsed is context dependent.
A bare block where an operator is expected terminates the current
@@ -176,7 +176,7 @@
block where a postfix is expected is treated as a hash subscript.
-A bare block where a term is expected merely produces a CCode object.
+A bare block where a term is expected merely produces a CBlock object.
If the term bare block occurs in a list, it is considered the final
element of that list unless followed immediately by a comma or colon
(intervening C\h* or unspace is allowed).
@@ -203,7 +203,7 @@
It also behaves like a block with respect to control exceptions.
If you Creturn from within a pointy block, the block is transparent
to the return; it will return from the innermost enclosing Csub or
-Cmethod, not from the block itself. It is referenced by C?BLOCK,
+Cmethod (et al.), not from the block itself. It is referenced by C?BLOCK,
not C?ROUTINE.
A normal pointy block's parameters default to Creadonly, just like
@@ -262,8 +262,8 @@
thereafter visible everywhere in a program via the GLOBAL package. They
may be made directly visible by importation.
-Global subroutines and variables are normally referred to use of the C*
twigil
-(short for CGLOBAL::).
+Global subroutines and variables are normally referred to by prefixing
+their identifiers with C* (short for CGLOBAL::).
$*next_id = 0;
sub GLOBAL::saith($text) { print Yea verily, $text }
@@ -428,7 +428,7 @@
by an array or hash that knows how to autovivify new elements).
Otherwise the signature fails to bind, and this candidate routine
cannot be considered for servicing this particular call. (Other multi
-candidates, if any, may succeed if the don't require Crw for this
+candidates, if any, may succeed if they don't require Crw for this
parameter.) In any case, failure to bind does not by itself cause
an exception to be thrown; that is completely up to the dispatcher.
@@ -534,14 +534,14 @@
doit %hash{'b'}:p,1,2,3;
The C:p stands for pairs, not positional--the C:p adverb may be
-placed on any Hash access to make it mean pairs instead of values.
-If you want the pair (or pairs) to be interpreted as a named argument,
+placed on any CAssociative access subscript to make it mean pairs instead
of values.
+If you want the pair (or pairs) to be interpreted a named argument,
you may do so by prefixing with the C prefix:| operator:
doit |%hasha:p,1,2,3;
doit |%hash{'b'}:p,1,2,3;
-Pair constructors are recognized syntactically at the call level and
+CPair constructors are recognized syntactically at the call level and
put into the named slot of the CCapture structure. Hence they may be
bound to positionals only by name, not as ordinary positional CPair
objects. Leftover named arguments can be slurped into a slurpy hash.
@@ -770,8 +770,8 @@
a C:a() argument in preference to the first positional argument.
It might seem that performance of binding would suffer by requiring
a named lookup before a positional lookup, but the compiler is able
-to guarantee that subs with known fixed signatures (both onlys and
-multis with protos) translate named arguments to positional
r26926 - docs/Perl6/Spec
Author: jdlugosz Date: 2009-05-24 06:48:07 +0200 (Sun, 24 May 2009) New Revision: 26926 Modified: docs/Perl6/Spec/S02-bits.pod Log: Refer to actual concrete class CRoutine where applicable, replace Code with actual class or role names. Add mention of non-instantiatable roles were classes were listed instead of etc. Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-05-24 04:26:41 UTC (rev 26925) +++ docs/Perl6/Spec/S02-bits.pod2009-05-24 04:48:07 UTC (rev 26926) @@ -12,8 +12,8 @@ Maintainer: Larry Wall la...@wall.org Date: 10 Aug 2004 - Last Modified: 8 May 2009 - Version: 168 + Last Modified: 23 May 2009 + Version: 169 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -583,9 +583,10 @@ Built-in object types start with an uppercase letter. This includes immutable types (e.g. CInt, CNum, CComplex, CRat, CStr, -CBit, CRegex, CSet, CCode, CBlock, CList, +CBit, CRegex, CSet, CBlock, CList, CSeq), as well as mutable (container) types, such as CScalar, -CArray, CHash, CBuf, CRoutine, CModule, etc. +CArray, CHash, CBuf, CRoutine, CModule, and non-instantiable Roles +such as CCallable, CFailure, and CIntegral. Non-object (native) types are lowercase: Cint, Cnum, Ccomplex, Crat, Cbuf, Cbit. Native types are primarily intended for @@ -973,7 +974,6 @@ Complex Perl complex number BoolPerl boolean Exception Perl exception -CodeBase class for all executable objects Block Executable objects that have lexical scopes ListLazy Perl list (composed of immutables and iterators) Seq Completely evaluated (hence immutable) sequence @@ -1609,7 +1609,7 @@ =item * Unlike in Perl 5, the notation Cfoo merely stands for the Cfoo -function as a Code object without calling it. You may call any Code +function as a CRoutine object without calling it. You may call any Code object by dereferencing it with parens (which may, of course, contain arguments): foo($arg1, $arg2); @@ -1659,7 +1659,7 @@ foo:(Int,Num) -It still just returns a CCode object. A call may also be partially +It still just returns the CRoutine object. A call may also be partially applied by using the C.assuming method: foo.assuming(1,2,3,:miceblind)
