Uniting the Prolog Community During ICLP 2008, a special session organized by Bart and Tom took place, aimed at stimulating the discussion of how to move the Prolog community forward. There has been a general feeling that other communities are gaining a greater momentum, while the logic programming has not been as organized and pro-active. In this section you will be able to find a report (by Tom and Bart) on the even, along with two follow-ups that were submitted to the newsletter. I hope you enjoy and I strongly encourage further feedback (and action!) on these issues.     Enrico Uniting the Prolog Community (T. Schrijvers and B. Demoen) Uniting the Prolog Community: Personal Notes (P. Moura) Prolog Commons (T. Swift) Event Report Uniting the Prolog Community Tom Schrijvers and Bart Demoen K.U.Leuven Belgium Editor: Enrico Pontelli In his article "A Wake-Up Call for the Logic Programming Community", published in the ALP Newsletter, Tom raised several concerns about the viability of the Prolog programming language in the near future. This session on "Uniting the Prolog Community" was organized to reiterate these concerns, to announce recent positive developments and to involve the whole community in the discussion. Bart started out with an overview of the issues at stake: Love & Passion: for Logic Programming, and Prolog in particular (witnessed by the packed sala Floria) Separation: many fragmented systems Guilt: for causing separation Jealousy & Envy: for more thriving communities Hope & Reconciliation: SWI-Prolog and Yap are joining forces He ended with a call to the audience to contribute with positive arguments. Next, Tom compared the state of affairs between the Prolog and Haskell communities. The Haskell community strongly integrates researchers, hobbyists, open source volunteers and industry. For Prolog the picture is much less clear. Few attendants could name more than one company using Prolog. This does not indicate so much that they don't exist, but rather that the community as a whole is simply not aware of them. In order to address the separation issue, Tom suggested we might learn a thing or two form Haskell community tools, of which the two most important ones are  a community-maintained wiki portal with all the information you may possibly want to know about the language, and a library database for code sharing. Jan Wielemaker and Vitor Santos Costa reported on a hopeful development: they are joining forces, sharing code and increasing portability between their systems. All parties benefit, not only the users of YAP and SWI, but also Jan and Vitor who do not have to do the same work twice. Vitor concluded with a challenge for the community: we should give the outside world (and ourselves) a strong message: Prolog is simply the best and we can do things with it that others simply cannot conceive. In the last presentation, Paulo Moura related on the pain and struggle to port a Prolog application to different system. If Prolog systems would behave more consistently, his life and that of many other users would be so much easier. Throughout we had plenty of constructive discussion and suggestions from all the participants. For instance, Michael Codish reminded us of LP teachers and LP users in other communities, such as Natural Language Processing, and Markus Triska pointed out the existence of a #prolog IRC channel. Many other good points were raised. Will all this discussion lead to any concrete action? The answer is yes! The developers of Ciao, SWI-Prolog and Yap will reconcile at a hackaton beginning next year, to improve interoperability bottom-up. The ALP is setting up a wiki on very short term, and programming competitions will be organized to improve Prolog's presence at the Programming Language Shoot-Out. The rest is up to you: content for the wiki, programs for the shoot-out, and libraries for  the interoperable Prolog systems. Other ideas are welcome and the wiki will give you the means to realise them. The session ended in an optimistic atmosphere and we are very grateful for the positivism of the participants. Finally, we would like to thank the ALP, the program chairs and local organizers for giving us the opportunity to organize this session. We hope to see you again next year, at ICLP 2009, with more good news. ?- can(we). Yes
		Uniting the Prolog Community: Personal Notes Paulo Moura Universidade da Beira Interior Portugal Editor: Enrico Pontelli Bart Demoen and Tom Schrijvers kindly invited me to share my experience in writing portable Prolog applications at the ICLP'08 session on "Uniting the Prolog Community". My experience comes mostly from developing Logtalk and from my work with implementers and with the ISO committee towards Prolog standardization. What follows is an extended version of the main points in my short (10 minutes) presentation. Be sure to read the session manifesto in the ICLP'08 proceedings for the context of these notes. Portability There are more than 20 Prolog compilers available today. Some of them are academic experiments, some of them are commercial products, and a healthy percentage of them are free, open source compilers. Most of them are actively maintained today. I have 12 of these compilers installed on my laptop. While doing Logtalk development, I rotate daily between a subset of them. This might sound crazy, and certainly would not be feasible for many applications, but it is generally possible in the case of Logtalk and it helps me finding portability problems and bugs both in my own code and in the Prolog compilers. Just to give you a quick example, while developing the latest Logtalk stable release (2.35.0), I found two bugs in my code. One of them only manifested itself in B-Prolog. The other one was only apparent in ECLiPSe. In the past 10 years, this working routine helped finding, isolating, reporting, and sometimes fixing, a few hundreds bugs in Prolog compilers. Most of the trouble could be avoided, with obvious productivity gains, if Prolog compilers would fully comply with the ISO Prolog Core Standard (Part I), published in 1995 (i.e. 14 years ago!). The good news is that the current status of standard compliance improved considerably in recent years. The bad news is that the missing bits still can cause a lot of grief when writing portable applications. One of the lingering problems is the exceptions thrown by built-in predicates. In error cases, some compilers fail instead of throwing an exception while others throw an exception term that doesn't comply with the standard. Operators can also be problematic. Some compilers choke when parsing valid code that uses operators and not all compilers make module declared operators local. A third issue are meta-predicates, specially when closures are used. Compounded with flawed modules systems, these and other problems make write porting Prolog applications something that is avoided rather than being the norm. QA Quality assurance (QA) is missing in action for too many Prolog compilers. Some may argue that QA is something that one only have the right to demand for commercial Prolog compilers. I disagree. Embarrassing bugs are embarrassing bugs, no matter where you find them. With a significant amount of Prolog development occurring in the open source realm, users, specially industrial users, need to trust our development processes. That means, among other things, unit testing applied in a systematic way. ISO The "Uniting the Prolog Community" manifesto in the ICLP'08 proceedings contains the following comment regarding the ISO Prolog standardization process: "Despite many (also recent) efforts, the ISO committee seems unable to make substantial progress on the core standard, let alone to impose the modules standard." I find this remark to be a good summary of the current status of of ISO Prolog standardization. It's also a misleading remark. The ISO Prolog standardization is an open process where anyone can participate. The ISO committee is you, me, and anyone willing to contribute. True, there are formal voting procedures but that does not prevent in any way attending a meeting, presenting a case, and helping improving the current draft proposals. Criticizing the ISO committee for the sore state of Prolog standardization is easy but, most of the time, is just plain blame shifting. Very few people actively participate. Case in point: most Prolog implementers at ICLP'08 didn't bother to attend the ISO meeting. The same happened in previous meetings, held during past ICLP events. Besides the yearly meetings, there is also a mailing list and standardization forums. Both are ignored most of the time. Nevertheless, despite the lack of human resources, progress is being made! Five draft documents cover Definite Clause Grammars, Core revision, Threads, operating-system interface, and Globals. Being drafts means there are still rough on the edges. More work is needed to improve their quality. The published standards are not perfect either. They have flaws and we must have the courage to correct them, despite their official status. Two examples are the limited way of dealing with different text encodings in Part 1 and most of Part 2 (the modules standard). Libraries and code sharing There is no systematic development of Prolog libraries. Even when considering only pure Prolog libraries, a lot of desirable functionality is incomplete or missing. Pure Prolog libraries are the perfect candidate for code sharing among systems. Or so it seems at first glance. The trouble begins when a library predicate needs to call a built-in predicate, say, arg/3, whose behavior when called with a non-existing argument number is implementation dependent. Suddenly, applications using the library and working perfectly in Prolog X fail unexpectedly when run with Prolog Y. The library writer, faced with the prospect of writing once and testing everywhere, often chooses to make its library Prolog-specific. Reliable, portable libraries require Prolog compilers that comply to a core standard, include adequate documentation, and come with a set of unit tests. Thus, with need portable documenting tools and portable unit test frameworks. One of the problems is that most of work that needs to be done hardly warrants you any publications. Commercial development of Prolog libraries is hardly feasible giving the small size of our community. Everyone is pressed on time so... we need code sharing at all levels, not only libraries but also at the compiler level. Developing, for example, a common source reader, a common foreign-language interface, or using common stream handling code would strength collaboration and improve portability. The SWI-Prolog and YAP developers are already hard at work doing joint development. Hopefully, others will follow their lead. During the ICLP session, while discussing how Prolog systems could collaborate, someone remarked that "the fittest may survive". In order for the fittest to survive we do not need any community at all. The fragmentation of our community, expressed by the large number of Prolog dialects is indeed a problem. Most implementations, however, specially the smaller ones, contain unique and interesting features that we should consider keeping while looking for new ways to cooperate and unit our efforts. Not our father's Prolog! Prolog compilers have came a long way since the first implementations at Marseille and Edinburgh. Nowadays, we've unicode, tabling, constraints, threads, modules and objects, graphical source-level debuggers, profilers, foreign-language interfaces among other features. Most Prolog compilers provide a subset of these features making them suitable for a broad range of application domains. We do, however, have a marketing problem! A big one. Is quite frequent to find people disdainful of Prolog, claiming that it's slow, quirky, a relic from old AI language wars, useless as a general purpose programming language. Mention Prolog in a research grant request and you risk getting a short, dismissive sentence as a reward. Thus, improved collaboration among Prolog implementers only goes half way. We also need to show the rest of the world that Prolog implementations have come a long way and can be an effective tool for solving non-academic problems. Prolog-Commons Working Group Report Terrance Swift Universidade Nova de Lisboa Portugal Editor: Enrico Pontelli Have you ever tried to port a complex Prolog program from one Prolog system to another?  The ISO Prolog standard makes this easy, right? As anyone knows who has ever attempted such a port, the answer is usually "no".  The core ISO Prolog standard, while a significant achievement, is limited in its scope.  It does not address libraries interfaces, constraint systems, or a number of other features that real applications need.  And the lack of a broad-based standard is not the only impediment to portability.  It actually may be impossible to move between Prolog systems if your application requires features such as tabling, native code generation, dynamic indexing, compiler analysis or an interactive development environment.  To some extent, this diversity is a result of the good health of logic programming, as there are numerous fine Prolog systems, each of which has a rapidly evolving code base and specializes in diverse and important research directions.  However the limited portablity of Prolog code, along with the lack of a single Prolog system to which all researchers contribute, can also be a barrier for potential users of logic programming. The Prolog-Commons Working Group has formed in order to start to address some of these issues.  The first meeting of the group, organized by Bart Demoen and Tom Schrijvers occurred in Leuven, Belgium on February 12-14, and was attended by Manuel Hermenegildo and José Morales of Ciao Prolog, Jan Wielemaker of SWI Prolog, Vítor Santos Costas of YAP Prolog, Daniel Diaz and Salvador Abreu of GNU Prolog , and Terrance Swift of XSB Prolog.  Each of the Prologs mentioned has unique features that the others do not, and as a result all have their own dedicated user communities. The first day of the meeting was somewhat informal.  An important psychological milestone was passed when all implementors managed to install one another's Prologs on their laptops.  A common repository for working code was also created, and discussion began on what exactly to do with the repository.  The group quickly agreed on general standards for using modules in libraries, for adding annotations about types, and for unit testing.  At the same time, consensus for documenting code in a "literate programming" style proved more difficult, although the group achieved a provisional agreement on this as well.  The second and third days built on the progress of the first, when the attendees began to actually add code and APIs to the repository, which by the end of the meeting contained nearly 4000 lines of code. Creation of a common set of sophisticated libraries and packages for Prolog is a giant task, of which the Leuven meeting was (hopefully) the first step.  However, in addition to the concrete progress made on the repository, the attendees agreed that there was a great deal of intangible benefit in understanding both one another's systems and how to write more portable library code. The next meeting of the working group is planned to take place near the time of ICLP 2009 in Pasadena, California.