Constraint Imperative Programming

Constraint Imperative Programming (CIP) is what you get when you combine an algol-like language with ConstraintLogicProgramming.

CIP is still in its alpha stage: working implementations, yet to be strongly developed even by academia.

Kaleidoscope is a little-known CIP language.

[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.463] - a paper describing Kaleidoscope.

Turtle is another little-known CIP language.

[http://uebb.cs.tu-berlin.de/~magr/talks/GI2003-pres.pdf] - a slideshow that showcases Turtle.

As one can see, CIP provides some very desirable ways of expressing certain kinds of programs.

CIP is very related to GoalBasedProgramming in that it fits into the execute/consequent quadrant mentioned there.

Based on my (admittedly cursory) study of the examples for ConstraintImperativeProgramming (in AlmaLanguage?) it seems the focus is the automated construction of values that meet imperatively-described goals rather than the automated construction of procedures that meet declarative goals. If this holds in broader examination, it seems that ConstraintImperativeProgramming is far more closely related to ConstraintProgramming (which obtains values that meet declaratively described goals) than GoalBasedProgramming (which constructs procedures to meet declaratively described goals). I'll be reading the above documents over the next few days and relaying impressions here. Addendum1: Document on Turtle does nothing to change impression.

One executes actions to meet goals. The other creates actions to execute to meet the same goals. The former is, in-effect, doing what the latter does, but at runtime instead of compiletime. Basically, GBP and CIP seem to be the same paradigm, but utilizing different implementation methods. Of course, I'd rather have both methods at my disposal. :)

Both CIP and GBP are both potentially runtime. I'd say the bigger distinction is that GBP would typically be aimed at a runtime environment that receives continuous feedback while attempting to achieve its goals. An example might be programming an unmanned vehicle to accomplish certain routine actions while remaining fueled and avoiding driving over any mines. Manipulating the current 'goal set' in response to sensory and command inputs would be a big part of programming, and actions aimed at achieving these goals and verifying progress towards them would be continuous efforts. CIP constraints are solved in a more spatially and temporally limited fashion. PartialEvaluation and other optimizations would allow either to be used for DeclarativeMetaprogramming at CompileTime, but isn't required for either. I do agree that having at least one ConstraintProgramming language in the toolkit would be useful.

Admittedly, if procedures themselves are first-class and the procedure-processor is available to the constraint-solver (along with such conditions as reentrance, multi-threading, comprehension of shared state, etc.), any ConstraintProgramming language is automatically capable of a form of GoalBasedProgramming by means of constructing procedures that meet a known set of goals. However, being capable of something and being optimized and designed for it are entirely different beasts (pay attention to ExpressivePower and beware the TuringTarpit).