Sort of "do it once" feature request...

[Michele Dondi]

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?"

[Joshua Gatcomb]

On 9/21/05, Michele Dondi <bla...@pcteor1.mi.infn.it> wrote:
>
> 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
> }

I have mocked up an example of how you could do this in p5 with some ugly
looking code:

#!/usr/bin/perl
use strict;
use warnings;

do_something(5);

sub do_something {
my $target = shift;

my $block;

my $block2 = sub {
print "No need to check $_ against $target anymore\n";
};

my $block1 = sub {
no warnings;
if ( $_ == $target ) {
print "Skipping 5\n";
$block = $block2;
next LOOP;
}
else {
print "$_ is not $target\n";
}
};
$block = $block1;

LOOP:
for ( 1 .. 9 ) {
$block->();
}
}

Once the condition has been met, the code dynamically changes to no longer
check for the condition. Keep in mind, you are paying the price of
dereferencing as well as ENTER/LEAVE on subs to get this "performance"
benefit.

I will be interested to see what the experts say on this. I have often
desired this in long tight running loops and found that the ways to achieve
it (as shown above) are worse then leaving the op in.

Michele
>

Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region

[Michele Dondi]

On Wed, 21 Sep 2005, Joshua Gatcomb wrote:

> I have mocked up an example of how you could do this in p5 with some ugly
> looking code:

You may be interested to know that this has had an echo at

http://www.perlmonks.org/index.pl?node_id=493826

mostly misunderstood in the replies, IMHO. Basically the idea is that
not unexpectedly if you want a workaround TIMTWOWTDI already in Perl5. But
what is conceptually interesting would be the possibility, In L~R's much
better phrasing than mine, of modifying the optree or (P6's equivalent) as
the code is running. The only ad-hoc solution given there that is really
along these lines is Diotalevi's one at

http://www.perlmonks.org/index.pl?node_id=493947

which -not completely undexpectedly either- made my head hurt... ;-)

Michele
--
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

[Michele Dondi]

On Wed, 21 Sep 2005, Joshua Gatcomb wrote:

> Cheers,
> Joshua Gatcomb
> a.k.a. Limbic~Region

Oops... I hadn't noticed that you ARE L~R...

Michele
--
Your ideas about Cantorian set theory being awful suffer from the
serious defect of having no mathematical content.
- Torkel Franzen in sci.math, "Re: Die Cantor Die"

[Austin Hastings]

Michele Dondi wrote:

> On Wed, 21 Sep 2005, Joshua Gatcomb wrote:
>
>> Cheers,
>> Joshua Gatcomb
>> a.k.a. Limbic~Region
>
>
> Oops... I hadn't noticed that you ARE L~R...
>

In the tradition of i18n, etc., I had assumed that L~R was shorthand for
Luke Palmer. You may want to keep up the old tradition of defining your
acronyms once. :)

=Austin

[Juerd]

Piers Cawley skribis 2005-09-26 16:34 (+0100):
> And you've done it again. What you ask for is already there. See below.
> next if (($_ ne 'boo')..undef)
> if 0..MAX { push @buffer, $_; next }

IIRC, flip flop will not return as the ".." operator. Also, the global
state of syntactic flip flops makes me be afraid of using them in subs.

Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

[Piers Cawley]

Michele Dondi <bla...@pcteor1.mi.infn.it> writes:

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

And you've done it again. What you ask for is already there. See below.

>

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

for @foo {

next if (($_ ne 'boo')..undef)

# do something useful
}

> 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, $_;
> }

while <> {

if 0..MAX { push @buffer, $_; next }

end

--
Piers Cawley <pdca...@bofh.org.uk>
http://www.bofh.org.uk/

[Larry Wall]

On Mon, Sep 26, 2005 at 05:42:31PM +0200, Juerd wrote:
: Piers Cawley skribis 2005-09-26 16:34 (+0100):

: > And you've done it again. What you ask for is already there. See below.
: > next if (($_ ne 'boo')..undef)
: > if 0..MAX { push @buffer, $_; next }
:
: IIRC, flip flop will not return as the ".." operator.

That's correct, though we haven't decided what to call the flipflop
operator. Wants to be relatively long, huffmanly speaking, so
flipflop() could work. Could maybe be infix:<thru> or infix:<till> or
some such. Could have ^ forms as well. I'm not sure about preserving
the line number hack though.

: Also, the global

: state of syntactic flip flops makes me be afraid of using them in subs.

When you say that sort of thing nowadays, think "state" variables. So

if truify() till falsify() {...}

macroizes to something like:

if state $s ?? $s = falsify() !! $s = truify() {...}

Actually, I think that's the old ... operator. You'd write it slightly
differently to allow it to falsify immediately.

if state $s ?? $s = falsify() !! $s = truify() && !falsify() {...}

Or something like that...

But yes, even with that desugaring, it does mean you're not writing
"pure" code in the functional sense.

Larry

[TSa]

HaloO,

Larry Wall wrote:
> ... though we haven't decided what to call the flipflop operator.

Sorry, I'm totally out of scope to what 'the flipflop operator' is.
Could you be so kind to give some hints. Thanks in advance.

> if state $s ?? $s = falsify() !! $s = truify() && !falsify() {...}
>
> Or something like that...

It is beautiful to see all these double-char boolean connectives at work
but again I'm hopelessly confused what you are referring to.

BTW, has dropping the '::' from the ternary alleviated its beeing a macro
and it has now a simple

infix:<?? !!>:(&condition, &true_block, &false_block --> Bit) {...}

signature? The Bit there is actually oversimplified because it should be
the supertype of the two alternative blocks.
--
$TSa.greeting := "HaloO"; # mind the echo!

[Juerd]

TSa skribis 2005-09-26 19:39 (+0200):

> Sorry, I'm totally out of scope to what 'the flipflop operator' is.
> Could you be so kind to give some hints. Thanks in advance.

http://perldoc.perl.org/perlop.html#Range-Operators

[TSa]

HaloO,

Juerd wrote:
> TSa skribis 2005-09-26 19:39 (+0200):
>
>>Sorry, I'm totally out of scope to what 'the flipflop operator' is.
>>Could you be so kind to give some hints. Thanks in advance.
>
>
> http://perldoc.perl.org/perlop.html#Range-Operators

Thanks. I'm glad that 1..Inf these days is just a lazy
closure or some such. Does someone consider this 'inner
boolean state' and the 'magical auto-increment algorithm
if the operands are strings' of the Perl5 range op a feature
worth preserving?

[Juerd]

TSa skribis 2005-09-26 20:32 (+0200):

> Does someone consider this 'inner boolean state' and the 'magical
> auto-increment algorithm if the operands are strings' of the Perl5
> range op a feature worth preserving?

Yes, many someones do.