You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main building stone on prolog systems is a "fact", same as in XL each time a new definition is given with the keyword is.
How does one differentiate from each other in conceptual level? How is the evaluator planned? AOT or lazy as in red/rebol/wolfram alpha?
I like the ideas behind XL, as I myself have as well theorized with some of them in my free time, and the whole definition of the concepts within the standard library, if well combined with literate programming can become simply game changing.
But isn't it missing a spot not looking deeper into prolog? For me it seems like implementing a more complete logic system for the definitions (concepts/facts) would definetely frame XL as a prolog descendent with a whole new set of features.
By logic programing I meant implementing a system with Horn Clauses and a facts database.
Don't let the superficial syntax similarity fool you. XL is not evaluating things the way Prolog does, at least not by default. This is because Prolog's backtracking, while very practical and useful in some cases, is not necessarily expressive in others. I would not do heavy duty number-crunching in Prolog, for example.
It was, however, important to me to design a language that would make it possible, if not easy, to implement Prolog-style inference.
The way XL approaches the problem is to focus on the process of translation. At the root, there is a very simple parse tree, and the is operator describes how you transform the parse tree. This is why a pattern in the form Pattern is Implementation is called a rewrite. Conceptually, it rewrites code that looks like Pattern as code that looks like Implementation. This is true even for builtin operations, where the implementation will be builtin Something.
This means that if you can find a nice syntax to "tag" some specific rewrites as being Horn clauses, then you can completely control how the rewrite for these happens. We could even use the Prolog syntax for that, since it's not used in XL.
move 1,X,Y,Z :-
writeln "Move top disk from ", X, " to ", Y
move N,X,Y,Z :-
N>1 // May backtrack here
M = N-1
move M,X,Z,Y
move 1,X,Y,0
move M,Z,Y,X
The implementation could use automatic returns as currently envisioned for the error types, i.e. boolean value would cause backtrack / return if false.
The main building stone on prolog systems is a "fact", same as in XL each time a new definition is given with the keyword
is
.How does one differentiate from each other in conceptual level? How is the evaluator planned? AOT or lazy as in red/rebol/wolfram alpha?
I like the ideas behind XL, as I myself have as well theorized with some of them in my free time, and the whole definition of the concepts within the standard library, if well combined with literate programming can become simply game changing.
But isn't it missing a spot not looking deeper into prolog? For me it seems like implementing a more complete logic system for the definitions (concepts/facts) would definetely frame XL as a prolog descendent with a whole new set of features.
By logic programing I meant implementing a system with Horn Clauses and a facts database.
https://en.wikipedia.org/wiki/Horn_clause
The text was updated successfully, but these errors were encountered: