Hmm, there seems to be some debate about this of late, does there not?

As far as I know, which is most of the successful languages of the last two or three decades, D's implementation of the foreach construct is *entirely* novel, being based on nested functions. This was entirely Walter's invention; though he was kind enough to involve me in its development, I barely managed to hold onto his coat-tails as it sped from nascent idea to brilliant implementation.

For anyone who needs/wants to know more, you should get this month's DDJ, containing our article "Collection Enumeration: Loops, Iterators and Nested Functions". It's also downloadable from http://ddj.com if you're a subscriber to any CMP magazines. In the article we offer a challenge to anyone who thinks it's easier to write an equivalent enumeration construct in C++ to download and compare the Phobos and the WinSTL (the Win32 sub-project of STLSoft; http://winstl.org) implementations of their respective registry enumeration components, since they had the same author.

If you want to contrast the levels of difficulty of collection enumeration implementations with other languages, you should be reading my "Positive Integration" column in CUJ. If you don't get CUJ, you can still constrast the implementations for C, C++ ("regular" classes), C++ (STL), C#, COM, D, and Java by downloading the distributions from the recls website (http://recls.org/downloads.html). If anyone digests that and _honestly_ tells me that D's solution is not the simplest to implement, I'll eat my hat.

Cheers

Matthew

I would argue that the combination of features is unique, otherwise you wouldn't see the activity around D that is evident today.

IMHO, the biggest step forward is that we have a systems programming language, compatible with C, that gets rid of the preprocessor. Having spent the last few years optmizing C++ code by transforming source-to-source based on a given library semantics, I can tell you that not a day goes by without me hoping that we will do this in D (or something very much like it) someday. Apart from the complexity of C++, the preprocessor is one of the primary reasons why tools for C/C++ are second-rate compared to those for Java, C#, Smalltalk, Lisp, etc.

One more comparison. The general notion of a type-safe systems programming language with objects and single inheritance is certainly not new. A very good example of what can be achieved is the Oberon System from ETH, Zurich. Hardware, OS, and programming language were designed and implemented by a small team of researchers and students in the late 80s to early 90s, and the results were quite impressive. Note that Oberon does not have generics or interfaces, the syntax is derived from Pascal (not my favorite), and the kernel was single-user, single-processor (no preemption). But it had some cool features like GC throughout, even for persistent objects like files. Although there were a few attempts at commercialization, its success in industry was not great. The only Swiss company that really went anywhere with the technology is a small shop called esmertec, which now specializes in (hard) realtime Java for embedded systems. From what I've seen and read, they are the only company that has demonstrated using Java this close to the machine, and with some impressive results regarding space and time efficiency -- they compile Java to machine code ahead of time.

I would love to see another OS and system library implemented based on modules, dynamic loading and linking, GC, etc. that doesn't expose its APIs as C functions. With D getting more traction, I think it's just a matter of time.

Just rambling...

Matthias

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c19kb1$1nad$1@digitaldaemon.com...
> Hmm, there seems to be some debate about this of late, does there not?
>
> As far as I know, which is most of the successful languages of the last
two
> or three decades, D's implementation of the foreach construct is
*entirely*
> novel, being based on nested functions. This was entirely Walter's invention; though he was kind enough to involve me in its development, I barely managed to hold onto his coat-tails as it sped from nascent idea to brilliant implementation.
>
> For anyone who needs/wants to know more, you should get this month's DDJ, containing our article "Collection Enumeration: Loops, Iterators and
Nested
> Functions". It's also downloadable from http://ddj.com if you're a subscriber to any CMP magazines. In the article we offer a challenge to anyone who thinks it's easier to write an equivalent enumeration construct in C++ to download and compare the Phobos and the WinSTL (the Win32 sub-project of STLSoft; http://winstl.org) implementations of their respective registry enumeration components, since they had the same
author.

One question I had after reading the DDJ article was about different kinds
of iterators. The foreach/nested-function implementation of forward
iterators
(enumerators) is very nice and general but how would reverse iterators or
other STL-like iterators work with nested functions?

It would be very satisfying to use the DDJ technique in more places than
just a forward iterator - otherwise there will be at least two ways to
iterate:
enumerators and STL-like iterators.

> If you want to contrast the levels of difficulty of collection enumeration implementations with other languages, you should be reading my "Positive Integration" column in CUJ. If you don't get CUJ, you can still constrast the implementations for C, C++ ("regular" classes), C++ (STL), C#, COM, D, and Java by downloading the distributions from the recls website (http://recls.org/downloads.html). If anyone digests that and _honestly_ tells me that D's solution is not the simplest to implement, I'll eat my hat.
>
> Cheers
>
> Matthew
>
>

Ben Hinkle wrote:
>
> One question I had after reading the DDJ article was about different kinds
> of iterators. The foreach/nested-function implementation of forward
> iterators
> (enumerators) is very nice and general but how would reverse iterators or
> other STL-like iterators work with nested functions?

See my post titled "foreach, slices, and reverse ranges."  I'm hoping we can agree on a way to expand the functionality of foreach.  But for other more C++-like work to be done, I think we may need to provide real iterators as well as trait information.  I'm currently working to get a "fun" project out the door but after that I'm going to start working on iterators.


Sean

"Sean Kelly" <sean@ffwd.cx> wrote in message news:c1g8qo$19uj$1@digitaldaemon.com...
> Ben Hinkle wrote:
> >
> > One question I had after reading the DDJ article was about different
kinds
> > of iterators. The foreach/nested-function implementation of forward
> > iterators
> > (enumerators) is very nice and general but how would reverse iterators
or
> > other STL-like iterators work with nested functions?
>
> See my post titled "foreach, slices, and reverse ranges."  I'm hoping we can agree on a way to expand the functionality of foreach.  But for other more C++-like work to be done, I think we may need to provide real iterators as well as trait information.  I'm currently working to get a "fun" project out the door but after that I'm going to start working on iterators.

Thinking out loud some more the foreach statement

 foreach(T x; y) <statement>

generates code that does something like

int stmt_callback(inout T x)
{
  while(1) {
    <statement>
    return 0;
  }
  return 1;
}
y(&stmt_callback);

Also there's a hook for an indexing variable

 foreach(S index, T x; y) <statement>

becomes

int stmt_callback(inout S index, inout T x)
{
  while(1) {
    <statement>
    return 0;
  }
  return 1;
}
y(&stmt_callback);

So to generalize this whole thing maybe it just works if you
declare a non-trivial index class S that overloads opIncrement, etc.
That way <statement> can increment and decrement the
index variable and the class/struct S has all the smarts about
what it means to increment or decrement.

Since the opApply for the container generates the indexer it can make whatever it wants. To do reverse iterating a small struct wrapper around the container could be whipped up that has a custom opApply that iterates backwards. So user code would look something like

 int[] y;
 ...
 foreach( int x; reverse_iter(y) ) {...}

It could work that no new syntax is needed to get the more complex iterators out of the current foreach semantics - just some struct and opApply trickery.

-Ben

Ben Hinkle wrote:
>
> It could work that no new syntax is needed to get the more complex
> iterators out of the current foreach semantics - just some struct
> and opApply trickery.

Yup, I think this is true.  But that still leaves a potential need for iterators to handle algorithm adaption.  Like "sort" may need to be implemented one way for random-access containers and another for sequential-access containers.


Sean

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c1fnmm$9mi$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c19kb1$1nad$1@digitaldaemon.com...
> > Hmm, there seems to be some debate about this of late, does there not?
> >
> > As far as I know, which is most of the successful languages of the last
> two
> > or three decades, D's implementation of the foreach construct is
> *entirely*
> > novel, being based on nested functions. This was entirely Walter's invention; though he was kind enough to involve me in its development, I barely managed to hold onto his coat-tails as it sped from nascent idea
to
> > brilliant implementation.
> >
> > For anyone who needs/wants to know more, you should get this month's
DDJ,
> > containing our article "Collection Enumeration: Loops, Iterators and
> Nested
> > Functions". It's also downloadable from http://ddj.com if you're a subscriber to any CMP magazines. In the article we offer a challenge to anyone who thinks it's easier to write an equivalent enumeration
construct
> > in C++ to download and compare the Phobos and the WinSTL (the Win32 sub-project of STLSoft; http://winstl.org) implementations of their respective registry enumeration components, since they had the same
> author.
>
> One question I had after reading the DDJ article was about different kinds
> of iterators. The foreach/nested-function implementation of forward
> iterators
> (enumerators) is very nice and general but how would reverse iterators or
> other STL-like iterators work with nested functions?
>
> It would be very satisfying to use the DDJ technique in more places than
> just a forward iterator - otherwise there will be at least two ways to
> iterate:
> enumerators and STL-like iterators.

As soon as time allows, Walter and I'll be battling like a couple of half-dead old stags in pursuit of DTL, and these issues will all be cropping up

It's going to be a few more weeks, though. :-(