develooper Front page | perl.perl5.porters | Postings from September 2013

Re: [perl #116020] toggle operator missing reset: proposal

Thread Previous | Thread Next
From:
Zefram
Date:
September 5, 2013 19:03
Subject:
Re: [perl #116020] toggle operator missing reset: proposal
Message ID:
20130905190258.GC31643@fysh.org
tlhackque wrote:
>call-checker plugin?

See L<perlapi/cv_set_call_checker>.  It's a mechanism that allows an
XS module to completely transform the op tree resulting from parsing a
subroutine call.  The "toggle $tog, /^--a$/, /^--b$/" expression parses
as a call to the toggle() sub, provided there is such a sub in scope.
A call checker attached to the sub can then replace the sub call with
an op tree that uses the argument ops in a different way.

>The problem with an explicit variable is that having a lifetime with
>the right semantics is not intuitively trivial.

A "state" variable gives you the whole-program lifetime that you get for
the state of a built-in toggle.  That's only rarely the best scope to
use, but it's there if you want it.  It looks like you want this scoping
(or think you want it) just because it's what the built-in feature does.
Most of your cases for resetting toggles would probably be better handled
by having a separate instance of the state variable per invocation of
some function, which you could get with a "my" variable.

>Without an explicit variable,  how do you have instance state?

A call checker can introduce implicit variables if it wants to.
If they're "state" variables, they'll act exactly like the implicit
state of built-in toggles.

>have to label the statement (and deal with more than one in a
>statement - e.g. toggle1 || toggle2)

That's a good reason why the labels on statements are not a good approach
to linking reset operations to toggle expressions.  Another good reason
is that statement labels are designed to be resolved at runtime, whereas
this feature makes more sense with compile-time resolution.  Some of the
other issues you list are also problems that only arise if you attempt
to use statement labels for this.  The great thing about using ordinary
variables to hold state is that the whole mechanism already exists,
with sensible semantics and a lot of flexibility.

>To me, this seems a lot harder than making the current toggle's state
>visible and addressable

The problems with using statement labels would apply regardless of
whether it's a new module implementation or a modification of the
built-in toggles.

>                      This might be neater, but I assumed that novel
>syntax was the greater barrier.

Novel syntax (both here and for the reset operator) is less of a problem
than using a semantic feature for a purpose for which it is not suitable.
But overall there's some resistance to adding *any* substantive feature
to the core that could be implemented as a module.

-zefram

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About