Every time I've desired a feature for Perl6 it has turned out that either
it was already planned to be there or I have been given good resons why it
would have been better not be there.
Now in Perl(5) {forum,newsgroup}s you can often see people doing stuff
like
my @files=grep !/^\.{1,2}/, readdir $dir;
Letting aside the fact that in the 99% of times they're plainly
reinventing the wheel of glob() a.k.a. File::Glob, there are indeed
situations in which one may have stuff like
for (@foo) {
next if $_ eq 'boo';
# do something useful here
}
whereas they know in advance that C<if> can succeed at most once (e.g. foo
could really be C<keys %hash>).
Or another case is this:
while (<>) {
if (@buffer < MAX) {
push @buffer, $_;
next;
}
# ...
shift @buffer;
push @buffer, $_;
}
in which one wouldn't like the C<if> condition to be tested any more after
it first evaluated false. Now efficiency is seldom a real issue in all of
these situations, and in the rare cases in which it is one may adopt
alternative strategies, like prefilling @buffer (with apparent referal to
the previous example). In some cases one could need refactoring into subs
to avoid duplication of code, but then the original logic may have been
more clear intuitively to start with...
Whatever, I feel slightly uncomfortable psychologically with the idea of
something that will be tested even when it's not necessary. So now I
wonder if Perl6 is already expected to provide syntactical sugar enough to
do what I want: which something easy enough to type to make a portion of
code (behave like it) "silently evaporate"(ed) after a condition has been
verified for the first time (or, say, n times). I think this is similar
to the functionality of macros, but as I said, this should be -to be
really useful- only a moderate bunch of keystrokes away from the code that
doesn't employ it...
Michele
--
I just said it was my conjecture. That doesn't mean I think it's right. :-)
- Larry Wall in p6l, "Subject: Re: What do use and require evaluate to?"
