Mailing List Archive

Ovid via perl5-porters wrote on 15 August:
>
> Here are some of the arguments for and against them.
>
> Pros:
> • You can't accidentally shadow class/instance data. (technical)
> • Great Huffman encoding for "this is not a regular variable" (social)
> • Easy to syntax highlight (technical)
>
> Cons:
> • No direct parser support for twigils (technical)
> • Is somewhat controversial (social)
> • May contribute to "line-noise" complaints (social)
>
> I can't say that I'm "for" twigils, but so far, that's two strong technical and one strong social argument for them.

/Are/ these strong arguments, though?

The accidental shadowing argument seems to not hold much merit: We already have that same problem now in /every/ block, including experimental sub signatures, and it should be solved the same way everywhere.

As for the "not a regular variable" argument: Looking at Java, there are no sigils/twigils of course, but there is "this.", which can optionally be prepended to a name to make accessing instance data explicit. Java is kind of verbose by nature, yet few Java coders seem to use this style (except when needed to disambiguate, obviously). I personally /have/ used that coding style in Java for a few years based on the same "not a regular variable" argument and have gotten more than a few funny looks and comments about that. Eventually I gave in and have to admit: My Java code tends to be easier to read without "this.". Therefore, in my mind, the "not a regular variable" argument is also rather weak.

The synhi argument also seems pretty weak. It's /syntax/ highlighting, not semantic highlighting. All variables /should/ look the same. If you really do want to treat instance variables specially, that shouldn't be hard for today's advanced highlighters anyway by virtue of the declaration with `has`, which is easy to parse. My editor of choice doesn't have /very/ advanced highlighting, but I know this is possible with it. No twigils needed for synhi.

I got one more pro for your list, but it's also kind of weak in my opinion: Twigils could be interpolated in a string, a `slot` keyword probably couldn't. But, again, this is in no way different than any other subroutine call, which also can't be interpolated. I'd say not everything /needs/ to be interpolated.


> So if you have a strong argument for or against them, [...]

I suppose I don't? I mean, certainly not a /technical/ argument against. The thing is, I've never really used Raku, so the entire twigil concept is somewhat new to me. I'm sure Raku is great, I just never found the time to understand it. I did look into learning Raku twice, but honestly what put me off both times is all the line noise in the Raku code I looked at. I could hardly even read it.

Perl looks already noisy. Yes, it makes sense for Perl to look that way, but no need to make it worse. This is all stuff people have to invest effort to learn. A lot of the appeal of Corinna to me initially was its simplicity and elegance. Requiring twigils chips away at both of these.

IMHO, twigils should, if introduced at all (and this ought to be a big if), at least be entirely optional. That is, something like the following should be allowed:

class Point {
has $:x :param;
has $y :param;
method move ($dx, $dy) {
$x += $dx;
$:y += $dy;
}
}


--
Arne Johannessen

There are two parts to this argument I haven't seen anyone else make
yet, so here in the hope that this isn't at all a repeat.

Also, both of these points are made by reference to myself having
actually written large amounts of real actual code using Object::Pad.
[1].


## Dynamic Method Generation

If twigil syntax exists, then methods that access slots can be
dynamically added to classes by MOP access, by way of a `:unbound`
method attribute. This tells the compiler *not* to resolve slot names
at the time the method body is compiled:

my $mref = method :unbound {
$:aslot++;
};

This "unbound method" is not yet useable, but can now be attached to a
class by a MOP call, and only at that point we'll resolve the slot name
in that class:

$metaclass->add_slot( '$:aslot' );
$metaclass->add_method( inc_slot => method :unbound { $:aslot++ } );

If instead, slot variables look identical to regular lexicals, then
code of this form cannot be constructed. There would be no way to write
the anonymous `method {}` reference in the first block of code above,
without it failing to parse at compiletime because of an unrecognised
variable name.

A mechanism does currently exist in Object::Pad to do this kind of
thing, and it is Not Pretty:

my $metaslot = $metaclass->add_slot( '$aslot' );
$metaclass->add_method( inc_slot => sub { # we can't use method
my $self = shift; # because we're not method
$metaslot->value($self)++;
});

It turns what would be a simple efficient OP_SLOTPAD inside the method
body into a closure capture of the $metaslot instance which invokes
an lvalue accessor method on it at runtime, just to fetch the value of
that slot. It works, but it's incredibly inefficient and removes most
of the entire point of having these slot variables feel variable-like
in the first place.


## Surprising Lazy Initialization

One of the commonly-requested features from Moo(se?) users is "does it
support lazy builders?". I have been hesitant to add these to
Object::Pad itself for the reasons I explain below, but because people
kept asking about it, I created a mechanism to allow 3rd-party
attributes, and then created this:

https://metacpan.org/pod/Object::Pad::SlotAttr::LazyInit

This kind of thing is subtle to use in practice, because "slots look
like lexicals". With Moo(se?), all instance data is accessed via
accessor methods, and people are culturally used to the fact that
methods can run code. They might print spurious warnings, or they might
fail outright:

use Moo;
package OrangePeeler;

has orange => ( is => 'lazy' );
sub _build_orange {
die "Not on a Tuesday, no" if (localtime)[6] == 2;
warn "Maybe, maybe not" if rand > 0.5;
return Orange->new;
}

sub peel {
my $self = shift;

# might die or warn but that's OK; we expect that
my $orange = $self->orange;
say "Peeling $orange...";
}

Whereas, if all your slot variables look just like variables, then this
might be considered surprising:

use Object::Pad;
class OrangePeeler;

has $orange :LazyInit(_make_orange);
method _make_orange {
die "Not on a Tuesday, no" if (localtime)[6] == 2;
warn "Maybe, maybe not" if rand > 0.5;
return Orange->new;
}

method peel {
# This variable interpolation itself might die or warn
say "Peeling $orange...";
}

By using a twigil and making slots "look different to variables", we
can disarm this false feeling of safety, by reminding the programmer
that these aren't just boring lexical variables, and that fun things
may still happen:

method peel {
# This interpolation might die, but that's OK because it looks weird
say "Peeling $:orange...";
}

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

??, 12 ???. 2021 ?. ? 14:25, Ovid via perl5-porters <perl5-porters@perl.org>:
> Twigils is one way of solving that issue.

Nobody's asked yet, but what's the price? Is new parser hook enough,
or this would be a forever-binding code block that exists in core
solely to support a single CPAN module?

Best regards,
Sergey Aleynikov

On Fri, Aug 20, 2021 at 9:14 AM Sergey Aleynikov
<sergey.aleynikov@gmail.com> wrote:
>
> ??, 12 ???. 2021 ?. ? 14:25, Ovid via perl5-porters <perl5-porters@perl.org>:
> > Twigils is one way of solving that issue.
>
> Nobody's asked yet, but what's the price? Is new parser hook enough,
> or this would be a forever-binding code block that exists in core
> solely to support a single CPAN module?

This is not meant for Object::Pad, this is meant for an in-core
implementation of Corinna.

>
> Best regards,
> Sergey Aleynikov

??, 20 ???. 2021 ?. ? 11:44, Graham Knop <haarg@haarg.org>:
> This is not meant for Object::Pad, this is meant for an in-core
> implementation of Corinna.

I haven't heard that it's a done deal, and previous messages from Ovid
implied so. So, is it and p5p was unnotified?

Best regards,
Sergey Aleynikov

On Fri, Aug 20, 2021 at 12:37 PM Sergey Aleynikov
<sergey.aleynikov@gmail.com> wrote:
>
> ??, 20 ???. 2021 ?. ? 11:44, Graham Knop <haarg@haarg.org>:
> > This is not meant for Object::Pad, this is meant for an in-core
> > implementation of Corinna.
>
> I haven't heard that it's a done deal, and previous messages from Ovid
> implied so. So, is it and p5p was unnotified?

It isn't a done deal. That's why it's being discussed. This entire
thread is meant to help decide one part of what will go into the
Corinna RFC.

>
> Best regards,
> Sergey Aleynikov

On Friday, 20 August 2021, 14:21:59 CEST, Graham Knop <haarg@haarg.org> wrote:

> It isn't a done deal. That's why it's being discussed. This entire
> thread is meant to help decide one part of what will go into the
> Corinna RFC.
Just to be clear: ordinarily I wouldn't trouble P5P with trivial details about the RFC and I don't imagine doing so again. However, I know that some people are, um, so incredibly passionate about the twigil question that I just needed to quickly check on this issue.
I don't know which way we're going to go with twigils, but at least it doesn't look like a showstopper here.
Best,Ovid-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl

this would be a nice use case for a more robust macro language / source
rewriter. The twigils could get rewritten into valid miniperl. As well as a
lot of core features, for a general refactoring of the parsing steps.
Leading to "perl in perl" which AFAIK nobody has actually followed through
with.

On Fri, Aug 20, 2021 at 2:14 AM Sergey Aleynikov <sergey.aleynikov@gmail.com>
wrote:

> ??, 12 ???. 2021 ?. ? 14:25, Ovid via perl5-porters <
> perl5-porters@perl.org>:
> > Twigils is one way of solving that issue.
>
> Nobody's asked yet, but what's the price? Is new parser hook enough,
> or this would be a forever-binding code block that exists in core
> solely to support a single CPAN module?
>
> Best regards,
> Sergey Aleynikov
>


--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

Re-ordered to avoid top posting.

> > ??, 12 ???. 2021 ?. ? 14:25, Ovid via perl5-porters <
> > perl5-porters@perl.org>:
> > > Twigils is one way of solving that issue.
> >
> > Nobody's asked yet, but what's the price? Is new parser hook enough,
> > or this would be a forever-binding code block that exists in core
> > solely to support a single CPAN module?

On Fri, Aug 20, 2021 at 10:25:09AM -0500, David Nicol wrote:
> this would be a nice use case for a more robust macro language / source
> rewriter. The twigils could get rewritten into valid miniperl. As well as a
> lot of core features, for a general refactoring of the parsing steps.
> Leading to "perl in perl" which AFAIK nobody has actually followed through
> with.

At first read your message seems on topic and reasonable.

But I keep thinking - THIS ADDS NO VALUE.

Hence my reply.

In that,

1) no-one has any good idea *how* to write a viable macro-language/source
re-writer
2) Saying "this would be a good use case for it" is true, but pointless if
we don't have one, or any route to one
3) repeatedly mentioning something as a "nice to have" doesn't change this.

Hence your reply is not useful, because it does not advance this discussion.
Or any discussion.


It doesn't add any value to this to say "This hypothetical other technology
that doesn't exist is a viable alternative to something we do have"


I'm asking you (and everyone, really) to stop mentioning concepts that don't
have any viable implementation. If we're proposing feature A, please stick
to insightful comments/observations for approaches that we can deliver it
using the technology that we have, rather than proposing feature B as a
prerequisite and hence a blocker.


(If you have some idea how to implement feature B, that's cool, but it
ought to be on a new thread.)


And as Neil and others have written previously, sending "harmless" mails is
not harmless - there is a cost to everyone else to read (or actively ignore)
mails sent to the list - "but you don't have to read my message" is *not* a
valid reason to continue writing off-topic messages.

Nicholas Clark

On 2021-08-20 8:25 a.m., David Nicol wrote:
> this would be a nice use case for a more robust macro language / source
> rewriter. The twigils could get rewritten into valid miniperl. As well as a lot
> of core features, for a general refactoring of the parsing steps. Leading to
> "perl in perl" which AFAIK nobody has actually followed through with.

The use of a source rewriter for this would imply that the proposed use of
Twigils is a short-hand for something else.

However, in this case the Twigils ARE the FUNDAMENTAL feature syntax, they are
the ONLY way to express what they are intended for, which is direct access to
slots, which are a new fundamental concept implemented in core and not
implemented over something that already exists.

(I had proposed that the Twigils could be a special short-hand for a more
general syntax that lets one reference slots of multiple objects directly from
the same context, however this idea was rejected for the Corinna MVP / v1.)

Therefore, it does not make sense to propose Twigils be immplemented using a
source rewriter.

-- Darren Duncan

On Thu, Aug 12, 2021 at 11:24:43AM +0000, Ovid via perl5-porters wrote:
> We're working on the Corinna RFC and it won't be sent soon, but due to
> Corinna's design, we have a subtle issue that isn't shared by most other
> OO languages. In short, lexical variables (declared in a method or in a
> signature) can hide the instance variables. Twigils is one way of
> solving that issue.

1) Note I am not (yet) very familiar with Corinna.

2) My main comment is that I don't mind the idea of twigils in principle.

A couple of further observations (bearing in mind (1)):

3) I like the idea that they should be optional, only needing to be used
when necessary to disambiguate. I.e.

class Foo {
has $x;
method inc ($i) { $x += $i }
method set ($x) { $:x = $x } # only ambiguous here
}

4) (bikeshedding) I prefer $.x over $:x. The former has the idea (from C
etc) of accessing an element. $:x is visually similar to my
(currently stalled) proposal for named parameters in signatures:

sub foo (:$x, :$y) { ... }
foo(y => 1, x => 0);

Both $:x and $.x suffer from the same parsing ambiguities, in that both $.
and $: are legal variables (although $. is much more commonly used):

$x < $.or;
$x < $. or next;

--
All wight. I will give you one more chance. This time, I want to hear
no Wubens. No Weginalds. No Wudolf the wed-nosed weindeers.
-- Life of Brian

On Fri, Aug 20, 2021 at 7:34 PM Darren Duncan <darren@darrenduncan.net>
wrote:

> On 2021-08-20 8:25 a.m., David Nicol wrote:
> > this would be a nice use case for a more robust macro language / source
> > rewriter. The twigils could get rewritten into valid miniperl. As well
> as a lot
> > of core features, for a general refactoring of the parsing steps.
> Leading to
> > "perl in perl" which AFAIK nobody has actually followed through with.
>
> The use of a source rewriter for this would imply that the proposed use of
> Twigils is a short-hand for something else.
>
> However, in this case the Twigils ARE the FUNDAMENTAL feature syntax, they
> are
> the ONLY way to express what they are intended for, which is direct access
> to
> slots, which are a new fundamental concept implemented in core and not
> implemented over something that already exists.
>

Except -- in the macro rewriting daydream, lots of other core syntax gets
rewritten too. Anyway, the suggested question appears to be, what would the
twigil expression get rewritten to?

Presuming every method starts by defining $context (whatever that is),
$.slot would get rewritten to something like

drumroll please

CORE::Corinna::twigil_access($context,'slot');

see what I mean?

On Monday, 30 August 2021, 13:59:51 CEST, Dave Mitchell <davem@iabyn.com> wrote:

On Thu, Aug 12, 2021 at 11:24:43AM +0000, Ovid via perl5-porters wrote:
> 1) Note I am not (yet) very familiar with Corinna.
When we eventually have the Corinna RFC ready, this will be an issue.
For those who want to know more (and especially for those of you who have veto access), I've written code to generate a table of contents and navigable RFC sections:
https://github.com/Ovid/Cor/blob/master/rfc/toc.md

The proposal is now much easier to both read and navigate. More features are forthcoming. The RFC generator, of course, is written in Object::Pad (https://github.com/Ovid/Cor/blob/master/lib/Corinna/RFC/Writer.pm) and the long-term goal is to convert it to Corinna, thus helping to dogfood our work. It's already proved to be enlightening.
Best,Ovid-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl