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

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

Thread Previous | Thread Next
September 5, 2013 18:23
Re: [perl #116020] toggle operator missing reset: proposal
Message ID:
On 29-Aug-13 11:49, Zefram via RT wrote:
> tlhackque wrote:
>>> One might imagine a toggle object as a middle ground -- e.g.
>>>     $toggle = Toggle::new( '...', sub {/^--a$/} , sub {/^--b$/}); #
> Can be done much more neatly by a call-checker plugin and custom ops.
> I'm thinking of it looking something like
> 	$out .= $_ if toggle /^--a$/, /^--b$/;
> Named toggles just need a slight extension to put their state somewhere
> visible.  As the hiddenness of a toggle's state is a nasty aspect of
> the core feature, I'd be inclined to make these toggles use an explicit
> variable, whose lifetime can be controlled in the usual ways:
> 	my $tog;
> 	reset_toggle $tog;
> 	$out .= $_ if toggle $tog, /^--a$/, /^--b$/;
call-checker plugin?

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

The current (core) feature is associated with a line of code, not a 
recursion level, block scope or closure.  Once could put a variable at 
file scope, but as previously noted, that's likely to be many lines of 
code distant from the point of use.

Without an explicit variable,  how do you have instance state? You have 
to label the statement (and deal with more than one in a statement - 
e.g. toggle1 || toggle2) in order to have a reset operator/function.  
Then do you hook the state onto the label?  Can a function in the 
compiled code find its caller's label?

To me, this seems a lot harder than making the current toggle's state 
visible and addressable - and adding a means to reset it. Plus, the 
function/object approach ends up with TWO (well, four if you count the 
../... variants) operators in the language: the original ops that aren't 
resetable, and the new function/objectish ones that have different 
semantics (and precedence), but are resetable.  So harder doesn't get an 
externally pleasing result...even if you make this work.

But I'm not a Perl internals person.  From a consumer's point of view, 
the current implementation has defined the scope, precedence, behavior 
of the operators and has a place where the state lives. All that's 
necessary is a way to name that existing state, and a way to apply a 
reset operation to that name.

I thought that since any statement can be labeled, a label would be a 
good way to name the state - or more precisely, the states since a 
statement can have more than one toggle operator.  It doesn't require 
novel syntax.

But I suppose there are other approaches.  condition1 ..('name') 
condition2 comes to mind...That allows labeling each operator (even 
allowing 'Package::name' to refer to it) rather than hooking on to the 
statement label.  This might be neater, but I assumed that novel syntax 
was the greater barrier.

>>> such as
>>>       reset ['label']; or reset( ['label'], 2 );
> If a toggle reset feature is added to the core, it should not further
> overload an existing core operator, especially one that is presently
> unrelated.
I don't care how the reset function/operator is spelled - the word seems 
to have the right sense, and using it avoids adding a new reserved word 
to the language.  But if it were spelled "/Snuffleupagus/('name')" & had 
the desired semantics I'd be happy!
> -zefram

This communication may not represent my employer's views,
if any, on the matters discussed.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About