Exciting new directions for ScalPL: Splatr

I haven't posted much over the last few months, in part because I have been working hard in an exciting new direction, and figured it would make more sense to organize and firm up some of those ideas before posting them here.  In fact, I have been using a certain workshop deadline (originally June 20, then changed to June 27) to motivate myself to finally get these concepts down formally in writing, for submission.  Alas, I missed the deadline, but only just barely, and partially because the ideas have kept coming at such a rapid pace, and partially because the conference paper was understandably restricted to 15 rather small pages.  With reasons like this, I don't see the missed deadline as a failure.  While I expect it to be possible, at some point, to express the important concepts in such a concise form, for now, it is more important for me to ensure the concepts are fully consistent and complete before I begin to abbreviate.

So what is this direction? A few years ago, as I whiled away some hours at a supercomputing conference, I began to wonder how difficult it would be to make ScalPL (Scalable Planning Language, described on this blog and elsewhere) easier to learn and use, and to that end, probably more like some existing parallel computer languages.  While I firmly believe that ScalPL is more flexible and better designed in many ways than most of those existing languages, there is also no arguing that it takes longer to explain and to learn the constructs and how they fit together.  Why?

• Many of these existing parallel languages start with a sequential language and then add a few constructs here and there, subtly introducing and altering semantics.  This is interpreted as lowering the learning curve... at least until the programmer understands some of the inherent restrictions, and how those "little" syntactic and semantic changes can have far-flung implications.
• Instead, ScalPL is just glue between modules ("tactics") implemented in traditional sequential languages as-is, with virtually no syntactic or semantic changes to those languages (except a few restrictions).  While this allows ScalPL to stay completely "language agnostic", not caring what language is (or languages are) used for tactics, it also means (for example) that ScalPL has its own type system separate from the tactic languages, and associations between them must be made at each tactic interface.
• The individual modularization of each tactic is not only clumsy and verbose, it can also affect the understandability of the program, and the ability to propagate type information in an obvious, sensible way.  Everything must be spelled out, there is little type inference or lexical scoping.
• ScalPL is a graphical language (uses graphical language constructs, like circles, boxes, lines), which is very different from what most programmers (and their tools) are accustomed to.  This is another hike up the learning curve.

Fine, so how many of these drawbacks can be overcome?  There may be no overcoming the first without total redesign, and if the advantages of doing so are skin-deep rather than substantive, it may not pay off anyway.  As for the last, I have already introduced a textual form of ScalPL, called SPLAT (Scalable Planning Language as text), but in doing so, made no effort to overcome the other obstacles listed: SPLAT is primarily an archival form of ScalPL that can be understood by humans and manipulated by more traditional tools. So what could be done to address the above in a text/lexical form by restricting our attention to one tactic language, and by borrowing that language's type system and permitting some amount of lexical scope?

My answer to that ("what could be done") is a new textual concurrent language called Splatr (SPLAT Refined, pronounced "splatter").  As I say, I'm excited, and even though its constructs are based entirely on ScalPL, I think I have looked at some old problems in some novel ways.  Also, thanks to this blog and the book, I have some pretty good sample programs to try it out on.  I'll probably also put together a working parser before publishing the syntax, but I might expose some of the basic forms before that.

If all works out, people will grasp it fairly quickly, and see some vague similarities to languages they've seen before (Occam, UNITY), while preserving the theoretical and practical advantages of ScalPL.