Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conceptual question: how is this language different than other prologs? #43

Open
vrescobar opened this issue Dec 24, 2020 · 1 comment

Comments

@vrescobar
Copy link

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

@c3d
Copy link
Owner

c3d commented Dec 25, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants