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++>? How about C<@a++>? 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
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.
: > * 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.