There's an interesting article on Hewitt's Planner.
https://en.wikipedia.org/wiki/Planner_(programming_language)
Did Planner or MicroPlanner have unification?
Mark
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.
Mark Tarver schrieb am Freitag, 1. Oktober 2021 um 12:54:24 UTC+2:
There's an interesting article on Hewitt's Planner.
https://en.wikipedia.org/wiki/Planner_(programming_language)
Did Planner or MicroPlanner have unification?
Mark
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 schrieb am Samstag, 2. Oktober 2021 um 12:54:07 UTC+2:
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 schrieb am Samstag, 2. Oktober 2021 um 12:39:32 UTC+2:
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 schrieb am Samstag, 2. Oktober 2021 um 12:25:41 UTC+2:
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.
Mark Tarver schrieb am Freitag, 1. Oktober 2021 um 12:54:24 UTC+2:
There's an interesting article on Hewitt's Planner.
https://en.wikipedia.org/wiki/Planner_(programming_language)
Did Planner or MicroPlanner have unification?
Mark
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 schrieb am Samstag, 2. Oktober 2021 um 12:25:41 UTC+2:
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.
Mark Tarver schrieb am Freitag, 1. Oktober 2021 um 12:54:24 UTC+2:
There's an interesting article on Hewitt's Planner.
https://en.wikipedia.org/wiki/Planner_(programming_language)
Did Planner or MicroPlanner have unification?
Mark
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 schrieb am Samstag, 2. Oktober 2021 um 12:39:32 UTC+2:
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 schrieb am Samstag, 2. Oktober 2021 um 12:25:41 UTC+2:
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.
Mark Tarver schrieb am Freitag, 1. Oktober 2021 um 12:54:24 UTC+2:
There's an interesting article on Hewitt's Planner.
https://en.wikipedia.org/wiki/Planner_(programming_language)
Did Planner or MicroPlanner have unification?
Mark
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 161:13:57 |
| Calls: | 9,700 |
| Files: | 13,732 |
| Messages: | 6,179,757 |