"Ben Hinkle" <ben.hinkle@gmail.com> wrote:

[...]
> I don't the see the
> usefulness of a step other than 1 or -1 for trees, though. but
> for lists of things it would be handy.

For trees without any ordering of the nodes there are only two natural traversals: breadth-first and depth-first and none of them maps to an integer in a natural way. If the tree is implemented as linked cells of an array, then there are two more "natural" traversals defined by the ordering of the cells of the array. And whenever I say "for each node in tree" I mean that the choosen traversal is unimportant, that is in addition to the free choosing of the traversal any permutations of the elements is allowed.

The same holds for lists.

Whenever the order does matter you have to describe how to choose the next element and that is done be a `for'-loop. On which criteria has the decision to be made to a `for' or a `foreach' if both have nearly identical semantics?


> I'll give an example from MATLAB. It is common to pass around string-value lists like ['Color', 'red', 'LineWidth', 2.4, 'LineStyle', ,'--'] and then have code that runs down the strings or values by stepping by 2.
> 
> An example closer to D would be having a list of points in a polygon and wanting to draw only every 3rd point for increased performance.

Thanks. But in both examples the order of the items does matter. And in the second example you said "every" not "each". SO it looks like you are talking about a new iterative statement `forevery' with a step-clause --- but not of modifying `foreach'.

Then the syntax should look like
  forevery( step; container; iterator)

-manfred

-manfred

"Andy Knowles" <andy.knowles@gmail.com> wrote in message news:cvm7hp$2lr4$1@digitaldaemon.com...
> Perhaps a good all round extension to the foreach statement would be if it took delegates to iterators as well.
[mega-snip]

That is a pretty neat idea. It got me thinking. A post of Manfred's on this
thread mentioned breadth-first and depth-first traversals and it would be
nice to be able to specify which kind of traversal you want in a foreach (if
the tree supplied those). Using your propsed syntax,
  foreach(int i; &foo.breadthFirst)
    writefln(i);
  foreach(int i, &foo.depthFirst)
    writefln(i);
(plus most likely the reverse versions of breadth and depth first).

Yet another way to skin this cat is to allow trailing parameters to foreach.
For example
  class Foo {
    int opApply(int delegate(inout int) dg, bool reverse = false) { ... }
  }
that can be used like
  foreach(int x; obj) { ... } % called with reverse = false
or
  foreach(int x; obj; true) { ... }% called with reverse = true

Or users can pass a step parameter if allowed:
  class Foo {
    int opApply(int delegate(inout int) dg, int step = 1) { ... }
  }
  foreach(int x; obj; 2) { ... }% called with step = 2

Or users can pass a flag for tree traversals:
  const int BreathFirst = 0;
  const int DepthFirst = 1;
  class Tree {
    int opApply(int delegate(inout int) dg, int method = BreadthFirst) {
... }
  }
  foreach(int x; obj) { ... }% called with method = BreadthFirst
  foreach(int x; obj; DepthFirst) { ... }% called with method = DepthFirst

Anyhow, I hope foreach gets something like any of these ideas- it would be
pretty useful to customize traversals.
-Ben

Regan Heath wrote:
> On Thu, 24 Feb 2005 05:34:44 +0000 (UTC), James Dunne  <jdunne4@bradley.edu> wrote:
> 
>> In article <opsmooadap23k2f5@ally>, Regan Heath says...
>>
>>>
>>> On Thu, 24 Feb 2005 03:41:02 +0000 (UTC), James Dunne
>>> <jdunne4@bradley.edu> wrote:
>>>
>>>> In article <opsmol1osx23k2f5@ally>, Regan Heath says...

> 
>> Besides, adding a step, start, and end to the current foreach syntax has  the
>> possibility of breaking code as it stands now.
> 
> 
> I think breaking code pre 1.0 is ok, case by case, if we want to we'll  have to consider it.

That is certainly true. Rather break as much as needed right now,
than some later.

Of course, any programmer who does even remotely "production" code
does keep the precise version of compiler around. And for added
security, zipped in the same file as his app sources!

In a larger environment, of course the compiler versions are
archeived anyway, so you only label the app as using V x.xx.0x.