--- Matthijs van Duin <[EMAIL PROTECTED]> wrote: > Now the real subject.. has the issue of multiple statement modifiers > already been settled? I saw some mention it wasn't going to be > supported, but also mentions of how it would be useful; I can think > of such a situation myself: > > .method when MyClass given $obj; > as alternative to: > $obj.method if $obj.isa(MyClass);
I think this is an unusually clear case, and even then has problems. The real nightmare tends to show up when you duplicate a modifier. What does .method given $x given $y; # which object's .method is called? mean? It gets worse below.... > except without duplicating $obj, which may be worthwhile if it's a > longer expression. If multiple modifiers are really a no-no, then > I think at least the conditionals (if, unless, when) could be made > lowest-precedence right-associative infix operators, and leave the > status of "statement modifier" for loops and topicalizers. lowest? why lowest? Careful with that.... If you make it a lowest precedence operator, $x = $y if $z; # = is higher precedence Does it get assigned if $z is undefined? > This would mean that the above would be valid, and also things like: > .. if .. if .. for ..; I may be missing something, but print if $x if $y; # ?? Are you saying "test $y, and if it's true, test $x, and if it's true then print"? I suppose that might work....but that still makes it high priority, doesn't it? > But that multiple nested loops would be illegal using modifiers and > would require a real block. (which makes some sense, since it's hard > to think of a construction where multiple loop-modifiers would be > useful: if you have ... for @a for @b then you'd be unable to > use the @b-element since $_ would be the loop var of the inner loop) Maybe not in p6. print "$x,$y\n" for $x -> @x for $y -> @y; # is that approximate? Ok, this is hurting my head, and I think I might hurt someone who left me to maintain it, but I could see how it could be useful, and I think I see how it could be parsed.... It would be like for $y -> @y { for $x -> @x { print "$x,$y\n"; } } My question is that, though TMTOWTDI is a Good Thing, and in general dictating style is a Bad Thing, is this much flexibility a Good Thing or a Bad Thing? And more importantly, will the people writing the parser become homicidal if it is decided this should be implemented? Still, print for @x for @y; # @y's topic masked would probably make no sense unless it's a rather twisted form of recursion, and for that I'd recommend writing a function rather than setting up reference loops.... > I also think this gives a nice symmetry of various operators that > only differ in L2R/R2L and precedence (plus the ability to overload > ofcourse): > > $x and $y $y if $x > $x or $y $y unless $x > $x . $y $y <~ $x > $x ( $y ) $y ~> $x I have no idea what you mean by this. Paul __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/