"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bjam8u$21if$1@digitaldaemon.com...
> I agree this is a little slower, BUT removes the "magic" from the programmers view, I feel the int magic although a little faster does expose the inner workings a little too much and is a bug waiting to
happen.

That would work just as well, but I don't think there's any real difference.

Walter wrote:
> "Mike Wynn" <mike@l8night.co.uk> wrote in message
> news:bjam8u$21if$1@digitaldaemon.com...
> 
>>I agree this is a little slower, BUT removes the "magic" from the
>>programmers view, I feel the int magic although a little faster does
>>expose the inner workings a little too much and is a bug waiting to
> 
> happen.
> 
> That would work just as well, but I don't think there's any real difference.
> 

the inner workings of the block->nested_function/delgate is hidden from the programmer.
the apply method can not cause unexpected errors by returning a silly value.
to experienced D/C developers maybe there is no difference, but to those new to D, I think the need to keep the return value from the delgate and pass it back may seem odd, (and who reads the manual?)

to me the difference is that its more robust, no "you need to know this to use X", and the types used reflect their use explicitly.

"Walter" <walter@digitalmars.com> wrote in message news:bj9ha5$eff$1@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bj9eod$aps$1@digitaldaemon.com...
> > Will it inline these calls to the nested function if everything is
final?
>
> No, since it is done as a pointer to a function.

Can you make it a referece to a function instead so future compilers can inline it if they want?  This is the great thing about STL's for_each.

> > One nice thing about having actual iterators is that you can form a
range
> > over which to iterate.  It doesn't sound like this setup allows that...
it
> > just allows sequentially iterating from the beginning until the Apply() function decides to return a "stop" value or it hits the end, correct? Granted, 90% of the cases would want to iterate the entire container,
but in
> > the other 10% it may prove a bit constrictive.
>
> The secret to modifying this for specific cases is to override/modify the apply(). Here's a little template technique to run an array in reverse:

So to iterate over a range you can just make a slice and iterate that, I guess.  ;)

> All the container needs is an apply() function - no need for iterators. I have never particularly liked the iterator paradigm, as it just involves lots of cruft to write. Things get really ugly when trying to write an iterator for a recursive structure, articles on iterators tend to ignore these cases and show instead the trivial ones. The C# people seem to be trying to get around this by using coroutines, but the complexities of
that
> are just too awful. There hasn't been a foreach in D before because I just could never figure out a solution that I liked, and then finally had a brainwave about using a magic nested function.

I'm glad you figured it out!  It seems like a pretty good solution.

> The more I use nested functions, it turns out, the more useful they become <g>.

Awesome!

One thing you might think about is the name apply().  Most functional languages would call this feature "map".  With D having associative arrays built in, there's not much need for STL-style map container, so this may be an ok name.

Sean

"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bjam8u$21if$1@digitaldaemon.com...
> Walter wrote:
> >
> > The need for it to return an int rather than bit is because of the
compiler
> > 'magic' involved with making this work. The foreach body is transformed
into
> > a nested function (!). The return value is needed to handle the various
ways
> > of exiting the foreach body, such as goto, break label, return, etc. The foreach itself is replaced with a switch statement calling the apply function. It sounds a bit hairy, but that's all hidden from the
programmer.
> > The neato thing is there is no need to write state-preserving iterators,
a
> > rather tricky thing to get right for containers that are recursive or otherwise need state-preserving iterators.
>...
> simple break is just return false (stop iterating)
> simple continue is just return true (stop current iteration, but continue)
>
> I agree this is a little slower, BUT removes the "magic" from the programmers view, I feel the int magic although a little faster does expose the inner workings a little too much and is a bug waiting to
happen.

I agree... at very least consider making it an enum instead of a plain int.

Sean

"Sean L. Palmer" <palmer.sean@verizon.net> escreveu na mensagem news:bjcuo2$2c19$1@digitaldaemon.com...

[snip]

> One thing you might think about is the name apply().  Most functional languages would call this feature "map".  With D having associative arrays built in, there's not much need for STL-style map container, so this may
be
> an ok name.
>
> Sean

This isn't correct. In functional languages map is a function that transform one kind of collection in another. As a foreach can do several different things (e.g. sum the elements) it's just a matter of finding the correct name. For example in DTL I defined both a foreach function (a command to be executed for each item) and an apply function (a transformation to be applied for each array entry):


public void foreach(T[] array, void function(T) operation);
public void apply(inout T[] array, T function(T) operation);


IMO we should call this operation "forEach", but I'm ok with apply (I'll change DTL "apply" to "transform").

    Best regards,
    Daniel Yokomiso.

"Boss: "D?" What happened to C? Or that other one, C++, that you're always
harping about?
Me: Well, D is a further refinement of C++, and ...
Boss: Weren't you just telling me that "J" language was supposed to be the
next big thing? Isn't J further along than D?
Me: Yes and no ...
Boss: And if only want to make small changes, is a "+" higher than a "#"?
[suddenly, a shot rang out]"
 - sunwukong at /.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 29/8/2003

"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bjb0en$2gk9$1@digitaldaemon.com...
> Walter wrote:
> > "Mike Wynn" <mike@l8night.co.uk> wrote in message news:bjam8u$21if$1@digitaldaemon.com...
> >>I agree this is a little slower, BUT removes the "magic" from the programmers view, I feel the int magic although a little faster does expose the inner workings a little too much and is a bug waiting to
> > happen.
> > That would work just as well, but I don't think there's any real
difference.
> the inner workings of the block->nested_function/delgate is hidden from
> the programmer.
> the apply method can not cause unexpected errors by returning a silly
value.
> to experienced D/C developers maybe there is no difference, but to those
> new to D, I think the need to keep the return value from the delgate and
> pass it back may seem odd, (and who reads the manual?)
> to me the difference is that its more robust, no "you need to know this
> to use X", and the types used reflect their use explicitly.

Ok, I see your point, although am not convinced. If experience shows you to be correct, I'll change it. I'm also a bit reluctant to take the speed sacrifice, even though it is only a 3 or 4 instructions. This needs to be speed competitive with C++.

Walter wrote:
> "Mike Wynn" <mike@l8night.co.uk> wrote in message
> news:bjb0en$2gk9$1@digitaldaemon.com...
> 
>>the inner workings of the block->nested_function/delgate is hidden from
>>the programmer.
>>the apply method can not cause unexpected errors by returning a silly
> 
> value.
> 
>>to experienced D/C developers maybe there is no difference, but to those
>>new to D, I think the need to keep the return value from the delgate and
>>pass it back may seem odd, (and who reads the manual?)
>>to me the difference is that its more robust, no "you need to know this
>>to use X", and the types used reflect their use explicitly.
> 
> 
> Ok, I see your point, although am not convinced. If experience shows you to
> be correct, I'll change it. I'm also a bit reluctant to take the speed
> sacrifice, even though it is only a 3 or 4 instructions. This needs to be
> speed competitive with C++.
> 

I did think about that, I'm not convinced that it will be slower, EAX will be free as a temp until the return value is assign, instead of it having to retain the value or be spilled to the stack.

on other platforms the same may be true too, ARM for instance uses R0..R3 as the first 4 params and also as the return/temp regs, (I think MIPS is the same) which would force you to save R0 on each loop.

I know you only need to save it if its not 0, in which case you should be exiting the loop so want it as a return value, but the iterator might call another function (hence it need storing across the func call on almost all archs,  sparc with reg windows is about the only one i can thnk of that might not be effected.

this has to be done inside the iterating loop, where as saving the "enum" to the parent frame is only done once at the time that it needed (just before exiting prematurly) it seems to me it might actually be faster.