Re: Required whitespace issues.
Larry Wall wrote: On Sat, Dec 04, 2004 at 08:55:00PM -0600, Rod Adams wrote: : $x ==$foo; # $x == $foo; $x = =$foo; : @x ==$foo; # @x = =$foo; @x == $foo; : $x//=$foo; # $x // =$foo; $x //= $foo; : [EMAIL PROTECTED]; # $x ** [EMAIL PROTECTED]; $x **= @y; In each of those cases the longest-token rule comes into effect. That's not only consistent, but standard CompSci for the last 30 years or so. The only person who will get burned on those is someone who insists on *not* putting whitespace in front of unary = when it would be ambiguous. I have negative sympathy for such people. Well said! Although I by no means dispute that longest token rule is a long term standard in language design, I will claim that many programmers, including myself before this, are unaware of it. So I will now change my concerns to: The longest-token rule needs to be mentioned in S03, and explained in a future perlop.pod. -- Rod Adams
Required whitespace issues.
Alexey Trofimenko wrote:
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.. :)
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.
$y++ while $a $bfoo[$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 \Sbinop\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) \Sbinop\S is allowable for for all binop.
2) \sbinop\s is required for all binop, save method postfix ones.
Pros \Sbinop\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 \Sbinop\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 \sbinop\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 \sbinop\s:
- very imposing for an otherwise programmer friendly language.
- makes obsfication contests a lot harder.
Personally, I would very much prefer \Sbinop\S. But I strongly suspect
that removing all the conditions where \sbinop\s is needed is a lost
cause at this stage on the game. So barring that possibility, I'd vote
for the consistency of \sbinop\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
Re: Required whitespace issues.
On Sat, Dec 04, 2004 at 08:14:17PM -0600, Rod Adams wrote: : In fact, unary = imposes whitespace requirements on all ops that end in =. Not true. Larry
Re: Required whitespace issues.
Larry Wall wrote: On Sat, Dec 04, 2004 at 08:14:17PM -0600, Rod Adams wrote: : In fact, unary = imposes whitespace requirements on all ops that end in =. Not true. I guess not all cases. But several do in certain situations. $x ==$foo; # $x == $foo; $x = =$foo; @x ==$foo; # @x = =$foo; @x == $foo; $x//=$foo; # $x // =$foo; $x //= $foo; [EMAIL PROTECTED]; # $x ** [EMAIL PROTECTED]; $x **= @y; Enough to make my overall issue of an increasing number of operators are acquiring whitespace requirements valid. If I'm not mistaken, \S\S is invalid, but \S\S is valid. The rest of my post can be summarized as A consistent set of rules about when whitespace is and is not allowed are in order. -- Rod Adams
Re: Required whitespace issues.
On Sat, Dec 04, 2004 at 08:55:00PM -0600, Rod Adams wrote: : Larry Wall wrote: : : On Sat, Dec 04, 2004 at 08:14:17PM -0600, Rod Adams wrote: : : In fact, unary = imposes whitespace requirements on all ops that end in : =. : : Not true. : : I guess not all cases. But several do in certain situations. : : $x ==$foo; # $x == $foo; $x = =$foo; : @x ==$foo; # @x = =$foo; @x == $foo; : $x//=$foo; # $x // =$foo; $x //= $foo; : [EMAIL PROTECTED]; # $x ** [EMAIL PROTECTED]; $x **= @y; In each of those cases the longest-token rule comes into effect. That's not only consistent, but standard CompSci for the last 30 years or so. The only person who will get burned on those is someone who insists on *not* putting whitespace in front of unary = when it would be ambiguous. I have negative sympathy for such people. : Enough to make my overall issue of an increasing number of operators : are acquiring whitespace requirements valid. If I'm not mistaken, \S\S : is invalid, but \S\S is valid. You have to put whitespace in C$x lt$y too. That doesn't seem to bother people too terrible much. : The rest of my post can be summarized as A consistent set of rules : about when whitespace is and is not allowed are in order. They're not only in order, but they've been defined for several years. I think the deep rules are actually pretty simple and consistent. You can leave out the space between a term and an infix operator only if the infix operator wouldn't be confused with a postfix operator. This is just an extension of the longest-token rule to treat the combination of a term and a postfix operator as a kind of supertoken. It's also the sort of thing yacc is doing when it prefers shifting over reducing. This deep rule doesn't change. The main complication is that the surface rules change as you change your definitions. We are designing Perl 6 to be mutable. As you define new postfix operators you put more restrictions on your infix operators, and vice versa. Right now you could define either a postfix:! or an infix:!, and they wouldn't interfere. But if you defined both, the infix:! would be required to have a space before it, and the postfix:! would be required to *not* have a space before it. (To put space before postfix:!, you'd have to prefix it with a dot just like all the other postfix operators.) The same would happen if you defined an infix:++ operator. The existing postfix:++ operator would then be required to omit the space or use a dot. Going the other direction, if one really hates postfix:« », one can delete it from the grammar and then write $a$b to one's heart's content. The disambiguation rule is not applied except where needed. The underlying rule is still exactly the same, and hasn't changed in the last couple of years. We're just tweaking the shallow grammar, and yes, that changes the shallow disambiguation rules. But the underlying disambiguation rule stays the same regardless of how many operators you define or undefine. Larry
