http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt

Marcio wrote:

> http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt

This was a very, very interesting presentation.  Tim makes a lot of very good points, and a very large portion of it applies far past game development.  To that end, there are a lot of items in there which I hope will be features for D 2.0.

In particular, I'm hoping that Walter's got some ideas concerning parallelism.  I don't think there's any doubt that a language which excels at allowing programmers to massively parallel code easily would be absolutely invaluable.  Although I think that a lot of parallel-assist mechanisms should and can be implemented in a library, but some compiler assisted stuff would be great.

Some for instances:
-object versioning could help a library to implement non-locking
transactional writes (does this terminology make any sense?).
-If the compiler could somehow tell a library whether or not two functions
ever write to the same memory, the library could schedule one to run after
the other or in parallel.
-What if the compiler could tell a library that a certain function call
never writes to and/or reads from existing heap space?
-Race condition checking and possible dead-lock checking are also obvious
assists.
-Some interface for a library to manage the code execution would also be
cool:
manager(ParallelComputation) {
        float foo() {
                float pi = calcPiLotsofAccuracy();
                long rects = getRectangleCount();
                return pi * rects;
        }
}
If the compiler can tell "ParallelComputation" manager that
calcPiLostofAccuracy() and getRectangleCount never write to the heap, it
will execute them in parallel.  Clearly, we could just introduce a keyword
to tell the compiler to do this, but allowing some interface for some other
component of the program to manage execution would allow for great
flexibilty, like functionally-specific thread-pools, or various
prioritization algorithms.

Here's another thought:
D's in and out function blocks are great, but could we get some
automagically generated stuff?  For instance,
void foo(notnull Object o){}
would automatically put an assert(o) in the in block.  Better yet, what
about some way to genericize that, so we could have something like in block
mixins?
template LessThan(A,B) {
        in {
                assert(A < B);
        }
}
template NotNull(O) {
        in {
                assert(O);
        }
}
void var(Object o, int i, int j) LessThan!(i,j), NotNull!(o) {
        //o won't be null, and i is less than j!
}


I dunno if any of these are decent ideas, but the above slides sparked some ideas and real thought about some cool features, and I figured I might as well throw some of them out there as food for thought....

Real point of the post, I guess:

Clearly some (err.. all) of these thoughts are quarter-baked, extreme ideas, so I what I'm saying is that I'd like to get D 1.0 out there so we can move on to some really innovative and extreme features....  D's pretty great as is, but it's not the quantum leap forward needed to really assist programmers with new challenges; it's got some really great potential to get there, though.

-- 
~John Demme
me@teqdruid.com
http://www.teqdruid.com/

John Demme a écrit :
> Here's another thought:
> D's in and out function blocks are great, but could we get some
> automagically generated stuff?  For instance,
> void foo(notnull Object o){}
> would automatically put an assert(o) in the in block.  Better yet, what
> about some way to genericize that, so we could have something like in block
> mixins?
> template LessThan(A,B) {
>         in {
>                 assert(A < B);
>         }
> }
> template NotNull(O) {
>         in {
>                 assert(O);
>         }
> }
> void var(Object o, int i, int j) LessThan!(i,j), NotNull!(o) {
>         //o won't be null, and i is less than j!
> }
> 
> 
> I dunno if any of these are decent ideas, but the above slides sparked some
> ideas and real thought about some cool features, and I figured I might as
> well throw some of them out there as food for thought....

These are decent ideas.
In some ways, this looks like aspect oriented programming. LessThan is an aspect, the « in » block code is an advice of that aspect, void var ( Object, int, int ) is a joinpoint. What we're looking for is a way to weave the aspect in D code. However using aspect oriented programming for something no more complex than a contract definition is like using a rocket launcher to kill a fly.
In the presentation, Tim writes that sometimes developpers need to change a framework's base classes. In this situation, aspect oriented programming would allow to define totally and exclusively all the changes in a separate module and avoid to mess up with the framework's code.


> Real point of the post, I guess:
> 
> Clearly some (err.. all) of these thoughts are quarter-baked, extreme ideas,
> so I what I'm saying is that I'd like to get D 1.0 out there so we can move
> on to some really innovative and extreme features....  D's pretty great as
> is, but it's not the quantum leap forward needed to really assist
> programmers with new challenges; it's got some really great potential to
> get there, though.
> 

I agree.

John Demme wrote:
> Marcio wrote:
> 
> 
>>http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt
> 
> 
> This was a very, very interesting presentation.  Tim makes a lot of very
> good points, and a very large portion of it applies far past game
> development.  To that end, there are a lot of items in there which I hope
> will be features for D 2.0.
> 
> In particular, I'm hoping that Walter's got some ideas concerning
> parallelism.  I don't think there's any doubt that a language which excels
> at allowing programmers to massively parallel code easily would be
> absolutely invaluable.  Although I think that a lot of parallel-assist
> mechanisms should and can be implemented in a library, but some compiler
> assisted stuff would be great.
> 
> Some for instances:
> -object versioning could help a library to implement non-locking
> transactional writes (does this terminology make any sense?).
> -If the compiler could somehow tell a library whether or not two functions
> ever write to the same memory, the library could schedule one to run after
> the other or in parallel. -What if the compiler could tell a library that a certain function call
> never writes to and/or reads from existing heap space?
> -Race condition checking and possible dead-lock checking are also obvious
> assists.
> -Some interface for a library to manage the code execution would also be
> cool:
> manager(ParallelComputation) {
>         float foo() {
>                 float pi = calcPiLotsofAccuracy();
>                 long rects = getRectangleCount();
>                 return pi * rects;
>         }
> }
> If the compiler can tell "ParallelComputation" manager that
> calcPiLostofAccuracy() and getRectangleCount never write to the heap, it
> will execute them in parallel.  Clearly, we could just introduce a keyword
> to tell the compiler to do this, but allowing some interface for some other
> component of the program to manage execution would allow for great
> flexibilty, like functionally-specific thread-pools, or various
> prioritization algorithms.
> 
> Here's another thought:
> D's in and out function blocks are great, but could we get some
> automagically generated stuff?  For instance,
> void foo(notnull Object o){}
> would automatically put an assert(o) in the in block.  Better yet, what
> about some way to genericize that, so we could have something like in block
> mixins?
> template LessThan(A,B) {
>         in {
>                 assert(A < B);
>         }
> }
> template NotNull(O) {
>         in {
>                 assert(O);
>         }
> }
> void var(Object o, int i, int j) LessThan!(i,j), NotNull!(o) {
>         //o won't be null, and i is less than j!
> }
> 
> 
> I dunno if any of these are decent ideas, but the above slides sparked some
> ideas and real thought about some cool features, and I figured I might as
> well throw some of them out there as food for thought....
> 
> Real point of the post, I guess:
> 
> Clearly some (err.. all) of these thoughts are quarter-baked, extreme ideas,
> so I what I'm saying is that I'd like to get D 1.0 out there so we can move
> on to some really innovative and extreme features....  D's pretty great as
> is, but it's not the quantum leap forward needed to really assist
> programmers with new challenges; it's got some really great potential to
> get there, though.
> 


CSP has been around for 30 years to address much of these concerns. Amusingly, certain somewhat prominent figures are 'rediscovering' CSP and calling it their own. You might be interested in reading up on Tony Hoare's CSP, and a principal implementation, occam ?

kris wrote:
> 
> 
> CSP has been around for 30 years to address much of these concerns. Amusingly, certain somewhat prominent figures are 'rediscovering' CSP and calling it their own. You might be interested in reading up on Tony Hoare's CSP, and a principal implementation, occam ?

Thanks for the pointer, Kris.  I've downloaded Tony's book and will try to digest some of it.  Looks very interesting.

-- 
~John Demme
me@teqdruid.com
http://www.teqdruid.com/

kris wrote:
> CSP has been around for 30 years to address much of these concerns. Amusingly, certain somewhat prominent figures are 'rediscovering' CSP and calling it their own. You might be interested in reading up on Tony Hoare's CSP, and a principal implementation, occam ?


For a rediscovery of CSP channels but in C#, see:

"The Concurrency and Coordination Runtime (CCR) is a lightweight port-based concurrency library for C# 2.0 developed by George Chrysanthakopoulos in the Advanced Strategies group at Microsoft. Here http://channel9.msdn.com/ShowPost.aspx?PostID=143582 , we have a deep discussion about CCR with George, a Software Architect, and Satnam Singh, Architect. You can get more info about CCR on the CCR Wiki http://channel9.msdn.com/wiki/default.aspx/Channel9.ConcurrencyRuntime . This is super cool stuff and represents a really innovative approach to making managed threaded programming more readily understandable and predictable.

Please check out the OOPSLA/SCOOL paper on the CCR http://research.microsoft.com/~tharris/scool/papers/sing.pdf .

Click here http://channel9.msdn.com/Showpost.aspx?postid=206574 to see how the CCR is being used by the Microsoft Robotics Group."

CCR Programming http://channel9.msdn.com/ShowPost.aspx?PostID=219308



marcio

Marcio wrote:
> kris wrote:
> 
>> CSP has been around for 30 years to address much of these concerns. Amusingly, certain somewhat prominent figures are 'rediscovering' CSP and calling it their own. You might be interested in reading up on Tony Hoare's CSP, and a principal implementation, occam ?
> 
> 
> 
> For a rediscovery of CSP channels but in C#, see:
> 
> "The Concurrency and Coordination Runtime (CCR) is a lightweight port-based concurrency library for C# 2.0 developed by George Chrysanthakopoulos in the Advanced Strategies group at Microsoft. Here http://channel9.msdn.com/ShowPost.aspx?PostID=143582 , we have a deep discussion about CCR with George, a Software Architect, and Satnam Singh, Architect. You can get more info about CCR on the CCR Wiki http://channel9.msdn.com/wiki/default.aspx/Channel9.ConcurrencyRuntime . This is super cool stuff and represents a really innovative approach to making managed threaded programming more readily understandable and predictable.
> 
> Please check out the OOPSLA/SCOOL paper on the CCR http://research.microsoft.com/~tharris/scool/papers/sing.pdf .
> 
> Click here http://channel9.msdn.com/Showpost.aspx?postid=206574 to see how the CCR is being used by the Microsoft Robotics Group."
> 
> CCR Programming http://channel9.msdn.com/ShowPost.aspx?PostID=219308
> 
> 
> 
> marcio



Nice! Thanks;

This presentation seems familiar... :)

One interesting point, is the need to specify ranges of valid numbers. Pascal had decent support for this, allowing one to define integer types constrained to a given range:

type MyNumber : 1..15;

D could use something like this, though I'm not sure what to make of the syntax.

alias   1..15 MyNumber; // allows implicit conversion to (but not from) int. typedef 1..15 MyNumber; // only allows explicit conversion.

One could imagine this extended to dynamic ranges:

void foo(int i, 0..i j)

But then again, maybe not.

> Software Frameworks The Problem: Users of a framework want to extend the
> functionality
> of the framework's base classes!
> The workarounds:
> - Modify the source ... and modify it again with each new version
> - Add references to payload classes, and dynamically cast them at
>   runtime to the appropriate types. - These are all error-prone: Can the
> compiler help us here?

This is a problem I've only seen handled in the pretty obscure language TADS, which had a "modify" keyword, which allowed user code to replace entire methods of library classes, as well as add methods. Unlike the traditional approach -- overriding the methods in a subclass -- this affected all instances of the given class, also those instantiated in library code.

class LibraryClass
{
    void doStuff() { printf("foo\n"); }
}

modify LibraryClass
{
    void doStuff() { printf("bar\n"); }
    void entirelyNewFunction() { }
}

This was implemented by making an anonymous subclass of the LibraryClass, and then having the "LibraryClass" symbol refer to the subclass instead, and I guess the same could be done in D by screwing around with the linker and VMT.

I'm not saying this belongs in D; it's a horrible hack from an OOP standpoint (handy, though), and the "real" solution would be to design better libraries, with proper hooks.

Søren J. Løvborg
web@kwi.dk

Søren J. Løvborg wrote:
>> Software Frameworks The Problem: Users of a framework want to extend the functionality
>> of the framework's base classes!
>> The workarounds:
>> - Modify the source ... and modify it again with each new version
>> - Add references to payload classes, and dynamically cast them at
>>   runtime to the appropriate types. - These are all error-prone: Can the compiler help us here?
> 
> This is a problem I've only seen handled in the pretty obscure language TADS, which had a "modify" keyword, which allowed user code to replace entire methods of library classes, as well as add methods. Unlike the traditional approach -- overriding the methods in a subclass -- this affected all instances of the given class, also those instantiated in library code.



	Smalltalk has always had the ability to add methods to existing classes, and even replace methods. This notion was organized better with more Software Engineering principles with ENVY/Developer from OTI (which was later bought by IBM and went on to produce VIsualAge for Smalltalk, VisualAge for Java and later what is now called Eclipse).

	Anyway, ENVY/Developer brought the notion of modules (applications) that could extend existing applications by adding 1) classes or 2) methods to existing classes. So, ENVY/Swapper, for example, was an application framework that added persistency. It pre-req'ed and extended the Kernel application and, among other things, added methods to class Object (Object was defined in Kernel).

	I believe Ruby may have been inspired by Smalltalk here and allows later code to add methods to existing classes a la Smalltalk. But I am not a Ruby expert, so check the facts for yourself.

	Replacing an existing method is always dangerous and was flagged in ENVY/Developer (if memory serves me well) as a conflict. This is more common for runtime system - patching is a clear example. Another clear example of runtime modification is AOP (Aspect Oriented Programming) where people can plug code into running code and do things like logging, profiling, code coverage analysis etc.

	Obviously CLOS people will probably say "we've been doing this for decades", even inserting a class C between A and B (inheritance-wise).

marcio

Marcio a écrit :
>     Replacing an existing method is always dangerous and was flagged in ENVY/Developer (if memory serves me well) as a conflict. This is more common for runtime system - patching is a clear example. Another clear example of runtime modification is AOP (Aspect Oriented Programming) where people can plug code into running code and do things like logging, profiling, code coverage analysis etc.

AOP can also be done with a precompiler like AspectJ or AspectC++. However, compared to dynamic AOP ( using a dynamic language, with metaclases or reflexion ), it becomes more difficult to debug an weaved program because the aspects are scattered throughout the generated code thus it becomes less apparent what the programmer intended but tools exist, mainly for Eclipse ( I don't use it ).

>     Obviously CLOS people will probably say "we've been doing this for decades", even inserting a class C between A and B (inheritance-wise).

Thanks to the power of reflexion and metaprogramming. It seems that D's TypeInfo classes could be considered as metaclasses. Maybe there is a way to use them to extend existing classes, and replace methods or wrap them around new ones.