Hewitt's Planner

[Mark Tarver]

There's an interesting article on Hewitt's Planner.

https://en.wikipedia.org/wiki/Planner_(programming_language)

Did Planner or MicroPlanner have unification?

Mark

[Mostowski Collapse]

Maybe PLANNER had unification , maybe it didn't have
unification , is there some computer museum code?

If it didn't have unification , this would somehow
justify that PLANNER built on top of MATCHLESS.

The version with unification would then be based
on MATCHMORE.

[Mostowski Collapse]

You can look at, both rather say that Planner had single
sided unification but not unification:

Hewitt, Carl (1969). "PLANNER: A Language for Proving Theorems in Robots". IJCAI.
https://stacks.stanford.edu/file/druid:cm792pj8606/cm792pj8606.pdf

Hewitt, Carl (1971). "Procedural embedding of knowledge in planner". IJCAI.
https://www.ijcai.org/Proceedings/71/Papers/014%20A.pdf

May own interpretation why unification did not find
a place in planner: I was based on LISP which is a functional
language, so you would return values.

Whereas unification in Prolog comes handy to build
and return values. Take append, in mode (+,+,-):

append([], X, X).
append([X|Y], Z, [X|T]) :- append(Y, Z, T).

In the first clause unification can return in the third
argument the first argument. In the second clause
unification does even more, it builds a partial result

in the third argument which is later completed when
the body of the goal succeeds. This is not some LISP
thinking, this is rather very subtle and Prologish.

[Mostowski Collapse]

Hewitt mentions in his 1969 MATCHLESS. In his 1971 he has
a section where he advertises his pattern matching as being
able doing both deconstruction and construction of terms.

But this still doesn't capture unification not completely.
In append, in the second clause and in mode (+,+,-), the
first argument [X|Y] indeed works as a deconstructor, but

the third argument [X|T] is not really a constructor, because
T is not yet known. It is even extremly contraproductive in Prolog
to follow the constructor idea, like if you would do:

/* Functional Style Variant */
append([], X, X).
append([X|Y], Z, H) :- append(Y, Z, T), H = [X|T].

There are the following drawbacks:

- append is not anymore the last goal, last goal
optimization becomes difficult

- T is still a fresh variable, like before, you would
need some optimization to have it not allocated,
like add a mode (+,+,-) based notion of return value
to the notion of predicate

- H is an additional variable, without optimizations it
would be also viewed as a fresh variable, but fortunately
we can just take what is passed as an argument,
and spare a variable allocation (Works now in Dogelog
Runtime, didn't work in Jekejeke Prolog)

On the other hand in the 1971 I find some first sketches
of a trail and so on. So there are nevertheless similarities
probably of the PLANNER system with a Prolog systems.

This similarities have possibly more to do with similarlities
between pattern matching and single sided unification (SSU),
althouth the later has different Prolog incarnations (ECLiPSe,

SWI and Jekejeke do it differently). Also the MATCHLESS
pattern matching had boolean combination of patterns and
spreading patterns, things that are not in the Prolog core.

[Mostowski Collapse]

Sometimes I wish for spreading pattens in Prolog so as to realize
varargs predicates. Recently I noticed that JavaScript and Python
have spreaders. The syntax is:

- JavaScript
Spreaders are denoted by 3 dots `...`

- Python:
List spreaders are denoted by 1 star `*`,
there is also a dict spreaders by 2 stars `**`

Here is what spreading patterns could do in Prolog, for example
we could define call/n via spreading, working for any arity, lets
say '&' would denote spreading in Prolog:

call(X,&Y) :- apply(X,Y).

But the above is only tail spreading, in LPA Prolog one
could attempt the following:

call(X | Y) :- apply(X,Y).

The '|' works like in a list when used inside an argument
list of a compound.

[Mostowski Collapse]

The JavaScript and Python spreaders are especially useful,
since they solve some problem of invoking varargs functions.
These problems are for example not so well solved in Java,

in Java there is a messy type system dependence, whereas
JavaScript and Python do not have types per se, so they have
a syntactic solution. Take the SWI-Prolog format predicate:

?- format('~w ~46t ~w~72|~n', [Title, Page]).

With spreaders definition of format you could do, spares
some annoying [ ] typing:

?- format('~w ~46t ~w~72|~n', Title, Page).

Or in case you want to pass an argument list, using
my suggestion of & as a spreader:

?- List = [Title, Page], format('~w ~46t ~w~72|~n', &List).

or then with LPA Syntax, since its tail again:

?- List = [Title, Page], format('~w ~46t ~w~72|~n' | List).