On Sat, Jan 09, 2010 at 12:51:42AM +0100, Carl Mäsak wrote:
: pugscommitbot, channeling Larry (>):
: > [...]
: > +    $x = "Today" but Tue;       # $x.Day is read-only
: > +    $x = "Today" but Day;       # $x.Day is read-write
: > +
: > +Mixing in a specific enum object implies only the readonly accessor.
: > +
: >     $x = "Today" but Tue;
: >
: > -really means something more like:
: > +really means something like:
: >
: > -    $x = "Today";
: > -    $x does Has[Day, '$.Day', (:rw), { Tue }];
: > +    $x = "Today".clone;
: > +    $x does anon role { method Day { Day::Tue } };
: > [...]
: 
: I'm not 100% clear on when this 'anon' keyword is to be applied and when not.

Syntactically, it is allowed anywhere 'my' is allowed.

: Why is it 'anon role' for anonymous roles but not 'anon enum' for
: anonymous enumerations?

The enum and constant declarators used to be parsed more like 'my',
but they have recently moved in the direction of filling the type
declarator slot, independent of scoping declarators such as 'my'.
(The subset declarator now also relies on <trait>* to parse any 'of'
instead of special casing it, so that it can also detect an extra
'of' type using the same validator.)  Anyway, that transition was not
complete, so I had to patch up STD a bit yesterday.  Hopefully the
type-like declarators are more consistent now.

: If 'anon' isn't strictly required before 'enum', is it still allowed?

Yes, it is optional, and should work everywhere 'my' does now.

As a declarator, 'anon' has several effects.  Syntactically, it allows you
to put an 'of' type before any non-scope_declarator that wants an 'of'
type, including enum, constant, subset, sub, multi, etc.

    my $x = anon Int subset Even where * !% 2;
    my $y = anon Sink sub log($x) { say $*LOG: $x };
    my $z = anon uint2 enum <Zero One>;

(Arguably, some of these would be more readable with an explicit 'of'
or 'returns' trait, but we like to keep the possibilities open.)

Since you can optionally give a name for most declarators, the 'anon'
declarator also has the effect of throwing away the name if you happen
to have supplied one:

    my $foo = anon role Foo {...};

So the anonymous role thinks its name is 'Foo', but that name is not
put into any symbol table.

And finally, while you can say something like:

    my $x = role {...}

it may be better self-documentation to say:

    my $x = anon role {...}

just to tell the reader that the omission of the name was intentional,
or to make the semantic nature of the beastie more clear up front, if
the other form makes you do mental backtracking.

Larry

Reply via email to