www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Revamped concurrency API

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Occasionally people here ask for ways in which they can help D. One 
thing that would be extremely helpful at this point would be to help 
defining and implementing D's new concurrency API. Unfortunately, 
Bartosz has declined to contribute. That leaves Walter, Sean, Don, and 
participants to this group to do it.

I'm sure you know the three of us are overcommitted, and I'm also sure 
many of you are also in that situation. But if we could somehow focus 
all of the energy and good will in this group to one task of 
extraordinary urgency and importance, that would be awesome.

If anyone has ideas, suggestions, and code to help defining a new 
concurrency API for D, please post.


Andrei
Oct 12 2009
next sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Andrei Alexandrescu wrote:
 Occasionally people here ask for ways in which they can help D. One 
 thing that would be extremely helpful at this point would be to help 
 defining and implementing D's new concurrency API. Unfortunately, 
 Bartosz has declined to contribute. That leaves Walter, Sean, Don, and 
 participants to this group to do it.
 
 I'm sure you know the three of us are overcommitted, and I'm also sure 
 many of you are also in that situation. But if we could somehow focus 
 all of the energy and good will in this group to one task of 
 extraordinary urgency and importance, that would be awesome.
 
 If anyone has ideas, suggestions, and code to help defining a new 
 concurrency API for D, please post.
 
 
 Andrei
Don't fix it to one model, leave room for multiple concurrency models to be used side by side! I would begin by making the 'shared' specs usable, since the rest will be within the runtime and everything will rely on shared. I already made a post on this some time ago: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=96161 Jeremie
Oct 12 2009
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
 If anyone has ideas, suggestions, and code to help defining a new 
 concurrency API for D, please post.
I think that the correct way to handle concurrency is through a library, D is flexible enough, so that a library can be used, and then one can even write special handlers for special cases. In blip (http://dsource.org/project/blip) I actually did exactly that, in D 1.0 for two reasons: 1) I need 64 bits 2) concurrency is complex, and I had a hard time already with bugs in the stable branch, furthermore the possibility of breakage in very sensitive code that I don't want to touch too often by language changes was not appealing to me. That said there is a feature that would help much D 1.0, and that I would really love to have. I know that D 1.0 is frozen and stuff... but I will try to ask all the same... real closures from delegates when you put a "new" in front of them new delegate(ref int x){x+=y} would create a closure (allocating y). I know that D 2.0 has basically that by default (and scope to get the previous behavior), but as I said D 2.0 is not yet an option for me (I want to work on my projects, I think I am already doing enough for the community), so I thought that asking for a feature that does not break existing D 1.0 code and is in some way already implemented in D 2.0 could be worth trying :) The other D 2.0 features are nice, I do like structure constructors/destructors, post blits, template constraints, const..., well shared I am not so sure about, but anyway all of them are not needed for concurrency. Now about the concurrency infrastructure, here I will discuss SMP parallelization, there is also a more coarse grained parallelization that needs another approach (MPI and agent based model, for now I just wrapped mpi and serialization in a way that could be implemented directly on tcp, and allow to easily communicate arbitrary objects). The concurrency has two sides one is the user/programmer side and the other the efficient realization, I will discuss the user level api, as I realized it in Blip, which is optimized for recursive operations that have to be finished (i.e computations to be performed, not to simulate concurrent systems). The idea is to separate each tasks in chunks that are as small as possible, while still being large enough so that the switching time is small wrt. to the computing time. This subdivision typically is not directly dependent on the number of processors ---- Task is a class the represents a task, it has a string name (for debugging purposes) and can be initialized with a delegate, a function, a fiber or a generator (in two flavors). There are some optimizations to make allocation cheaper. a task can spawn subtasks, and it "knows" how many subtasks there are executing. a task is considered finished when the task is complete and all its subtasks are completed you can append operations to be executed after a task has finished executing. you can wait for a task to finish (but try avoiding it, addint the task to the onFinish of the task is much more efficient). a task has a given level, subtasks have level+1, and tasks that cannot have subtasks have a very high level (int.max/2). a new task can be submitted with t.submit() or t.submitYield() submitYield submits the current task and possibly stops the current one, this together with the fact that tasks with higher level are executed before tasks with lower level means that execution is preferentially a depth first reduction which minimizes the number of suspended tasks (I have also task stealing that steals preferentially the tasks with lowest level, but that part is not yet really used). other important operations are delay and resubmitDelayed that allow one to delay a task, for example when you have to do i/o and you use a method like epoll you can delay the current task, add the file handler to the one to control, and execute resubmitDelayed when that handler has new data. executeNow is useful to execute a task synchronously. That is basically the core that one has to know, the library is actually much more rich, but for a typical usage this is enough. With it one can write code like: import blip.parallel.WorkManager; class SubProblem{ void execute(){ if(problem is large){ SubProblem firstHalf=...; Task("subproblem1",&firstHalf.execute).autorelease.submitYield(); SubProblem secondHalf=...; Task("subproblem2",&secondHalf.execute).autorelease.submitYield(); } else { direct solver } } } solveProblem(){ if(problemIsLarge){ SubProblem wholeProblem=...; Task("solveProblem",&wholeProblem.execute).executeNow(default); } else { direct solver } } just to show a very basic divide and conquer approach
Oct 12 2009
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 12 Oct 2009 18:21:37 -0400, Fawzi Mohamed <fmohamed mac.com> wrote:

 If anyone has ideas, suggestions, and code to help defining a new  
 concurrency API for D, please post.
I think that the correct way to handle concurrency is through a library, D is flexible enough, so that a library can be used, and then one can even write special handlers for special cases. In blip (http://dsource.org/project/blip) I actually did exactly that, in D 1.0 for two reasons:
[snip] Looks very interesting. ( Corrected link: http://www.dsource.org/projects/blip ) It looks like it's under the Apache 2.0 license? Would you be willing to put it under the boost license, so that it might be considered for Phobos?
Oct 12 2009
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-10-13 03:17:13 +0200, "Robert Jacques" <sandford jhu.edu> said:

 On Mon, 12 Oct 2009 18:21:37 -0400, Fawzi Mohamed <fmohamed mac.com> wrote:
 
 If anyone has ideas, suggestions, and code to help defining a new  
 concurrency API for D, please post.
I think that the correct way to handle concurrency is through a library, D is flexible enough, so that a library can be used, and then one can even write special handlers for special cases. In blip (http://dsource.org/project/blip) I actually did exactly that, in D 1.0 for two reasons:
[snip] Looks very interesting. ( Corrected link: http://www.dsource.org/projects/blip ) It looks like it's under the Apache 2.0 license? Would you be willing to put it under the boost license, so that it might be considered for Phobos?
if there is interest, yes
Oct 12 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Fawzi Mohamed wrote:
 On 2009-10-13 03:17:13 +0200, "Robert Jacques" <sandford jhu.edu> said:
 
 On Mon, 12 Oct 2009 18:21:37 -0400, Fawzi Mohamed <fmohamed mac.com> 
 wrote:

 If anyone has ideas, suggestions, and code to help defining a new  
 concurrency API for D, please post.
I think that the correct way to handle concurrency is through a library, D is flexible enough, so that a library can be used, and then one can even write special handlers for special cases. In blip (http://dsource.org/project/blip) I actually did exactly that, in D 1.0 for two reasons:
[snip] Looks very interesting. ( Corrected link: http://www.dsource.org/projects/blip ) It looks like it's under the Apache 2.0 license? Would you be willing to put it under the boost license, so that it might be considered for Phobos?
if there is interest, yes
Thanks. There definitely is. I'll start looking at the lib soon, and I recommend others to do the same. Andrei
Oct 12 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Occasionally people here ask for ways in which they can help D. One
 thing that would be extremely helpful at this point would be to help
 defining and implementing D's new concurrency API. Unfortunately,
 Bartosz has declined to contribute. That leaves Walter, Sean, Don, and
 participants to this group to do it.
 I'm sure you know the three of us are overcommitted, and I'm also sure
 many of you are also in that situation. But if we could somehow focus
 all of the energy and good will in this group to one task of
 extraordinary urgency and importance, that would be awesome.
 If anyone has ideas, suggestions, and code to help defining a new
 concurrency API for D, please post.
For what it's worth, I've been experimenting with message-passing for one leg of the API. I decided to copy the Erlang API because it's very simple and easy to build fancier stuff on top of. What I have so far is: void sendmsg(T)( Pid pid, T val ); final void recvmsg(T...)( Pid pid, T ops ); Pid spawn(T)( T fun ); spawn() is pretty limited so far in that it only spawns threads--I'd expect that function to end up with multiple overloads at some point. Also 'ops' in recvmsg are delegates. Typical use would be: // Thread A sendmsg( pid, 5 ); sendmsg( pid, tuple(5) ); // Thread B recvmsg( pid, (int val) { writefln( "got int: %s", val ); } ); recvmsg( pid, (Tuple!(int) val) { writefln( "got tuple: %s", val ); } ); I thought about using predefined types for "receive any" and "abort after timeout" functions to pass to recvmsg. Pattern matching in D is largely limited to type matching at the moment, which is kind of a limitation, so I'd considered having the delegates return a bool indicating whether the value passed was a match or not. Anyway, thought I'd just add this to the thread in case it sparks discussion. I have a working implementation of this around somewhere if anyone is interested.
Oct 12 2009
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Sean Kelly Wrote:
 
 void sendmsg(T)( Pid pid, T val );
 final void recvmsg(T...)( Pid pid, T ops );
Oops, I should mention that 'pid' shouldn't be in recvmsg. I just have it in there for now for testing purposes.
Oct 12 2009
prev sibling parent reply MIURA Masahiro <echochamber gmail.com> writes:
Sean Kelly wrote:
 void sendmsg(T)( Pid pid, T val );
 final void recvmsg(T...)( Pid pid, T ops );
 Pid spawn(T)( T fun );
 
 spawn() is pretty limited so far in that it only spawns threads--I'd
 expect that function to end up with multiple overloads at some point.
Interesting. Future spawn() may spawn the thread in a remote CPU that doesn't share the memory. In that case it perhaps helps to limit fun to be pure, and val to be immutable, as in Erlang. D already has pure and transitive const, so the first few steps for the massively-parallel D programs are already completed! :-)
Oct 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
MIURA Masahiro wrote:
 Sean Kelly wrote:
 void sendmsg(T)( Pid pid, T val );
 final void recvmsg(T...)( Pid pid, T ops );
 Pid spawn(T)( T fun );

 spawn() is pretty limited so far in that it only spawns threads--I'd
 expect that function to end up with multiple overloads at some point.
Interesting. Future spawn() may spawn the thread in a remote CPU that doesn't share the memory. In that case it perhaps helps to limit fun to be pure, and val to be immutable, as in Erlang. D already has pure and transitive const, so the first few steps for the massively-parallel D programs are already completed! :-)
That's the plan, except that we weren't thinking of creating remote processes, only sending messages across process and machine boundaries. Here's where notions like value vs. reference and deep cloning become very important. Andrei
Oct 12 2009
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:

 MIURA Masahiro wrote:
 Sean Kelly wrote:
 void sendmsg(T)( Pid pid, T val );
 final void recvmsg(T...)( Pid pid, T ops );
 Pid spawn(T)( T fun );

 spawn() is pretty limited so far in that it only spawns threads--I'd
 expect that function to end up with multiple overloads at some point.
Interesting. Future spawn() may spawn the thread in a remote CPU that doesn't share the memory. In that case it perhaps helps to limit fun to be pure, and val to be immutable, as in Erlang. D already has pure and transitive const, so the first few steps for the massively-parallel D programs are already completed! :-)
That's the plan, except that we weren't thinking of creating remote processes, only sending messages across process and machine boundaries. Here's where notions like value vs. reference and deep cloning become very important.
Creating remote threads (maybe not OS-level processes) is certainly possible, and I wouldn't be surprised if we did that at some point, assuming something like spawn() is added. But this would be largely invisible at an API level. Like Andrei, I'm more interested in exploring what types should be allowed within messages, what language and library features are necessary, etc. Restricting messages to only shallow value types is certainly possible, but it's rather limiting. I've also experimented with ways to wrap a "shared" container in the same sendmsg/recvmsg interface, but haven't decided if it's an idea worth pursuing yet (or whether it can even be done in a sufficiently robust manner). In any case, that seemed like one way to eliminate obvious use of mutexes for accessing shared data.
Oct 12 2009
prev sibling next sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-10-13 07:45:41 +0200, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 MIURA Masahiro wrote:
 Sean Kelly wrote:
 void sendmsg(T)( Pid pid, T val );
 final void recvmsg(T...)( Pid pid, T ops );
 Pid spawn(T)( T fun );
 
 spawn() is pretty limited so far in that it only spawns threads--I'd
 expect that function to end up with multiple overloads at some point.
Interesting. Future spawn() may spawn the thread in a remote CPU that doesn't share the memory. In that case it perhaps helps to limit fun to be pure, and val to be immutable, as in Erlang. D already has pure and transitive const, so the first few steps for the massively-parallel D programs are already completed! :-)
That's the plan, except that we weren't thinking of creating remote processes, only sending messages across process and machine boundaries. Here's where notions like value vs. reference and deep cloning become very important. Andrei
I think that there are different parallelization levels, and different strategies, there isn't ne that "rules them all". I am very suspicious of systems where data is moved around "magically", normally the cost of that cannot be ignored, so for coarse level parallelization the message passing approach with explicit data distribution done by the programmer is the way to go. On Numa, or really well connected machines having some kind of shared memory is an option, this works well especially if the data is immutable. Finally when one really has shared memory one can go to task scheduling without thinking too much about transfer of memory, it is this last thing that I did address in my previous post. I think that threads are the wrong approach to parallelization at that level, so what I did was to create Tasks that one can use to express more complex relationships between them, so that one can avoids locks almost always, which is both more efficient and less error prone. Fawzi
Oct 12 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Fawzi Mohamed wrote:
 On 2009-10-13 07:45:41 +0200, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 MIURA Masahiro wrote:
 Sean Kelly wrote:
 void sendmsg(T)( Pid pid, T val );
 final void recvmsg(T...)( Pid pid, T ops );
 Pid spawn(T)( T fun );

 spawn() is pretty limited so far in that it only spawns threads--I'd
 expect that function to end up with multiple overloads at some point.
Interesting. Future spawn() may spawn the thread in a remote CPU that doesn't share the memory. In that case it perhaps helps to limit fun to be pure, and val to be immutable, as in Erlang. D already has pure and transitive const, so the first few steps for the massively-parallel D programs are already completed! :-)
That's the plan, except that we weren't thinking of creating remote processes, only sending messages across process and machine boundaries. Here's where notions like value vs. reference and deep cloning become very important. Andrei
I think that there are different parallelization levels, and different strategies, there isn't ne that "rules them all". I am very suspicious of systems where data is moved around "magically", normally the cost of that cannot be ignored, so for coarse level parallelization the message passing approach with explicit data distribution done by the programmer is the way to go. On Numa, or really well connected machines having some kind of shared memory is an option, this works well especially if the data is immutable. Finally when one really has shared memory one can go to task scheduling without thinking too much about transfer of memory, it is this last thing that I did address in my previous post. I think that threads are the wrong approach to parallelization at that level, so what I did was to create Tasks that one can use to express more complex relationships between them, so that one can avoids locks almost always, which is both more efficient and less error prone.
I also don't believe one model is "ruling them all". I agree that threads aren't the best approach, even things like async I/O can be done with futures, other operations can be done with async methods, the actor model is perfect for lots of independent operations that can be executed in any order, message passing is great for event driven designs such as GUIs, software transactional memory works great with state management, and those are only a few models. Threads only need a platform abstraction in the library, from which all other concurrency models can be built. Jeremie
Oct 13 2009
parent reply MIURA Masahiro <echochamber gmail.com> writes:
Jeremie Pelletier wrote:
 I also don't believe one model is "ruling them all".
Let me clarity this, just in case I have caused an unnecessary confusion: I think Sean's Erlang-like API is meant to coexist with the current core.thread, and that you can use one or both of them to build higher-level concurrency models. I think it's nice to have core.thread *and* message-passing API in Phobos. Thread alone is too primitive for daily use, but we don't want to have too many concurrency models.
Oct 13 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
MIURA Masahiro wrote:
 Jeremie Pelletier wrote:
 I also don't believe one model is "ruling them all".
Let me clarity this, just in case I have caused an unnecessary confusion: I think Sean's Erlang-like API is meant to coexist with the current core.thread, and that you can use one or both of them to build higher-level concurrency models. I think it's nice to have core.thread *and* message-passing API in Phobos. Thread alone is too primitive for daily use, but we don't want to have too many concurrency models.
Absolutely! I agree. We need to attack the beast with everything we have. Andrei
Oct 13 2009
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 13 Oct 2009 11:19:30 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:
 MIURA Masahiro wrote:
 Jeremie Pelletier wrote:
 I also don't believe one model is "ruling them all".
Let me clarity this, just in case I have caused an unnecessary confusion: I think Sean's Erlang-like API is meant to coexist with the current core.thread, and that you can use one or both of them to build higher-level concurrency models. I think it's nice to have core.thread *and* message-passing API in Phobos. Thread alone is too primitive for daily use, but we don't want to have too many concurrency models.
Absolutely! I agree. We need to attack the beast with everything we have. Andrei
I'd recommend reading Bartosz's blog on thread objects vs spawn (http://bartoszmilewski.wordpress.com/2009/09/01/spawning-a-thread-the-d-way/). It makes a really good case for why thread objects should never be sub-classed and therefore should be a private, hidden implementation detail and not a public API.
Oct 13 2009
next sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Robert Jacques wrote:
 On Tue, 13 Oct 2009 11:19:30 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 MIURA Masahiro wrote:
 Jeremie Pelletier wrote:
 I also don't believe one model is "ruling them all".
Let me clarity this, just in case I have caused an unnecessary confusion: I think Sean's Erlang-like API is meant to coexist with the current core.thread, and that you can use one or both of them to build higher-level concurrency models. I think it's nice to have core.thread *and* message-passing API in Phobos. Thread alone is too primitive for daily use, but we don't want to have too many concurrency models.
Absolutely! I agree. We need to attack the beast with everything we have. Andrei
I'd recommend reading Bartosz's blog on thread objects vs spawn (http://bartoszmilewski.wordpress.com/2009/09/01/spawning-a thread-the-d-way/). It makes a really good case for why thread objects should never be sub-classed and therefore should be a private, hidden implementation detail and not a public API.
Threads should NOT be private, I don't mind making them final classes but some programs may not require, or some programmers may not want, the high level constructs. If you put the thread construct in core.thread and the concurrent implementations in std.concurrent you still need the std api to access the core threads. But threads being a core module makes it a "here it is should you want it, but check these standard modules first" kind of module. Threads being public also allow any programmer to build custom concurrent models if they're not in the library. Jeremie
Oct 13 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Tue, 13 Oct 2009 11:19:30 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 MIURA Masahiro wrote:
 Jeremie Pelletier wrote:
 I also don't believe one model is "ruling them all".
Let me clarity this, just in case I have caused an unnecessary confusion: I think Sean's Erlang-like API is meant to coexist with the current core.thread, and that you can use one or both of them to build higher-level concurrency models. I think it's nice to have core.thread *and* message-passing API in Phobos. Thread alone is too primitive for daily use, but we don't want to have too many concurrency models.
Absolutely! I agree. We need to attack the beast with everything we have. Andrei
I'd recommend reading Bartosz's blog on thread objects vs spawn (http://bartoszmilewski.wordpress.com/2009/09/01/spawning-a thread-the-d-way/). It makes a really good case for why thread objects should never be sub-classed and therefore should be a private, hidden implementation detail and not a public API.
I reviewed that article so I guess I read it :o). Bartosz's position is held by many people in the C++ threading community. Andrei
Oct 13 2009
prev sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Andrei Alexandrescu wrote:
 MIURA Masahiro wrote:
 Sean Kelly wrote:
 void sendmsg(T)( Pid pid, T val );
 final void recvmsg(T...)( Pid pid, T ops );
 Pid spawn(T)( T fun );

 spawn() is pretty limited so far in that it only spawns threads--I'd
 expect that function to end up with multiple overloads at some point.
Interesting. Future spawn() may spawn the thread in a remote CPU that doesn't share the memory. In that case it perhaps helps to limit fun to be pure, and val to be immutable, as in Erlang. D already has pure and transitive const, so the first few steps for the massively-parallel D programs are already completed! :-)
That's the plan, except that we weren't thinking of creating remote processes, only sending messages across process and machine boundaries. Here's where notions like value vs. reference and deep cloning become very important. Andrei
With the popularity of cloud computing today and applications pushing toward a client frontend to a server backend, it would only be logical to access server threads from clients. I can see many uses of such a model, for example a cloud IDE that reads from and saves to a specialized version control server, showing what other devs are working on in realtime and being notified instantly of their changes, just like google docs do. That's why I keep saying we need multiple concurrent models in D, there are many usages to every single one of them, and if they can all live together its even better. Jeremie
Oct 13 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Unfortunately, Bartosz has declined to contribute.<
I have read a good amount of his interesting blog posts, he has shown me many things I didn't know about. And he was very happy about the idea of helping D concurrency. Do you know why he has changed his mind regarding this? Maybe because Walter has refused the uniqueness/lend ideas? Bear hugs, bearophile
Oct 12 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 
 Unfortunately, Bartosz has declined to contribute.<
I have read a good amount of his interesting blog posts, he has shown me many things I didn't know about. And he was very happy about the idea of helping D concurrency. Do you know why he has changed his mind regarding this? Maybe because Walter has refused the uniqueness/lend ideas?
You may want to email Bartosz and ask him. Andrei
Oct 12 2009
parent reply Nick B <nickB gmail.com> writes:
Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Unfortunately, Bartosz has declined to contribute.<
I have read a good amount of his interesting blog posts, he has shown me many things I didn't know about. And he was very happy about the idea of helping D concurrency. Do you know why he has changed his mind regarding this? Maybe because Walter has refused the uniqueness/lend ideas?
You may want to email Bartosz and ask him. Andrei
I will ask him, via his blog, and then will post the link. Nick B.
Oct 12 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick B wrote:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Unfortunately, Bartosz has declined to contribute.<
I have read a good amount of his interesting blog posts, he has shown me many things I didn't know about. And he was very happy about the idea of helping D concurrency. Do you know why he has changed his mind regarding this? Maybe because Walter has refused the uniqueness/lend ideas?
You may want to email Bartosz and ask him. Andrei
I will ask him, via his blog, and then will post the link.
Great, in the meantime I've also let him know. FWIW, there's no falling out or other juicy details. Bartosz and I are still good friends, we review each other's work, and I eat the mean brioche he bakes whenever I'm given a chance. Andrei
Oct 12 2009
prev sibling parent Nick B <nickB gmail.com> writes:
Nick B wrote:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Unfortunately, Bartosz has declined to contribute.<
I have read a good amount of his interesting blog posts, he has shown me many things I didn't know about. And he was very happy about the idea of helping D concurrency. Do you know why he has changed his mind regarding this? Maybe because Walter has refused the uniqueness/lend ideas?
You may want to email Bartosz and ask him. Andrei
I will ask him, via his blog, and then will post the link. Nick B.
here it is. http://bartoszmilewski.wordpress.com/2009/09/22/ownership-systems-against-data-races/#comment-922 Nick B.
Oct 12 2009
prev sibling parent Nick B <nickB gmail.com> writes:
bearophile wrote:
 Andrei Alexandrescu:
 
 Unfortunately, Bartosz has declined to contribute.<
I have read a good amount of his interesting blog posts, he has shown me many things I didn't know about. And he was very happy about the idea of helping D concurrency. Do you know why he has changed his mind regarding this? Maybe because Walter has refused the uniqueness/lend ideas?
I believe that Bearophile is likely to be on target here. Bartosz has spent a lot of time and effort educating the D community on the subject of data races etc, and many thanks for him for doing this. And now he 'declined to contribute' ? Too busy at work, perhaps ? More likely, a difference in opinion, as to the direction this should proceed, without any discussion on various/conflicting proposals with the community. Is this the way serious architecture decisions should be made ? Would Walter/Bartosz/Andrei like to comment further .... Nick B
Oct 12 2009
prev sibling next sibling parent Sam Hu <samhudotsamhu gmail.com> writes:
Nick B Wrote:
 Is this the way serious architecture decisions should be made ?
 
 Would  Walter/Bartosz/Andrei like to comment further ....
 
 
 Nick B
Good point.
Oct 12 2009
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-10-12 11:45:55 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Occasionally people here ask for ways in which they can help D. One 
 thing that would be extremely helpful at this point would be to help 
 defining and implementing D's new concurrency API. Unfortunately, 
 Bartosz has declined to contribute. That leaves Walter, Sean, Don, and 
 participants to this group to do it.
So Bartosz quit? Not that much surprising given the all too many missing building blocks. I recently realized that you can easily implement unique in a library. It can work pretty much the same as auto_ptr in C++. But to guaranty uniqueness you need either to rely on convention (as in C++), or add support for lent to the compiler. I know we discussed at length how lent could be implemented, we called it 'scope' and 'escape analysis' at the time and the conclusion you (and Walter I guess) came with was that it was too much for D2. Well, without lent (and thus without unique), safe message passing systems across threads will be limited to immutable data, or copied data, which not at all useful in many situations. Now if you want a good concurrency API relying on convention, then that's great: there are plenty of examples to follow out there. But if you want it to be both safe (enforced) and useful at the same time, that's a mission impossible with the current set of tools available from the compiler. That's why I'm not surprised Bartosz declined to implement it. (And sorry if I sound pessimistic.) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 12 2009
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 12 Oct 2009 21:45:20 -0400, Michel Fortin  
<michel.fortin michelf.com> wrote:

 On 2009-10-12 11:45:55 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> said:

 Occasionally people here ask for ways in which they can help D. One  
 thing that would be extremely helpful at this point would be to help  
 defining and implementing D's new concurrency API. Unfortunately,  
 Bartosz has declined to contribute. That leaves Walter, Sean, Don, and  
 participants to this group to do it.
So Bartosz quit? Not that much surprising given the all too many missing building blocks. I recently realized that you can easily implement unique in a library. It can work pretty much the same as auto_ptr in C++. But to guaranty uniqueness you need either to rely on convention (as in C++), or add support for lent to the compiler. I know we discussed at length how lent could be implemented, we called it 'scope' and 'escape analysis' at the time and the conclusion you (and Walter I guess) came with was that it was too much for D2. Well, without lent (and thus without unique), safe message passing systems across threads will be limited to immutable data, or copied data, which not at all useful in many situations. Now if you want a good concurrency API relying on convention, then that's great: there are plenty of examples to follow out there. But if you want it to be both safe (enforced) and useful at the same time, that's a mission impossible with the current set of tools available from the compiler. That's why I'm not surprised Bartosz declined to implement it. (And sorry if I sound pessimistic.)
I agree. Particularly about lent. Immutable and mutable weren't considered complete without const, so I'm surprised that local and shared are considered complete without lent. You can even implement it without escape analysis. Strangely, from what I remember of Bartosz's posts, it was unique that was the sticking point, though you can implement both unique and owned as library types (though they do become less efficient).
Oct 12 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Robert Jacques wrote:
 On Mon, 12 Oct 2009 21:45:20 -0400, Michel Fortin 
 <michel.fortin michelf.com> wrote:
 
 On 2009-10-12 11:45:55 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:

 Occasionally people here ask for ways in which they can help D. One 
 thing that would be extremely helpful at this point would be to help 
 defining and implementing D's new concurrency API. Unfortunately, 
 Bartosz has declined to contribute. That leaves Walter, Sean, Don, 
 and participants to this group to do it.
So Bartosz quit? Not that much surprising given the all too many missing building blocks. I recently realized that you can easily implement unique in a library. It can work pretty much the same as auto_ptr in C++. But to guaranty uniqueness you need either to rely on convention (as in C++), or add support for lent to the compiler. I know we discussed at length how lent could be implemented, we called it 'scope' and 'escape analysis' at the time and the conclusion you (and Walter I guess) came with was that it was too much for D2. Well, without lent (and thus without unique), safe message passing systems across threads will be limited to immutable data, or copied data, which not at all useful in many situations. Now if you want a good concurrency API relying on convention, then that's great: there are plenty of examples to follow out there. But if you want it to be both safe (enforced) and useful at the same time, that's a mission impossible with the current set of tools available from the compiler. That's why I'm not surprised Bartosz declined to implement it. (And sorry if I sound pessimistic.)
I agree. Particularly about lent. Immutable and mutable weren't considered complete without const, so I'm surprised that local and shared are considered complete without lent. You can even implement it without escape analysis. Strangely, from what I remember of Bartosz's posts, it was unique that was the sticking point, though you can implement both unique and owned as library types (though they do become less efficient).
I may sound ignorant, but that does lent means? I mean the word itself, I couldn't find something relevant on google. Anyways, I agree that we need a type qualifier between unshared (local) and shared, just like const sits between mutable and immutable. It would make shared handling just so much easier and convenient. If shared/lent were properly implemented and as easy to use as immutable/const, we'd already begin to see concurrency APIs, I tried a few times to implement different concurrency models and always failed due to shared requiring either too much casts or forces too many structures and methods to be shared. I vote for a 'lent' qualifier to be implemented in the compiler. Jeremie
Oct 12 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Jeremie Pelletier, el 12 de octubre a las 22:45 me escribiste:
I agree. Particularly about lent. Immutable and mutable weren't
considered complete without const, so I'm surprised that local and
shared are considered complete without lent. You can even
implement it without escape analysis. Strangely, from what I
remember of Bartosz's posts, it was unique that was the sticking
point, though you can implement both unique and owned as library
types (though they do become less efficient).
I may sound ignorant, but that does lent means? I mean the word itself, I couldn't find something relevant on google.
The terms "unique", "shared" and "lent" used here generaly refers to the terms used by Bartoz Milewski in his blog[1]. I think he defines lent in this particular blog post[2], but maybe you might need to read a couple of posts more to understand everything. [1] http://bartoszmilewski.wordpress.com/ [2] http://bartoszmilewski.wordpress.com/2009/05/21/unique_ptr-how-unique-is-it/ -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Sometimes you got to suffer a little in your youth to motivate you to succeed later in life. Do you think if Bill Gates got laid in high school, do you think there'd be a Microsoft? Of course not. You gotta spend a lot of time stuffin your own locker with your underwear wedged up your arse before you think "I'm gona take over the world with computers! You'll see I'll show them."
Oct 12 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Leandro Lucarella wrote:
 Jeremie Pelletier, el 12 de octubre a las 22:45 me escribiste:
 I agree. Particularly about lent. Immutable and mutable weren't
 considered complete without const, so I'm surprised that local and
 shared are considered complete without lent. You can even
 implement it without escape analysis. Strangely, from what I
 remember of Bartosz's posts, it was unique that was the sticking
 point, though you can implement both unique and owned as library
 types (though they do become less efficient).
I may sound ignorant, but that does lent means? I mean the word itself, I couldn't find something relevant on google.
The terms "unique", "shared" and "lent" used here generaly refers to the terms used by Bartoz Milewski in his blog[1]. I think he defines lent in this particular blog post[2], but maybe you might need to read a couple of posts more to understand everything. [1] http://bartoszmilewski.wordpress.com/ [2] http://bartoszmilewski.wordpress.com/2009/05/21/unique_ptr-how-unique-is-it/
I know of this article, he mentions the word but he doesn't say where it comes from. My native language is french (I'm from Quebec, Canada), I don't know every word of the english dictionary. That's why I asked, I'm just curious as to what it meant. I did some googling but I only landed on a religious page :/ I assume it means 'temporary shared' just like const is 'temporary immutable', but if i can make a link with the english language too its even better.
Oct 12 2009
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 13 Oct 2009 01:59:57 -0400, Jeremie Pelletier <jeremiep gmail.com>  
wrote:

 Leandro Lucarella wrote:
 Jeremie Pelletier, el 12 de octubre a las 22:45 me escribiste:
 I agree. Particularly about lent. Immutable and mutable weren't
 considered complete without const, so I'm surprised that local and
 shared are considered complete without lent. You can even
 implement it without escape analysis. Strangely, from what I
 remember of Bartosz's posts, it was unique that was the sticking
 point, though you can implement both unique and owned as library
 types (though they do become less efficient).
I may sound ignorant, but that does lent means? I mean the word itself, I couldn't find something relevant on google.
The terms "unique", "shared" and "lent" used here generaly refers to the terms used by Bartoz Milewski in his blog[1]. I think he defines lent in this particular blog post[2], but maybe you might need to read a couple of posts more to understand everything. [1] http://bartoszmilewski.wordpress.com/ [2] http://bartoszmilewski.wordpress.com/2009/05/21/unique_ptr-how-unique-is-it/
I know of this article, he mentions the word but he doesn't say where it comes from. My native language is french (I'm from Quebec, Canada), I don't know every word of the english dictionary. That's why I asked, I'm just curious as to what it meant. I did some googling but I only landed on a religious page :/ I assume it means 'temporary shared' just like const is 'temporary immutable', but if i can make a link with the english language too its even better.
Oh. Yes Lent is a religious holiday, but it's also simple past tense and past participle of lend. ( From http://en.wiktionary.org/wiki/lent ) Apparently it's based off of lentus from French.
Oct 12 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jeremie Pelletier wrote:
 Leandro Lucarella wrote:
 Jeremie Pelletier, el 12 de octubre a las 22:45 me escribiste:
 I agree. Particularly about lent. Immutable and mutable weren't
 considered complete without const, so I'm surprised that local and
 shared are considered complete without lent. You can even
 implement it without escape analysis. Strangely, from what I
 remember of Bartosz's posts, it was unique that was the sticking
 point, though you can implement both unique and owned as library
 types (though they do become less efficient).
I may sound ignorant, but that does lent means? I mean the word itself, I couldn't find something relevant on google.
The terms "unique", "shared" and "lent" used here generaly refers to the terms used by Bartoz Milewski in his blog[1]. I think he defines lent in this particular blog post[2], but maybe you might need to read a couple of posts more to understand everything. [1] http://bartoszmilewski.wordpress.com/ [2] http://bartoszmilewski.wordpress.com/2009/05/21/unique_ptr-how-unique-is-it/
I know of this article, he mentions the word but he doesn't say where it comes from. My native language is french (I'm from Quebec, Canada), I don't know every word of the english dictionary. That's why I asked, I'm just curious as to what it meant. I did some googling but I only landed on a religious page :/ I assume it means 'temporary shared' just like const is 'temporary immutable', but if i can make a link with the english language too its even better.
to lend loan lending are all of the same root. "lent" is the passive/simple past/past participle form of "to lend". I guess is the French word is one of "confer\'e" or "pr\^et\'e". Andrei P.S. Beer? Coffee? Marriage? I'll be in Quebec City on Dec 10th and 11th for a talk.
Oct 12 2009
next sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Andrei Alexandrescu wrote:
 Jeremie Pelletier wrote:
 Leandro Lucarella wrote:
 Jeremie Pelletier, el 12 de octubre a las 22:45 me escribiste:
 I agree. Particularly about lent. Immutable and mutable weren't
 considered complete without const, so I'm surprised that local and
 shared are considered complete without lent. You can even
 implement it without escape analysis. Strangely, from what I
 remember of Bartosz's posts, it was unique that was the sticking
 point, though you can implement both unique and owned as library
 types (though they do become less efficient).
I may sound ignorant, but that does lent means? I mean the word itself, I couldn't find something relevant on google.
The terms "unique", "shared" and "lent" used here generaly refers to the terms used by Bartoz Milewski in his blog[1]. I think he defines lent in this particular blog post[2], but maybe you might need to read a couple of posts more to understand everything. [1] http://bartoszmilewski.wordpress.com/ [2] http://bartoszmilewski.wordpress.com/2009/05/21/unique_ptr-how-unique-is-it/
I know of this article, he mentions the word but he doesn't say where it comes from. My native language is french (I'm from Quebec, Canada), I don't know every word of the english dictionary. That's why I asked, I'm just curious as to what it meant. I did some googling but I only landed on a religious page :/ I assume it means 'temporary shared' just like const is 'temporary immutable', but if i can make a link with the english language too its even better.
to lend loan lending are all of the same root. "lent" is the passive/simple past/past participle form of "to lend". I guess is the French word is one of "confer\'e" or "pr\^et\'e".
Thanks! I now make the link, may I then suggest the keyword 'borrow', seems to make more sense to me. Do you speak any french or did you just google that? :o)
 Andrei
 
 P.S. Beer? Coffee? Marriage? I'll be in Quebec City on Dec 10th and 11th 
 for a talk.
I will most definitely try to be there, I'd love a beer or a coffee, as for marriage.. you'd need to be female from birth, sorry :) Jeremie
Oct 12 2009
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 13 Oct 2009 02:25:07 -0400, Jeremie Pelletier <jeremiep gmail.com>  
wrote:
 Andrei Alexandrescu wrote:
[snip]
  to lend
 loan
 lending
  are all of the same root. "lent" is the passive/simple past/past  
 participle form of "to lend".
  I guess is the French word is one of "confer\'e" or "pr\^et\'e".
Thanks! I now make the link, may I then suggest the keyword 'borrow', seems to make more sense to me.
Borrow is a verb, borrowed would be correct noun (i.e. past tense). A lent object and a borrowed object have practically the same meaning, but one word has half the number of characters.
Oct 12 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Robert Jacques wrote:
 On Tue, 13 Oct 2009 02:25:07 -0400, Jeremie Pelletier 
 <jeremiep gmail.com> wrote:
 Andrei Alexandrescu wrote:
[snip]
  to lend
 loan
 lending
  are all of the same root. "lent" is the passive/simple past/past 
 participle form of "to lend".
  I guess is the French word is one of "confer\'e" or "pr\^et\'e".
Thanks! I now make the link, may I then suggest the keyword 'borrow', seems to make more sense to me.
Borrow is a verb, borrowed would be correct noun (i.e. past tense). A lent object and a borrowed object have practically the same meaning, but one word has half the number of characters.
I disagree that they have the same meaning, one side lends the object and the other borrows it :) But I agree that it makes more sense after reading what you said, maybe I just don't like the sound of past tense verbs in programming keywords, are there any other such keywords in D? Isn't there a qualifier name that would means lent or borrowed without being past-tense, without being a verb implying it also is a function (such as assert). Jeremie
Oct 12 2009
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 13 Oct 2009 02:50:41 -0400, Jeremie Pelletier <jeremiep gmail.com>  
wrote:

 Robert Jacques wrote:
 On Tue, 13 Oct 2009 02:25:07 -0400, Jeremie Pelletier  
 <jeremiep gmail.com> wrote:
 Andrei Alexandrescu wrote:
[snip]
  to lend
 loan
 lending
  are all of the same root. "lent" is the passive/simple past/past  
 participle form of "to lend".
  I guess is the French word is one of "confer\'e" or "pr\^et\'e".
Thanks! I now make the link, may I then suggest the keyword 'borrow', seems to make more sense to me.
Borrow is a verb, borrowed would be correct noun (i.e. past tense). A lent object and a borrowed object have practically the same meaning, but one word has half the number of characters.
I disagree that they have the same meaning, one side lends the object and the other borrows it :) But I agree that it makes more sense after reading what you said, maybe I just don't like the sound of past tense verbs in programming keywords, are there any other such keywords in D?
shared?
 Isn't there a qualifier name that would means lent or borrowed without  
 being past-tense, without being a verb implying it also is a function  
 (such as assert).

 Jeremie
Oct 12 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
Robert Jacques wrote:
 On Tue, 13 Oct 2009 02:50:41 -0400, Jeremie Pelletier 
 <jeremiep gmail.com> wrote:
 
 Robert Jacques wrote:
 On Tue, 13 Oct 2009 02:25:07 -0400, Jeremie Pelletier 
 <jeremiep gmail.com> wrote:
 Andrei Alexandrescu wrote:
[snip]
  to lend
 loan
 lending
  are all of the same root. "lent" is the passive/simple past/past 
 participle form of "to lend".
  I guess is the French word is one of "confer\'e" or "pr\^et\'e".
Thanks! I now make the link, may I then suggest the keyword 'borrow', seems to make more sense to me.
Borrow is a verb, borrowed would be correct noun (i.e. past tense). A lent object and a borrowed object have practically the same meaning, but one word has half the number of characters.
I disagree that they have the same meaning, one side lends the object and the other borrows it :) But I agree that it makes more sense after reading what you said, maybe I just don't like the sound of past tense verbs in programming keywords, are there any other such keywords in D?
shared?
I stand corrected :x
Oct 13 2009
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-10-13 02:16:30 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 P.S. Beer? Coffee? Marriage? I'll be in Quebec City on Dec 10th and 
 11th for a talk.
So you'll be in my city too. :-) How many of us are in Quebec City? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 13 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Jeremie Pelletier, el 13 de octubre a las 01:59 me escribiste:
 Leandro Lucarella wrote:
Jeremie Pelletier, el 12 de octubre a las 22:45 me escribiste:
I agree. Particularly about lent. Immutable and mutable weren't
considered complete without const, so I'm surprised that local and
shared are considered complete without lent. You can even
implement it without escape analysis. Strangely, from what I
remember of Bartosz's posts, it was unique that was the sticking
point, though you can implement both unique and owned as library
types (though they do become less efficient).
I may sound ignorant, but that does lent means? I mean the word itself, I couldn't find something relevant on google.
The terms "unique", "shared" and "lent" used here generaly refers to the terms used by Bartoz Milewski in his blog[1]. I think he defines lent in this particular blog post[2], but maybe you might need to read a couple of posts more to understand everything. [1] http://bartoszmilewski.wordpress.com/ [2] http://bartoszmilewski.wordpress.com/2009/05/21/unique_ptr-how-unique-is-it/
I know of this article, he mentions the word but he doesn't say where it comes from. My native language is french (I'm from Quebec, Canada), I don't know every word of the english dictionary. That's why I asked, I'm just curious as to what it meant.
Woops! Sorry, I understood exactly the opposite from you mail =/ -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Sus discipulos se miraron sin entended hasta que uno preguntose: Peperino, soy Daniel Q. de Olivos tengo 54 años y aún soy virgen. A lo que Peperino respondiole: Si sos ganso, ganso ser. Y lo frotó, y lo curó y lo sanó. A lo que todos dijeron: ­¡¡¡Peperino se la come, Peperino se la come!!! -- Peperino Pómoro
Oct 13 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jeremie Pelletier:

 I vote for a 'lent' qualifier to be implemented in the compiler.
You may be right, and Bartosz has explained me why and how to use lent. It sounds like a nice idea, but it has some costs too (in language complexity, for example). But I need to use such things in practice, in real (even small) programs to know/understand if I like and understand them enough. So I'd like to have an experimental version of D where such ideas (like lend, nonnull references, and few other things) can be tried, and if they are experimentally seen as not good (by me too), they can be discarded and removed. For me this is true for nonnull references, but such experimental need is even strong for lend. It seem all the long discussion regarding nonnull references has gone nowhere. That has made me a little sad. Only a bit of flow analysis has being accepted, to cover certain cases of a specific bug case of uninitialized objects. Bye, bearophile
Oct 12 2009
next sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
bearophile wrote:
 Jeremie Pelletier:
 
 I vote for a 'lent' qualifier to be implemented in the compiler.
You may be right, and Bartosz has explained me why and how to use lent. It sounds like a nice idea, but it has some costs too (in language complexity, for example). But I need to use such things in practice, in real (even small) programs to know/understand if I like and understand them enough.
I don't see how heavy that cost is since all of const/immutable/lent/shared are type qualifiers, the semantics are already there for const and immutable, and half there for shared. I would also much prefer compiler implementations to be a bit more complex and implement lent/shared properly than push that complexity to user code. If we're trying to get rid of data races and deadlocks and whatnot, the last thing we want are complex implementations in library/user code because they lack the proper language primitives. If we have just those two qualifiers, the rest of the concurrent models can be implemented entirely in the library.
 So I'd like to have an experimental version of D where such ideas (like lend,
nonnull references, and few other things) can be tried, and if they are
experimentally seen as not good (by me too), they can be discarded and removed.
For me this is true for nonnull references, but such experimental need is even
strong for lend.
D2 is already 'experimental' if you consider the state of shared right now :)
 It seem all the long discussion regarding nonnull references has gone nowhere.
That has made me a little sad. Only a bit of flow analysis has being accepted,
to cover certain cases of a specific bug case of uninitialized objects.
I never liked the Object vs Object? syntax, that would just create ambiguity with the ternary conditional. D already dropped the template syntax from C++ to drop the ambiguity with <> and comparison operators. I wouldn't mind something like nonnull(Object), ie yet another type qualifier, although that would get cumbersome in a few cases like const(shared(nonnull(Object))) :o)
 Bye,
 bearophile
Oct 12 2009
next sibling parent Don <nospam nospam.com> writes:
Jeremie Pelletier wrote:
 bearophile wrote:
 Jeremie Pelletier:

 I vote for a 'lent' qualifier to be implemented in the compiler.
You may be right, and Bartosz has explained me why and how to use lent. It sounds like a nice idea, but it has some costs too (in language complexity, for example). But I need to use such things in practice, in real (even small) programs to know/understand if I like and understand them enough.
I don't see how heavy that cost is since all of const/immutable/lent/shared are type qualifiers, the semantics are already there for const and immutable, and half there for shared. I would also much prefer compiler implementations to be a bit more complex and implement lent/shared properly than push that complexity to user code. If we're trying to get rid of data races and deadlocks and whatnot, the last thing we want are complex implementations in library/user code because they lack the proper language primitives. If we have just those two qualifiers, the rest of the concurrent models can be implemented entirely in the library.
 So I'd like to have an experimental version of D where such ideas 
 (like lend, nonnull references, and few other things) can be tried, 
 and if they are experimentally seen as not good (by me too), they can 
 be discarded and removed. For me this is true for nonnull references, 
 but such experimental need is even strong for lend.
D2 is already 'experimental' if you consider the state of shared right now :)
 It seem all the long discussion regarding nonnull references has gone 
 nowhere. That has made me a little sad. Only a bit of flow analysis 
 has being accepted, to cover certain cases of a specific bug case of 
 uninitialized objects.
I never liked the Object vs Object? syntax, that would just create ambiguity with the ternary conditional.
We tried really hard to find a situation that was ambiguous, but without success. I think it's OK. D already dropped the template
 syntax from C++ to drop the ambiguity with <> and comparison operators.
 
 I wouldn't mind something like nonnull(Object), ie yet another type 
 qualifier, although that would get cumbersome in a few cases like 
 const(shared(nonnull(Object))) :o)
 
 Bye,
 bearophile
Oct 13 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 13 Oct 2009 10:10:31 +0400, Jeremie Pelletier <jeremiep gmail.co=
m>  =

wrote:

 I never liked the Object vs Object? syntax, that would just create  =
 ambiguity with the ternary conditional. D already dropped the template=
=
 syntax from C++ to drop the ambiguity with <> and comparison operators=
.

=D0=A1# uses this syntax, and there is no ambiguity.
Oct 13 2009
prev sibling parent Bartosz Milewski <bartosz-nospam relisoft.com> writes:
bearophile Wrote:

 Jeremie Pelletier:
 
 I vote for a 'lent' qualifier to be implemented in the compiler.
You may be right, and Bartosz has explained me why and how to use lent. It sounds like a nice idea, but it has some costs too (in language complexity, for example). But I need to use such things in practice, in real (even small) programs to know/understand if I like and understand them enough. So I'd like to have an experimental version of D where such ideas (like lend, nonnull references, and few other things) can be tried, and if they are experimentally seen as not good (by me too), they can be discarded and removed. For me this is true for nonnull references, but such experimental need is even strong for lend. It seem all the long discussion regarding nonnull references has gone nowhere. That has made me a little sad. Only a bit of flow analysis has being accepted, to cover certain cases of a specific bug case of uninitialized objects.
This is where Java shines. Their annotation system is flexible enough to allow this kind of experimenting. In particular they were able to implement const and nonNull using annotations. See the talk by Mike Ernst from the University of Washington: http://www.vimeo.com/4368251 .
Oct 15 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:

 For what it's worth, I've been experimenting with message-passing for
 one leg of the API.  I decided to copy the Erlang API because it's very
 simple and easy to build fancier stuff on top of.
You may also want to take a look at how actors are in Scala (I think they are a little different than usual, so I think they even have a different name, something like Agents, or something like that): http://www.scala-lang.org/node/242 Bye, bearophile
Oct 12 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
bearophile wrote:
 Sean Kelly:
 
 For what it's worth, I've been experimenting with message-passing for
 one leg of the API.  I decided to copy the Erlang API because it's very
 simple and easy to build fancier stuff on top of.
You may also want to take a look at how actors are in Scala (I think they are a little different than usual, so I think they even have a different name, something like Agents, or something like that): http://www.scala-lang.org/node/242 Bye, bearophile
I really like the actor model, it can scale very well to thousands of concurrent actors, I know the Unreal engine use them for all scriptable entities and can process thousands of them per frame. Bartosz also had an entry about actors: http://bartoszmilewski.wordpress.com/2009/07/16/on-actors-and-casting/ This is definitely one concurrent model I want to see in D.
Oct 12 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jeremie Pelletier wrote:
 bearophile wrote:
 Sean Kelly:

 For what it's worth, I've been experimenting with message-passing for
 one leg of the API.  I decided to copy the Erlang API because it's very
 simple and easy to build fancier stuff on top of.
You may also want to take a look at how actors are in Scala (I think they are a little different than usual, so I think they even have a different name, something like Agents, or something like that): http://www.scala-lang.org/node/242 Bye, bearophile
I really like the actor model, it can scale very well to thousands of concurrent actors, I know the Unreal engine use them for all scriptable entities and can process thousands of them per frame. Bartosz also had an entry about actors: http://bartoszmilewski.wordpress.com/2009/07/16/on-actors-and-casting/ This is definitely one concurrent model I want to see in D.
Same here. If anyone would like to start putting together an actor API, that would be great. Andrei
Oct 12 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
MIURA Masahiro Wrote:

 Jeremie Pelletier wrote:
 I also don't believe one model is "ruling them all".
Let me clarity this, just in case I have caused an unnecessary confusion: I think Sean's Erlang-like API is meant to coexist with the current core.thread, and that you can use one or both of them to build higher-level concurrency models.
Exactly. That's also why I settled on the Erlang-like API instead of something like coroutines. It's possible to build a coroutine API on top of the Erlang API, but not vice-versa.
 I think it's nice to have core.thread *and* message-passing API
 in Phobos.  Thread alone is too primitive for daily use, but
 we don't want to have too many concurrency models.
I see core as holding language-essential stuff and "close to the metal" APIs, and have no inclination of hiding core.thread or core.sync from the user. If someone wants to work at this level and they understand the risks they should be able to. Any higher-level stuff like the message-passing API I proposed would live in Phobos and sit on top of what's in core. I disagree about poor performance though. With unique references or move semantics, a copy of even complex data isn't necessary to ensure that a message is passed safely.
Oct 13 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-10-13 11:39:21 -0400, Sean Kelly <sean invisibleduck.org> said:

 I disagree about poor performance though.  With unique references or 
 move semantics, a copy of even complex data isn't necessary to ensure 
 that a message is passed safely.
Yeah, but for unique reference to be usable you need lent semantics, otherwise you can't make sure you're the unique holder once you call a function to do something with your unique object. Anything that use the reference could be storing it elsewhere: unique!Object o = new Object; o.doSomething(); How in the example above can I enforce that doSomething() won't escape the 'o' reference elsewhere? 'doSomething' could be made 'pure', but that trick will only work for one-argument functions (in the case above, the argument is the implicit 'this') because otherwise a pure function could leak the reference through another argument. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 13 2009
parent Sean Kelly <sean invisibleduck.org> writes:
Michel Fortin Wrote:

 On 2009-10-13 11:39:21 -0400, Sean Kelly <sean invisibleduck.org> said:
 
 I disagree about poor performance though.  With unique references or 
 move semantics, a copy of even complex data isn't necessary to ensure 
 that a message is passed safely.
Yeah, but for unique reference to be usable you need lent semantics, otherwise you can't make sure you're the unique holder once you call a function to do something with your unique object. Anything that use the reference could be storing it elsewhere: unique!Object o = new Object; o.doSomething(); How in the example above can I enforce that doSomething() won't escape the 'o' reference elsewhere? 'doSomething' could be made 'pure', but that trick will only work for one-argument functions (in the case above, the argument is the implicit 'this') because otherwise a pure function could leak the reference through another argument.
I honestly don't know how to enforce this-- I simply mentioned it because people have suggested it. Phobos already has assumeUnique() for converting to invariant, which is one option. I was hoping someone could suggest alternatives.
Oct 13 2009
prev sibling next sibling parent reply Bartosz Milewski <bartosz-nospam relisoft.com> writes:
Nick B Wrote:

 Nick B wrote:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Unfortunately, Bartosz has declined to contribute.<
I have read a good amount of his interesting blog posts, he has shown me many things I didn't know about. And he was very happy about the idea of helping D concurrency. Do you know why he has changed his mind regarding this? Maybe because Walter has refused the uniqueness/lend ideas?
You may want to email Bartosz and ask him. Andrei
I will ask him, via his blog, and then will post the link. Nick B.
here it is. http://bartoszmilewski.wordpress.com/2009/09/22/ownership-systems-against-data-races/#comment-922 Nick B.
It's good to know that my ideas are still circulating in the D community. Thanks, guys! Since I'm now put on the spot, I have to explain my recent detachment from D. I didn't so much "decline to contribute" as hit a wall. I'm a bit of a perfectionist and it's hard for me to subscribe to the "good enough" philosophy (as long as it's better that C++, it's fine for D). My impression is that, as the release of D2 and the publication of Andrei's book are nearing, this attitude is gaining ground. I try to fight this attitude but it's an uphill battle. Or, as Andrei puts it, I start whining and give up ;-). Particular issues that bother me are: The semantics of "shared." I can live with postponing the implementation of the race-free type system, but not with the compiler inserting barriers around all shared reads and writes, even inside synchronized sections. The C++-derived template metaprogramming mess. Especially when C++0x provides better support for variadic templates than D (see my upcoming blog). I fought successfully for non-functional approach to string mixins. The same is needed for more general templates. In my opinion, there should not be any part of the language that is understandable only by seasoned library writers. The "better than Java" aspect of D ignores the latest development in Java. In particular the work on non-null pointers and the use of annotations for type-system extensions. Annotations are being added to D as we speak because it finally became obvious that no amount of cleverness can make object properties work without additional syntax. So the patching begins, without a clear vision of the role of annotation in future D. As far as my thread work went, I had an almost working implementation of spawn, except for a nasty compiler bug which resisted all efforts to reduce it to a simple test case. Threads also required some clever work with templates (testing arguments to "spawn" for sharing violations). I implemented typelist.d in Phobos to make it easier, and learned how inflexible D templates were. At least they are better than C++, or are they?
Oct 13 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-10-13 18:26:04 -0400, Bartosz Milewski 
<bartosz-nospam relisoft.com> said:

 I didn't so much "decline to contribute" as hit a wall. I'm a bit of a 
 perfectionist and it's hard for me to subscribe to the "good enough" 
 philosophy (as long as it's better that C++, it's fine for D). My 
 impression is that, as the release of D2 and the publication of 
 Andrei's book are nearing, this attitude is gaining ground. I try to 
 fight this attitude but it's an uphill battle. Or, as Andrei puts it, I 
 start whining and give up ;-).
I don't like that attitude either. I'd rather remove completely an unfinished feature than leave it there half-done. If the main feature of D2 is a new concurrency model, then leaving things in the state they are now isn't going to impress much.
 The semantics of "shared." I can live with postponing the 
 implementation of the race-free type system, but not with the compiler 
 inserting barriers around all shared reads and writes, even inside 
 synchronized sections.
I hadn't thought about that, but it's somewhat ridiculous. On my part I'm more preoccupied by the absence of lent semantics as it goes much deeper than concurrency: you need it to implement proper invariant constructors and unique references.
 The C++-derived template metaprogramming mess. Especially when C++0x 
 provides better support for variadic templates than D (see my upcoming 
 blog). I fought successfully for non-functional approach to string 
 mixins. The same is needed for more general templates. In my opinion, 
 there should not be any part of the language that is understandable 
 only by seasoned library writers.
I'm quite eager to read about that.
 The "better than Java" aspect of D ignores the latest development in 
 Java. In particular the work on non-null pointers and the use of 
 annotations for type-system extensions. Annotations are being added to 
 D as we speak because it finally became obvious that no amount of 
 cleverness can make object properties work without additional syntax. 
 So the patching begins, without a clear vision of the role of 
 annotation in future D.
I'm not even sure what convinced Walter to put annotations in and what they're supposed to be capable of. I hope it's not just a new way to create keywords without them really being keywords.
 As far as my thread work went, I had an almost working implementation 
 of spawn, except for a nasty compiler bug which resisted all efforts to 
 reduce it to a simple test case. Threads also required some clever work 
 with templates (testing arguments to "spawn" for sharing violations). I 
 implemented typelist.d in Phobos to make it easier, and learned how 
 inflexible D templates were. At least they are better than C++, or are 
 they?
I'm not that satisfied with D templates either. You can use them in mixins to achieve pretty amazing things, but I've been hindered by the visibility rules with non-mixin templates and how templates with alias arguments are difficult to instantiate in certain contexts. If it were me in charge of the D2 project, given the approaching deadline, I'd scrap the new concurrency model completely (including immutable, unless we are given a way to write safe constructor for it) and focus on everything else. In my view, that's better than leave it in the state it is now. (Note that I'm speaking of the model at the compiler level, creating new library code is a perfectly fine idea.) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 13 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bartosz Milewski:

It's good to know that my ideas are still circulating in the D community.
Thanks, guys!<
They will keep circulating! And there's not just D in computer science, future computer languages may use your ideas. Someday I'll design my own C-like language, simpler (and more limited in scope) than D ;-)
Since I'm now put on the spot, I have to explain my recent detachment from D.<
This makes me (and surely many other persons here) a little sad. D is an engineering project, and it's not small. And the first thing to learn about all sizeable real-world engineering projects (like the creation of a large bridge, or many other things) is that they are first of all politics. They are not the result of rationality, even if often some rationality is required. All large engineering project come out of a large amount of compromises. If you pretend to see one of such systems to come out of rationality alone, you will never see a real one. So every time you have to fight for the rationality to prevail, and you have to be ready to accept some compromises. It's life.
it's hard for me to subscribe to the "good enough" philosophy (as long as it's
better that C++, it's fine for D).<
D language is largely grown, and not designed. D is not Scala or Haskell. I think there is not enough brain mass in this group to design rationally a C++-class language. Probably there's not even brain mass to design a Python-class language. D2 will surely have a big amount of design mistakes, every one here can list you some of them. But one of the best qualities of Walter is that he's not frozen, he sometimes seems to move very slowly, but he never stops moving, and usually he eventually sees the light (and when this happens it's usually a small surprise for everyone else, like the show of a rabbit pulled out of a hat). So I think some of the design mistakes of D2 will be fixed in D3 :-)
My impression is that, as the release of D2 and the publication of Andrei's
book are nearing, this attitude is gaining ground. I try to fight this attitude
but it's an uphill battle. Or, as Andrei puts it, I start whining and give up
;-).<
Andrei's book comes too much early, forcing rhythms that I think aren't good for D2. On the other hand no software is ever finished, it's just abandoned. And you must not think of D2 as the finished product :-) You may even think of D2 as just a bridge toward D3 :-) D2 is probably just an experiment, to experimentally see what design ideas are good and what to throw away and redesign. And such things are slow. So you may want to come back in few years, to try to improve the concurrency design of D3 :-)
The semantics of "shared." I can live with postponing the implementation of the
race-free type system, but not with the compiler inserting barriers around all
shared reads and writes, even inside synchronized sections.<
This is a topic that can be discussed. If enough people think this is a problem, then eventually Walter may change his mind, or he may design something better, etc. If no one discussed problems they can't be fixed/improved. I know that discussing things and accepting compromises is a pain, but it's an inevitable pain. Rationality alone usually never wins, you need politics too.
The C++-derived template metaprogramming mess. Especially when C++0x provides
better support for variadic templates than D (see my upcoming blog). I fought
successfully for non-functional approach to string mixins. The same is needed
for more general templates. In my opinion, there should not be any part of the
language that is understandable only by seasoned library writers.<
Again, this seems a small piece of D2, so it may be fixed if enough people think this is bad. You can explain what do you want to change here, and people will see and think. Eventually it may even be fixed.
The "better than Java" aspect of D ignores the latest development in Java. In
particular the work on non-null pointers<
We have discussed weeks about nonnull references in D (and I have even discussed about nonnull pointers too), I have done my best. A good percentage of people have said that they like to try this idea. Walter in the end was not interested (I think). But maybe in future the situation will change. There's always hope on this. At the end I have seen no one say "This is a totally wrong idea and will never see the light in D".
and the use of annotations for type-system extensions. Annotations are being
added to D as we speak because it finally became obvious that no amount of
cleverness can make object properties work without additional syntax. So the
patching begins, without a clear vision of the role of annotation in future D.<
Annotations in D are just an embryo, and I think they come from no design yet, they are just a bit copied from Java. If you have a vision for their role in D, then it's a very good moment to talk and show such vision. I am sure we will be interested to listen. It's surely not too much late to design them well.
As far as my thread work went, I had an almost working implementation of spawn,
except for a nasty compiler bug which resisted all efforts to reduce it to a
simple test case. Threads also required some clever work with templates
(testing arguments to "spawn" for sharing violations).<
Walter isn't magic. If some feature is very hard to implement then it may be better to not add it until a good implementation is actually created.
I implemented typelist.d in Phobos to make it easier, and learned how
inflexible D templates were. At least they are better than C++, or are they?<
D templates are not "better" than C++ ones, they are simpler to use, less bug-prone, nicer-looking, but I think they are also less flexible. In D there are many things that are less flexible than similar things in C++ (see for example operator overloading too), this can be a good thing, a design choice, because too much flexibility makes a design bug-prone, complex to implement and harder to use. So you often want less flexibility, even if in hard situations (like your one) such limits may look bad. Bye and thank you for all your work so far, bearophile
Oct 14 2009
next sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
bearophile wrote:
 Bartosz Milewski:
 
 It's good to know that my ideas are still circulating in the D community.
Thanks, guys!<
They will keep circulating! And there's not just D in computer science, future computer languages may use your ideas. Someday I'll design my own C-like language, simpler (and more limited in scope) than D ;-)
 Since I'm now put on the spot, I have to explain my recent detachment from D.<
This makes me (and surely many other persons here) a little sad.
Same here, I read your blog with much interest and check it almost daily for updates, your ideas about concurrency are really inspiring! I'm also sure many of us here, me included, did our first steps in GUI programming years ago by following your tutorial on reliable software.
 D is an engineering project, and it's not small. And the first thing to learn
about all sizeable real-world engineering projects (like the creation of a
large bridge, or many other things) is that they are first of all politics.
They are not the result of rationality, even if often some rationality is
required. All large engineering project come out of a large amount of
compromises. If you pretend to see one of such systems to come out of
rationality alone, you will never see a real one. 
 
 So every time you have to fight for the rationality to prevail, and you have
to be ready to accept some compromises. It's life.
I still have faith that Walter and Andrei can filter out all the ideas here no matter how heated up the arguments and come up with a design that will be a decent compromise in the requested features and design changes.
 it's hard for me to subscribe to the "good enough" philosophy (as long as it's
better that C++, it's fine for D).<
D language is largely grown, and not designed. D is not Scala or Haskell. I think there is not enough brain mass in this group to design rationally a C++-class language. Probably there's not even brain mass to design a Python-class language. D2 will surely have a big amount of design mistakes, every one here can list you some of them. But one of the best qualities of Walter is that he's not frozen, he sometimes seems to move very slowly, but he never stops moving, and usually he eventually sees the light (and when this happens it's usually a small surprise for everyone else, like the show of a rabbit pulled out of a hat). So I think some of the design mistakes of D2 will be fixed in D3 :-)
The brain mass is there, more than enough too. Its the manpower that lacks, we propose way more features than we have manpower to implement in time to either release them or properly test them and see if the design works as good as wanted. A lot of us would like to contribute to the compiler and library but we're already busy with our daily jobs, maybe Walter needs to hire half this newsgroup and build us an office :o)
 My impression is that, as the release of D2 and the publication of Andrei's
book are nearing, this attitude is gaining ground. I try to fight this attitude
but it's an uphill battle. Or, as Andrei puts it, I start whining and give up
;-).<
Andrei's book comes too much early, forcing rhythms that I think aren't good for D2. On the other hand no software is ever finished, it's just abandoned. And you must not think of D2 as the finished product :-) You may even think of D2 as just a bridge toward D3 :-) D2 is probably just an experiment, to experimentally see what design ideas are good and what to throw away and redesign. And such things are slow. So you may want to come back in few years, to try to improve the concurrency design of D3 :-)
I agree here, while I think Andrei's book is a must for the community to grow, it should rush the compiler. I strongly believe D2 needs proper shared and lent semantics, or else we're just creating a stepping stone for D3, leaving D2 in a state that isn't suited for concurrent model implementations in a type-safe manner. I don't mind however getting the spec ready with the features coming in the near future as part of D2 (either in patch releases or minor releases, ie 2.1).
 The semantics of "shared." I can live with postponing the implementation of
the race-free type system, but not with the compiler inserting barriers around
all shared reads and writes, even inside synchronized sections.<
This is a topic that can be discussed. If enough people think this is a problem, then eventually Walter may change his mind, or he may design something better, etc. If no one discussed problems they can't be fixed/improved. I know that discussing things and accepting compromises is a pain, but it's an inevitable pain. Rationality alone usually never wins, you need politics too.
I brought up this topic a number of time without much success. Shared is hard to work with right now without tons of casting. It's also way too easy to accidentally write recursive locks with the current synchronized model, which is a nice fallback for the code to run, but generates way more calls than is actually needed. If what we need are politics, then the republic of J (aka my ego) declares we need shared and lent qualifier in D that are as easy to use without a casting mess as immutable and const are, the rest of the concurrent details will follow in the many, many library implemented models.
 The C++-derived template metaprogramming mess. Especially when C++0x provides
better support for variadic templates than D (see my upcoming blog). I fought
successfully for non-functional approach to string mixins. The same is needed
for more general templates. In my opinion, there should not be any part of the
language that is understandable only by seasoned library writers.<
Again, this seems a small piece of D2, so it may be fixed if enough people think this is bad. You can explain what do you want to change here, and people will see and think. Eventually it may even be fixed.
I can't wait to read the article, I agree that forcing templates to work in a functional way is often counter-intuitive, took me a while to get used to it.
 The "better than Java" aspect of D ignores the latest development in Java. In
particular the work on non-null pointers<
We have discussed weeks about nonnull references in D (and I have even discussed about nonnull pointers too), I have done my best. A good percentage of people have said that they like to try this idea. Walter in the end was not interested (I think). But maybe in future the situation will change. There's always hope on this. At the end I have seen no one say "This is a totally wrong idea and will never see the light in D".
We just haven't found an elegant and practical solution to it yet.
 and the use of annotations for type-system extensions. Annotations are being
added to D as we speak because it finally became obvious that no amount of
cleverness can make object properties work without additional syntax. So the
patching begins, without a clear vision of the role of annotation in future D.<
Annotations in D are just an embryo, and I think they come from no design yet, they are just a bit copied from Java. If you have a vision for their role in D, then it's a very good moment to talk and show such vision. I am sure we will be interested to listen. It's surely not too much late to design them well.
 As far as my thread work went, I had an almost working implementation of
spawn, except for a nasty compiler bug which resisted all efforts to reduce it
to a simple test case. Threads also required some clever work with templates
(testing arguments to "spawn" for sharing violations).<
Walter isn't magic. If some feature is very hard to implement then it may be better to not add it until a good implementation is actually created.
 I implemented typelist.d in Phobos to make it easier, and learned how
inflexible D templates were. At least they are better than C++, or are they?<
D templates are not "better" than C++ ones, they are simpler to use, less bug-prone, nicer-looking, but I think they are also less flexible. In D there are many things that are less flexible than similar things in C++ (see for example operator overloading too), this can be a good thing, a design choice, because too much flexibility makes a design bug-prone, complex to implement and harder to use. So you often want less flexibility, even if in hard situations (like your one) such limits may look bad.
I partly disagree here, more flexibility is a great thing for a systems language, but it doesn't have to be the only way of doing things. Less flexibility is often only a good thing in higher level languages.
 Bye and thank you for all your work so far,
 bearophile
Oct 14 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Jeremie Pelletier wrote:
 I agree here, while I think Andrei's book is a must for the community to 
 grow, it should rush the compiler. I strongly believe D2 needs proper 
 shared and lent semantics, or else we're just creating a stepping stone 
 for D3, leaving D2 in a state that isn't suited for concurrent model 
 implementations in a type-safe manner.
s/should rush/shouldn't rush/
Oct 14 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jeremie Pelletier wrote:
 Jeremie Pelletier wrote:
 I agree here, while I think Andrei's book is a must for the community 
 to grow, it should rush the compiler. I strongly believe D2 needs 
 proper shared and lent semantics, or else we're just creating a 
 stepping stone for D3, leaving D2 in a state that isn't suited for 
 concurrent model implementations in a type-safe manner.
s/should rush/shouldn't rush/
For the record, I delayed signing for the book for quite a few months. Before I did sign, there was solemn agreement in the D team that we can commit. The book is already late by a few months. If the book is trying to rush anything, it's doing a lousy job at that. Andrei
Oct 14 2009
parent reply Nick B <nickB gmail.com> writes:
Andrei Alexandrescu wrote:

 
 For the record, I delayed signing for the book for quite a few months. 
 Before I did sign, there was solemn agreement in the D team that we can 
 commit. [snip]
 
Commit to what, exactly ? Nick B
Oct 14 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick B wrote:
 Andrei Alexandrescu wrote:
 
 For the record, I delayed signing for the book for quite a few months. 
 Before I did sign, there was solemn agreement in the D team that we 
 can commit. [snip]
Commit to what, exactly ? Nick B
Commit to delivering the book and the language matching it. Andrei
Oct 14 2009
parent reply Nick B <nickB gmail.com> writes:
Andrei Alexandrescu wrote:


 Commit to what, exactly ?

 Nick B
Commit to delivering the book and the language matching it. Andrei
To meet a final release of D 2.0 ? Nick B
Oct 14 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick B wrote:
 Andrei Alexandrescu wrote:
 

 Commit to what, exactly ?

 Nick B
Commit to delivering the book and the language matching it. Andrei
To meet a final release of D 2.0 ? Nick B
Yes, that's the plan. D2 final release begets TDPL, and TDPL describes the final release of D2. Andrei
Oct 14 2009
prev sibling parent Bartosz Milewski <bartosz-nospam relisoft.com> writes:
bearophile Wrote:

 
it's hard for me to subscribe to the "good enough" philosophy (as long as it's
better that C++, it's fine for D).<
D language is largely grown, and not designed. D is not Scala or Haskell. ... So I think some of the design mistakes of D2 will be fixed in D3 :-)
With every release of D we are narrowing our options. After D2 and TDPL, backward compatibility will become a major thing, so every ad-hoc feature in D2 will have to be carried over. Why is C++ so bad? Not for lack of brainpower. It's because it fell into the compatibility trap (essentially from day one). There are some areas of D, like Andrei's ranges, that are well thought out and theoretically sound (we hope), but there are also hacks upon hacks that make my hair stand on end.
Oct 14 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Bartosz Milewski wrote:
 Nick B Wrote:
 
 Nick B wrote:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Unfortunately, Bartosz has declined to contribute.<
I have read a good amount of his interesting blog posts, he has shown me many things I didn't know about. And he was very happy about the idea of helping D concurrency. Do you know why he has changed his mind regarding this? Maybe because Walter has refused the uniqueness/lend ideas?
You may want to email Bartosz and ask him. Andrei
I will ask him, via his blog, and then will post the link. Nick B.
here it is. http://bartoszmilewski.wordpress.com/2009/09/22/ownership-systems-against-data-races/#comment-922 Nick B.
It's good to know that my ideas are still circulating in the D community. Thanks, guys! Since I'm now put on the spot, I have to explain my recent detachment from D. I didn't so much "decline to contribute" as hit a wall. I'm a bit of a perfectionist and it's hard for me to subscribe to the "good enough" philosophy (as long as it's better that C++, it's fine for D). My impression is that, as the release of D2 and the publication of Andrei's book are nearing, this attitude is gaining ground. I try to fight this attitude but it's an uphill battle. Or, as Andrei puts it, I start whining and give up ;-).
Please stay in touch, we will try to win you back... Of the issues you mention, this one seems the easiest to address:
 As far as my thread work went, I had an almost working implementation of
spawn, except for a nasty compiler bug which resisted all efforts to reduce it
to a simple test case.
Could you give us _any_ kind of test case (even if it's enormous)?
Oct 14 2009
parent reply Nick B <nickB gmail.com> writes:
Don wrote:
 Bartosz Milewski wrote:
 [snip]
 Please stay in touch, we will try to win you back...
 
 Of the issues you mention, this one seems the easiest to address:
 
 As far as my thread work went, I had an almost working implementation 
 of spawn, except for a nasty compiler bug which resisted all efforts 
 to reduce it to a simple test case.
Could you give us _any_ kind of test case (even if it's enormous)?
Bartosz - are you able to provide a test case as requested by Don ? Then it might be possible, to get this bug fixed. Nick B.
Oct 14 2009
parent reply Bartosz Milewski <bartosz-nospam relisoft.com> writes:
Nick B Wrote:
 
 Could you give us _any_ kind of test case (even if it's enormous)?
Bartosz - are you able to provide a test case as requested by Don ? Then it might be possible, to get this bug fixed. Nick B.
I can send you the files I have checked out. The problem was in core.thread. I tried to implement a struct Tid (thread ID) with reference-counting semantics and deterministic destruction. It passed all the tests, but when it was used in one particular place in druntime it produced incorrect assembly. Even the slightest change made the bug disappear, so I wasn't able to reproduce it under controlled conditions. Unfortunately, I have undone some of my changes trying to bypass the bug, so at the moment I don't even have the buggy version, but it can be reconstructed. We can discuss it off-line, if you want. Use my email address with -nospam removed.
Oct 14 2009
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wed, Oct 14, 2009 at 05:56:10PM -0400, Bartosz Milewski wrote:
 The problem was in core.thread. I tried to implement a struct Tid (thread ID)
with reference-counting semantics and deterministic destruction. It passed all
the tests, but when it was used in one particular place in druntime it produced
incorrect assembly. Even the slightest change made the bug disappear, so I
wasn't able to reproduce it under controlled conditions.
Was it by any chance a null this pointer making its way into the ebx register somehow, thus causing an access violation on Windows seemingly at random? (My bug didn't happen if I compiled the exact same code on Linux - I figure it must be a Windows codegen problem.) If so, I've been fighting that bug for over two years, similarly unable to track down a small test case. I haven't put it on bugzilla since I can't even really prove it exists to an outsider. I just keep hoping that the next dmd release will magically fix it. -- Adam D. Ruppe http://arsdnet.net
Oct 14 2009
prev sibling parent reply Nick B <nickB gmail.com> writes:
Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?
Bartosz - are you able to provide a test case as requested by Don ? Then it might be possible, to get this bug fixed. Nick B.
I can send you the files I have checked out. The problem was in core.thread. I tried to implement a struct Tid (thread ID) with reference-counting semantics and deterministic destruction. It passed all the tests, but when it was used in one particular place in druntime it produced incorrect assembly. Even the slightest change made the bug disappear, so I wasn't able to reproduce it under controlled conditions. Unfortunately, I have undone some of my changes trying to bypass the bug, so at the moment I don't even have the buggy version, but it can be reconstructed. We can discuss it off-line, if you want. Use my email address with -nospam removed.
Bartosz I think that Don is the best person to contact you. I will try to contact him. Nick B
Oct 14 2009
parent reply Nick B <nickB gmail.com> writes:
Nick B wrote:
 Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?
Bartosz - are you able to provide a test case as requested by Don ? Then it might be possible, to get this bug fixed. Nick B.
I can send you the files I have checked out. The problem was in core.thread. I tried to implement a struct Tid (thread ID) with reference-counting semantics and deterministic destruction. It passed all the tests, but when it was used in one particular place in druntime it produced incorrect assembly. Even the slightest change made the bug disappear, so I wasn't able to reproduce it under controlled conditions. Unfortunately, I have undone some of my changes trying to bypass the bug, so at the moment I don't even have the buggy version, but it can be reconstructed. We can discuss it off-line, if you want. Use my email address with -nospam removed.
Bartosz I think that Don is the best person to contact you. I will try to contact him. Nick B
Don, are you able to contact Bartosz, re the details of this test case. Nick B
Oct 15 2009
parent reply Don <nospam nospam.com> writes:
Nick B wrote:
 Nick B wrote:
 Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?
Bartosz - are you able to provide a test case as requested by Don ? Then it might be possible, to get this bug fixed. Nick B.
I can send you the files I have checked out. The problem was in core.thread. I tried to implement a struct Tid (thread ID) with reference-counting semantics and deterministic destruction. It passed all the tests, but when it was used in one particular place in druntime it produced incorrect assembly. Even the slightest change made the bug disappear, so I wasn't able to reproduce it under controlled conditions. Unfortunately, I have undone some of my changes trying to bypass the bug, so at the moment I don't even have the buggy version, but it can be reconstructed. We can discuss it off-line, if you want. Use my email address with -nospam removed.
Bartosz I think that Don is the best person to contact you. I will try to contact him. Nick B
Don, are you able to contact Bartosz, re the details of this test case. Nick B
Bartosz has sent it to me. I can reproduce the error. It's my top priority, but it'll take a while -- it's nasty.
Oct 20 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Don, el 20 de octubre a las 09:00 me escribiste:
Unfortunately, I have undone some of my changes trying to
bypass the bug, so at the moment I don't even have the buggy
version, but it can be reconstructed. We can discuss it
off-line, if you want. Use my email address with -nospam
removed.
Bartosz I think that Don is the best person to contact you. I will try to contact him. Nick B
Don, are you able to contact Bartosz, re the details of this test case. Nick B
Bartosz has sent it to me. I can reproduce the error. It's my top priority, but it'll take a while -- it's nasty.
Do you have a bugzilla # so we can keep track of it? Thanks. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- HACIA NEUQUEN: EL JUEVES SALDRA CARAVANA CON PERROS DESDE CAPITAL EN APOYO AL CACHORRO CONDENADO A MUERTE -- Crónica TV
Oct 20 2009
prev sibling next sibling parent reply Nick B <nickB gmail.com> writes:
Don wrote:


 Don, are you able to contact Bartosz, re the details of this test case.

 Nick B
Bartosz has sent it to me. I can reproduce the error. It's my top priority, but it'll take a while -- it's nasty.
Don - thanks for filing this. I did try to contact you, via bugzilla email (which bounced back)and via Skype,(no reply), without success. Nick B
Oct 20 2009
parent reply Don <nospam nospam.com> writes:
Nick B wrote:
 Don wrote:
 
 
 Don, are you able to contact Bartosz, re the details of this test case.

 Nick B
Bartosz has sent it to me. I can reproduce the error. It's my top priority, but it'll take a while -- it's nasty.
Don - thanks for filing this. I did try to contact you, via bugzilla email (which bounced back)and via Skype,(no reply), without success. Nick B
All my public email addresses are fake. Bugzilla is just spam bait. It clearly comes from a more innocent age. I once made the mistake of submitting a bug to gcc. Although the GCC Bugzilla hides the email in the submitter field, the idiots include the real email address in the 100% useless 'X-Ref' line. Two weeks later, my email address was dead. I've never made that mistake again. I am contactable through my dsource account.
Oct 21 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Don, el 21 de octubre a las 09:46 me escribiste:
 Nick B wrote:
Don wrote:


Don, are you able to contact Bartosz, re the details of this test case.

Nick B
Bartosz has sent it to me. I can reproduce the error. It's my top priority, but it'll take a while -- it's nasty.
Don - thanks for filing this. I did try to contact you, via bugzilla email (which bounced back)and via Skype,(no reply), without success. Nick B
All my public email addresses are fake. Bugzilla is just spam bait. It clearly comes from a more innocent age. I once made the mistake of submitting a bug to gcc. Although the GCC Bugzilla hides the email in the submitter field, the idiots include the real email address in the 100% useless 'X-Ref' line. Two weeks later, my email address was dead. I've never made that mistake again. I am contactable through my dsource account.
You don't even use a real account for personal e-mails! That's odd. I couldn't reply your private e-mail about changing the title of the bugzilla report because the From address were fake. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Hoy estuvimos en el museo de antropología, pero yo voy a volver para estar por lo menos un día ahí adentro... es una locura, como Disney pero de indigenas -- Carla Lucarella (10/2008 contando de su viaje a México)
Oct 21 2009
parent reply Nick B <nickB gmail.com> writes:
Leandro Lucarella wrote:
 Don, el 21 de octubre a las 09:46 me escribiste:
 
 All my public email addresses are fake. Bugzilla is just spam bait.
 It clearly comes from a more innocent age. I once made the mistake
 of submitting a bug to gcc. Although the GCC Bugzilla hides the
 email in the submitter field, the idiots include the real email
 address in the 100% useless 'X-Ref' line. Two weeks later, my email
 address was dead. I've never made that mistake again.
 I am contactable through my dsource account.
You don't even use a real account for personal e-mails! That's odd. I couldn't reply your private e-mail about changing the title of the bugzilla report because the From address were fake.
Yes, I too use fake personal email accounts, as I do not want my gmail accounts hammered with spam. I could add -nospam to the name, but I am unsure how good the spammers are these days to get around this. Any suggestions/comments, anyone ? Nick B
Oct 21 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick B wrote:
 Leandro Lucarella wrote:
 Don, el 21 de octubre a las 09:46 me escribiste:
 All my public email addresses are fake. Bugzilla is just spam bait.
 It clearly comes from a more innocent age. I once made the mistake
 of submitting a bug to gcc. Although the GCC Bugzilla hides the
 email in the submitter field, the idiots include the real email
 address in the 100% useless 'X-Ref' line. Two weeks later, my email
 address was dead. I've never made that mistake again.
 I am contactable through my dsource account.
You don't even use a real account for personal e-mails! That's odd. I couldn't reply your private e-mail about changing the title of the bugzilla report because the From address were fake.
Yes, I too use fake personal email accounts, as I do not want my gmail accounts hammered with spam. I could add -nospam to the name, but I am unsure how good the spammers are these days to get around this. Any suggestions/comments, anyone ? Nick B
If you have a domain, my low-tech approach seems to work pretty well. Andrei
Oct 22 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Nick B, el 22 de octubre a las 19:35 me escribiste:
 Leandro Lucarella wrote:
Don, el 21 de octubre a las 09:46 me escribiste:
All my public email addresses are fake. Bugzilla is just spam bait.
It clearly comes from a more innocent age. I once made the mistake
of submitting a bug to gcc. Although the GCC Bugzilla hides the
email in the submitter field, the idiots include the real email
address in the 100% useless 'X-Ref' line. Two weeks later, my email
address was dead. I've never made that mistake again.
I am contactable through my dsource account.
You don't even use a real account for personal e-mails! That's odd. I couldn't reply your private e-mail about changing the title of the bugzilla report because the From address were fake.
Yes, I too use fake personal email accounts, as I do not want my gmail accounts hammered with spam. I could add -nospam to the name, but I am unsure how good the spammers are these days to get around this. Any suggestions/comments, anyone ?
I just use my real e-mail everywhere and let the spammers eat the world's BW as they please. I just let my anti-spam (bogofilter and gmail in case of the gmail address) to take care of things... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Que importante, entonces en estos días de globalización refregar nuestras almas, pasarle el lampazo a nuestros corazones para alcanzar un verdadero estado de babia peperianal. -- Peperino Pómoro
Oct 22 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 22 Oct 2009 17:32:00 +0400, Leandro Lucarella <llucax gmail.com>  
wrote:

 Nick B, el 22 de octubre a las 19:35 me escribiste:
 Leandro Lucarella wrote:
Don, el 21 de octubre a las 09:46 me escribiste:
All my public email addresses are fake. Bugzilla is just spam bait.
It clearly comes from a more innocent age. I once made the mistake
of submitting a bug to gcc. Although the GCC Bugzilla hides the
email in the submitter field, the idiots include the real email
address in the 100% useless 'X-Ref' line. Two weeks later, my email
address was dead. I've never made that mistake again.
I am contactable through my dsource account.
You don't even use a real account for personal e-mails! That's odd. I couldn't reply your private e-mail about changing the title of the bugzilla report because the From address were fake.
Yes, I too use fake personal email accounts, as I do not want my gmail accounts hammered with spam. I could add -nospam to the name, but I am unsure how good the spammers are these days to get around this. Any suggestions/comments, anyone ?
I just use my real e-mail everywhere and let the spammers eat the world's BW as they please. I just let my anti-spam (bogofilter and gmail in case of the gmail address) to take care of things...
So do I. And as a result I missed a very important message sent to me about a week ago (I was classified as a spam for some reason) :(
Oct 22 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 22 Oct 2009 09:32:00 -0400, Leandro Lucarella <llucax gmail.com>  
wrote:

 Nick B, el 22 de octubre a las 19:35 me escribiste:
 Leandro Lucarella wrote:
Don, el 21 de octubre a las 09:46 me escribiste:
All my public email addresses are fake. Bugzilla is just spam bait.
It clearly comes from a more innocent age. I once made the mistake
of submitting a bug to gcc. Although the GCC Bugzilla hides the
email in the submitter field, the idiots include the real email
address in the 100% useless 'X-Ref' line. Two weeks later, my email
address was dead. I've never made that mistake again.
I am contactable through my dsource account.
You don't even use a real account for personal e-mails! That's odd. I couldn't reply your private e-mail about changing the title of the bugzilla report because the From address were fake.
Yes, I too use fake personal email accounts, as I do not want my gmail accounts hammered with spam. I could add -nospam to the name, but I am unsure how good the spammers are these days to get around this. Any suggestions/comments, anyone ?
I just use my real e-mail everywhere and let the spammers eat the world's BW as they please. I just let my anti-spam (bogofilter and gmail in case of the gmail address) to take care of things...
Been posting on D for over 2 years with my real address. Haven't seen much difference in my spam input (except occasionally when Andrei replies directly to me instead of the newsgroup by accident ;) ) -Steve
Oct 22 2009
prev sibling parent reply Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:
Don wrote:
 Nick B wrote:
 Nick B wrote:
 Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?
Bartosz - are you able to provide a test case as requested by Don ? Then it might be possible, to get this bug fixed. Nick B.
I can send you the files I have checked out. The problem was in core.thread. I tried to implement a struct Tid (thread ID) with reference-counting semantics and deterministic destruction. It passed all the tests, but when it was used in one particular place in druntime it produced incorrect assembly. Even the slightest change made the bug disappear, so I wasn't able to reproduce it under controlled conditions. Unfortunately, I have undone some of my changes trying to bypass the bug, so at the moment I don't even have the buggy version, but it can be reconstructed. We can discuss it off-line, if you want. Use my email address with -nospam removed.
Bartosz I think that Don is the best person to contact you. I will try to contact him. Nick B
Don, are you able to contact Bartosz, re the details of this test case. Nick B
Bartosz has sent it to me. I can reproduce the error. It's my top priority, but it'll take a while -- it's nasty.
Don - can you advise the Bugzilla number for this ? thanks Nick B
Oct 27 2009
parent reply Don <nospam nospam.com> writes:
Nick B wrote:
 Don wrote:
 Nick B wrote:
 Nick B wrote:
 Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?
Bartosz - are you able to provide a test case as requested by Don ? Then it might be possible, to get this bug fixed. Nick B.
I can send you the files I have checked out. The problem was in core.thread. I tried to implement a struct Tid (thread ID) with reference-counting semantics and deterministic destruction. It passed all the tests, but when it was used in one particular place in druntime it produced incorrect assembly. Even the slightest change made the bug disappear, so I wasn't able to reproduce it under controlled conditions. Unfortunately, I have undone some of my changes trying to bypass the bug, so at the moment I don't even have the buggy version, but it can be reconstructed. We can discuss it off-line, if you want. Use my email address with -nospam removed.
Bartosz I think that Don is the best person to contact you. I will try to contact him. Nick B
Don, are you able to contact Bartosz, re the details of this test case. Nick B
Bartosz has sent it to me. I can reproduce the error. It's my top priority, but it'll take a while -- it's nasty.
Don - can you advise the Bugzilla number for this ? thanks Nick B
3423. My patch has already been included in the dmd svn, and Bartosz has a compiled DMD with the bug fixed.
Oct 27 2009
next sibling parent Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:
Don wrote:
 Nick B wrote:
 Don wrote:
 Nick B wrote:
 Nick B wrote:
 Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?
Bartosz - are you able to provide a test case as requested by Don ? Then it might be possible, to get this bug fixed. Nick B.
I can send you the files I have checked out. The problem was in core.thread. I tried to implement a struct Tid (thread ID) with reference-counting semantics and deterministic destruction. It passed all the tests, but when it was used in one particular place in druntime it produced incorrect assembly. Even the slightest change made the bug disappear, so I wasn't able to reproduce it under controlled conditions. Unfortunately, I have undone some of my changes trying to bypass the bug, so at the moment I don't even have the buggy version, but it can be reconstructed. We can discuss it off-line, if you want. Use my email address with -nospam removed.
Bartosz I think that Don is the best person to contact you. I will try to contact him. Nick B
Don, are you able to contact Bartosz, re the details of this test case. Nick B
Bartosz has sent it to me. I can reproduce the error. It's my top priority, but it'll take a while -- it's nasty.
Don - can you advise the Bugzilla number for this ? thanks Nick B
3423. My patch has already been included in the dmd svn, and Bartosz has a compiled DMD with the bug fixed.
Don Thanks for the quick response. Hopefully Bartosz will be able to get a working implementation of spawn running (see his reply of 13 Oct 2009). Nick B
Oct 27 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:
 3423. My patch has already been included in the dmd svn, and Bartosz has 
 a compiled DMD with the bug fixed.
You are my third hero :-) (the first is Richard Feynman). Bye, bearophile
Oct 27 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bartosz Milewski:

With every release of D we are narrowing our options. After D2 and TDPL,
backward compatibility will become a major thing, so every ad-hoc feature in D2
will have to be carried over.<
D is a bit compatible with the C language, but one of the main selling points of D (D1, D2, D3...) is its newer and cleaned up nature. So I think D3 will break compatibility with frozen-D2 in many places, trying to fix the design errors of D2. D3 will not have a quick release schedule, I think it will try to learn from D2 and D1 in a more thought-out way, because D2 will be an essentially complete language, so the purpose of D3 will be mostly to improve things replacing features with better ones that do similar things :-) For example in D3 the switch may use three ... points as in the GCC extension, and so on. In the meantime people will often use D1 (until LDC becomes a good D2 compiler). Bye, bearophile
Oct 15 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Bartosz Milewski:
 
 With every release of D we are narrowing our options. After D2 and TDPL,
backward compatibility will become a major thing, so every ad-hoc feature in D2
will have to be carried over.<
D is a bit compatible with the C language, but one of the main selling points of D (D1, D2, D3...) is its newer and cleaned up nature. So I think D3 will break compatibility with frozen-D2 in many places, trying to fix the design errors of D2. D3 will not have a quick release schedule, I think it will try to learn from D2 and D1 in a more thought-out way, because D2 will be an essentially complete language, so the purpose of D3 will be mostly to improve things replacing features with better ones that do similar things :-) For example in D3 the switch may use three ... points as in the GCC extension, and so on. In the meantime people will often use D1 (until LDC becomes a good D2 compiler). Bye, bearophile
Speaking of switch, I have tried to convince Walter to require either a break; or a goto case xxx; at the end of each snippet inside a switch. I was surprised by his answer: "but I use fall through all the time!" :o) I personally think requiring a goto case xxx; is more robust in presence of code maintenance because its semantics is invariant to code moves. Andrei
Oct 15 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Oct 15, 2009 at 12:47 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 bearophile wrote:
 Bartosz Milewski:

 With every release of D we are narrowing our options. After D2 and TDPL,
 backward compatibility will become a major thing, so every ad-hoc feature in
 D2 will have to be carried over.<
D is a bit compatible with the C language, but one of the main selling points of D (D1, D2, D3...) is its newer and cleaned up nature. So I think D3 will break compatibility with frozen-D2 in many places, trying to fix the design errors of D2. D3 will not have a quick release schedule, I think it will try to learn from D2 and D1 in a more thought-out way, because D2 will be an essentially complete language, so the purpose of D3 will be mostly to improve things replacing features with better ones that do similar things :-) For example in D3 the switch may use three ... points as in the GCC extension, and so on. In the meantime people will often use D1 (until LDC becomes a good D2 compiler). Bye, bearophile
Speaking of switch, I have tried to convince Walter to require either a break; or a goto case xxx; at the end of each snippet inside a switch. I was surprised by his answer: "but I use fall through all the time!" :o)
But only if there's _some_ statement in between cases, right? case 1: case 3: break; should still be allowed.
 I personally think requiring a goto case xxx; is more robust in presence of
 code maintenance because its semantics is invariant to code moves.
Agreed. --bb
Oct 15 2009
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bill Baxter wrote:
 
 case 1:
 case 3:
       break;
 
 should still be allowed.
 
 
 --bb
Or replace with: case 1, 3: break; -- Chris Nicholson-Sauls
Oct 15 2009
prev sibling next sibling parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-10-15 21:47:05 +0200, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Speaking of switch, I have tried to convince Walter to require either a 
 break; or a goto case xxx; at the end of each snippet inside a switch. 
 I was surprised by his answer: "but I use fall through all the time!" 
 :o)
that shows that he unrolls loops ;) basically the only case I know where fall through is really useful Fawzi
Oct 15 2009
prev sibling parent Tim Matthews <tim.matthews7 gmail.com> writes:
Andrei Alexandrescu wrote:

 
 Speaking of switch, I have tried to convince Walter to require either a 
 break; or a goto case xxx; at the end of each snippet inside a switch. I 
 was surprised by his answer: "but I use fall through all the time!" :o)
 
 I personally think requiring a goto case xxx; is more robust in presence 
 of code maintenance because its semantics is invariant to code moves.
 
 
 Andrei
First of all goto case is without a doubt safer and more robust but please leave as much of D as possible to remain compatible with C. Since D has objects a lot of code can be polymorphic through the classes/interfaces that C didn't have. C's design is trust the programmer, provide full power. It is unsafe agreed but by design. Breaking compatibility between D1, D2 etc may be an issue but if you loose the C then you lose what defines D.
Oct 20 2009