Re: Support for ensuring invariants from one loop iteration to the next?

[John Macdonald]

On Thu, Dec 04, 2008 at 04:40:32PM +0100, Aristotle Pagaltzis wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-12-03 21:45]:
> > loop {
> > doSomething();
> > next if someCondition();
> > doSomethingElse();
> > }
> 
> I specifically said that I was aware of this solution and that I
> am dissatisfied with it. Did you read my mail?

While this is still the same solution that you dislike, how about
recasting it a bit:

loop {
PRE_CONDITION: {
doSomething();
}

last unless someCondition();

BODY: {
doSomethingElse();
}
}

That uses additional indenting and labelling to identify the iteration-setup
and actual loop body parts, and keeping the termination condition easily
visible with non-indenting.

Re: Support for ensuring invariants from one loop iteration to the next?

[Aristotle Pagaltzis]

* David Green <[EMAIL PROTECTED]> [2008-12-05 15:45]:
> I tried to break down the reasons for wanting to write such
> loops different ways:
>
> 1) Simple code […]
> 2) Clear code […]
> 3) Self-documenting code […]

Yes, exactly right.

> What we need is something a bit like  the "continue" block,
> except that it gets executed before the loop- condition is
> checked the first time.  So what if we split the loop-body into
> two parts?
>
>   repeat { something(); }
>   while ( condition(); )
>   { something_else(); }
>
>
> Now the condition is in the middle and is syntactically
> separate. (It's still not up front, but if the first block is
> really long, you can always... add a comment!)

I actually don’t think putting the condition up front is the most
desirable constellation. I just want the condition syntactically
highlighted and separated from both the loop body and the
invariant enforcement.

In fact, it seems more desirable to have the invariant
enforcement up top because the order of the code then corresponds
to the order of evaluation. That is the reason I wasn’t quite
happy with its being rendered as a closure trait.

Funnily enough, I think you’re onto something here that you
didn’t even notice: the following has the right semantics, apart
from the fact that it doesn’t perform any work:

repeat {
@stuff = grep { !.valid }, @stuff };
} while @stuff;

Now if we had a NOTFIRST (which would run before ENTER just as
FIRST does, but on *every* iteration *except* the first), then
we could trivially attain the correct semantics and achieve all
desired results:

repeat {
@stuff = grep { !.valid }, @stuff };
NOTFIRST {
.do_something( ++$i ) for @stuff;
}
} while @stuff;

The really nice thing about this is that the blocks are nested,
so that any variable in scope for the invariant enforcement will
also be in scope in the NOTFIRST block without the user ever
having to arrange another enclosing scope.


* David Green <[EMAIL PROTECTED]> [2008-12-05 16:50]:
> Well, you don't need a comment -- why not allow the condition to come
> first?
>
>   repeat while ( condition(); )
>   { something(); },
>   { something_else(); }
>
> You need the comma there because the final semicolon is
> optional, and we don't want Perl to think it's an ordinary loop
> followed by an independent block. Probably better is to name
> the introductory block, and then programmers as well as
> compilers know that something unusual is going on:
>
>   repeat while (condition)
>   preamble { something }
>   { something_else }

What I don’t like about these solutions is: how do you indent
them? If you try multiple statements on multiple lines within the
blocks, then suddenly there is no good and natural indentation
style for at least one of the blocks.

Also, you are supposed to be able to leave the parentheses off
the `while` condition in Perl 6, and then it breaks down
visually, particularly if you throw an arrow in there.

Regards,
-- 
Aristotle Pagaltzis // 

Re: how to write literals of some Perl 6 types?

[Dave Whipp]

Carl Mäsak wrote:

Paul (>):

I can't find anything in the existing synopses about Blobs.
Probably looking in the wrong place, sorry.


 


Re-reading that, a slightly tangent (though still on topic, I hope) 
thought come to mind. The definition of the Mapping immutable type:


Mapping Set of Pairs with no duplicate keys

The question is, what to do when a Mapping is created from a
source that contains pairs with duplicate keys? The Perl5 answer is 
simply to silently drop all but the last in the list ... but I can think 
of many other answers: sometimes you might want an error; other times 
you might want to create a list/set/bag from the values of the duplicate 
keys; other times a junction might be appropriate. One theme of P6 is to 
not lose information unnecessarily -- which is what P5 does here.


The option of creating a list of the values is interesting because, in 
scalar context, a list returns the value of its last item -- which is 
the existing P5 semantics but without losing information until the value 
is used as a scalar. And lists can be used to construct all the other 
interesting cases.


Will there be a syntax for choosing the strategy for reducing a list of 
pairs that contains duplicate keys to a "Mapping"?