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