Re: Observations from a C++/Python developer that never used Perl5

[Aaron Sherman]

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 
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"  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 

Re: Observations from a C++/Python developer that never used Perl5

[Brock Wilcox]

Quotes are almost a circumfix operator, but they act a bit more like a
macro by controlling the parsing of the contents. But you can do some weird
things like define your own quote-likes.

perl6 -e ' sub circumfix:<>($v) { "{$v}" } ; say B"foo"B ' #
output: foo

or more verbosely

perl6 -e ' sub circumfix:<>($v) { "{$v}" } ; say bold
"foo" endbold ' # output foo

That said, I think the quoting of the left side of => is understandably
startling. With normal quotes (single, double, etc) you read left to right
and you see a quote and you know that until you see another (unescaped)
quote something different is happening. With => you have to read from the
middle and go back to the left to get the whole picture. Very powerful and
handy and easy once you recognize it, but definitely different from pure
left-to-right.


On Fri, Sep 9, 2016 at 8:59 PM, Joseph Garvin 
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"  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.
>>
>>
>>
>>> 

Re: Observations from a C++/Python developer that never used Perl5

[Joseph Garvin]

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"  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.
>
>
>