--- 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/