Ann: Paper about Web Prolog

Dear All,

I just got back from ICFP in Berlin where I presented a paper in the co-located Erlang’19 workshop. Here’s the title and an abstract:

Intro to Web Prolog for Erlangers

We describe a programming language called Web Prolog. We think of it as a web programming language, or, more specifically, as a web logic programming language. The language is based on Prolog, with a good pinch of Erlang added. We stay close to traditional Prolog, so close that the vast majority of programs in Prolog textbooks will run without modification. Towards Erlang we are less faithful, picking only features we regard as useful in a web programming language, e.g. features that support concurrency, distribution and inter-process communication. In particular, we borrow features that make Erlang into an actor programming language, and on top of these we define the concept of a pengine – a programming abstraction in the form of a special kind of actor which closely mirrors the behaviour of a Prolog top-level. On top of the pengine abstraction we develop a notion of non-deterministic RPC and the concept of the Prolog Web.

The paper is here: https://gup.ub.gu.se/file/207827

Comments are of course welcome!

And should you want to know more, there is (as some of you already know) a github repo from which a proof-of-concept implementation can be downloaded and taken for a trail run - and there’s a tutorial too!

The repo is here: https://github.com/Web-Prolog/swi-web-prolog

I’m happy to let you know that Damon Sicore, former contributor and leader in the Mozilla Firefox and Wikipedia projects, has taken interest in the Web Prolog project. In his own words, he “wants to secure attention and resources in order to publicly advance the project to enable Prolog to be a key component of the Web”.

Expect to read more about our plans for Web Prolog in the near future.

Best regards,
Torbjörn

7 Likes

Great paper and great effort!

1 Like

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. :slight_smile: 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. :wink: )

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

Why would you subset ISO Prolog? I always thought extending is the problem, like SWI-Prolog added strings, and somebody(*) went bonkers because now double quotes could have a new meaning.

Does subsetting ISO Prolog mean that Web Prolog would not have anymore any backtracking and logical variables (**)? Or no if-then-else? Or no dynamic database? Could you give an example?

(*) Name is known to the poster.

(**) Then don’t call it Prolog, maybe call it Erlang.

P.S.: Thats one of the papers that started Erlang by subsetting Prolog:
Use of Prolog for developing a new programming language (1992)
by J. L. Armstrong , S.R. Virding , M. C. Williams
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.3972

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. :slight_smile:

1 Like

So you cannot write on the browser console, since Web Prolog wont have streams? I think Tau Prolog had similar problems, but its no a pengine, it sits directly in the browser. I don’t know what the fix is so far for Tau Prolog, I think I saw a twitter post about some stream writing.

So Web means Web server. How about other servers? Any kind of micro or macro service? Or are pengines restricted to be accessed through “Web”? Does “Web” here mean HTTP and HTTPS protocol? Are for example web sockets also supported?

Maybe I should skim your paper, instead of asking 1000 questions.

Edit 28.08.2019:
The PDF is not search friendly, I tried https://gup.ub.gu.se/file/207827 and wanted to search “socket”, but it doesn’t show something useful in acrobat reader. Very strange:

Unbenannt

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.)

[1] https://www.swi-prolog.org/build/WebAssembly.html

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? :slight_smile: )

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

FAP: Format and Protocols
https://www.igi-global.com/dictionary/b2b-eai-business-process-management/11420

Depends on the use case/business case and further platform requirements. For example on an Android device there are like at least 4 different ways to communicate between apps (none of them talk about a programming language, thats outside of a FAP):

Content provides always gets me on Android platform. Especially annoying since Prolog texts are sometimes treated as documents, and then I get an URL with a schema currently my Prolog system doesn’t support. Anyway.

This was just a thought, since yesterday I wrote micro and macro service, and I did have alternative examples of communcation at hand different from HTTP and web sockets. But then I guess Android is a palatable example.

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.

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

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.

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. :slight_smile:

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.