develooper Front page | perl.perl6.language | Postings from March 2005

Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?

Thread Previous | Thread Next
From:
Larry Wall
Date:
March 26, 2005 17:12
Subject:
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Message ID:
20050327011220.GC22991@wall.org
On Sat, Mar 26, 2005 at 03:13:07AM -0700, Luke Palmer wrote:
: Chip Salzenberg writes:
: > I'm working on enhancing Perl6::Subs[*] to support more parameter
: > traits than just C<is required>.  I have some questions about
: > parameters and traits.  (These questions all apply to pure Perl 6,
: > which I know I won't be able to translate completely, but I want to
: > know which target I'm missing.)
: > 
: >  * Given a parameter C<Array @a>, it's obvious I'm not allowed to
: >    C<push @a,1>, because I didn't say C<is rw>.  But am I allowed to
: >    C<@a[0]++>?  How about C<@a[0][0]++>?  How deep is read-only-ness?
: 
: I believe that the default constant parameters is so we don't have to
: construct lvalues out of our arguments when we call.  So that probably
: means that it's very shallow.
: 
: On the language level, I've been thinking that it would be good to go
: C's way and not allow any parameter modification whatsoever.  The
: problem is that in the presence of methods, we can't tell whether we
: have to lvaluize anymore, so we're back to the Perl 5 trap of lvaluizing
: everything.  

I think only predeclared simple subs are allowed to have "rw" parameters.
Methods can have "is ref" parameters, but those don't require enforced
lvaluehood on the caller end like rw does.

: So if you want things modified, you'd have to pass in a reference.
: Arrays and hashes would not generally have this restriction, since we
: pass references of those guys anyway.

Yes.

: >  * Similarly, how deep is the copy implied by C<is copy>?
: 
: I think it's exactly as deep as read-only-ness.

And both may be exactly as deep as COW.

: >  * Do traits attach syntactically to the variable name, or to the
: >    declaration as a whole?
: > 
: >      variable:     @a is rw of Array
: >                    Array @a is rw
: > 
: >      declaration:  @a of Array is rw
: >                    Array @a is rw
: 
: Well, from this example it seems like `of` should be tighter than `is`.

Traits are not allowed on ordinary rvalues, only on declarations.  "is"
traits always attach to the main declaration.  "of" types always attach
to the container on their immediate left.

: >  * As far as I can tell, the choice of spelling an array parameter
: >    C<Array @a> or C<Array $a> is entirely cosmetic: both @a and
: >    $a are capable of holding an Array reference.  Is there actually
: >    a difference, e.g. in how they handle an undefined value?
: 
: Hmmm... well I think all scalars are allowed to be undef.  Arrays
: aren't.  So yeah, if you give @a undef, it probably gives you [] (or
: croaks, but I don't think that's a good idea).  If you give $a undef, it
: gives you undef.

As I mentioned in my other message, I think we should not assume that
Perl 6 works the same in this regard as Perl 5 does.  There needs to be
something we can return that not only means (), but means also means
"You're hosed! (And here's why.)"  And I think we can make undef mean
that if we make it lazily sensitive to scalar/list context (much like @a
itself can be lazily sensitive to context).

Hmm, maybe it would simpler to just tell everyone undef is a special empty
lazy array that refuses to produce a value no matter how you ask.

Larry

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About