www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unofficial wish list status.(Mar 2009)

reply 4tuu4k002 sneakemail.com writes:
Hi

This is the monthly status for the unofficial d wish list: 
http://all-technology.com/eigenpolls/dwishlist/

Right now the wish list looks like this:

198  Stack tracing (#26)
192  Reflection API (#6)
131  vectorization (#10)
110  Multiple return values (tuples (#28)
98  Multiple opCast per class (#24)
90  Debug check for null reference (#52)
85  Native AMD64 codegen (#36)
77  Short syntax for new (#18)
74  !in (#44)
73  unit test after compilation (#1)
69  extra compiler values (#19)
63  Return-type overloading (#49)
57  Explicit out/inout (#38)
54  Foreach on first/on last (#42)
53  Unit test isolation  (#2)
49  Posix threads support native (#3)
46  Array pushback/popback (#51)
45  Array masking (#11)
45  Variadic arguments re-passing (#102)
44  better syntax for cast (#23)
44  Consistent struct/class sizeof (#40)
41  Explicit type initializers (#35)
41  L-Value return (#73)
37  Named keyword arguments (#87)
36  black box unit testing (#8)
35  associative arrays by index (#16)
35  struct constructor (#97)
34  unit test & code separation (#7)
34  Non-Static isExpression (#37)
34  Explicit module `friendship` (#43)
33  coherent assoc. array syntax (#20)
33  Pass value params byref (#34)
33  auto-member objects (#45)
31  Conditional syncronized (#30)
29  Unit test measurements (#9)
29  Explicit property keyword (#83)
27  Inline enum declaration (#76)
26  Renaming ctor/dtor (#17)
24  User-defined sync function (#31)
24  Small Exectables (#88)
23  interface to C++ (#71)
22  proper cast operators (#21)
22  Iterators and Generators (#58)
22  Pascal like sets (#61)
22  if, while, true, false, int (#86)
21  Built-in variant type (#56)
20  Precise names for floats (#62)
17  D library contest (#59)
17  No Postfix Array Declarations (#85)
17  range type (#106)
17  Full lexical closures (#140)
16  Real C bitfields (#145)
15  garbage collection switch  (#96)
15  Multi-Dimensional Allocation (#109)
14  Finite sets (#72)
14  opCast overloading (#81)
14  copy operator (#95)
13  Call log (#47)
13  Improve module architecture (#64)
13  conv() and opConv (#66)
13  Meta Information (#69)
13  modules must not rely on files (#84)
11  inout variable and return (#60)
11  imag and comp FP types. (#63)
11  inline expansion (#67)
10  In flight exception detection (#101)
9  Against class instance sizeof (#48)
9  function inheritance (#92)
8  Relational class/array algebra (#65)
8  Parallel Scavenging GC (#80)
8  in for arrays (#160)
8  Get rid of const (#165)
7  Statically check for == null (#98)
7  support struct&array in switch (#99)
7  date/time/datetime literal (#105)
7  void Class.Method() {} syntax (#146)
7  static foreach(scope/unscope) (#152)
7  in for arrays (#161)
7  throws keyword (#173)
6  Declaration in function calls (#74)
6  array in template arguments (#91)
6  Efficient array opCatAssign (#148)
5  Better UTF32 Support (#113)
5  First-class continuations (#141)
5  Implicit New (#143)
4  named tuple (#103)
4  Explicit out/inout/lazy (#110)
4  {Cleaner Operator Overloading} (#166)
4  suffix identifiers. (#168)
4  Tango to work with D2 (#179)
3  System.Windows.Forms (#93)
3  Reallocation Keyword (#108)
3  function call over network (#111)
3  Property shortcut (#144)
3  variable template(short syntax (#149)
3  template literal (#150)
3  tuple literal and append-op (#151)
3  ext property for  basic types (#154)
3  Custom Attributes (#159)
3  templated constructors (#164)
3  Remove const (#171)
3  Remove const (#172)
3  Property declarator (#174)
3  Voting in bugzilla for D. (#176)
3  Power operator (#177)
2  Manage .resources files (#70)
2  Multistep return (#75)
2  constant operater overloading (#100)
2  solve interdepend static this (#107)
2  Quick For Syntax (#142)
2  invariant function (#156)
2  constant member functions (#158)
2  Keyword Pow Operator (#162)
2  Custom Syntax (#163)
2  C++ Member Pointers (#167)
2  New Switch Case Design (#170)
2  Template inst. syntax: <> (#182)
1  consistant new (#77)
1  temp alias param specialize (#112)
1  remove initializers (#147)
1  __traits (#153)
1  temporary variable (#155)
1  Dynamic Conditional (#157)
1  Better Array Function Template (#169)
1  Remove SFINAE (#175)
1  Enum string cast (#178)
1  Auto const member funcs (#180)
1  Overlapping array copy (#181)
1  Template inst. syntax: <> (#183)
1  Template inst. syntax: <> (#184)
1  Invariant => invar (#185)
1  similar templt/function syntax (#186)
1  classes on stack (or ROM) (#188)
1  Easy threading a la OpenMP (#189)
0  -nogc option (#187)
Feb 28 2009
parent reply "Tim M" <a b.com> writes:
On Sun, 01 Mar 2009 13:27:43 +1300, <4tuu4k002 sneakemail.com> wrote:

 Hi

 This is the monthly status for the unofficial d wish list:
 http://all-technology.com/eigenpolls/dwishlist/

 Right now the wish list looks like this:

 198  Stack tracing (#26)
 192  Reflection API (#6)
 131  vectorization (#10)
 110  Multiple return values (tuples (#28)
 98  Multiple opCast per class (#24)

http://all-technology.com/eigenpolls/dwishlist/index.php?it=10 Who's idea was the vectorization? Seems very usefull but not sure if really like the syntax. Wouldn't it be simpler to have unordered attribute for all kinds loops that the compiler can use?
Feb 28 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 7:55 PM, Tim M <a b.com> wrote:
 Who's idea was the vectorization? Seems very usefull but not sure if really
 like the syntax. Wouldn't it be simpler to have unordered attribute for all
 kinds loops that the compiler can use?

D already has some simple vectorization features: int[] a = [1, 2, 3, 4, 5]; auto b = a[] + 5; // [6, 7, 8, 9, 10] auto c = a + b; // [7, 9, 11, 13, 15]
Feb 28 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Tim M wrote:
 Through out that page it shows examples of iterations where order is not
 actually defined, the index has to modify by one but it gives the
 compiler the ability to create a few threads and execute in parallel.
 Thats what I was actually talking about. I would hate for that code to
 be valid and would prefer to use the usual while, do while, for and
 foreach loops but have an attribute to enable optimization eg:
 
 unordered for(i = 0; i < 10; ++i)
 {
    //anything here is independant of the previous iterations
    //and I dont care if compiler splits accross cpu cores
 }
 
 Anyway I still think there is of low priority over other things like
 cent data type but it is rated rather high.

C-style for is a pretty terrible construct for this. How can it be unordered when you've SPECIFIED that i increases linearly? Does that mean it's equivalent to this? unordered for(i = 9; i >= 0; --i) { ... } If so, then 60% of that statement is redundant. So let's try using foreach instead. unordered foreach( i ; 0..10 ) { ... } Much better. But now the compiler has to prove that it's actually possible to run this in arbitrary order. The easiest way to do this is to check to see whether the body of the foreach is pure or not. Problem there is that it CAN'T be pure; if it's pure, then the loop cannot produce any results. I think we have a better chance in stealing ideas from the functional world like parallel map, or map-reduce.
 pure int mutate(int x)
 {
     // some long calculation which mutates x
     return x;
 }

 pure int combine(int a, int b)
 {
     // some long calculation which mutates a and b
     return a + b;
 }

 auto results = pmap!(mutate)(inter[0..10]);

 // or...

 auto result = mapreduce!(mutate, combine)(inter[0..10]);

Because we've relinquished direct control over iteration and our functions are pure, the compiler is free to rewrite both those last two statements any way it pleases. It could distribute the workload across hardware threads, or even distribute it across machines; it doesn't matter. Another potential way of doing this would be to make the following valid: auto results = foreach( i ; 0..10 ) { ... continue 2*i; } Assuming the body of the foreach is pure, that might work. How you'd write a reduce with a loop, I have no idea. :P The nice thing about using functional constructs is that they're just functions; they can be implemented in a library without having to touch the language itself. -- Daniel
Mar 01 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Daniel Keep wrote:
 unordered foreach( i ; 0..10 )
 {
     ...
 }

If the foreach body consists of a pure function call, then the foreach is reorderable and parallelizable. Considering that, you could save a keyword and use 'pure' rather than 'foreach'. If you like the idea, send Walter a patch for this.
Mar 01 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Christopher Wright wrote:
 Daniel Keep wrote:
 unordered foreach( i ; 0..10 )
 {
     ...
 }

If the foreach body consists of a pure function call, then the foreach is reorderable and parallelizable. Considering that, you could save a keyword and use 'pure' rather than 'foreach'. If you like the idea, send Walter a patch for this.

I *don't* like this; I was pointing out that it doesn't work. Let's say the body is pure. Pure means that it only depends on its arguments and doesn't use or mutate any non-immutable external state. So you do lots of computations based on i. Now, how do you store the result? You *can't*, because that would involve changing state external to the loop. As Tim said, you can go to lock-based programming. But that's just reinventing the problem we have today with multithreading: it's virtually impossible to do it right. The point is that by the time you've munged foreach or whatever into a state suitable for automatic parallelisation, you've likely just gone and reinvented the map function, so you might as well just cut to the chase and use that. That plus pure functions should make it virtually impossible to get it *wrong*. -- Daniel
Mar 01 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Tim M" <a b.com> wrote in message news:op.up3qsai6jdp9fl tim-laptop...
 On Sun, 01 Mar 2009 16:58:15 +1300, Jarrett Billingsley 
 <jarrett.billingsley gmail.com> wrote:

 On Sat, Feb 28, 2009 at 7:55 PM, Tim M <a b.com> wrote:
 Who's idea was the vectorization? Seems very usefull but not sure if 
 really
 like the syntax. Wouldn't it be simpler to have unordered attribute for 
 all
 kinds loops that the compiler can use?

D already has some simple vectorization features: int[] a = [1, 2, 3, 4, 5]; auto b = a[] + 5; // [6, 7, 8, 9, 10] auto c = a + b; // [7, 9, 11, 13, 15]

I have no problems with that code there. http://all-technology.com/eigenpolls/dwishlist/index.php?it=10 Through out that page it shows examples of iterations where order is not actually defined, the index has to modify by one but it gives the compiler the ability to create a few threads and execute in parallel. Thats what I was actually talking about. I would hate for that code to be valid and would prefer to use the usual while, do while, for and foreach loops but have an attribute to enable optimization eg: unordered for(i = 0; i < 10; ++i) { //anything here is independant of the previous iterations //and I dont care if compiler splits accross cpu cores } Anyway I still think there is of low priority over other things like cent data type but it is rated rather high.

Daniel mentioned part of the problem with that. The other problem I have with it is that in most cases it mixes two different levels of abtraction. You can't look at the code and immediately see the "what" without first analysing the "how". If I look at that code, the *first* thing I comprehend should not be "make 'i' go from 0 to 10, and then do somthing with 'i'", it should be, "Ok, this is calculating a single particular value from an array, ie, min, max, sum, doesBlahBlahExist, indexOfBlahBlah, whatever", or "This is transforming (or outputting, or inputting) the content of a collection", or "combining two collections in some way" etc. That's the stuff I want to know, the "what". The "how" belongs elsewhere, at an entirely different level of abstraction. That's the whole point of having functions in the first place, separating that "what" from the "how", otherwise we'd all be writing asm. (Of course, comments can be used to explain the intended "what", but self-documenting code is better whenever possible.)
Mar 01 2009
prev sibling next sibling parent "Tim M" <a b.com> writes:
On Sun, 01 Mar 2009 16:58:15 +1300, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:

 On Sat, Feb 28, 2009 at 7:55 PM, Tim M <a b.com> wrote:
 Who's idea was the vectorization? Seems very usefull but not sure if  
 really
 like the syntax. Wouldn't it be simpler to have unordered attribute for  
 all
 kinds loops that the compiler can use?

D already has some simple vectorization features: int[] a = [1, 2, 3, 4, 5]; auto b = a[] + 5; // [6, 7, 8, 9, 10] auto c = a + b; // [7, 9, 11, 13, 15]

I have no problems with that code there. http://all-technology.com/eigenpolls/dwishlist/index.php?it=10 Through out that page it shows examples of iterations where order is not actually defined, the index has to modify by one but it gives the compiler the ability to create a few threads and execute in parallel. Thats what I was actually talking about. I would hate for that code to be valid and would prefer to use the usual while, do while, for and foreach loops but have an attribute to enable optimization eg: unordered for(i = 0; i < 10; ++i) { //anything here is independant of the previous iterations //and I dont care if compiler splits accross cpu cores } Anyway I still think there is of low priority over other things like cent data type but it is rated rather high.
Feb 28 2009
prev sibling next sibling parent "Tim M" <a b.com> writes:
On Sun, 01 Mar 2009 21:25:10 +1300, Daniel Keep  
<daniel.keep.lists gmail.com> wrote:

 Tim M wrote:
 Through out that page it shows examples of iterations where order is not
 actually defined, the index has to modify by one but it gives the
 compiler the ability to create a few threads and execute in parallel.
 Thats what I was actually talking about. I would hate for that code to
 be valid and would prefer to use the usual while, do while, for and
 foreach loops but have an attribute to enable optimization eg:

 unordered for(i = 0; i < 10; ++i)
 {
    //anything here is independant of the previous iterations
    //and I dont care if compiler splits accross cpu cores
 }

 Anyway I still think there is of low priority over other things like
 cent data type but it is rated rather high.

C-style for is a pretty terrible construct for this. How can it be unordered when you've SPECIFIED that i increases linearly?

Compilers are intelligent.
 Does that mean it's equivalent to this?

 unordered for(i = 9; i >= 0; --i)
 {
     ...
 }

 If so, then 60% of that statement is redundant.  So let's try using
 foreach instead.

 unordered foreach( i ; 0..10 )
 {
     ...
 }

 Much better.  But now the compiler has to prove that it's actually
 possible to run this in arbitrary order.

The idea is that iteration two doesnt have to come after 1 as you specify to the compiler that it doesnt matter. You are also adding extra syntax and it would be best if D didn't do that because before you know it will become to ambiguous to the compiler, not saying that alone is ambiguous though.
 The easiest way to do this is
 to check to see whether the body of the foreach is pure or not.  Problem
 there is that it CAN'T be pure; if it's pure, then the loop cannot
 produce any results.

Pure shouldn't be required. If you need you can put you locks in place but pure is too restricted. Anyway pure is so the compiler can parralise anyway. Most of the need for pure is that parralel will be there automatically by default.
Mar 01 2009
prev sibling parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Tim M wrote:
 On Sun, 01 Mar 2009 13:27:43 +1300, <4tuu4k002 sneakemail.com> wrote:
 
 Hi

 This is the monthly status for the unofficial d wish list:
 http://all-technology.com/eigenpolls/dwishlist/

 Right now the wish list looks like this:

 198  Stack tracing (#26)
 192  Reflection API (#6)
 131  vectorization (#10)
 110  Multiple return values (tuples (#28)
 98  Multiple opCast per class (#24)

http://all-technology.com/eigenpolls/dwishlist/index.php?it=10 Who's idea was the vectorization? Seems very usefull but not sure if really like the syntax. Wouldn't it be simpler to have unordered attribute for all kinds loops that the compiler can use?

I don't remember who had the idea originally, but Norbert Nemec and me discussed it way back around 2004 and I added it when the wishlist went online. For old posting search the news group for vectorization. http://www.google.com/search?q=vectorization&domains=www.digitalmars.com&sitesearch=www.digitalmars.com%2Fd&sourceid=google-search&submit=Go If you suggest a new syntaks, then try to write down the examples on http://all-technology.com/eigenpolls/dwishlist/index.php?it=10 using it. Most people is quick to suggest a new syntaks without actuly testing it by writing down some non-trivial examples. -- Crowdnews.eu - a social news site based on sharing instead of voting. Follow me on CrowdNews http://crowdnews.eu/users/addGuide/42/
Mar 02 2009