* Mark J. Reed <[EMAIL PROTECTED]> [2008-12-03 20:30]:
> OK, so let's look at the general problem. The structure is this:
> doSomething();
> while (someCondition())
> {
>     doSomethingElse();
>     doSomething();
> }
> ...and you want to factor out the doSomething() call so that it only
> has to be specified once.
> Is that correct, Aristotle?


> The "gotcha" is that the first doSomething() is unconditional,
> while the first doSomethingElse() should only happen if the
> loop condition is met (which means just moving the test to the
> end of the block doesn't solve the problem).


> Overall, the goal is to ensure that by the end of the loop the
> program is in the state of having just called doSomething(),
> whether the loop runs or not - while also ensuring that the
> program is in that state at the top of each loop iteration.

It’s not a goal in itself. It’s just a necessity: you cannot test
the loop condition without ensuring the invariant, so whether or
not the loop runs is irrelevant, you have to run it once before
you can know whether the loop will run at all.

> It does seem like a closure trait sort of thing, but I don't think
> it's currently provided by the p6 spec.

I don’t see anything suitable there either. And while it does
seems like a closure trait, that seems somewhat problematic in
that the order of evaluation is weird when compared to other
closure traits, which I suppose is what led you to declare the
“coy” solution as the most natural. I am trying to think of a
good block structure to capture these semantics spatially and
not currently coming up with anything very good.

* Mark J. Reed <[EMAIL PROTECTED]> [2008-12-03 20:40]:
> We can guarantee it's set at the top of each loop iteration
> with ENTER, but that doesn't get run if the loop never runs.
> We can guarantee it's set at the end of the loop with LAST, but
> that also doesn't get run if the loop never runs, and doesn't
> take care of the first iteration.

For the purposes of this particular problem, there isn’t even
much difference between those two.

* Patrick R. Michaud <[EMAIL PROTECTED]> [2008-12-03 21:10]:
> Perhaps PRE ... ?
>     while (someCondition()) {
>         PRE { doSomething(); }
>         doSomethingElse();
>     }

The problem is, doSomething() has to be run *prior* to *any* loop
condition check – including the very first. PRE (or ENTER) can’t
do that.

> Or, if you wanted to be sure that doSomething() is always called
> at least once:
>     repeat {
>         PRE { doSomething(); }
>         doSomethingElse();
>     } while someCondition();

That will run doSomething() once unconditionally. That’s not what
I’m after.

*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
#Aristotle Pagaltzis // <http://plasmasturm.org/>

Reply via email to