migrate 360dialog Orc code to OAM

introduction

Xray 1.0

From the Xray platform perspective, everything is an Orc program. As such a JSON doc describing a 360dialog CRM campaigns is turned into an Orc program by our json2orc transpiler.

The DAG-VM based Orc implementation in Xray 1.0 has serious limitations/restrictions (wrt. our Orc refereference implementation):

often subobtimal performances of the VM (in space and time),
usage of Lua scripting in lieu of hosting language
Orc unreliable semantics,
no support for pattern matching and poor if any support for FP style,
missing otherwise combinator,
very limited subset of Orc standard library implemented, often with incompatible API.

These limitations due to Xray 1.0 Orc's lack of expressiveness, resulted in unnecessary complexity in the Orc programs used by 360dialog (either transpiled or handwritten): we had to workaround missing Channels, otherwise, patterns and so forth, most of the time by "pushing" the business logic we could not express in Orc, to Lua scripting...

Xray OAM

Besides considerable performance improvments, and a rigorous implementation for all 4 Orc combinators (prune, sequence, parallel and otherwise), OAM's runtime provides a substantial subset of the Orc standard librairy:

support for clausal definitions and for most patterns,
an impementation for most (useful) sites and operators in core,
all higher-order Orc programming idioms,
from state: Cell, Counter, Channel, Ref, := and ?.
support most operations on lists.
a clear separation between Orc's internal and external semantics: between the OAM and what we call an environment (the component responsible for servicing site calls).

scope and result

The scope for this epic is simple: migrate mutatis mutandis 360dialog's CRM Orc code to OAM. Ideally the successful completion of this task will result in the following deliveries:

a (360dialog) CRM Orc library,
specification for a set of CRM specific sites together with an environment capable of servicing them,
a new json2orc transpiler, generating code for 1. and 2. above, and
a framework for testing/accepting the migration.

migration strategies

top down: start from the business logic itself

Go through various currently supported campaigns asking oneself: given OAM, what's the most efficient, minimal and elegant way to express what it is that we are trying to do with these campaigns.

bottom up: start from the code itself

Go throught all the code (both Orc and Lua) and "mecanically" port to Orc.

Most likely both strategies will be applied simultanously.

xray-tech / xorc-xray