www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - More D on reddit

reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei's presentation:

http://www.reddit.com/r/programming/info/6sv8d/comments/

and an interview of me:

http://www.reddit.com/r/programming/info/6stpd/comments/
Jul 22 2008
next sibling parent reply "Craig Black" <cblack ara.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g6449d$hf5$1 digitalmars.com...
 Andrei's presentation:

 http://www.reddit.com/r/programming/info/6sv8d/comments/

 and an interview of me:

 http://www.reddit.com/r/programming/info/6stpd/comments/

It's encouraging to hear the emphasis on multi-threading and that there are more people than just Andrei working on it. I like that Andrei's functional programming support is not considered to the "the solution" to multi-threading. There are numerous ways to tackle multi-threading. Embracing only one would be too limiting. -Craig
Jul 23 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Craig Black wrote:

 I like that Andrei's functional 
 programming support is not considered to the "the solution" to 
 multi-threading.  There are numerous ways to tackle multi-threading. 
 Embracing only one would be too limiting.
 
 -Craig 
 

Well, good, because indeed it is not the solution to multi-threading. And it is not even *a* solution (as in, one of many solutions). The const system is first and foremost an improvement on the static type system. In addition, the const system, specially invariant (and upcoming features such as pure functions) also allow for _some *particular* optimizations related to concurrency_. But it's nowhere near a full solution like STM, message-passing, or other things in the same category. I hope everyone acknowledges this (and from what I've in some other posts, it seems that's not the case). I know Walter has said that const/pure is "key to multi-threading", but I'm fairly sure it was meant in the sense that const/pure was necessary for a concurrency solution, but was not the whole solution. And it clearly is not. (note, I'm not disparaging the const system because of this, I'm only clarifying its objective) -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 04 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Andrei's presentation:
 
 http://www.reddit.com/r/programming/info/6sv8d/comments/
 

DrBartoz commented: "We thought about letting the compiler figure out most of the const and invariant qualifiers in D (you'd specify them only in strategic places). The problem is, this would require whole-program analysis. When function f1 in module M1 calls function f2 in module M2, and they pass through an argument by reference, you have to analyze f2 before you can decide if f1 may declare this argument const or invariant. Although D has access to regular modules during compilation, the same is not true about libraries. If everybody agreed to ship libraries with their sources, a lot more would be possible." Why would the whole source code the library be needed for that? Isn't it necessary only for the library API to be well-specified in terms of it's const semantics? -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 04 2008
parent reply mort <mortm gmail.com> writes:
Bruno Medeiros Wrote:

 DrBartoz commented: [...]
 
 Why would the whole source code the library be needed for that? Isn't it 
 necessary only for the library API to be well-specified in terms of it's 
 const semantics?

You could setup 'const inference' to stop at package/library boundaries, but it wouldn't be as powerful. Consider the function 'Object id(Object x) { return x; }'. This function is const-polymorphic. There's no way to explicitly tag it as const without reducing its applicability since you might want to pass in const parameters in some places and mutate the result in others. Also, I think you'd have to tweak the syntax to avoid confusion - you might not want the default (when specifiers are absent) to be 'not-const' at package level and 'inferred-const' elsewhere.
Aug 04 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
mort wrote:
 Bruno Medeiros Wrote:
 
 DrBartoz commented: [...]

 Why would the whole source code the library be needed for that? Isn't it 
 necessary only for the library API to be well-specified in terms of it's 
 const semantics?

You could setup 'const inference' to stop at package/library boundaries, but it wouldn't be as powerful. Consider the function 'Object id(Object x) { return x; }'. This function is const-polymorphic. There's no way to explicitly tag it as const without reducing its applicability since you might want to pass in const parameters in some places and mutate the result in others. Also, I think you'd have to tweak the syntax to avoid confusion - you might not want the default (when specifiers are absent) to be 'not-const' at package level and 'inferred-const' elsewhere.

But you can't specify a "const-polymorphic" function with the current const system either. You (the library writer) would have to define two functions, so const-inference wouldn't limit you in any way. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 11 2008