www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D2 status interim report ?

reply Extrawurst <spam extrawurst.org> writes:
Hey Walter,
this is just a list of changes which were originally planned to be 
integrated into D2.0 according to the slides you and Andrei presented on 
DConference '07. So please give us a comment on what perhaps has changed 
or when certain things are going to be addressed.
A little insight on your roadmap would be great.

(1) STRUCT opImplicitCastTo/From (p.21)
---------------------------------
How do you want to solve the problem of overloading by return value 
which would be necessary to solve something like the example in the 
slides (p.21):

    struct S{
        int opImplicitCastTo(){...}
        float opImplicitCastTo(){...}
    }
    
(2) STRUCT "inheritance" (p.27)
---------------------------------
Is this still planned as it was meant to be some kind of 
template-concepts-replacement, now that there is the 
template-constraints implementation (D2.015) ?

(3) ENUM Member Lookup Rules (p.34)
---------------------------------
I hope this one did not fall under the table, though it is a small thing 
cause it would simplify many enum usages.

enum OpenMode {READ, WRITE, READ_WRITE}
void foo(OpenMode mode = READ){...}

(4) return Storage Class (p.38)
---------------------------------
No more doubled getter functions for const/not-const !

(5) final switch (p.41)
---------------------------------
This one is such a great proposal, when will it be implemented? No more 
worry if on runtime a enum value leads to the safety "default: 
assert(false);" control path because perhaps i have forgotton to add new 
behaviour after adding a new enum member.

(6) AST macros (p.45)
---------------------------------
The wet dream of every D-coder but when is it going to become reality ?

(7) static foreach (p.52)
---------------------------------


My final bid is again, please let the community know what your roadmap 
is, so we can stop wonder how and if all this is still going to be part 
of D2.0 which was intended to become stable in this years fall.

Regards for the awesome work on our all-favourite programming language !

~Stephan
Jun 22 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Extrawurst wrote:

 Hey Walter,
 this is just a list of changes which were originally planned to be 
 integrated into D2.0 according to the slides you and Andrei presented on 
 DConference '07. So please give us a comment on what perhaps has changed 
 or when certain things are going to be addressed.
 A little insight on your roadmap would be great.
 
 (1) STRUCT opImplicitCastTo/From (p.21)
 ---------------------------------
 How do you want to solve the problem of overloading by return value 
 which would be necessary to solve something like the example in the 
 slides (p.21):
 
    struct S{
        int opImplicitCastTo(){...}
        float opImplicitCastTo(){...}
    }


Still planning on it.


    (2) STRUCT "inheritance" (p.27)
 ---------------------------------
 Is this still planned as it was meant to be some kind of 
 template-concepts-replacement, now that there is the 
 template-constraints implementation (D2.015) ?


Template constraints may have obsoleted it.


 
 (3) ENUM Member Lookup Rules (p.34)
 ---------------------------------
 I hope this one did not fall under the table, though it is a small thing 
 cause it would simplify many enum usages.
 
 enum OpenMode {READ, WRITE, READ_WRITE}
 void foo(OpenMode mode = READ){...}


This suffers from some large chicken-and-egg semantic issues. May not 
happen.


 
 (4) return Storage Class (p.38)
 ---------------------------------
 No more doubled getter functions for const/not-const !


Actually, we've been looking for a better way to do this, as nobody 
really likes the syntax.



 (5) final switch (p.41)
 ---------------------------------
 This one is such a great proposal, when will it be implemented? No more 
 worry if on runtime a enum value leads to the safety "default: 
 assert(false);" control path because perhaps i have forgotton to add new 
 behaviour after adding a new enum member.



That's been kind of overlooked.


 
 (6) AST macros (p.45)
 ---------------------------------
 The wet dream of every D-coder but when is it going to become reality ?


D 3.0.


 (7) static foreach (p.52)
 ---------------------------------


Yes.


 
 My final bid is again, please let the community know what your roadmap 
 is, so we can stop wonder how and if all this is still going to be part 
 of D2.0 which was intended to become stable in this years fall.


There was a shift in focus, we're working a lot on trying to figure out 
a better way to do multithreaded programming.


 Regards for the awesome work on our all-favourite programming language !


Welcs!
Jun 22 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Extrawurst wrote:

 My final bid is again, please let the community know what your roadmap
 is, so we can stop wonder how and if all this is still going to be part
 of D2.0 which was intended to become stable in this years fall.


 There was a shift in focus, we're working a lot on trying to figure out
 a better way to do multithreaded programming.


There are decades of research in SMP and a raft of established practice...
outside of the classic and frustrating explicit use of mutexes and the like.
Why not agents, CSP, transactional memory, plain old parallel programming
instructions as per languages like Cilk, etc?  This is one area where I don't
think D should necessarily try to re-invent the wheel.


Sean
Jun 22 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:

 There are decades of research in SMP and a raft of established practice...
 outside of the classic and frustrating explicit use of mutexes and the like.
 Why not agents, CSP, transactional memory, plain old parallel programming
 instructions as per languages like Cilk, etc?  This is one area where I don't
 think D should necessarily try to re-invent the wheel.


None of them has caught on and established itself as the right way to do 
parallel programming.
Jun 22 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Sean Kelly wrote:

 There are decades of research in SMP and a raft of established practice...
 outside of the classic and frustrating explicit use of mutexes and the like.
 Why not agents, CSP, transactional memory, plain old parallel programming
 instructions as per languages like Cilk, etc?  This is one area where I don't
 think D should necessarily try to re-invent the wheel.


 None of them has caught on and established itself as the right way to do
 parallel programming.


I don't think that looking at the history of mainstream programming is going
to be of much use here.  SMP didn't even matter until just a few years ago, as
most of the world's programmers weren't targeting platforms where SMP was
practical or desirable.  But the research community hasn't been standing still,
and some specialist circles have been doing SMP all along.  I suppose what I'm
saying is that I think it's wrongheaded to discount existing practice because
none of them are mainstream, because this has nothing to do with how good
they are.


Sean
Jun 22 2008
parent janderson <askme me.com> writes:
Sean Kelly wrote:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Sean Kelly wrote:

 There are decades of research in SMP and a raft of established practice...
 outside of the classic and frustrating explicit use of mutexes and the like.
 Why not agents, CSP, transactional memory, plain old parallel programming
 instructions as per languages like Cilk, etc?  This is one area where I don't
 think D should necessarily try to re-invent the wheel.


 None of them has caught on and established itself as the right way to do
 parallel programming.


 
 I don't think that looking at the history of mainstream programming is going
 to be of much use here.  SMP didn't even matter until just a few years ago, as
 most of the world's programmers weren't targeting platforms where SMP was
 practical or desirable.  But the research community hasn't been standing still,
 and some specialist circles have been doing SMP all along.  I suppose what I'm
 saying is that I think it's wrongheaded to discount existing practice because
 none of them are mainstream, because this has nothing to do with how good
 they are.


That is so true.  Look at D for instance.


 Sean
Jun 24 2008
prev sibling parent reply Extrawurst <spam extrawurst.org> writes:
Walter Bright schrieb:

 Extrawurst wrote:

 Hey Walter,
 this is just a list of changes which were originally planned to be 
 integrated into D2.0 according to the slides you and Andrei presented 
 on DConference '07. So please give us a comment on what perhaps has 
 changed or when certain things are going to be addressed.
 A little insight on your roadmap would be great.

 (1) STRUCT opImplicitCastTo/From (p.21)
 ---------------------------------
 How do you want to solve the problem of overloading by return value 
 which would be necessary to solve something like the example in the 
 slides (p.21):

    struct S{
        int opImplicitCastTo(){...}
        float opImplicitCastTo(){...}
    }


 Still planning on it.


So does it mean we gonna get overloading on different return types ?
Jun 22 2008
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Extrawurst <spam extrawurst.org> wrote:


 Walter Bright schrieb:

 Extrawurst wrote:

 Hey Walter,
 this is just a list of changes which were originally planned to be  
 integrated into D2.0 according to the slides you and Andrei presented  
 on DConference '07. So please give us a comment on what perhaps has  
 changed or when certain things are going to be addressed.
 A little insight on your roadmap would be great.

 (1) STRUCT opImplicitCastTo/From (p.21)
 ---------------------------------
 How do you want to solve the problem of overloading by return value  
 which would be necessary to solve something like the example in the  
 slides (p.21):

    struct S{
        int opImplicitCastTo(){...}
        float opImplicitCastTo(){...}
    }


 Still planning on it.


 So does it mean we gonna get overloading on different return types ?



I wouldn't bet on it. This is already possible:



struct S
{
	void opCastTo(ref int result) {}
	void opCastTo(ref float result) {}
}

int i;
float f;
S s;

s.opCastTo(i);
s.opCastTo(f);



Add syntactic sugar to taste, inform the compiler that opImplicitCastTo is  
a special function, and voilà!

-- Simen
Jun 23 2008
prev sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Mon, 23 Jun 2008 10:02:39 +0400, Extrawurst <spam extrawurst.org> wrote:


 Walter Bright schrieb:

 Extrawurst wrote:

 Hey Walter,
 this is just a list of changes which were originally planned to be  
 integrated into D2.0 according to the slides you and Andrei presented  
 on DConference '07. So please give us a comment on what perhaps has  
 changed or when certain things are going to be addressed.
 A little insight on your roadmap would be great.

 (1) STRUCT opImplicitCastTo/From (p.21)
 ---------------------------------
 How do you want to solve the problem of overloading by return value  
 which would be necessary to solve something like the example in the  
 slides (p.21):

    struct S{
        int opImplicitCastTo(){...}
        float opImplicitCastTo(){...}
    }


 Still planning on it.


 So does it mean we gonna get overloading on different return types ?


There was a suggestion to change a signature to something like this:
struct S {
	void opImplicitCastTo(ref float result) { ... }
	void opImplicitCastTo(ref int result) { ... }
}

bacause overload on return value is basically unacceptable.
Jun 23 2008
prev sibling next sibling parent BLS <nanali nospam-wanadoo.fr> writes:
DTL ?

D2 const/invariant/ pure functions/ new alias handling /  doubts about 
synchronized ...

Seems that Walter and Co are really willing to blow STL away by creating 
tools for the "After Free Lunch Time"


- Software is concurrent
– Interactive applications
– Web services
– Distributed software
- Hardware is concurrent
– Hyperthreading
– Multicores,
Manycores
– Grid computing

at least for me : ALL current D2 development steps are showing in that 
direction.

bls
Jun 26 2008
prev sibling parent Dan <murpsoft hotmail.com> writes:
Koroskin Denis Wrote:


 On Mon, 23 Jun 2008 10:02:39 +0400, Extrawurst <spam extrawurst.org> wrote:
 

 Walter Bright schrieb:

 Extrawurst wrote:

 Hey Walter,
 this is just a list of changes which were originally planned to be  
 integrated into D2.0 according to the slides you and Andrei presented  
 on DConference '07. So please give us a comment on what perhaps has  
 changed or when certain things are going to be addressed.
 A little insight on your roadmap would be great.

 (1) STRUCT opImplicitCastTo/From (p.21)
 ---------------------------------
 How do you want to solve the problem of overloading by return value  
 which would be necessary to solve something like the example in the  
 slides (p.21):

    struct S{
        int opImplicitCastTo(){...}
        float opImplicitCastTo(){...}
    }


 Still planning on it.


 So does it mean we gonna get overloading on different return types ?


 
 There was a suggestion to change a signature to something like this:
 struct S {
 	void opImplicitCastTo(ref float result) { ... }
 	void opImplicitCastTo(ref int result) { ... }
 }
 
 bacause overload on return value is basically unacceptable.


Yes, and the lack of orthogonality of the old/current system is annoying at
best.  The source code for Walnut was roughly 15% larger because of this.

I abandoned the project mostly because the code that I thought was being
generated was so vastly different from the code that was being generated.

For example, passing a 16-byte struct was being done by rep movsd'ing the
arguments while I was programming it envisioning xmm register usage for
"arguments" and closure-like behavior for "self" and "context".

I started reworking the whole project in fasm so I could write exactly what I
thought, but then abandoned the scripting engine altogether to the next project
about the time I finished writing the lexer because I became disinterested.
Jun 26 2008