Re: Array variables as formal parameters ???

[John M. Dlugosz]

Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:

On May 23, 2009 11:26:16 pm John M. Dlugosz wrote:
  

 > 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


I think (that I may be getting out of my depth here) that the implementation 
type refers to the container at a deeper level.  That is, Scalar is a Perl 
container and not a Java nor Ruby container, which allows having objects from 
different languages (with their different semantics) in a single application.


  
That's right.  The way I learned it (and I worry about these 
early-learned principles being out of date!) is that using something 
other than the default Scalar class is like "tieing" in Perl 5.  You 
create your own item container that (presumably, following Perl 5's 
names) implements STORE and FETCH.  That could be a foreign variable I 
suppose.


If you wrote a class MyScalar, it could, for example, access the Windows 
"registry" when accessed, or automatically read or update a value from a 
GUI form.



 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';


At first, I thought that this was a aliasing mechanism, but now I worry that 
this is how we have to assign non-Perl variables in a Perl application.  That 
is, the semantics of assignment differ depending the container type.


  
I'm assuming that the container defines what item assignment means.  At 
the very least, it will have the STORE method.  But I want to have 
infix:<=> definable in general without having to make it masquerade as 
an Item Container.





 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.


Rephrasing:  $x is a Perl container holding a Str object whose content 
(value?) is 'Just Another'.
  

Agree.  Scalar is a type of item container.

  

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.


I don't think it has been changed, I think that if you don't understand how 
"tie" is implemented in Perl5 (which is referenced heavily in the synopsis), 
then it is easy to miss the distinctions being made.  (It doesn't help that 
the Implementation type is in the middle of a bunch of "higher level" types).


  
Taken literally, it has:  "$x may be bound to any object, including any 
object that can be bound to any other sigil." 

That means that $x may be bound to an item container containing some 
other object, or may be bound directly to some other kind of object.  
That's my fundamental understanding at this point.  Unless something 
*really*strange* has become of "item container" ... (Larry, please?)

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?


The "List prefix precedence" section of Synopsis 3 says that it returns a list.  
It goes on a bit about t

r26929 - docs/Perl6/Spec

[pugs-commits]

Author: jdlugosz
Date: 2009-05-25 06:10:06 +0200 (Mon, 25 May 2009)
New Revision: 26929

Modified:
   docs/Perl6/Spec/S03-operators.pod
Log:
Code to Callable, clarify "Type" under smart matching (see 


Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod   2009-05-24 19:46:24 UTC (rev 26928)
+++ docs/Perl6/Spec/S03-operators.pod   2009-05-25 04:10:06 UTC (rev 26929)
@@ -12,8 +12,8 @@
 
   Maintainer: Larry Wall 
   Date: 8 Mar 2004
-  Last Modified: 17 May 2009
-  Version: 165
+  Last Modified: 24 May 2009
+  Version: 166
 
 =head1 Overview
 
@@ -3060,8 +3060,8 @@
 
 $_X Type of Match Implied   Match if (given $_)
 === =   ===
-Any   Code:($)  item sub truth  X($_)
-Any   Code:()   simple closure truthX() (ignoring $_)
+Any   Callable:($)  item sub truth  X($_)
+Any   Callable:()   simple closure truthX() (ignoring $_)
 Any   undef undefined   not .defined
 Any   * block signature match   block successfully binds to |$_
 Any   .foo  method truth?X   i.e. ?.foo
@@ -3105,7 +3105,7 @@
 Any   Type  type membership $_.does(X)
 
 Signature Signature sig compatibility   $_ is a subset of X  ???
-Code  Signature sig compatibility   $_.signature is a subset of X  
???
+Callable  Signature sig compatibility   $_.sig is a subset of X  ???
 Capture   Signature parameters bindable $_ could bind to X (doesn't!)
 Any   Signature parameters bindable |$_ could bind to X (doesn't!)
 
@@ -3150,7 +3150,9 @@
 === ===
 List SeqArray
 KeySet KeyBag KeyHash   Hash
-Class Enum Role Type
+named values created with
+  Class, Enum, or Role,
+  or generic type binding  Type
 Subst   Regex
 Char CatStr
 Int UInt etc.   Num
@@ -3208,7 +3210,7 @@
 
 $_  XType of Match Wanted   What to use on the right
 ==  ===     
-CodeAny  item sub truth .ACCEPTS(X) or .(X)
+Callable Any  item sub truth .ACCEPTS(X) or .(X)
 Range   Any  in range   .ACCEPTS(X)
 TypeAny  type membership.ACCEPTS(X) or .does(X)
 Regex   Any  pattern match  .ACCEPTS(X)

Re: Array variables as formal parameters ???

[Henry Baragar]

On May 23, 2009 11:26:16 pm John M. Dlugosz wrote:
>  > 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
>
I think (that I may be getting out of my depth here) that the implementation 
type refers to the container at a deeper level.  That is, Scalar is a Perl 
container and not a Java nor Ruby container, which allows having objects from 
different languages (with their different semantics) in a single application.

>
>  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';
>
At first, I thought that this was a aliasing mechanism, but now I worry that 
this is how we have to assign non-Perl variables in a Perl application.  That 
is, the semantics of assignment differ depending the container type.

>  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.
>
Rephrasing:  $x is a Perl container holding a Str object whose content 
(value?) is 'Just Another'.

> 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.
>
I don't think it has been changed, I think that if you don't understand how 
"tie" is implemented in Perl5 (which is referenced heavily in the synopsis), 
then it is easy to miss the distinctions being made.  (It doesn't help that 
the Implementation type is in the middle of a bunch of "higher level" types).

>
> 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?
>
The "List prefix precedence" section of Synopsis 3 says that it returns a list. 
 
It goes on a bit about the "contortions" that must be done to do this.

>
> 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?
>
Not quite (I think).  As mentioned above, I think that the Scalar is the the 
thing that knows how/which dispatch to use.

> 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 an

Re: Array variables as formal parameters ???

[John M. Dlugosz]

Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:


Good question, since Nil does Positional, as evidenced by rakudo:
> say Nil ~~ Positional
1
Should report this as a bug?

Henry

  



At the very least, it is the most simple test case for Nil.  Should be 
in the test suite.

r26928 - docs/Perl6/Spec

[pugs-commits]

Author: schwarzer
Date: 2009-05-24 21:46:24 +0200 (Sun, 24 May 2009)
New Revision: 26928

Modified:
   docs/Perl6/Spec/S02-bits.pod
   docs/Perl6/Spec/S06-routines.pod
   docs/Perl6/Spec/S19-commandline.pod
   docs/Perl6/Spec/S28-special-names.pod
Log:
[Perl6/Spec] typos

Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-05-24 05:05:44 UTC (rev 26927)
+++ docs/Perl6/Spec/S02-bits.pod2009-05-24 19:46:24 UTC (rev 26928)
@@ -2332,7 +2332,7 @@
 }
 
 This tends to be more efficient since it only has to do one mixin
-at the the end of the block.  Note that the slang declaration has
+at the end of the block.  Note that the slang declaration has
 nothing to do with package C, but only with C<$~Regex>.
 Sublanguages are in their own namespace (inside the current value
 of C<%?LANG>, in fact).  Hence C is modifying one of the local

Modified: docs/Perl6/Spec/S06-routines.pod
===
--- docs/Perl6/Spec/S06-routines.pod2009-05-24 05:05:44 UTC (rev 26927)
+++ docs/Perl6/Spec/S06-routines.pod2009-05-24 19:46:24 UTC (rev 26928)
@@ -145,7 +145,7 @@
 sub swap (*...@_ is rw, *%_ is rw) { @_[0,1] = @_[1,0]; %_ = 
"Q:S"; }
 
 Note: the C container trait is automatically distributed to the
-individual elements by the the slurpy star even though there's no
+individual elements by the slurpy star even though there is no
 actual array or hash passed in.  More precisely, the slurpy star
 means the declared formal parameter is I considered readonly; only
 its elements are.  See L below.

Modified: docs/Perl6/Spec/S19-commandline.pod
===
--- docs/Perl6/Spec/S19-commandline.pod 2009-05-24 05:05:44 UTC (rev 26927)
+++ docs/Perl6/Spec/S19-commandline.pod 2009-05-24 19:46:24 UTC (rev 26928)
@@ -398,8 +398,8 @@
 =item ++CMD --command-line-parser *parser* ++/CMD
 
 Add a command-line processor.  When this option is parsed, it immediately
-triggers an action that affects or replaces the the command-line parser.
-Therefore, it's a good idea to put this option as early as possible in the
+triggers an action that affects or replaces the command-line parser.
+Therefore, it is a good idea to put this option as early as possible in the
 argument list.
 
 =item --check-syntax, -c

Modified: docs/Perl6/Spec/S28-special-names.pod
===
--- docs/Perl6/Spec/S28-special-names.pod   2009-05-24 05:05:44 UTC (rev 
26927)
+++ docs/Perl6/Spec/S28-special-names.pod   2009-05-24 19:46:24 UTC (rev 
26928)
@@ -52,7 +52,7 @@
 the outermost definition of these variables are kept in the C
 package.
 
-The C<$=foo> variables are related to the the C<$?foo> variables
+The C<$=foo> variables are related to the C<$?foo> variables
 insofar as the text of the program is known at compile time, so the
 values are static.  However, the different twigil indicates that the
 variable contains POD data, which is primarily under user control

Re: Array variables as formal parameters ???

[Henry Baragar]

On May 23, 2009 11:31:35 pm John M. Dlugosz wrote:
> 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?  
>
Good question, since Nil does Positional, as evidenced by rakudo:
> say Nil ~~ Positional
1
Should report this as a bug?

Henry

> At its
> simplest, Nil is an object whose Positional personality shows an empty
> list, and that's what the @ variable uses.
>
> --John

-- 

Henry Baragar
Instantiated Software
416-907-8454 x42