[dmd-concurrency] std.concurrency

[Sean Kelly]

I'd planned to support pattern matching by having the functions optionally return a bool, true==handled, false==not.

On Feb 24, 2010, at 7:38 AM, Mark Kegel wrote:

> All,
> 
> I haven't seen this discussed yet, but could I make a small request?
> Would it be possible to add a mechanism to the receive() function so
> that if any one of the message handlers throws a certain exception,
> call it ContinueMessageDispatch, that when this exception is caught in
> receive(), receive() then tries the rest of the handlers with the
> message that's just come in. Thus a handler that didn't like a message
> (but for which the signature matched) could pass on it, but give
> another handler the opportuntity to process the message.
> 
> This kind of mechanism would make it possible to write:
> 
> receive(
>  (int a) {
>    if (a != 5)
>      throw new ContinueMessageDispatch();
>    else
>      doSomethingCool();
>  },
> (int b) {
>   doSomethingelseCool();
>  }
> );
> 
> 
> Before anyone says "but these have the same signature, they should be
> combined!", let me state that I want this particular addition to make
> it easier to add in pattern matching as a library. Thus the above code
> could be written like this:
> 
> receive( pattern!( _1 == 5) + (int a) {doSomethingCool();},
>            pattern!( _1 != 5) + (int b) {doSomethingelseCool();})
> 
> I don't know about anyone else, but I really like this second bit of
> code much more than the first. But without the ability to continue
> dispatching I'm not sure it would be possible to implement this kind
> of pattern maching behavior.
> 
> Mark Kegel
> 
> 
> On Wed, Feb 24, 2010 at 3:29 AM, Igor Lesik <curoles at yahoo.com> wrote:
>> Sean, I think your implementation of receive() has some imperfections, which I fixed and it works now all right.
>> 
>>> Most importantly, this still doesn't work: receive( (int a) {}, (string b) {} );
>>> The compiler still "sticks" on the type of the first delegate in the foreach ...
>> That is very true, but we can iterate over T instead of ops, which is even better idea.
>> 
>>> Once this is fixed I'll add checking for overload conflicts in the receive set, etc.
>> "receive( (int a) {}, (string b) {} );" works now, we can continue
>> 
>> version with working receive():
>> http://www.curoles.com/j/concurrency.d.txt
>> 
>> code that tests receive() (see Feb 23):
>> http://www.curoles.com/j/dstdconcur.html
>> 
>> 
>> 
>> 
>> ----- Original Message ----
>> From: Sean Kelly <sean at invisibleduck.org>
>> To: Discuss the concurrency model(s) for D <dmd-concurrency at puremagic.com>
>> Sent: Mon, February 22, 2010 11:40:59 AM
>> Subject: Re: [dmd-concurrency] std.concurrency
>> 
>> Here's the module:
>> 
>> http://www.invisibleduck.org/sean/src/concurrency.d
>> 
>> It just has send and receive so far, but those are tested and work correctly.  For the moment, Tid is a struct and Cid doesn't exist.  I'd like to try and keep Tid and Cid as structs if possible to avoid the need for dynamic allocation when thisTid() is called (using a single shared Tid instance isn't really safe since it could be deleted by the user).  Most importantly, this still doesn't work:
>> 
>>     receive( (int a) {}, (string b) {} );
>> 
>> The compiler still "sticks" on the type of the first delegate in the foreach expansion and errors during compilation.  Once this is fixed I'll add checking for overload conflicts in the receive set, etc.
>> 
>> On Feb 21, 2010, at 1:43 PM, Igor Lesik wrote:
>> 
>>> Sean, just in case, I put my stuff here:
>>> http://www.curoles.com/j/dstdconcur.html
>>> 
>>> Get better.
>>> 
>>> 
>>> 
>>> ----- Original Message ----
>>> From: Sean Kelly <sean at invisibleduck.org>
>>> To: Discuss the concurrency model(s) for D <dmd-concurrency at puremagic.com>
>>> Sent: Sun, February 21, 2010 1:19:18 PM
>>> Subject: Re: [dmd-concurrency] std.concurrency
>>> 
>>> On Feb 21, 2010, at 10:52 AM, Andrei Alexandrescu wrote:
>>> 
>>>> Igor Lesik wrote:
>>>>> Good. Then I will stop working on it.
>>>> 
>>>> Just until you coordinate with Sean. I'm sure your contribution would add a lot of value. Also, don't forget - new ideas are always appreciated!
>>> 
>>> Definitely.  I've been out sick recently but will be back in commission tomorrow.  I'll try and shape up the module then.
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> dmd-concurrency mailing list
>>> dmd-concurrency at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>> 
>> _______________________________________________
>> dmd-concurrency mailing list
>> dmd-concurrency at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>> 
>> 
>> 
>> 
>> _______________________________________________
>> dmd-concurrency mailing list
>> dmd-concurrency at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>> 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency