Great paper and great effort!
Thanks Dan! I’d love to strike up a conversation around the ideas expressed in the paper. So, should you, or anyone else, have any thoughts I’d like to know them all!
I realise that for those of you not familiar with Erlang it may be a difficult read since it’s an article targeting Erlangers. Getting familar with Erlang is a piece of cake if you’re a Prologer, and it’s worth it. Don’t you worry, you will remain a Prologer afterwards - I did. 
But Erlang is doing one thing right, and that’s concurrency and distribution. With the multi-core hardware revolution in full swing, I believe that’s the direction in which we should aim.
BTW, what do you think we should do in order to celebrate the 50th anniversary of Prolog in 2020? (The paper actually has a suggestion here. 
)
1 Like
The first thing that comes to my mind is to show (or showcase, if possible), (swi) Prologs relevance and key benefits to industry strength application and scalable system development.
How can this be accomplished …
1 Like
Thanks Dan, and if this is your answer to the question how to celebrate the 50th anniversary of Prolog, I certainly agree!
50 years is a very respectable age, so I think the celebration should be wild and bit crazy. Here’s the suggestion made in the paper:
In parallel to investing more work into building something [a implementation of Web Prolog] that can be used in production, we are considering making an early attempt to create a standard for Web Prolog, based on a suitable subset of ISO Prolog, but developed under the auspices of the W3C this time rather than ISO, or under a liaison between these organisations. As a first move in this direction, we might create a W3C Community Group, as this appears to be an easy way to find out if enough interest can be generated among people of appropriate expertise.
A realistic but ambitious deadline for a standardisation effort would be to aim for 2022, the year when Prolog celebrates its 50th birthday. We find it difficult, in fact, to think of a better way to celebrate this occasion than to release version 1.0 of such a standard along with software implementing it.
An ambitious yet reasonable goal is the have, by 2022, a very good and comprehensive proposal for a standard for Web Prolog and the Prolog Web, as well as two conforming implementations of runtime systems (i.e. nodes). Ideally, the standardisation effort would take place under the auspices of a liaison between ISO and the W3C, and the implementation be carried out by implementers who agree with our goals and motives.
I know, that’s a very tight deadline. But a language only gets to be 50 years old once in its lifetime. Logic programming researchers more generally, even those who think that Prolog is not the ideal logic programming language, will probably recognise the value of Prolog for the evolution of the field, and see this as a reason to celebrate the occasion. Also, the celebration as such would be a chance to create some buzz around Prolog.
1 Like
One way to think about the ideas behind Web Prolog is as an extension of the ideas behind library(pengines). Web Prolog has pengines too, and they can be understood as special kind of actors - actors that come with a “built-in” communication protocol. So backtracking and logical variables and the dynamic database are certainly there, just as they are when you are using library(pengines).
Thanks to inspiration from Erlang, the design behind pengines in Web Prolog is much better and much clearer than the design behind library(pengines).
The built-in ISO Prolog predicates that are not in Web Prolog are the ones that do not seem to be useful (and/or dangerous) in the web domain - such as predicates for writing to disk, or to access the OS. The idea is that an application that needs to do such things need to use the capabilities of the host language (e.g. SWI-Prolog). Having said that, I don’t want to specify the contents or the size of the ISO subset at this point. If and when push comes to shove, I see it as a question for the community to handle.
When I gave the talk in Berlin, I occasionally referred to the language as a dialect of Erlang. It’s a bit far-fetched though, and I prefer to call it Web Prolog, especially in a group devoted to Prolog.
1 Like
Websockets are indeed supported.
Tau Prolog certainly appears to have some streams. The built-in write/1 writes to console. It can also open streams to a given DOM element or file handle with open/3&4. Tau Prolog is an interpreter in JavaScript.
The way I understand this concept, I see no need for streams in a web programming language. I’m not sure, but JavaScript doesn’t have them, right? In a web programming language, being able to send and receive messages (or events) should be enough for both intra- and inter-node communication. Other kinds of I/O might be needed for debugging purposes, but then streams are not required.
Web Prolog running in a browser (rather than from) would be nice to have. I suppose such a profile might be implemented in Tau Prolog (or by extending it), although it would probably not be possible to spawn concurrent processes, unless web workers can be used in a clever way. Personally, I see the work on compiling SWI-Prolog to WASM by Raivo Laanemets [1] as more promising.
But we don’t want Web Prolog to run only in the browser. After all, Prolog is particularly useful for large databases of facts and rules that are shared over a networks such as the Web. Therefore, a pengine running in a browser often needs to be able to create and then talk to a pengine (or another kind of actor) running on a remote node. This is where the predicates for spawning and sending and receiving in Web Prolog come in useful.
For example, given a Prolog program foo/1 running in a browser and the need to communicate in a synchronous fashion with a remote node, this would allow us to use the non-deterministic RPC predicate rpc/2-3 in this way:
foo(X) :-
...,
rpc('http://ex.org', q(X, Y)),
...
If we prefer communication to be asynchronous, we can do something like this:
foo(X) :-
spawn(baz, Pid, [
node('http://ex.org')
]),
...
Pid ! msg(X),
...
receive({
msg(A) -> do_something(A);
msg(B) -> do_something_else(B)
})
...
Using Prolog everywhere in this this way might be really nice. Still, I suspect most web application developers would choose to use JavaScript (perhaps together with a framework such as React or Vue) on the client side, and Web Prolog on the server-side only. For such purposes, a Web Prolog node comes with a HTTP(S) API as well as a WebSocket API. (The first example above can use HTTP as transport, but the second example must be run over websockets.)
2 Likes
Yeah, but that’s JavaScript and yes, a lot of it is only available in node.js. It’s been awhile since I touched JavaScript too, so why don’t we talk about Java instead? After all, Jan, you are a programming your own Prolog system in Java. What would you do if you wanted to build a Web Prolog node in a combination of Jekejeke Prolog and Java? That would be more interesting to discuss, for me at least (even though I know even less Java). (Why do I always need to draw people back to the topic of the conversation? )
This brings me to another point of having a standardised Web Prolog language. It can serve as an lingua franca, allowing different Prolog systems as well as other kind of systems to talk to each other. This picture sort of captures this idea:
1 Like
So, let’s specify some requirements. Lets stick to Windows (as I believe is your platform) and to ordinary web browsers (so that SWISH or something similar can talk to pengines running on your node). Also, since Web Prolog is supposed to be a web programming language, lets require the WebSocket and HTTP transport only.
Here’s roughly how it should work. Over and above what’s in a traditional Prolog system, we want to be able to spawn local pengines and other actor processes that have their own private workspace plus access to Web Prolog built-ins as well as to predicates defined by the node (in what I call the “node-resident program(s)”). Each process should be equipped with a mailbox named by a process identifier (pid). We need a receive operator - Web Prolog specifies one that works very similar to Erlang’s, that can process messages (nonvar terms) selected from the mailbox. We need a send operator as well, also very similar to Erlangs, that takes a pid and a term T and sends T to the (mailbox of the) actor process named by the pid, where it can be received. We are looking for network transparency here, so it should be just as easy to create the process on a remote node instead, by passing the option ‘node’ with the value a URI that names the node. The send operator should be capable of sending any (nonvar) term to any process for which it has the pid, even to remote ones. Process creation and messaging must be done over websockets.
The HTTP API works somewhat differently. The main idea is due to Jan Wielemaker (a long time ago) - but blame me and not him if it can be shown not to scale or has other problems. The point of the idea is that the HTTP is stateless (or RESTful if you want), which is supposed to be good from a scalability point of view.
Don’t get hung up on the choice of protocols here. What Web Prolog needs is some stateless request-response protocol, and some stateful, bidirectional protocol. It might be argued, though, that if neither HTTP nor WebSocket is used, we are not on the Web. Also, these protocols come with security (e.g. HTTPS and CORS), which we also need.
Yes, you seem to have at least some of what’s required to implement a Web Prolog node.
A draft appendix covering the predicates specific to Web Prolog is here:
Another source of info is the tutorial that comes with the PoC implementation. It provides a way to test all the predicates, as well as the web APIs. Note that its just a PoC after all, so there are bugs in the implementation and it’s not safe to expose it to the world since sandboxing doesn’t work yet.
Superficially, the Web Prolog predicates look somewhat similar to the ones in library(pengines), but there are three layers rather than just two: the actor abstraction, the pengines abstraction, and the RPC abstractions. Also, the naming of (some of) the predicates are different, as I want to borrow as much as possible of Erlang’s terminology (where this makes sense). More importantly, thanks to ideas borrowed from Erlang, Web Prolog actually works as a model for concurrent and distributed programming. (You can see it as my way of correcting the mistakes I made when I proposed the design of library(pengines).)
This is not to say that the design of Web Prolog doesn’t contain mistakes - of course not! - that’s why I’m consulting the community.
1 Like
How do web assemblies play into all of this …
You mean WebAssembly (WASM)? Only as a way to implement a version of Web Prolog that runs in a browser, as far as I can see.
Yes, I suppose I didn’t understand what a FAP is. Googling revealed very little, only something from a slang dictionary which I guessed you didn’t mean by FAP.
I don’t have a FAP. What I do have is chapter 6 in the longer manuscript at https://github.com/Web-Prolog/swi-web-prolog/raw/master/book/web-prolog.pdf which deals with the two web APIs that a full-blown node should support. Distribution in Web Prolog is totally dependent on them, so this chapter might give you an idea of what a real FAP might look like.
And yes, the problem of different Prolog dialects shows up as soon as we start thinking about Web Prolog as a standardised lingua franca. I agree that it’s a hard problem, but one that we should perhaps ignore for now, since it’s probably more important to get at least one node implementation up and running. The SWI-Prolog implementation of the PoC is nearly there, so it might be a good idea to continue working on this.
I haven’t said anything about different profiles of Web Prolog yet, but that’s something I’ve also been thinking about. It turns out that the non-deterministic RPC (i.e. rpc/2-3) can be implemented on top of the stateless HTTP API, and that this might be interesting enough for less sophisticated but easier to implement profiles. See chapter 10 in the manuscript for a tentative split-up of Web Prolog into profiles.
Excellent discussion.
Early at Mozilla Firefox, we faced an important decision: Focus on desktop, mobile, or both? We saw almost all desktop users switch most of their time to mobile. Everyone saw this trend happen faster than most companies/projects could adapt.
With Prolog, since everyone is spending all of their time on the Web, how and where does Prolog play a key role in the Web? That is the challenge Prolog faces today.
WebAssembly is the culmination of the effort to create a safe and powerful Web environment for native applications, and all major browser vendors are focusing on WASM’s development.
The race is on to be the browser that can provide native-speed, safe, self-contained Web applications through a secure channel.
I suspect WebAssembly will play a key role not only for for Web Prolog but Prolog itself in that it may be possible to provide a safe and robust Prolog environment profile inside of the browser.
When we combine WASM, Web Prolog, and the Distributed Web (IPFS, dat://, etc.), we begin to see a path for Prolog as a key component of the Web.
SWI-Prolog is already ahead of the game as a lot of the work to get it running in a WASM context has been done thanks to the amazing efforts of our community. I believe WASM should be a top priority for Prolog.
3 Likes
Hi Damon,
Thank you for the great analysis …
To add a few comments to this from another (semantic web) angle …
I suspect that with the move away from formal (heavy weight) semantic ontologies on the web to light-weight shapes, and with semantics (by necessity) moving into accompanying JavaScript, there is a chance here to provide a better middle ground with web-prolog.
Web prolog could provide a better solution than javascript for this purpose to enable the kind of knowledge-based and non-deterministic symbolic reasoning needed in open environments …
Dan
3 Likes
Yes. And, we haven’t even mentioned AI and NLP yet. AI, just in the past three years alone, has become the #1 technology effort today and when Web Prolog is used as the language of the Distributed Web, then AI and NLP efforts will have Prolog to go to for building Web-based conversational agents and distributed search engines.
This is why Web Prolog is so important.
3 Likes
As far as I know, there’s isn’t a WASM Web Prolog implementation. I’m not claiming that one exists. I’m saying that I believe time should be invested in creating one that is viable.
2 Likes
By cloning the repository and hacking on it until it works with as many people as we can find. How else?
2 Likes
Torbjörn discusses the proposed profiles in his paper. I believe WASM Prolog should support the maximum profile possible inside of the browser in order to maximize the efficacy of the language for the Web.
The capabilities and limitations are imposed by the Web, in this case, because things like WebSockets, CORS, CSP, and Web APIs are the ways and means that one accomplishes anything inside of a browser.
We have to decide: Is Prolog going to be on the Web or not?
We could choose to ignore the decision; however, I’m not sure that’s the wise choice.
2 Likes