2 ms·

Thank you for your hard work in promoting Prolog! It has made a great impact on the community. Do you think you can do a few posts on interfacing Prolog with ex

Thank you for your hard work in promoting Prolog! It has made a great impact on the community. Do you think you can do a few posts on interfacing Prolog with external systems? E.g. not just manual, carefully crafted proof-of-concept demos. But a full interface with perhaps an API endpoint or database with utf-8 data. A lot of Prolog tutorials refuse to acknowledge the fact that it has poor support for non-proprietary Web/GUIs, compared to at least JS/Ruby/Python. It would be really helpful if you can do a post illustrating how to get from the step of multi-language data entry in e.g. React with a Python backend to getting it processed in Prolog.

triska 7y ago
Thank you very much for your kind words, and for your interest! Yes, absolutely: In fact, Prolog was designed for natural language processing and convenient interfacing. However, currently, all existing Prolog systems fall short for such use cases in that they do not optimally combine efficiency with convenience when processing lists of characters. Ideally, lists of characters are efficiently represented internally, i.e., as sequences as raw bytes, and at the same time made available to Prolog programmers as "completely normal" lists, like all other lists, so that they are amenable to DCGs etc. So, to seriously advertise such use cases, there must first be a Prolog system that handles lists of characters in an efficient way. Recently, Mark Thom has confirmed his interest in implementing such an efficient internal representation in Scryer Prolog, please see the relevant issue: https://github.com/mthom/scryer-prolog/issues/95 https://github.com/mthom/scryer-prolog/issues/95 Rust programmers may be interested in helping with the implementation!