Re: Precedence design question...'x' & arith

I have spoken out against such changes in the past (Re: Thoughts on replacing -> with .) because I think that the benefits are overestimated relative to the costs.

Here, only the wizards will be sure they know what they are doing, when they omit the parentheses. And the wizards will know that the x-operator has higher precedence. Changing Perl to the more intuitive way (I admit it would be) will break older code and will be very difficult to spot.

I also think that less parentheses is not automatically cleaner code. Especially, when you have to remember rarely used and recently changed precedence rules.

And lastly, your initial post has already more than 3000 characters, not counting your follow ups, which makes more than 1500 pairs of parentheses you could have typed in your code... ;)

Comment on Re: Precedence design question...'x' & arith

Replies are listed 'Best First'.
Re^2: Precedence design question...'x' & arith by perl-diddler (Chaplain) on Jul 05, 2013 at 20:23 UTC
The example you give would be an incompatible change. Please understand, I'm suggesting a case where due to insufficient precision in precedence, the expression " " x 32, has no meaning in perl and yields an error. Syntactically, it is valid, but perl's semantics turn that statement into a semantic "void"... that does nothing for perl or perl authors. I'm asking to be able to use perl's "voids" (things that don't work by virtue of language semantics) and make them both useful, and, in the process, increase the power of perl as an expressive language. I'm not asking that anything other than obfuscation fodder be given up. If your preference is for perl to be obfuscated vs. concise and powerful, you are hurting perl's future. Languages are living things -- unless they are dead languages -- which means no one uses them. I asked for any useful case the current semantics are used for that would be harmed by my changes -- so far no one has come up with 1 example -- just F.U.D. (not to mention accusations of outright lying, 'Eh mate?'). While this is not an overwhelmingly positive outcome, it does seem to be proof that no one can come up with any useful examples in their own code that would be hurt by this change -- likely because using this syntax would currently through an error. Thus my assertion that it was backwards compatible, as it seems no one can come up with any real-life examples where they use or rely on current behavior. @superdoc -- I have to write extra long to just try* to clearly get my meaning across. I have enough problems with people going off on tangents because of things I didn't imply or say -- though 2ndly with not saying things clearly enough. sigh... concisely challenged && still working on it!	[reply]

Replies are listed 'Best First'.

Re^2: Precedence design question...'x' & arith
by perl-diddler (Chaplain) on Jul 05, 2013 at 20:23 UTC

Please understand, I'm suggesting a case where due to insufficient precision in precedence, the expression " " x 3*2, has no meaning in perl and yields an error.

Syntactically, it is valid, but perl's semantics turn that statement into a semantic "void"... that does nothing for perl or perl authors.

I'm asking to be able to use perl's "voids" (things that don't work by virtue of language semantics) and make them both useful, and, in the process, increase the power of perl as an expressive language. I'm not asking that anything other than obfuscation fodder be given up.

If your preference is for perl to be obfuscated vs. concise and powerful, you are hurting perl's future. Languages are living things -- unless they are dead languages -- which means no one uses them.

I asked for any useful case the current semantics are used for that would be harmed by my changes -- so far no one has come up with 1 example -- just F.U.D. (not to mention accusations of outright lying, 'Eh mate?'). While this is not an overwhelmingly positive outcome, it does seem to be proof that no one can come up with any useful examples in their own code that would be hurt by this change -- likely because using this syntax would currently through an error. Thus my assertion that it was backwards compatible, as it seems no one can come up with any real-life examples where they use or rely on current behavior.

@superdoc -- I have to write extra long to just ***try*** to clearly get my meaning across. I have enough problems with people going off on tangents because of things I didn't imply or say -- though 2ndly with not saying things clearly enough. *sigh*...

*concisely challenged* && still working on it!

[reply]