Ask HN: How would a goal-oriented programming language look like?
25 comments
I find Picat an exciting new development, with all three paradigms represented properly. See https://news.ycombinator.com/item?id=16563349
Very interesting. Gonna read it. Thanks.
Neural networks and things like that look like "goal oriented" programming...
SHRDLU? It was goal oriented.
Prolog, SQL, or other logic programming languages...as mentioned in the linked C2 entry.
Right, but these languages are declarative.
Sorry. I guess I don't see how a goal oriented language would work without declaring the goal and declaring the conditions under which it must be achieved.
Did you read the article the poster is reffering to, though?
It specifically mentions that the kind of "missing paradigm" looked for is not one of the declarative ones we currently have (SQL, Prolog, etc) because those fall into the Evaluate + Consequent combo.
So, he gives 3 paradigms:
FunctionalProgramming -> Evaluate + Mechanism (list of instructions)
ImperativeProgramming -> Execute + Mechanism
LogicProgramming/ConstraintProgramming -> Evaluate + Consequent (i.e. towards a consequent (result) based on constraints) [this is where declarative falls).
So, the "goals oriented" language he defines as the missing: Execute + Consequent pair.
It specifically mentions that the kind of "missing paradigm" looked for is not one of the declarative ones we currently have (SQL, Prolog, etc) because those fall into the Evaluate + Consequent combo.
So, he gives 3 paradigms:
FunctionalProgramming -> Evaluate + Mechanism (list of instructions)
ImperativeProgramming -> Execute + Mechanism
LogicProgramming/ConstraintProgramming -> Evaluate + Consequent (i.e. towards a consequent (result) based on constraints) [this is where declarative falls).
So, the "goals oriented" language he defines as the missing: Execute + Consequent pair.
Yes, I agree. But in the article I shared, they say that this goal-oriented language would be somehow "imperative" in the sense that you would be telling to the computer concrete things to do, just from a (much) higher abstraction level.
The C2 page is a wiki (the orginal). The page contains several viewpoints by different authors. Among them is the view that the division into a 2x2 table is incomplete/incorrect/of-limited-utility. For me, the relationship of declarative languages to the ordinary usage of "goal" is much stronger (for me at least) than the vague terms used to create the 2x2 table. To put it another way, I find the premise dubious. For me, it is useful to keep in mind the truth table of conditional statements in modal logic:
a -> b
b = T b = F
+--------+--------+
a = T | T | F |
+--------+--------+
a = F | T | T |
+--------+--------+
An imperative goal oriented language can be implemented as a staged language using lambdas. The first stage answers the question, "What are the subgoals?" The second stage applies a subgoal to a candidate solution.
Logic-programming style control flow can be implemented on top of these two primitives.
Logic-programming style control flow can be implemented on top of these two primitives.
If you want to work on a new programming language, think hard about an application area where all current languages can't be used to express a developer's intention easily and clearly.
Designing a language in the abstract usually doesn't work, it is better to start with use cases that demonstrate how the new approach helps expressing nicely what was cumbersome in previous languages.
Designing a language in the abstract usually doesn't work, it is better to start with use cases that demonstrate how the new approach helps expressing nicely what was cumbersome in previous languages.
So, start small with a niche? Thanks.
Prolog and MiniZinc (google them) are two useful goal-oriented programming languages. They are amazing at solving goal-problems, but are IMHO lacking in the general purpose department. What I mean is that they are great at solving n-queens problems and finding optimal seating arrangements, but not great for writing web servers or GUI:s in.
Look at Racket. It hosts multiple languages including prolog/solver variants. Racket is made to create variant languages so you could start with a working system and change it to try designs. Here's just a few relevant Racket links:
https://docs.racket-lang.org/racklog/index.html
https://docs.racket-lang.org/parenlog/index.html
https://docs.racket-lang.org/datalog/index.html
https://docs.racket-lang.org/racklog/index.html
https://docs.racket-lang.org/parenlog/index.html
https://docs.racket-lang.org/datalog/index.html
Excellent, thanks!
I've been working on this (albeit as a library rather than a language in its own right).
The more papers I read the more lost I became trying to make sense of the different approaches to goal-oriented / relational / logic programming. This retrospective paper by Robert Kowalski gave me an historical framework to make sense of it all: https://www.doc.ic.ac.uk/~rak/papers/History.pdf
One of the key insights I gleaned from that paper is the difference between bottom-up and top-down strategies. All logic / relational / goal oriented paradigms exhibit a characteristic top-down or bottom-up quality, and this classification can then be used to understand the essence of goal-oriented programming.
The following is my interpretation of the historical information from that paper:
During the 1980s a burgeoning Datalog community, with roots in the database field, assimilated the existing deductive database community which had roots in AI. The database perspective focuses on finite models that are computable bottom-up. However a naive bottom-up implementation, deducing forwards from facts using rules, ignores the query until it derives it "as though by accident." To make generated models relevant to the query, Datalog uses transformations such as "Magic Sets" to incorporate the query into the rules.
An early deductive database (AI) strategy was Hyper-resolution, which is essentially also bottom-up, and it suffers from the same problem of generating new derivations blindly until one matches the query "by accident". Another strategy known as "set of support" restricted the inputs (axioms) so as to keep the derivations relevant to the query. However, according to Kowalski, set of support only approximates top-down reasoning, and a better approximation is linear resolution.
"Linear resolution addresses the problem of relevance by focusing on a top clause C0, which could represent an initial goal."
A problem which stood in the way of implementing this top-down strategy was the fact that given "n" clauses there are "n!" ways to compute the conjunction.
"The obvious solution was simply to resolve upon the literals in the clauses Ci in a single order. This order can be determined statically, by ordering the literals in the input clauses, and imposing the same order on the resolvents. Or it could be determined dynamically, as in selected linear (SL) resolution."
Thus, you see, it was the invention of SL, soon extended to SLD resolution (the D stands for "definite clause") which enabled top-down logic programming such as Prolog to be computationally tractable.
This top-down versus bottom-up distinction is what separates something like, e.g. language integrated query (LINQ) from logic programming: despite the similarity as a declarative form, a LINQ statement is computed bottom-up because datasets are generated and transformed in a forwards (i.e. not contingent) manner. In contrast a Prolog-style logic query (such as the Castor C++ library) is computed top-down: the query consists of an AND-OR tree of goals and subgoals which is visited top-down.
The more papers I read the more lost I became trying to make sense of the different approaches to goal-oriented / relational / logic programming. This retrospective paper by Robert Kowalski gave me an historical framework to make sense of it all: https://www.doc.ic.ac.uk/~rak/papers/History.pdf
One of the key insights I gleaned from that paper is the difference between bottom-up and top-down strategies. All logic / relational / goal oriented paradigms exhibit a characteristic top-down or bottom-up quality, and this classification can then be used to understand the essence of goal-oriented programming.
The following is my interpretation of the historical information from that paper:
During the 1980s a burgeoning Datalog community, with roots in the database field, assimilated the existing deductive database community which had roots in AI. The database perspective focuses on finite models that are computable bottom-up. However a naive bottom-up implementation, deducing forwards from facts using rules, ignores the query until it derives it "as though by accident." To make generated models relevant to the query, Datalog uses transformations such as "Magic Sets" to incorporate the query into the rules.
An early deductive database (AI) strategy was Hyper-resolution, which is essentially also bottom-up, and it suffers from the same problem of generating new derivations blindly until one matches the query "by accident". Another strategy known as "set of support" restricted the inputs (axioms) so as to keep the derivations relevant to the query. However, according to Kowalski, set of support only approximates top-down reasoning, and a better approximation is linear resolution.
"Linear resolution addresses the problem of relevance by focusing on a top clause C0, which could represent an initial goal."
A problem which stood in the way of implementing this top-down strategy was the fact that given "n" clauses there are "n!" ways to compute the conjunction.
"The obvious solution was simply to resolve upon the literals in the clauses Ci in a single order. This order can be determined statically, by ordering the literals in the input clauses, and imposing the same order on the resolvents. Or it could be determined dynamically, as in selected linear (SL) resolution."
Thus, you see, it was the invention of SL, soon extended to SLD resolution (the D stands for "definite clause") which enabled top-down logic programming such as Prolog to be computationally tractable.
This top-down versus bottom-up distinction is what separates something like, e.g. language integrated query (LINQ) from logic programming: despite the similarity as a declarative form, a LINQ statement is computed bottom-up because datasets are generated and transformed in a forwards (i.e. not contingent) manner. In contrast a Prolog-style logic query (such as the Castor C++ library) is computed top-down: the query consists of an AND-OR tree of goals and subgoals which is visited top-down.
Wow, very interesting.
I'm familiar with Prolog and its implementation, but definitely didn't know all of that.
I'm familiar with Prolog and its implementation, but definitely didn't know all of that.
Imagine you could design a general purpose goal-oriented programming language. I was wondering how would such a language look like.
Actually, I've been having much spare time lately, so I'd like to actively research this topic.