The pair constructor seems to be in a different category than the other
quoting operators since the expression that it quotes must look like an
identifier:
https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Grammar.nqp#L1776
token fatarrow {
<key=.identifier> \h* '=>' <.ws> <val=.EXPR('i<=')>
}
Brian
On Saturday, September 10, Aaron Sherman wrote:
> You cannot currently define your own quote-like operators. That will come
> with true macros (though you could certainly do it via a slang...
> everything is possible with a slang). But they are operators. Not only are
> they operators, but they nest other operators. vis:
>
> say "These are my args: {@*ARGS.join(',')}";
>
>
>
>
> Aaron Sherman, M.:
> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
> Toolsmith, developer, gamer and life-long student.
>
>
> On Fri, Sep 9, 2016 at 8:59 PM, Joseph Garvin <joseph.h.gar...@gmail.com>
> wrote:
>
> > Wait, quotes *are an operator* ? If so how would I define them? If the
> > operator returns string, what is the type of its argument? If so that's
> > even stranger -- most languages they're a hard coded bit of syntax -- the
> > closest thing I can think of is in C++11 you can add your own string
> > literal types, but even with that the closest you could get would be:
> >
> > "Foo"_mytype => bar
> >
> > You still wouldn't be able to omit the quotes.
> >
> > On Sep 9, 2016 12:12 AM, "Aaron Sherman" <a...@ajs.com> wrote:
> >
> >> it is combining too many new things at once:
> >>
> >>
> >> Well, it is meant to be the up-front example of everything at once before
> >> the step-by-step...
> >>
> >>
> >>> * BUILD
> >>> * new
> >>
> >>
> >> These are the heart of construction. I don't think there's any avoiding
> >> that in a class tutorial.
> >>
> >> * submethod
> >>> * bless
> >>
> >>
> >> These are simply necessary components of the above. BUILD is a submethod.
> >> new uses bless. These are non-negotiable aspects of the tutorial.
> >>
> >> * named arguments syntax
> >>> * slurping parameter syntax
> >>
> >>
> >> Named arguments are pretty standard stuff. Slurpy args... I suppose it's
> >> one more thing, but is it really that unusual that we expect someone
> >> reading this not to understand variadic arguments?
> >>
> >>
> >>> * code golfing cleverness of mapping arguments to identically named
> >>> named arguments
> >>
> >>
> >> Again, this is how you take arguments to BUILD that set attributes.
> >> That's the correct form, not code golfing.
> >>
> >> Constructors in a language that supports a flexible metaobject protocol
> >> aren't trivial beasts.
> >>
> >>
> >> The real nail in the coffin though is that it's an example that doesn't
> >>> need to use any of those features (nothing about Task really require
> >>> special construction),
> >>>
> >>
> >> This is, I think, the only really significant problem with that example.
> >> The BUILD method is doing no work, and doesn't need to. An example where
> >> new and BUILD were actually required would be vastly more useful.
> >>
> >>
> >>> * If I have a member that is read-only, when am I allowed to initialize
> >>> it and after what point must already be initialized? Can I assign to it in
> >>> BUILD but not new or vice versa?
> >>>
> >>
> >> You always get a free initializer, so if the user is going to provide it
> >> or it's going to get a static default, you're good to go. But let's say you
> >> have this:
> >>
> >> class Foo {
> >> has $.a;
> >> has $.b;
> >> submethod BUILD(:$!a) { $!b = $!a * 10 }
> >> }
> >>
> >> In this case, you need the BUILD submethod because you wanted to have a
> >> dynamic value for the .b attribute that is based on whatever the .a
> >> attribute was set to.
> >>
> >> Now, that out of the way, let's make $.b readonly:
> >>
> >> has $.b is readonly;
> >>
> >> This doesn't make $.b constant, it merely affects the automatically
> >> generated constructors. So your BUILD routine keeps working. The private
> >> form ($!b) only works within the class, but is not affected by such
> >> strictures.
> >>
> >> * If I want a constructor that takes positional arguments, do I write new
> >>> or BUILD?
> >>>
> >>
> >> For positionals, you have to define a new. Here's another example that
> >> does unecessary work, but in this case to show you what's going on:
> >>
> >> $ perl6 foo.p6
> >> new(1, 2) pre-bless
> >> BUILD(1, 2)
> >> 12
> >> $ cat foo.p6
> >> class Foo {
> >> has $.a;
> >> has $.b is readonly;
> >> multi method new($a, $b) {
> >> say "new($a, $b) pre-bless";
> >> self.bless(:$a, :$b);
> >> }
> >> submethod BUILD(:$!a, :$!b) {
> >> say "BUILD($!a, $!b)";
> >> }
> >> }
> >>
> >> my $f = Foo.new(1,2);
> >> say $f.a, $f.b;
> >>
> >>
> >>
> >>
> >>>
> >>> * If I need to do some computation when the object is constructed in
> >>> order to properly initialize the members, do I write new or BUILD? What if
> >>> one of the members I need to initialize is read-only?
> >>>
> >>
> >> All best suited to BUILD.
> >>
> >>
> >>> * Can either new or BUILD be a multimethod?
> >>>
> >>
> >> Both, sort of. BUILD is a submethod, not a method. It's a sub that looks
> >> like a method. But both can be multi.
> >>
> >>
> >>
> >>> Functions (including operators since they are just functions with a
> >>> different calling syntax after all) normally just operate on their
> >>> arguments without knowing anything about the context with the function was
> >>> called.
> >>>
> >>
> >> This is never a valid assumption in Perl. Perl is all about context.
> >> That's why we have so many operators for enforcing a context (e.g. the
> >> prefix ops ?, +, !, so, ~)
> >>
> >>
> >>> But the pair constructor operator **reaches back magically into the
> >>> place where it was called and changes the argument it was given into a
> >>> string**
> >>>
> >>
> >> Not really. It's a quoting operator and a binary operator rolled into
> >> one. As such, it's no more strange that it has this "contextual" behavior
> >> than the more traditional quoting operators. You don't balk at the fact
> >> that the doublequotes "reach back" and change the way their parameter is
> >> parsed, do you? In Perl 6, it's just more explicit that quoting operators
> >> are actually operators and can be treated as such.
> >>
> >>
> >>
> >
