Hope you fare better than I did with my say() patch.

Hope you fair better than I did with my say() patch.

Is "fair" pun or typo?

What was wrong with your patch? I can understand that the keyword it introduces might be a little too likely to already be used in scripts. Something that I hope given and when are not.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

A typo, or probably 'thinko', now corrected.

As for the answer to your question, it depends upon who you ask, what their agenda is, and possibly, who's asking.

Variously,

• "No new keywords". (except lock, err, defined-or...)
• New keywords break backwards compatitbility.
• Fixable by using "weak keywords", but the pumpking "hates weak keywords".
• Fixable by applying HINTS-style flag or bitword settable by use extended, a command line switch or similar--but it's:
  • "Too late in the life of Perl 5 to consider such a mechanism".
  • Adding such a mechanism, even if a few lines of code, is a "big deal".
  • "say" is too trivial a feature to consider such a mechanism for.

  Take your pick and good luck.

  ---

  Examine what is said, not who speaks.

  Silence betokens consent.

  Love the truth but pardon error.

  Lingua non convalesco, consenesco et abolesco.

IMO a crucial issue to get this into play is to find out how many scripts it breaks. You should have a good estimate of that before proposing it.

I doubt it breaks any script or module at all. Double ~ is already extremely rare currently, and using ~~ such that it's parsed differently with my patch applied seems only possible in contrieved situations.

This is the only scenario I've come up with so far:

print $fh ~~EXPR;
[download]

Double ~ is already extremely rare currently, and using ~~ such that it's parsed differently with my patch applied seems only possible in contrieved situations.

Based on what analysis? Is this just your opinion based on your experience or is it actually backed up a sampling of Perl modules from CPAN?

My point here is that i think this all is an interesting and clever idea that should go through the acceptance process, but that IMO you will need better evidence than that which you and Juerd have provided so far. Anyway.... I actually agree that this will probably prove to be a very rare construct, but you should have some solid numbers to back it up. Anyway, i hope you try to get this into blead, i think it would be nice.

---
demerphq

IMO a crucial issue to get this into play is to find out how many scripts it breaks. You should have a good estimate of that before proposing it.

Do I have statistics? Do you? Does anyone?

All we can reasonably test with is CPAN modules, our own scripts and perl's test suite. I know nothing in my repository would break except one throwaway script that uses Switch.pm for given/when.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

All we can reasonably test with is CPAN modules, our own scripts and perl's test suite.

Well then if you count how many break you have some statistics dont you?

---
demerphq

They will demand showing you it fills a demand. So they'll suggest you first implement it in a module (a source filter probably).

Since it does break backwards compatability

Please provide example code, as the only place I know where it'd be ambiguous, it's resolved in favour of the existing behaviour, sacrificing no real functionality in the new feature.

A smart match operator doesn't seem to fill a great demand (and no, "smart match operator" is not the same as "switch", for which there are alternatives - a "smart match operator" is yet another alternative to "switch").

Smart match is what gives a switch statement for free. Of course, those can be implemented without having the smart match at all, but it'd be nice to be able to use the logic used for switch statements outside givens too.

They will demand showing you it fills a demand. So they'll suggest you first implement it in a module (a source filter probably).

The smart match operator is not in great demand. The only reason for concentrating on that is its relation with given/when. And re doing it as a source filter: no, I won't. That's very nice for a proof that the syntax works, or if you want very badly to use this feature yourself. The only thing I'm interested in is getting given/when implemented in Perl 5 itself, not a source filter, because that source filter already exists and we all know why we're avoiding its use in production. This feature requires modifications to the core (which a minor release can do -- for conservatives, there are maintenance releases), and if we're at it, I think it makes sense to do it right the first time. If p5p doesn't like it, then the work we've done has still not been done for nothing. The code that implements SmartMatch::sm can be reused without modification, and some people (like me) learn a bit about how Perl's internals work by looking at xmath's work.

But for someone who said he was doing this to avoid discussion, I have been wasting too much time on unnecessary typing already. For now, I don't care about p5p's opinion on this at all, but there will be a time that I should care, and I trust that p5p will make a wise decision.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }