We should get Raivo help. That’s our job as a community. I’ve found one person who is willing to work on the project, and I hope to find more. If we work together to find people, we can do it.
1 Like
If history is any lesson – the sudden popularity of JavaScript was due to the favorable coincidence of it being used to enable the emerging dynamic web – from static to dynamic Web UIs.
Perhaps web prolog can now have this kind of favorable boost in emerging at the right time, when the web seeks better symbolic integration …
2 Likes
That’s right.
I could go on and on about how I see distinct advantages of the Prolog language when it comes to emerging-and-now-popular technologies that become available once Prolog-the-Language is used as the interstitial language of logic and even inference on the Web.
1 Like
I believe Jekejeke Prolog, along with tau-Prolog, and most of the other Prolog impls/projects out there are key efforts that must be supported.
We need a second reference implementation of Web Prolog. Our Prolog community has everything we need to contribute to Web Prolog. It’d be amazing to see Jekejeke Prolog help lead the way here.
This will only happen if we do it. And, fwiw, I believe we will. Too much excitement around this.
1 Like
I think the place to start is to identify the key requirements, and their justifications, so one knows what to work towards. As well as know to evaluate what exists in relation what is needed.
1 Like
If I could have client-side Prolog integrated with server-side Prolog, like WASM Web Prolog and pengines, I’d be using it in a heartbeat.
Those of us whose main focus is web application development are already hacking at how to do this, playing with Hans Beck’s Tau queries to a pengine is high up on my to do list. We’re also doing it to overcome limitations in existing systems, mostly to do with data representation. Even a tiny-SWI-Prolog would be useful, Tau isn’t exactly huge.
3 Likes
I agree with your sentiments. Torbjörn and I have been discussing this, too. From my perspective, Web Prolog is the language glue that needed to happen to connect Prolog to the Web, paving the way to WASM Prolog.
WebAssembly could leverage Web Prolog in many ways. And vice versa, I suspect.
WASM is the interstitial language that everything compiles into. This emscripten-produced interstitial compiled code performs far better in many cases than Javascript because it uses established and modern compiler optimization techniques (reaping the rewards of LLVM) and it can optimize in advance for Javascript engine features in V8 and Mozilla. At first, we could only provide basic functionality in a browser, but emscripten took off, and today new features, bug fixes, and performance optimizations are happening quickly.
WASM is now being deployed both on the client and the server, with some companies forming whole products with this stack.
Personally, I want to see this happen because I think Prolog is an ideal language to build a distributed Web search engine. If Prolog is part of the language of the Web, runs in the (Web) client and the (Web) server, this helps make that a reality.
I think this is a huge opportunity for Prolog.
2 Likes
That paper cites two paper’s from my old team’s efforts, one for the Javascript Tracing project (Andreas Gal’s research) which lists most of the Mozilla JS team as co-authors and also there’s Zakai’s paper (emscripten). 
1 Like
Javascript engines have improved dramatically since their paper was published. The tech referenced in the bibliography has since been replaced with more performant techniques. For example, tracing (which was the TraceMonkey project at Mozilla) no longer plays a significant role in modern Javascript engines.
So, I agree that we should run the tests again. 
Could be helpful to see where to focus.
1 Like
The WASM version of SWI-Prolog is simply compiled using CMake configuration from the main unmodified source. It is just the core (no packages), it is 32-bit (which is all WASM does right now AFAIK), single threaded and without bignums (gmp). But, it has constraints, tabling, all the indexing, etc. I don’t think including gmp is a big issue. There is/was some opportunity to use threads in WASM, but I vaguely recall it is disabled for security reasons. Adding some of the packages is probably doable as well. Of course, it gets bigger and bigger 
You could add SWI-Prolog engines to the single threaded version. That wouldn’t be a trivial project, but also not a really big thing: mainly disconnecting the multiple engines from the threads.
I didn’t run performance tests on the WASM version, mainly because due to a bug in the emscripten runtime libraries file I/O is severely broken when running under Node. That makes it rather clumsy to load and run the benchmark suites. I think the general expectation is a slowdown of 2-3 times.
4 Likes
2-3 times slowdown isn’t too bad considering that it’s running in the browser where it doesn’t have to compete with other clients. And since network roundtrips cost time, you can save time by running things locally, thus avoiding network roundtrips as much as possible.
And perhaps multi-threading doesn’t have to be there in a first version? It would mean you can’t call ?-spawn(foo, Pid) or pengine_spawn(Pid) (i.e. spawn a local actor or a pengine), but you can still call ?-spawn(foo, Pid, [node('http://ex.org')]) or ?-pengine_spawn(Pid, [node('http://ex.org')]) as well as rpc('http://ex.org', p(X)). The send and receive operators must be implemented as well, of course, so that you can send to remote actors and pengines, and receive messages arriving from them.
Then, when multi-threading in WASM shows up, the spawning of browser-local processes can hopfully just be added to what’s already there.
1 Like
Indeed. The 2-3 slowdown is not too bad. The current image is 1.3Mb, which isn’t too bad either. I’m not too sure WASM will see mature enough multi-threading anytime soon and even whether we will see threading at all. SWI-Prolog is fairly demanding on its requirements for reliable and scalable thread APIs. Surely you can still use the client API and quite likely it is possible to build a multi-engine Web Prolog system using I/O based task switching.
2 Likes
Indeed. Peter van Roy was at the Erlang’19 workshop when I gave my talk. He commented that the Web Prolog approach seems to be able to provide the Semantic Web with what it’s currently lacking - an architecture.
The moment after he made that comment, I showed the audience the following slide:
So, yes, I think Peter van Roy may be right. 
In this paper, Wielemaker et al show that since Prolog is a relational language, just like the Semantic Web languages, the notorious object-relation impedance mismatch problem can be avoided when building applications. They also show that Prolog is in many ways a better query language than SPARQL. Here’s a quote from the paper:
We do not consider SPARQL adequate for creating rich semantic web applications. SPARQL often needs additional application logic that is located near the data to provide a task-specific API that drives the user interface. Locating this logic near the data is required to avoid protocol and latency overhead. RDF-based application logic is a perfect match for Prolog and the RDF data is much easier queried through the Prolog RDF libraries than through SPARQL.
For purposes related to the Semantic Web, Jan’s current work on tabling is also important. Perhaps Web Prolog can be “sold” as a semantic web logic programming language? In a paper with the title Semantic Web Logic Programming Tools, the authors argue that Well-Founded Semantics (WFS) provides the right basis for such languages, and this is something that tabling makes possible. Indeed, SWI-Prolog already supports WFS - see this entry in the manual!
I don’t think this necessarily means that tabling has to be a part of Web Prolog as such - it might be one of those things that must be delegated to a host language that can deal with it.
1 Like
Thanks for the slide, very interesting.
There are various semantic underpinnings for logic programming, with well-founded semantics one of them (stable model semantics / answer sets is another one – if i understood that correctly).
I feel best to keep a simple and standard (ISO?) Prolog baseline, as a light-weight and easy to learn and use logic programming language, and enable other (more heavy weight) semantics, as further options – for those use cases that require such additional expressiveness and related formal reasoning (and related reasoning guarantees).
Perhaps also a comment on Prolog as a knowledge representation language:
While Prolog is essentially a rule-based knowledge representation language – its a very basic knowledge representation language – which is also its strength and versatility.
With prolog one can also go further …
Logtalk, which compiles to Prolog, provides higher level knowledge representation abstractions such as Objects and others – and then there are OWL variants implemented in Prolog, as well as the ability to import and link to OWL triple stores.
Dan
2 Likes
That old paper described Logtalk 1.x, an experiment in computational reflection. The implemented mechanisms that you mention were dropped for Logtalk 2.x/3.x, no longer an experiment but a language with little in common (other than the name) and no code shared with 1.x.
The co-author in that paper was my Master’s degree advisor. He helped review the paper and the thesis but had otherwise no significant participation in the creative process that resulted in the Logtalk 1.x prototype. There was no collaboration with him in any shape or form in the creation and development of Logtalk 2.x/3.x .
2 Likes
As someone unfamiliar with pengines and Erlang, but has built a fairly complex web application using SWI-Prolog, I’m a little confused as to what problem this solves.
I’m communicating between the Javascript in the browser and the Prolog server via Json like so:
move_handler(Request) :-
member(method(post), Request), !,
http_read_json_dict(Request, DictIn),
game_manager(DictIn, DictOut),
reply_json_dict(DictOut).
So far, I’ve got a chess player at http://www.newsgames.biz/chess and a draughts player at http://www.newsgames.biz/draughts working using this simple code. (They are not exactly tough players yet, but it’s work in progress).
A concern of mine is whether this SWI-Prolog server will hold up if the site gets busy and popular. But so far, so good.
I haven’t spent much time looking at the pengines documentation since I’m not sure if it does anything SWI-Prolog’s “plain vanilla” http predicates don’t do anyway?
3 Likes
Thanks Eric
What is probably more useful is the basic gameplaying code which I’ve put at https://swish.swi-prolog.org/p/Graphs1.swinb and my notes on writing a web server with SWI-Prolog at https://github.com/roblaing/swipl-webapp-howto which I’ve posted here before, but I’ll add to the references link.
The question is what one wants to achieve with object orientation.
In knowledge representation, such as RDFS / OWL, one wants to compactly capture domain knowledge with semantic correctness guarantees related to provided symbolic inferences. There is no notion of function (in the imperative code sense), method or dispatch.
In object-oriented programming you want to structure your data and function code for stability, scalability and reuse. Its a software engineering approach.
And, as far as i understand, in Logtalk you aim to create a reusable declarative structure for logic programs – i.e. also a software engineering approach for logic programming – with dispatch an extension of call conventions (i.e. the procedural reading of prolog code), while also enabling the taxonomical declarative reading of the code structures.
Dan
p.s. and i guess, historically, object-orientation derived from frame-based systems – based on a theory of mind by Minsky et al. to enable developing AI systems for common sense reasoning.
2 Likes