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

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

Thread Previous | Thread Next
August 29, 2013 16:11
Re: [perl #116020] toggle operator missing reset: proposal
Message ID:
On 29-Aug-13 03:15, Father Chrysostomos via RT wrote:
> On Wed Aug 28 13:20:25 2013, wrote:
>> via RT wrote:
>>> My proposal:
>>>   Since we can label any statement (now), why not have the reset
>> operator take a label argument?
>> I think the toggle operator is a wart that we should lean towards
>> removing, not something to encourage wider use of.  The context-
>> dependent
>> behaviour is particularly nasty to handle internally, compared to
>> other
>> context-dependent operators.
>> If you like the toggle behaviour, I suggest that you should implement
>> a cleaner version of it (certainly including explicit operations on
>> named toggles) on CPAN.
> I think I agree here.  Shall I close it?  What do others think?
I responded yesterday, but it didn't seem to get posted.  Short form: if 
ugly internals were the criterion, there's a lot of Perl that could be 

The range operator is part of the language, and is undeniably useful 
(and used) in real-world situations.  My suggestion would make it more 
usable - and I think the criterion for deciding what to do should be 
based primarily on what benefits users of the language, not on the 
ugliness of the Perl internals.

I would strongly oppose removing the range operator.   And given that it 
stays, making it easier to use seems worthwhile.

I don't see how CPAN distribution makes the problem simpler:  code to 
identify and manipulate the internals of flip-flops would be at least as 
ugly as the current implementation - with the added issues of version 
dependency and users not being able to rely on its presence.  I don't 
think it's a good idea to patch basic operators of the language with 
CPAN add-ons.

As I noted yesterday (quoted below), re-implementing a 'cleaner' version 
as an object has issues as well.

The range [flip-flop] operator isn't pretty - but it is expressive and 
hard to replace efficiently with some external device.

I don't see a deprecation effort being successful - and it's almost 
certainly more work (for someone who knows Perl internals) than 
extending reset (or introducing some other device to identify and clear 
the bit.)

Please focus on what's good for the language's users rather than the 
elegance of the internals...

> Although it certainly isn't the most elegant of Perl's operators and 
> could have been done differently/better at the beginning of time, it 
> exists.  It is used, and it's more than a wart - no matter how ugly 
> the internals.  It provides a very concise way to deal with the common 
> issue of processing data within brackets. (e.g. certificate operations 
> on PEM files such as BEGIN X509 (CERTIFICATE/CRL...) / DATA / END X509)
> The suggestion for a cleaner version in CPAN is interesting; although 
> exactly how to go about that without a heavy dependency on 
> version-specific Perl internals is not obvious.  I suspect that it's 
> really too closely coupled to Perl internals (for which I don't claim 
> expertise) to take this approach and end up with syntax as clean as 
> the current operator.
> One might imagine a toggle object as a middle ground -- e.g.
>     $toggle = Toggle::new( '...', sub {/^--a$/} , sub {/^--b$/}); # 
> booleans have to be a coderef for short-circuit semantics
>     .......
>    sub use_function{
>     $toggle->reset if ($. <= 1);
>     while (<>) {
>     $out .= $_ if $toggle->test > 1;
>     }
> }
> - which could be made to work, but is hardly concise or as clear as 
> the existing syntax, especially when one considers that the object 
> approach also has scoping/initialization issues that the existing 
> operator hides.  $toggle would have to be some file scope variable, so 
> it would often end up far from the point of use.  And if the boolean 
> inputs are more interesting (e.g. /^--$a$/, where $a is a MY variable 
> in the use_function scope) things go downhill rapidly.
> Note also that the range (a.k.a toggle) operator can not be 
> overloaded. ( 
> final bullet), so we can't use it for precedence or syntactic sugar.
> And so we end up with my original suggestion as the least inelegant 
> solution: provide a mechanism for reseting the existing operator, such as
>       reset ['label']; or reset( ['label'], 2 );
> Or any other syntax that expresses the semantics but is easier to deal 
> with in the internals.

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