I don't see any whitespace in that link.  Any way to correct that?

The current version of my code doesn't have any dynamic allocation in thisTid(), perhaps you grabbed an intermediate version?  I did update it a few times shortly after sending the email.

On Feb 23, 2010, at 5:00 AM, Igor Lesik wrote:

> I tried your code with removed dynamic allocation on thisTid(), Tid is "alias TID* Tid" where TID is the structure. Interesting that "delete tid" where tid is returned from spawn or thisTid does not actually destroy the structure and thisTid returns correct address, so there is nothing to be afraid of. Do I miss something?
> 
> Here is my version:
> http://www.curoles.com/j/concurrency.d
> 
> 
> 
> ----- 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

>I don't see any whitespace in that link.? Any way to correct that?
Sorry about that, I think it is better now: http://www.curoles.com/j/concurrency.d.txt

My bad, no dynamic allocation, but does not "return Tid(mbox)" still imply some overhead?
@property Tid thisTid()
{
??? return Tid( mbox );
}


----- Original Message ----
From: Sean Kelly <sean at invisibleduck.org>
To: Discuss the concurrency model(s) for D <dmd-concurrency at puremagic.com>
Sent: Tue, February 23, 2010 2:58:40 PM
Subject: Re: [dmd-concurrency] std.concurrency

I don't see any whitespace in that link.? Any way to correct that?

The current version of my code doesn't have any dynamic allocation in thisTid(), perhaps you grabbed an intermediate version?? I did update it a few times shortly after sending the email.

On Feb 23, 2010, at 5:00 AM, Igor Lesik wrote:

> I tried your code with removed dynamic allocation on thisTid(), Tid is "alias TID* Tid" where TID is the structure. Interesting that "delete tid" where tid is returned from spawn or thisTid does not actually destroy the structure and thisTid returns correct address, so there is nothing to be afraid of. Do I miss something?
> 
> Here is my version:
> http://www.curoles.com/j/concurrency.d
> 
> 
> 
> ----- 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

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

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
>

On Wed, 24 Feb 2010 10:38:16 -0500, Mark Kegel <mark.kegel at gmail.com> 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

Mark, exceptions are not valid form of flow control. This is a fairly well known anti-pattern. Also, the operator overloading of '+' is generally considered poor design. That said, adding this functionality in a more formalized way would be useful. i.e. giving receive the explicit ability to handle patterns via struct wrappers by putting something like:

static if( is( typeof(handeler) == struct ) ) {
     if( handeler.match(msg) == false )
         continue;
}
handeler( msg );
break;

inside the receive message handling body.

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

Yeah, I hadn't really thought out the syntax, but I did want to have some kind of control flow from within handlers and nothing I'd seen so far had any examples of how that might work. Since I hadn't seen anything return a value from a handler I just assumed that the only thing left would be an exception.

So then if you had a struct-pattern passed to a receive call you are talking about, what might that look like?

Mark

>Mark, exceptions are not valid form of flow control. This is a fairly well known anti-pattern. Also, the operator overloading of '+' is >generally considered poor design. That said, adding this functionality in a more formalized way would be useful. i.e. giving receive the >explicit ability to handle patterns via struct wrappers by putting something like:

>static if( is( typeof(handeler) == struct ) ) {
>   if( handeler.match(msg) == false )
>       continue;
>}
>handeler( msg );
>break;

>inside the receive message handling body

Sean has a way better understanding than me, I do not think I can contribute much.

Anyway, I have one small idea, I think we can safely get rid of receiveTimeout. See, receive() assumes that parameters are delegates, so if first parameter is integral then we handle it as a special case and conclude that it represents timeout. I have changed receive to:

bool receive(T...)(T ops) if (T.length > 0)
{
??? static if(isIntegral!(T[0])) {
??????? long timeout = ops[0];
??????? const opBegin = 1;
??? }
??? else {
??????? long timeout = long.max;
??????? const opBegin = 0;
??? }

??? return
??? theTid.mbox.get(
??????? timeout,
??????? (Variant val)
??????? {
??????????? foreach (i, param; TypeTuple!(T[opBegin .. $]))

and it seems to work just fine:

??????? for (bool fun = true; fun; )
??????? {
??????????? auto gotMessage = receive(
??????????????? 2_000_000,
??????????????? &handleString,
??????????????? (int val){ writeln("Got int: ", val); },
??????????????? (byte b, long l){ writefln("Got (byte,long): (%d,%d)", b, l); },
??????????????? (float f, double d){ writefln("Got (float,double): (%f,%f)", f, d); },
??????????????? &skipIt,
??????????????? &catchIt,
??????????????? (bool gun){ fun = gun; }
??????????? );
??????????? if (!gotMessage)
??????????????? writeln("Timeout!");
??????? }



----- Original Message ----
From: Andrei Alexandrescu <andrei at erdani.com>
To: Discuss the concurrency model(s) for D <dmd-concurrency at puremagic.com>
Sent: Sun, February 21, 2010 10:52:48 AM
Subject: Re: [dmd-concurrency] std.concurrency

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!

> Andrei, I have a question, if you do not mind.? I understood that receiveOnly call is blocking, correct?

Correct.


Andrei
_______________________________________________
dmd-concurrency mailing list
dmd-concurrency at puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

I think this is the?right way to do it.

I have tried to implement it in receive():

if (typeid(ReturnType!(param)) == typeid(bool)) {
??? if (op(val.get!(paramType).expand))? <---- unfortunately compiler does believe that op returns bool
???????? continue;



>From: Sean Kelly
>Sent: Wed, February 24, 2010 8:42:22 AM
>
>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

_______________________________________________
dmd-concurrency mailing list
dmd-concurrency at puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

I meant that I agree with Sean that it is right way.



----- Original Message ----
From: Igor Lesik <curoles at yahoo.com>
To: Discuss the concurrency model(s) for D <dmd-concurrency at puremagic.com>
Sent: Thu, February 25, 2010 12:13:14 AM
Subject: Re: [dmd-concurrency] std.concurrency

I think this is the?right way to do it.

I have tried to implement it in receive():

if (typeid(ReturnType!(param)) == typeid(bool)) {
??? if (op(val.get!(paramType).expand))? <---- unfortunately compiler does believe that op returns bool
???????? continue;



>From: Sean Kelly
>Sent: Wed, February 24, 2010 8:42:22 AM
>
>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

_______________________________________________
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