Re: How to define a new value type?

[Daniel Ruoso]

Ter, 2008-09-16 às 20:07 -0500, John M. Dlugosz escreveu:
> Yes, with immutable objects you don't have to clone it.  Multiple copies 
> can be shared.
> By making "value types" as described above also immutable, it formally 
> removes all distinction between reference assignment and value assignment.

I've been presuming that for SMOP, actually...

daniel

Should $.foo attributes without "is rw" be writable from within the class

[Carl Mäsak]

Rakudo and I have a disagreement over this: I expect to be able to
assign to a $.foo attribute in methods within the class, whereas
Rakudo demands the "is rw" attribute in order to do that.

We discussed it a bit on #perl6 today.

 

I only have pragmatic arguments to offer for my point of view:
somehow, it feels like each and every attribute gets an "is rw" as
things stand now. The modifier somewhat loses its meaning... if it
meant "_publicly_ readable/writable", it would only be used for some
variables.

(I may have to rethink the above reason when attribute initialization
(as in "has $.foo = 5") is fully implemented in Rakudo.)

The other argument is that I (for some reason) expect a $.foo variable
to be changeable from within the class -- even when it doesn't have an
"is rw" attribute. It's one of those presuppositions which keeps
biting me when writing classes. I know I could use "$!foo"
consistently, and things will work, but... then I have to remember to
write "$.foo" when declaring the variable and "$!foo" when using it.

Finally, some useless statistics: I count 12 attributes in different
classes in November right now. Out of those, 12 (100%) have the "is
rw" attribute.

// Carl

Re: Should $.foo attributes without "is rw" be writable from within the class

[Moritz Lenz]

Just to bring some of the IRC discussion to the list...

Carl Mäsak wrote:
> Rakudo and I have a disagreement over this: I expect to be able to
> assign to a $.foo attribute in methods within the class, whereas
> Rakudo demands the "is rw" attribute in order to do that.
> 
> We discussed it a bit on #perl6 today.
> 
>  
> 
> I only have pragmatic arguments to offer for my point of view:
> somehow, it feels like each and every attribute gets an "is rw" as
> things stand now. The modifier somewhat loses its meaning... if it
> meant "_publicly_ readable/writable", it would only be used for some
> variables.

There's also the point that you can initialize attributes with the . twigil:

class Stuff { has $.more_stuff = 3 }

So at least visually it appears as though you *can* assign to it. Not
allowing that in other places feels weird.

Yes, I know that $.stuff actually translates to $( self.stuff ), so
without 'is rw' there is no rw accessor generated - but couldn't we just
fake assignment to '$.foo' to actually affect '$!foo'?

> Finally, some useless statistics: I count 12 attributes in different
> classes in November right now. Out of those, 12 (100%) have the "is
> rw" attribute.

This is mostly probably due to non-working constructors. Simple cases
seem to work, though:

12:29 < moritz_> rakudo: class A { has $.b }; my A $x .= new(b => 3);
say $x.b
12:29 < p6eval> rakudo 31204: OUTPUT[3␤]

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: Should $.foo attributes without "is rw" be writable from within the class

[Jonathan Worthington]

Moritz Lenz wrote:

Yes, I know that $.stuff actually translates to $( self.stuff ), so
without 'is rw' there is no rw accessor generated - but couldn't we just fake 
assignment to '$.foo' to actually affect '$!foo'?
  
Why not just assign to $!foo, which is always read/write (since the rw 
affects whether you get an accessor that is read/write or not - $!foo 
refers to the underlying storage location; at least, that's how I 
understand it and what I think Rakudo is implementing today).


Jonathan

Re: Should $.foo attributes without "is rw" be writable from within the class

[Carl Mäsak]

Jonathan (>):
> Why not just assign to $!foo, which is always read/write (since the rw
> affects whether you get an accessor that is read/write or not - $!foo refers
> to the underlying storage location; at least, that's how I understand it and
> what I think Rakudo is implementing today).

I have come to understand that this is an available possibility, yes.
That doesn't mean I like it. :)

My complaint could be pithily summarized as "those are _my_,
attributes, why can't I write to them?"

// Carl

Re: How to define a new value type?

[TSa]

HaloO,

Moritz Lenz wrote:

When you read carefully through S29 you'll notice that most methods in
immutable classes (like Str, List, Int) only return modified copies,
even if they mutate the string in Perl 5.


Great!


(There are some exceptions like Str.substr, which explicitly 'is rw',
and which implies that the object somehow has to gain access to its
container).


Reading the description there I wonder how this is supposed to work.

   our Str multi method substr (Str $string: StrPos $start, Int 
$length)

 is rw is export

   $string ~~ /(barney)/;
   substr($string, $0.from, $0.to) = "fred";

The 'is rw' is on the method but I guess it is foreseen that the
result is stored in $string without preserving the identity of the
string?

   my $a = "His name is barney";
   my $b = $a;

   $a ~~ /(barney)/;
   substr($a, $0.from, $0.to) = "fred";

   say $b; # prints fred?

If substr should get access to the container passed as argument then
the signature should read

   our Str multi method substr (Str $string is rw: StrPos $start,
Int $length) is rw is export

and the docu should say that the result is written into the container
passed in the invocant slot. But the 'is rw' on the invocant has the
drawback that calling with a string literal is precluded.


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: How to define a new value type?

[Moritz Lenz]

TSa wrote:
> The 'is rw' is on the method but I guess it is foreseen that the
> result is stored in $string without preserving the identity of the
> string?

No. It means that the Str object has to get hold of the container in
which it is stored, and store a modified copy in it. If that fails (for
example in "abc".substr(0, 1) = "foo", where "abc" isn't in a container
at all) the write operation will fail.

> my $a = "His name is barney";
> my $b = $a;
> 
> $a ~~ /(barney)/;
> substr($a, $0.from, $0.to) = "fred";
> 
> say $b; # prints fred?

No, the match object needs to be bound to the value (which is immutable)
unless the :rw modifier is present.

> If substr should get access to the container passed as argument then
> the signature should read
> 
> our Str multi method substr (Str $string is rw: StrPos $start,
>  Int $length) is rw is export
> 
> and the docu should say that the result is written into the container
> passed in the invocant slot. But the 'is rw' on the invocant has the
> drawback that calling with a string literal is precluded.

Makes sense to me. (The Int should really be StrLen, but that's only a
minor glitch).

That said, much of S29 needs some loving care...

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: How to define a new value type?

[TSa]

HaloO,

Moritz Lenz wrote:

TSa wrote:

The 'is rw' is on the method but I guess it is foreseen that the
result is stored in $string without preserving the identity of the
string?


No. It means that the Str object has to get hold of the container in
which it is stored, and store a modified copy in it. If that fails (for
example in "abc".substr(0, 1) = "foo", where "abc" isn't in a container
at all) the write operation will fail.


Sorry, I don't understand why you say 'no' and then explain that the
resulting new string is stored in the container. The only container
that could be affected by this is $string in the example. The way for
a method to get access to the container is by declaring a parameter
as rw. Note that this brings the discussion back to the point how rw
is handled in dispatch and if an anonymous container is autovivified
for a naked value. Did you mean the 'no' as answer to the question if
the identity of the string--i.e. its pointer--is preserved? This would
violate the immutability assertion of string values.

Is it generally foreseen that an object knows about the containers
it is stored in? Furthermore is it informed which of these is currently
used as lvalue in a mutating operation? I think both are expensive and
much better handled through the rw declaration of parameters because
at binding time the container is available.


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: Should $.foo attributes without "is rw" be writable from within the class

[TSa]

HaloO,

Carl Mäsak wrote:

My complaint could be pithily summarized as "those are _my_,
attributes, why can't I write to them?"


Perhaps you should change your POV. The correct terminus
technicus for the $.foo twigil variables is 'call the method'
which nicely embeds attribute access into dispatch and makes
base methods future proof with respect to deriving classes.
Your 100% rw observation then to me indicates that OO is more
about data sharing than method dispatch. Note that rw accessors
are particularly difficult to handle in typesafe mode.


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: Chained Modifiers

[Larry Wall]

On Mon, Sep 15, 2008 at 12:16:22PM +0200, Moritz Lenz wrote:
: Chris Davaz wrote:
: > I'm not sure if it's anywhere in the specs, but I was expecting to be able
: > to do this:
: > 
: > .say for =$in unless $foo;
: 
: to quote http://perlcabal.org/syn/S04.html#Loop_statements
: 
: :Looping statement modifiers are the same as in Perl 5 except that, for
: :ease of writing list comprehensions, a looping statement modifier is
: :allowed to contain a single conditional statement modifier:
: :
: :@evens = ($_ * 2 if .odd for 0..100);
: 
: 
: > Where we have multiple modifiers, here "for" and "unless". Is this in the
: > specs? If yes, is it supposed to work in pugs or rakudo? If it's not in the
: > specs can we add it? ;-)
: 
: The "authoritative" source to ask if a piece of text is valid Perl 6 is
: STD.pm. It parses your example, but not as you might expect. Output from
: STD5_dump_match
: 
: :Unknown routines:
: :unless called at 1
: :comp_unit:
: : statementlist:
: :  statement:
: :   EXPR:
: :noun:
: : dotty:
: :  .
: :  dottyop:
: :   methodop:
: :longname:
: : name:
: :  identifier:
: :   say
: :
: :   statement_mod_loop:
: :for
: :modifier_expr:
: : EXPR:
: :  pre:
: :   prefix:
: :=
: :  noun:
: :   variable:
: :sigil:
: : sigil:
: :  $
: :desigilname:
: : longname:
: :  name:
: :   identifier:
: :in
: :
: :  statement:
: :   EXPR:
: :noun:
: : term:
: :  unless
: :  args:
: :
: :   arglist:
: :EXPR:
: : noun:
: :  variable:
: :   sigil:
: :sigil:
: : $
: :   desigilname:
: :longname:
: : name:
: :  identifier:
: :   foo
: :  ;\n
: 
: So 'unless' is actually parsed as a sub call.

That's obviously a bogus parse, and I even know how it happened
(because "unless" is currently considered a terminator that doesn't
distinguish between expression termination and statement termination),
but I'm not sure how to fix it yet.  It's possible that statement
modifiers should be demoted to very-low-precedence operators, but there
are some problems with that that I don't have enough brain to think
through at the moment.

Larry

Re: Should $.foo attributes without "is rw" be writable from within the class

[Larry Wall]

On Wed, Sep 17, 2008 at 01:00:07PM +0200, Carl Mäsak wrote:
: Jonathan (>):
: > Why not just assign to $!foo, which is always read/write (since the rw
: > affects whether you get an accessor that is read/write or not - $!foo refers
: > to the underlying storage location; at least, that's how I understand it and
: > what I think Rakudo is implementing today).
: 
: I have come to understand that this is an available possibility, yes.
: That doesn't mean I like it. :)
: 
: My complaint could be pithily summarized as "those are _my_,
: attributes, why can't I write to them?"

You have to have a way of talking about your own attributes *as if*
they were not your own attributes, and $.foo is that way.  We take
similar 3rd-person viewpoints in natural language too, especially
when talking to kids:

Daddy thinks that's okay, but Amy will have to go ask Mommy too.

In C++ish OO terms, $.foo is always virtual, and $!foo is never
virtual.  The "has" declarator can intuit from a virtual $.foo
declaration that you also need private non-virtual $!foo storage,
but it can't intuit from a non-virtual declaration that you want to
have a public accessor, at least, not without more information than
the sigil provides, which would be uglier.

So $.foo basically says that you want to talk about the slot from
the viewpoint of the actual object, while $!foo says you want to talk
about the slot from the viewpoint of your class.  This is orthogonal
to the actual class boundary, if you ignore the fact that we prohibit
$!foo access from outside the class.  (And, in fact, we could probably
still get at it with a private method from outside the class if there
is an appropriate "trusts" declaration.)

Larry

Re: Parrot 0.7.1 "Manu Aloha" released

[Patrick R. Michaud]

On Wed, Sep 17, 2008 at 08:08:47PM +0200, Reini Urban wrote:
> http://www.parrotcode.org/release/devel still points to 0.7.0

I sent the appropriate patch to the webmaster, but it hasn't
been applied yet (and I lack a commit bit for the parrotcode.org site).
Once that's applied, the url should be fixed.

Pm

Re: Should $.foo attributes without "is rw" be writable from within the class

[John M. Dlugosz]

Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote:

I have come to understand that this is an available possibility, yes.
That doesn't mean I like it. :)

My complaint could be pithily summarized as "those are _my_,
attributes, why can't I write to them?"

// Carl

  
If the accessor were implemented to do something more interesting than 
just assign to the private location, then having some code call the 
accessor and other code access the private location directly with the 
same syntax would be confusing.


For untyped variables, it would be difficult to determine whether 
something is a method call or an attribute on a type that I'm in the 
body of.  Everything would have to be public methods, with a run-time 
check on the scope of the caller to see if it were allowed.   Having a 
different syntax for private access simplifies things.


I'm wondering if the strange wording concerning
 has $x;
with no twigal is meant to take care of this case.  But I don't 
understand what he meant in the Synopses, though I've asked about it 
repeatedly on this list and other places, so I largely ignore that case.


It says something about making $x available as an alias in the lexical 
scope.  In context of what you are asking, maybe that's what it is for.


--John

Re: How to define a new value type?

[John M. Dlugosz]

TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:

Reading the description there I wonder how this is supposed to work.
I don't think S29 is in any shape as a serious design specification.  
Maybe you should not design it that way.  Maybe the left-hand-side is 
"as ref" so it can change the identity of the object it is called on.


our Str multi method substr (Str $string is ref: StrPos $start, Int 
$length)

is rw is export
{

... compute result in a new variable
$string = $result;  # ta-da!
... and what am I supposed to return?  A Str-like object that is a proxy 
to just

the changed substring?
}


As for your other comments in general, I think S29 is NOT in any shape 
as a gospel, and going over the (very preliminary) design is a necessary 
task.


--John

Re: How to define a new value type?

[John M. Dlugosz]

TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:

Sorry, I don't understand why you say 'no' and then explain that the
resulting new string is stored in the container. The only container
that could be affected by this is $string in the example. The way for
a method to get access to the container is by declaring a parameter
as rw. Note that this brings the discussion back to the point how rw
is handled in dispatch and if an anonymous container is autovivified
for a naked value.

For "rw" yes, for "ref" no.




Did you mean the 'no' as answer to the question if
the identity of the string--i.e. its pointer--is preserved? This would
violate the immutability assertion of string values.

Is it generally foreseen that an object knows about the containers
it is stored in? 
Yes.  But it is not generally the case that this is the same container 
as the caller is holding.  Detailed specifications of the meaning of 
'read-only', 'rw', 'copy', and 'ref' and the binding semantics thereof 
need to address this, and address the concerns of efficient implementations.


But off the cuff, I think it is safe to say that 'ref' parameters are 
guaranteed to have the same container that the caller sees, and 'copy' 
parameters are guaranteed not to.  default (read-only) passing may or 
may not at the implementation's whim, but you won't change it so it 
doesn't matter.  'rw' may allow the value to change before binding; 
'ref' never permits that.



--John

Re: Should $.foo attributes without "is rw" be writable from within the class

[Damian Conway]

Larry wrote:


You have to have a way of talking about your own attributes *as if*
they were not your own attributes, and $.foo is that way.  


When thinking about this, it's also important to remember that, in Perl 6, not 
everything with a sigil is automatically writeable. For example:


constant $answer = 42;
$answer = 99;  # Kaboom!

sub foo( $bar ) {
$bar = 42  # Biff!!
}

$baz := 86;
$baz++;# Zowie!!!


Likewise a $.foo attribute defaults to read-only,
whereas a $!foo attribute defaults to read-write.

Damian