Semantics of concurrent languages I've seen that the preferred way to specify the semantics of a concurrent language is to use a process calculus (e.g. pi calculus, join calculus). But in the paper presenting the F# asynchronous programming model the authors have a different approach: they first perform a CPS conversion to a core language, and then, define the semantics in terms of a transition system in which states are tuples of the form (A, Q, P), where A is the set of active computations, Q is the set of queued computations, and P is the set of pending computations--i.e. Waiting for an event. Each computation is of the form e@ctx, where ctx is a label corresponding to a synchronization context. Finally, they give transition rules for reduction (which uses the reduction rule of the core language), suspension of computations waiting on events, activation of computations (i.e. moving computations from Q to A), and event signaling.

I was wondering if this is an acceptable (i.e. accurate enough) way of specifying the semantics of a concurrent language.

EDIT: can anyone point me to papers that use a similar approach to the one taken in the F# paper?

Thanks.
Legally speaking, the term "calculus" is almost always used to describe a language, i.e., a piece of syntax, with added rules of calculation or reasoning.  Examples include the good old predicate calculus, lambda calculus, process calculi, various type theories and logics (e.g., Martin-Lof type theory and linear logic).  From a programming language point of view, a "calculus" is just a bare bones programming language, that we take to be fundamental in some way.

People with an engineering bent of mind often take calculi to be good enough for using as a foundation, and describe the "semantics" of other languages in terms of such calculi.  (Prominent examples of such people include Christopher Strachey, Robin Milner, and Tony Hoare to some extent.)  People with a logical/philosophical bent of mind regard such calculi as being inadequate on their own, and needing a proper "semantics".  (Prominent examples include Dana Scott, Gordon Plotkin, John Reynolds and again Tony Hoare to some extent.)  A true "semantics" then is expressed in terms of abstract concepts, rather than pieces of syntax.

From this point of view, the F# paper that you cite is doing the right thing by describing the semantics in terms of concepts.  It is indeed the preferred way of describing the semantics of programming languages (at least for those of us with a logical bent of mind).

[Additional note: See also the previous question What constitutes denotational semantics for related discussion, even though it is dealing with denotational rather than operational semantics.]