Component Programming in D

Nick Sabalausky SeeWebsiteToContactMe at semitwist.com
Tue Oct 2 18:43:44 PDT 2012


On Wed, 03 Oct 2012 03:05:08 +0200
"Jonathan M Davis" <jmdavisProg at gmx.com> wrote:

> On Tuesday, October 02, 2012 17:27:55 Andrei Alexandrescu wrote:
> > http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in
> > _d/
> 
> It's definitely the sort of article that we've needed to show what
> we're trying to do with ranges.
> 

Yes, and also why a lot of D's features, esp its metaprogramming
features, are so significant. And why most other languages, including
dynamic languages, don't even come close.

I think I'm starting to get a sense of the next big step, though. There
are other misc improvements I'd like to see, but I think the biggest
weakness our range approach faces now (even as far ahead as we are) is
the effort and, arguably, boilerplate to actually create the ranges.

Especially input/forward ranges: It's pretty well known and accepted
(esp. to those who have created input/forward ranges) that the easiest
way to make a generator is with a straight imperative function. But
ranges turn the whole logic inside-out. Walking a tree can get
particularly convoluted.

So I think the next *big* step from here, in D3 or some other D-derived
language, would be easing the creation of ranges. For example, a
special low-boilerplate syntax for creating bidirectional and
random-access ranges. Or for input (or maybe even forward) ranges, a
C#-style compile-time transformation of a generator function into a
range (With input ranges, you can technically get around needing source
transformation right now in D2 using fibers, but that has too
much runtime overhead to be used as a general solution).



More information about the Digitalmars-d-announce mailing list