[dmd-concurrency] Pattern matching on message receives, error handling

Mark Kegel mark.kegel at gmail.com
Tue Jan 12 19:24:12 PST 2010


I've been very interested in the actor style for the past year or
so. Altogether, I'm very glad to see D at least giving this
programming style a go.

After reading through the example posted in the latest fragment,
I have to confess that I'm a little concerned. The actor style is
something you really have to embrace from the groundup.

When I think of how message passing is accomplished in either
Erlang or Scala (the two languages I've looked at with message
passing / actors), one thing strikes as being absolutely
essential to getting this paradigm right: pattern matching. As
functional languages (arguably more so for Erlang than Scala, but
whatever), this is something that just makes messages easy to
handle.

I don't see pattern matching as a first class feature of D. And
this makes me scared. I do not want to have to handle complex
dispatch (or silly implicit message protocols, please) without
the saving grace of builtin pattern matching.

Call me silly, but how many of you have seen 1000 line switch
statements when polymorphism was called for? And what is
polymorphism but dispatch / pattern matching over argument type?

So when I see code like this:

       auto msg = receiveOnly!(Tid, int)();
       if (!msg[0]) return;
       writeln("Secondary thread: ", msg[1]);
       msg[0].send(thisTid);

...where you the first thing you tell new readers about how to
test what message you just got is with an 'if' statement, I get
scared. Please give users a more elegant mechanism, and if you
need ideas about what it could look like I would suggest that
Scala offers a passable (and maybe even compatible) syntax.

Since I read through a draft, I would also like to suggest that
another topic will need to be discussed in the final edition:
error handling. Throwing exceptions on unexpected messages is
nice, but what happens when spawned actors (actor != thread) have
a bad day? What kinds of guarentees can the other actors in the
system make about their state or does the entire theater burn
down if someone is missing some hairspray?

But really, one of the major things erlang has going for it (and
that scala completely missed) is that error handling is
important! If you can tell when other actors die, recover knowing
that nothing else is broken, then you can at least start to build
resilient systems. Does D even give you this? For a systems
programming language in which segfaults and memory corruption are
possible, even expected, how does D meld this to the actor system
in a way that keeps the system stable?


Mark Kegel


More information about the dmd-concurrency mailing list