Logtalk support

[pmoura]

I'm working on Logtalk support on a fork of your work at:

https://github.com/LogtalkDotOrg/logtalk-jupyter-kernel

The starting point was to write a Logtalk version of the Prolog files in the prolog_server. The goal is to support multiple Prolog backends supported by Logtalk. As the code requires native support for stream redirection, that's one of the main issues for wide portability. I'm planning to have basic functionality working by the end of the week. For now at least, I had to delete or comment out some of the features you implemented for SICStus Prolog and SWI-Prolog.

My initial plan was to contribute back the Logtalk support but the changes are extensive and it's likely best to have a separate project. I will ensure, of course, that full credit is given for your original work in the documentation. I also would like to explore possible venues for close collaboration in these projects. My work here is sponsored by industry and that may open some interesting opportunities.

I will post updates as I evolve the Logtalk support. Many thanks for sharing your hard work with the open source community.

[pmoura]

I have update the URL above and renamed the files so that both Prolog and Logtalk kernels can be installed side-by-side without conflicts. Currently, the only two backends that work are SICStus Prolog and SWI-Prolog (although configurations are provided for a few others). The fork uses Logtalk's own portable JSON library. The main portability issue (to support more Prolog backends) is still stream handling and redirection. I have added Anne's name to the list of authors of the Logtalk versions of the original Prolog files. If I'm missing a name of a co-author, please let me know.

[pmoura]

As I mentioned above, my derived work on Jupyter kernel for Logtalk allows it to co-exist with the Prolog kernel. Although simple pull requests are not feasible, cross porting of enhancements and new features should be doable.

The Logtalk kernel currently supports ECLiPSe, LVM, SICStus Prolog, SWI-Prolog, Trealla Prolog, and YAP. I'm working also with Daniel Diaz to also support GNU Prolog. To simplify supporting these and other Prolog systems, I have refactored the code that redirects goal output to a file (https://github.com/LogtalkDotOrg/logtalk-jupyter-kernel/commit/bdaa0421ede909ae922faec76b9a9f0bb91a2089). The changes should be easy to port if you also want to support other Prolog systems.

A major change in the Logtalk kernel is in how new predicates (and also Logtalk objects, protocols, ...) are added/modified via code cells. I replaced your solution (which is based on asserting/retracting/abolishing predicates) with a cell magic solution that fully delegates (re)loading code to the Logtalk process (https://github.com/LogtalkDotOrg/logtalk-jupyter-kernel/commit/26c54d444827d808d7d1b4f75eb783e56870d952). This greatly simplified the code and made it more portable. I update the slides to illustrate it (https://github.com/LogtalkDotOrg/logtalk-jupyter-kernel/blob/master/notebooks/slides/A%20Jupyter%20Kernel%20for%20Logtalk.ipynb). This change also simplifies interpreting code cells content: if the cell magic is not used, then the cell contents is always interpreted as a query.

Other noteworthy changes are debugging and testing where Logtalk portable developer tools are used. But I think that these are not currently relevant to the Prolog kernel.

[pmoura]

Experimenting with cell magic shortcuts to the print table and show term features (https://github.com/LogtalkDotOrg/logtalk-jupyter-kernel/commit/759594b5ba627bc74a50369a1937dfdd4ea13834):

[pmoura]

Added support for GNU Prolog when running its latest git version.

[pmoura]

https://pypi.org/project/logtalk-jupyter-kernel/0.2.0/