Front page | perl.perl6.language |
Postings from December 2004
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>; : $x**=@y; # $x ** =@y; $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. LarryThread Previous | Thread Next