Hi,
Having previously written a client in R, several years ago I began an attempt to write a client also in SWI-prolog for the XML database BaseX. Such a client makes intensive use of a socket connection. Since I could not manage to accomplish this in SWI-prolog alone, I decided to write a client first in C++ and then communicate with that client from Prolog. I hope to put that client on the Internet in a few days.
A few years ago there was a plugin available for Eclipse (PDT) that made it possible to combine Prolog and C++ within 1 project. That plugin is no longer available now.
My question is which development environment is currently best suited for work on a project combining use of Prolog and C++.
I’d go for Emacs. Great SWI-Prolog mode with sweep and good C++ support. Might not work too well on Windows with MSVC (don’t know). Vscode might be an alternative. I never used its Prolog mode.
Personally I use the built-in tools for Prolog. While sweep is close, I still prefer the built-in tools for slightly better integration and being faster. I switched from the built-in editor to GNU-Emacs for C(++), JavaScript, etc. as these modes are much better. As a consequence I improved the compatibility between the two editors.
All in all, Emacs is a good basis where you can expect long time good support for Prolog (not only SWI-Prolog), but vscode seems more popular these days. Time will tell. It appears hard to predict which editor will dominate.
Hi Jan,
I took a look at the start screen from the GNU-Emacs guides tour and at first sight it resembles much the standard SWI-editor (at least as fast as I remember, it now has been several years that I didn’t work with swipl).
What do you mean with the built-in tools, the editor that starts with ?-edit()?
When starting the development of the c++ library, i experimented with vscode for linux. I recall that I preferred the look and feel from Eclipse. And the PDT-plugin worked well in Eclipse. Pity that it is no longer supported.
By default, ?- edit. indeed starts the built-in editor. This is basically a GNU emacs clone written in Prolog (and xpce GUI). What makes it powerful is that Prolog can open the editor buffer as an I/O stream and thus can do very efficient analysis of your Prolog code. @oskardrums implemented a mode for GNU-Emacs called “sweep”. This basically works through the foreign language interface of GNU emacs, embedding SWI-Prolog. That is a little slower than what the built-in (called pceEmacs) does, but still fast enough to do similar things in GNU emacs. pceEmacs and sweep are closely related as both build on top of the same SWI-Prolog libraries (also used by the online SWISH).
GNU emacs has excellent support for many languages. There are a lot of people that consider it outdated. That is true in the sense that it doesn’t obey the CUA key bindings found almost anywhere these days as its own keybindings predate this and conflicts. There are modes that resolve this AFAIK.
My pattern for working with C++ and Prolog using GNU Emacs has generally been to use the CMakeLists.txt file to copy over Prolog source files to the project build directory. Then, I generally do more development on the Prolog files (writing high-level interface and tests) in the build directory, then finally copy the Prolog source files edited in the build directory back to the source directory to be added to version control.
I find this workflow to be “good enough for rock’n’roll” but doing development in the build directory seems kind of dirty. I plan to transition to something less amateurish soon, but I’ll have to resolve some other issues with my computing environment first (fried motherboard on desktop machine; currently using laptop with older version of Debian that I don’t want to upgrade).
Currently, due to the aforementioned old computer & OS (which are running a slightly dated GNU Emacs v27) I’m not using sweep, I’m just using whatever comes with the prolog-mode that you get from the package manager, (M)ELPA. I use projectile, company, semantic, and some other CEDET stuff for my IDE utilities. These tend to need a bit of customization to work well. They work reasonably well as project support for C/C++ development, but they don’t do as much, especially in terms of code completion and other hints, for Prolog source code. That may be due my failure to fully configure the hooks for visiting Prolog source files, however I’ve found that sweep is more “batteries-included” in terms of providing these conveniences.
Another cool thing about sweep is that it offers a lot of interoperability between Emacs Lisp and Prolog.
I’ve never gotten into it, but these days a lot of Emacs users use LSP as the backend for a lot of project support IDE stuff – that may be the way to go if you’re not interested in spending a lot of time and effort towards getting the native GNU Emacs project development tools up and running.
I do something like that for Prolog’s own development as well, but using links. I.e., the installed version is just a set of links to the files in the development tree. Of course, you need proper support for symbolic links …
For normal Prolog/C(++) projects I typically just use the Prolog files from the git repo. Note that you can do neat tricks in locating the files using file_search_path/2.
Sweep is a big step ahead compared to the default Prolog mode!