perl6-users mailing list
Hi everyone, We setup a perl6-users mailing list. It'll be our first list for perl6 "users" (as opposed to implementors). Of course I hope the implementors will join too and help the users. :-) Email [EMAIL PROTECTED] to subscribe. It will show up on the nntp server as perl.perl6.users within a few hours and eventually on Google Groups too (if you run a popular-ish NNTP server and want a read-only feed, send me a mail off-list). - ask -- http://askask.com/ - http://develooper.com/
Re: lvalues and "is rw" parameter passing
Chip Salzenberg wrote: > > All that's needed is for the Perl 6 implementors to create a perl6;Scalar > container that's more or less a translucent reference: It will handle > assignment by switching to a new value, but it will handle most other > operations by delegating to the value it currently holds. > > > Audrey, is this basically your plan for (scalar) containers? If not, what is? Yes, that is basically my plan. Thanks, Audrey signature.asc Description: OpenPGP digital signature
Re: lvalues and "is rw" parameter passing
On Wed, May 17, 2006 at 07:54:21AM +0800, Audrey Tang wrote:
> Chip Salzenberg wrote:
> > On Tue, May 16, 2006 at 03:24:20PM -0500, Patrick R. Michaud wrote:
> sub foo($x is rw) {
> $x = new SomeClass
> }
>
> @z = 0..2;
> foo( @z[1] );
>
> The assignment does do what Patrick suggests.
As a Perl 6 user: "Good." :-)
> If you change the assignment to a binding, it acts on the lexical pad of
> &foo, changing the object $x points to, and does _not_ touch @z.
Understood. [Remainder of helpful & detialed description of := vs. =
elided.]
> now suppose we assign into $x; that invokes the Scalar object's
> assignment method:
Interesting.
So it seems that "is rw" will work fine w/o Parrot changes.
All that's needed is for the Perl 6 implementors to create a perl6;Scalar
container that's more or less a translucent reference: It will handle
assignment by switching to a new value, but it will handle most other
operations by delegating to the value it currently holds.
Audrey, is this basically your plan for (scalar) containers? If not, what is?
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: lvalues and "is rw" parameter passing
Chip Salzenberg wrote:
> On Tue, May 16, 2006 at 03:24:20PM -0500, Patrick R. Michaud wrote:
sub foo($x is rw) {
$x = new SomeClass
}
@z = 0..2;
foo( @z[1] );
>
> I sympathize with your desire for an answer, but it's probably a good idea
> for you to get the sample code and desired behavior right in all its Perl 6
> details before we go further. As for me, I'm not sure what the "=" in &foo
> is *supposed* to do in Perl 6. I think it does what you suggest, but I'm
> not entirely sure. And I'm even less sure whether ":=" in the same place
> would be legal, and if it were, what it would mean.
(Cc'ing perl6-compiler.)
The assignment does do what Patrick suggests.
If you change the assignment to a binding, it acts on the lexical pad of
&foo, changing the object $x points to, and does _not_ touch @z.
$x := new SomeClass;
$x = 123; # invalid, unless SomeClass handles "="
Note that even when $x =:= @z[1], these two lines are still different:
$x := new SomeClass; # an action on the pad
@z[1] := new SomeClass; # an action on @z
After either of the two operations, $x and @z[1] will no longer point to
the same thing. Conceptually, we say that binding is working on an
"upper level" than assignment. As a concrete example:
my @z = 0, 1, 2;
my $x := @z[1];
The layout now looks like the same as Patrick's example above (except
there is only one pad here):
Pad (::MY) -- <$x> Scalar -- Int (1)
-- <@z> Array -- [0] Scalar -- Int (0)
-- [1] Scalar -- Int (1)
-- [2] Scalar -- Int (2)
the $x Scalar and @x[1] Scalar are the same object:
$x =:= @z[1]; # True
variable($x).id == variable(@z[1]).id # True
now suppose we assign into $x; that invokes the Scalar object's
assignment method:
$x = new SomeClass;
Pad (::MY) -- <$x> Scalar -- SomeClass
-- <@z> Array -- [0] Scalar -- Int (0)
-- [1] Scalar -- SomeClass
-- [2] Scalar -- Int (2)
so both @z[1] and $x now contains an object of SomeClass. Now suppose
we bind $x away:
$x := new AnotherClass;
Pad (::MY) -- <$x> AnotherClass
-- <@z> Array -- [0] Scalar -- Int (0)
-- [1] Scalar -- SomeClass
-- [2] Scalar -- Int (2)
as you can see, $x and @z[1] no longer point to the same thing, as we
changed what <$x> means to the Pad. We can bind @z[1] away in the same
fashion:
@z[1] := 3.14159;
Pad (::MY) -- <$x> Scalar -- SomeClass
-- <@z> Array -- [0] Scalar -- Int (0)
-- [1] Num (3.14159)
-- [2] Scalar -- Int (2)
Note how that effectively makes @z[1] immutable:
@z[1] = 123; # error: Num doesn't handle assignment!
> I infer that in Perl 6, assigning '1' is at root the same problem as
> assigning 'new SomeClass', because morphing is *not* assumed to be an
> ability of most types, so it may be necessary to store a new value of a
> completely new type in the given target container.
Yes. Exactly.
Audrey
signature.asc
Description: OpenPGP digital signature
[svn:perl6-synopsis] r9261 - doc/trunk/design/syn
Author: larry Date: Tue May 16 15:57:12 2006 New Revision: 9261 Modified: doc/trunk/design/syn/S02.pod Log: s/Tuple/Seq/ Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podTue May 16 15:57:12 2006 @@ -354,7 +354,7 @@ Built-in object types start with an uppercase letter. This includes immutable types (e.g. C, C, C, C, C, C, C, C, C, C, B, C, -C), as well as mutable (container) types, such as C, +C), as well as mutable (container) types, such as C, C, C, C, C, C, etc. Non-object (native) types are lowercase: C, C, C,
Re: lvalues and "is rw" parameter passing
On Tue, May 16, 2006 at 03:24:20PM -0500, Patrick R. Michaud wrote:
> On Tue, May 16, 2006 at 09:00:17AM -0700, Chip Salzenberg wrote:
> > On Fri, Apr 14, 2006 at 06:17:01PM -0500, Patrick R. Michaud wrote:
> > > How would you envision doing something like the following
> > > Perl 6 in PIR?
> > >
> > > sub foo($x is rw) {
> > >$x = new SomeClass
> > > }
> > >
> > > @z = 0..2;
> > > foo( @z[1] );
> >
> > I suspect that this problem is quite deep and may require significant
> > changes to Parrot. But I don't want to jump to conclusions, because my Perl
> > 6 is not as good as yours.
>
> It's entirely possible my Perl 6 isn't accurate here, either.
> My intent is that after the call to 'foo', @z[1] should be an
> instance of SomeClass because $x was a rw parameter in foo.
I sympathize with your desire for an answer, but it's probably a good idea
for you to get the sample code and desired behavior right in all its Perl 6
details before we go further. As for me, I'm not sure what the "=" in &foo
is *supposed* to do in Perl 6. I think it does what you suggest, but I'm
not entirely sure. And I'm even less sure whether ":=" in the same place
would be legal, and if it were, what it would mean.
Furthermore, I think you'll need to ask Audrey or Larry about the
implications of the Perl 6 container/value dichotomy on your example. Now
that Perl 6 scalars consist of containers that hold values, every Perl 6
scalar is made up of two distinct PMCs[*], so it seems to me that you're
likely to be able to do what you want with current Parrot.
[*] except for the containers that can't hold PMCs, e.g. C.
The reason I think you need to do this first is that "is rw" with "=" is a
common case, while supporting ":=" probably isn't. As an extreme
possibility, if "is rw" makes a deep enough alias to amount to call-by-name,
Perl 6 may need to pass all "is rw" parameters as implicit references, and
dereference them automatically and invisibly at each use.
Look before I leap.
> AFAIK "foo"(z[1]) isn't a valid call in Parrot.
I meant that to be the equivalent of
$P0 = z[1]
"foo"($P0)
> I suppose it could be made to be valid. But even then, I wonder
> about:
>
> .sub foo
> .param pmc x
> $P0 = new .SomeClass
> x = $P0
> .return ()
> .end
>
> [... ] Assuming that "assign" was meant here [...]
It was, mea culpa.
> I think [changing '= new SomeClass' to '= 1' is] OK only if we change the
> naive PIR to use 'assign' instead of 'set', and then only because $x
> happens to already be an Int when foo is called. To bring it down to base
> types, what about:
>
> sub foo($x is rw) { $x = 'hello'; }
>
> my $y = 3;
> foo($y);
>
> Can Parrot make this work if the Int type (.Integer) isn't automatically
> morphing into a Str (.String)?
I infer that in Perl 6, assigning '1' is at root the same problem as
assigning 'new SomeClass', because morphing is *not* assumed to be an
ability of most types, so it may be necessary to store a new value of a
completely new type in the given target container.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: lvalues and "is rw" parameter passing
On Tue, May 16, 2006 at 09:00:17AM -0700, Chip Salzenberg wrote:
> On Fri, Apr 14, 2006 at 06:17:01PM -0500, Patrick R. Michaud wrote:
> > How would you envision doing something like the following
> > Perl 6 in PIR?
> >
> > sub foo($x is rw) {
> >$x = new SomeClass
> > }
> >
> > @z = 0..2;
> > foo( @z[1] );
>
> I suspect that this problem is quite deep and may require significant
> changes to Parrot. But I don't want to jump to conclusions, because my Perl
> 6 is not as good as yours.
It's entirely possible my Perl 6 isn't accurate here, either.
My intent is that after the call to 'foo', @z[1] should be an
instance of SomeClass because $x was a rw parameter in foo.
(For clarity I probably should've written @z = (0, 1, 2);
instead of @z = 0..2; above, I forgot that ranges are lazy in Perl 6.
Let's treat it as written that way for the remainder of this thread.)
I don't think the naive PIR translation (complete copy at bottom of message)
expresses the intent, at least not within current Parrot capabilities. In
particular, AFAIK "foo"(z[1]) isn't a valid call in Parrot.
I suppose it could be made to be valid. But even then, I wonder
about:
.sub foo
.param pmc x
$P0 = new .SomeClass
x = $P0
.return ()
.end
IIUC, the x = $P0 line translates into a "set" opcode -- i.e.,
it causes the local x pmc register to rebind to the SomeClass object,
but doesn't affect the object x was previously bound to. So that
doesn't seem to do it.
Assuming that "assign" was meant here, as in
.sub foo
.param pmc x
$P0 = new .SomeClass
assign x, $P0
.return ()
.end
this would seem to imply that pmc x is something that knows to
morph its type into a .SomeClass object, regardless of what x (@z[1])
was when sub foo was invoked.
> I've made a naive translation of the above code
> into PIR below. Does it correctly express the intent of the above code? If
> not, is it possible to express this problem in Perl 5?
Yes, somewhat, since parameters are already passed rw in Perl 5:
#!/usr/bin/perl
use Digest;
sub foo { $_[0] = Digest->new('MD5'); }
@z = (0, 1, 2);
foo($z[1]);
print "@z\n"; # outputs "0 Digest::MD5=Scalar(...) 2\n"
The key question revolves around foo changing the second element of
@z to no longer be an Int.
Going back to the original Perl 6 code, I'll note that the problem
exists for scalars as well -- i.e., after
sub foo($x is rw) { $x = new SomeClass; }
my $y = 3;
foo($y);
the $y lexical is a SomeClass object and not an Int. So, how
does .sub foo make that happen? (I posed the array version simply
because it seems to cover more of the issues involved.)
> While you're at it, could you explain how the above code is problematic
> while, presumably,
> $x = 1
> is OK? (... or is it?)
I think it's OK only if we change the naive PIR to use 'assign'
instead of 'set', and then only because $x happens to already be
an Int when foo is called. To bring it down to base types,
what about:
sub foo($x is rw) { $x = 'hello'; }
my $y = 3;
foo($y);
Can Parrot make this work if the Int type (.Integer) isn't
automatically morphing into a Str (.String)?
Thanks,
Pm
Full Naive PIR translation from Chip:
>
> .sub main :main
> .local pmc z i
> z = new .ResizablePMCArray
>
> # assignment of z[0] and z[2] omitted for brevity
> i = new .Integer
> i = 1
> z[1] = i
>
> "foo"(z[1])
> .end
>
> .sub foo
> .param pmc x
> $P0 = new .SomeClass
> x = $P0
> .return ()
> .end
[svn:parrot-pdd] r12706 - in trunk: . docs docs/pdds/clip src/ops src/pmc t/pmc
Author: chip
Date: Tue May 16 13:27:30 2006
New Revision: 12706
Modified:
trunk/docs/pdds/clip/pdd02_vtables.pod
trunk/docs/pdds/clip/pdd15_objects.pod
Changes in other areas also in this revision:
Modified:
trunk/docs/ROADMAP.pod
trunk/docs/vtables.pod
trunk/src/ops/ops.num
trunk/src/ops/pmc.ops
trunk/src/pmc/default.pmc
trunk/src/pmc/parrotobject.pmc
trunk/src/pmc/ref.pmc
trunk/src/pmc/sharedref.pmc
trunk/t/pmc/prop.t
trunk/vtable.tbl
Log:
DELETED: object initialization with simultaneous setting of properties, via
the init_pmc_props() vtable method and its associated opcodes.
Documented: init_pmc() takes an arbitrary initializer with a PMC-specific
meaning, rather than the complicated mess that had been partly documented
but never actually used.
Modified: trunk/docs/pdds/clip/pdd02_vtables.pod
==
--- trunk/docs/pdds/clip/pdd02_vtables.pod (original)
+++ trunk/docs/pdds/clip/pdd02_vtables.pod Tue May 16 13:27:30 2006
@@ -50,29 +50,11 @@
=item void init_pmc(INTERP, PMC* self, PMC* initializer)
-This form of the init method takes a single initializer parameter. The
-initializer is an array that contains keys and values. The meaning of the keys
-and their corresponding values is left up to the PMC.
+This form of PMC initialization takes a single initializer parameter. The
+initializer is an arbitrary PMC whose contents are interpreted by the target
+PMC in an arbitrary fashion. Passing NULL is permitted by Parrot.
-Keys are either strings or integers. If strings, the PMC is responsible for
-figuring out what the string represents. If integers, it means the meaning has
-been pre-figured based on meta-information from the class.
-
-For example, if a class has the known properties "Size", "Dimension" and
-"Color", they may be assigned the values 100, 101, and 102. If the creator of
-the PMC knows enough about the class to make the translation to numbers it may;
-otherwise, the raw strings may be used. So, for the declaration:
-
- my @foo Size(12), Dimension(3), Color("Green");
-
-the init array may be [100, 12, 101, 3, 102, "Green"] or ["Size", 12,
-"Dimension", 3, "Color", "Green"]. Note that, in all cases, the array is an
-array of PMCs. (So you get either an int PMC or a string PMC in the list of
-keys).
-
-=item void init_pmc_props(INTERP, PMC* self, PMC* initializer, PMC* properties)
-
-XXX: what does this do?
+NOTE: It is strongly suggested that init_pmc(NULL) be equivalent to init().
=item void morph(INTERP, PMC* self, INTVAL type)
Modified: trunk/docs/pdds/clip/pdd15_objects.pod
==
--- trunk/docs/pdds/clip/pdd15_objects.pod (original)
+++ trunk/docs/pdds/clip/pdd15_objects.pod Tue May 16 13:27:30 2006
@@ -539,7 +539,12 @@
=item __init_pmc
-=item __init_pmc_props
+Alternative entry point called when object is first created. Accepts a PMC
+parameter used to initialize the given object. Interpretation of the PMC is
+PMC-specific.
+
+NOTE: It is strongly suggested that init_pmc(PMCNULL) be equivalent to
+init(), though there will of necessity be exceptions.
=item __morph
Re: ACID transactions for in-memory data structures
On 5/15/06, Audrey Tang <[EMAIL PROTECTED]> wrote: Rob Kinyon wrote: > I'm pretty sure it wouldn't be very feasible to do this natively in > P5. But, would it be possible to do it natively in P6? As in, > supported within the interpreter vs. through some sort of overloading. Look at "is atomic" in S17draft, and Software Transaction Memory in general? Would there be a way for me to say "Yes, I understand that Perl may not generically understand how to revert this outside resource, such as a database, but I do." and do a catch-type block for the revert? Rob
[PMC] init_pmc_props() DEPRECATED; init_pmc() GENERALIZED; beware set_pointer()
The documentation of the init_pmc() vtable method (a.k.a. '.sub __init_pmc' for ParrotObjects) is inconsistent. In some places, the single PMC's interpretation is simply described as "pmc-dependent"; in other places, it's described as a set of properties, possibly keyed by number instead of name [!]. The former usage is obviously more ... useful ... and will be consistently documented as correct. Meanwhile, I can't find any users of init_pmc_props (a.k.a. '.sub __init_pmc_props' for ParrotObjects) so I'm going to deprecate it. In a third topic, I seem to recall that some PMCs are using set_pointer() as a dodge to avoid proper initialization, i.e. init() followed by set_pointer() instead of a proper init_pmc(). If I'm remembering this correctly, it's a bad idea. In fact ... I'm not entirely sure I like that set_pointer() even exists, since it's impossible to cleanly re-implement from PIR for a ParrotObject. So I'll be reviewing whether it can go away. -- Chip Salzenberg <[EMAIL PROTECTED]>
[ARCH] Classes moving into namespaces; parrot reserved namespace
There's is a problem with the naming of classes and their associated namespaces that must be addressed. Creating Parrot classes currently requires _typed_ namespaces, that is, namespaces where more than one object can have the same fully-qualified name. Parrot's default namespace allows that there be both a namespace and another object (often a class) with the same name. Namespace typing is a fine feature for any given HLL to use, but a basic function of Parrot like class creation must not depend on it. There's also a more subtle flaw: a violation of the principle of least repetition. Given a class (let's say it's a Perl 6 class) named foo::bar, two distinct Parrot entities, both named foo;bar, must be created to implement it: the class object, and its method namespace. This is weak design. For example, it makes removing (or renaming) a class into a multi-step operation. So here are the changes I'm planning to PDD today: (1) By default, the implementation objects of a class foo;bar will consist of: a namespace named foo;bar a class object named foo;bar;__parrot_class (2) HLLs will be asked to never use names matching /^__parrot/ for any purpose. This edict would apply to HLL maintainers only. (None of us can be held responsible for the actions of HLL users.) It would also be a more general rule that we could use to drop other Parrot implementation objects (e.g. thunks or things we might need to make MMD work) into user-controlled namespaces. (3) Parrot default namespaces will be entirely untyped. That is, in a Parrot default namespace, there will only ever be a maximum of one object with a given fully qualified name. ==[ Entering alternative universe ]=== An alternativeq design has the _classes_ being the visible objects, with namespaces being externally anonymous and only visible by indirecting through the classes that use them. This alternative is, of course, entirely feasible, but it has downsides. First, some namespaces would become more equal than others: class namespaces, vs. namespaces unrelated to classes, would require a new technique for lookup, or else some convention that classes would provide a namespace interface; neither of these options appeals, especially since the base namespace interface is 'hash', and I doubt that classes responding to the hash interface meets anybody's idea of "elegant". Second (and much less worrisome), users would have to create class objects before defining any methods for them. ==[ Normality restored ]== ==[ Anything you can't handle is now your own problem ]=== -- Chip Salzenberg <[EMAIL PROTECTED]>
