Alexey Trofimenko wrote:
Yes, I know all about being able to use 'and' instead of '&&', and that does make things a bit more readable. But I prefer to reserve 'and/or' for those cases where you really need the ultra loose binding. Like when you have assignments mixed in. Not to mention that when you remove the ()'s on control structures, it's easy to confuse the reader (but likely not the parser) as to whether your inside the conditional, or outside of it, since and/or are often used as a poor man's if.On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams <[EMAIL PROTECTED]> wrote:
Okay, this rant is more about the \s<\s than \s=\s. To me, it is easier to understand the grouping of line 1 than line 2 below:
if( $a<$b && $c<$d ) {...} if( $a < $b && $c < $d ) {...}
In line2, my mind has to stop and ask: is that "($a < $b) && ($c < $d)", or "$a < ($b && $c) < $d". It quickly comes to the right answer, but the question never comes up in the first line. If I wanted to use more parens for clarity, I'd use LISP.
I've got used to write it as if( $a < $b and $c < $d) {...} already. if it could help.. :)
$y++ while $a < $b<foo>[$bar]{$baz = =<'foobar'>}
and $c = $d;Not that I'd actually ever write something that obscene.
I'm deciding I don't like the unary = proposal, for similar reasons to <. It feels like we are rapidly approaching the point where all binary operators require surrounding whitespace, to distinguish them from similar looking unary/quoting operators. There are at least enough of them, including fairly popular ones like = and <, (but not necessarily >), that allowing some of them to be \S<binop>\S is bound to cause a great deal of confusion. In fact, unary = imposes whitespace requirements on all ops that end in =.
So I would suggest that P6 adopt one of the following: 1) \S<binop>\S is allowable for for all <binop>. 2) \s<binop>\s is required for all <binop>, save method postfix ones.
Pros \S<binop>\S :
- very P5ish
- allows users great flexibility on how they logically group terms in more complex expressions
- one liners get easier, especially on platforms that have troubles passing args with whitespace in them.
Cons \S<binop>\S:
- requires a great deal of reworking to remove ambiguity with similar looking unary ops.
- can make code indistinguishable from line noise at times.
Pros \s<binop>\s :
- opens up the realm of available binary and unary/balanced ops considerably.
- makes life easier for the lexical analyzers.
- forwards compatible with new operators, including user defined ones.
Con \s<binop>\s: - very imposing for an otherwise programmer friendly language. - makes obsfication contests a lot harder.
Personally, I would very much prefer \S<binop>\S. But I strongly suspect that removing all the conditions where \s<binop>\s is needed is a lost cause at this stage on the game. So barring that possibility, I'd vote for the consistency of \s<binop>\s. But I still wouldn't like it.
For reference, here is a list of the operators that have some form of whitespace issue so far:
= := ::= += -= *= **= .= /= //= ||= &&= %= < <== +< >= <= == != =:= all the alpha ops +<< ~<< many hyper variants of operators .. # 0 .. .length() vs 0 ... length()
likely others as well.
-- Rod Adams
