Guidelines for porting libraries from SWI-Prolog?

[panasenco]

I need a JSON reading/writing library for a project I'm starting.

The gold standard in the Prolog community seems to be http/json.

I notice that there are already several modules ported from SWI Prolog: tabling, ordsets, assoc, and xpath.

My questions in no particular order:

• Are there any guidelines for porting a library?
• Is there a general expected etiquette that we're supposed to follow (ask the original author, put in an acknowledgement, etc.)?
• Are there any legal issues we have to worry about?
• Are there some common technical issues that arise when attempting to port libraries to Scryer? For example, http/json useslibrary(record), library(memfile), and library(option), none of which seem to be available in Scryer.
• When dependent libraries are not available in Scryer, is it better to port the dependent libraries to Scryer also if possible, or try to rewrite to have fewer dependencies?
• Should ported libraries be in their own repos or added to the main scryer-prolog repository via a pull request?

[triska]

There is one important consideration that should be taken into account when porting libraries to Scryer Prolog:

Scryer Prolog sets a new standard for efficient encoding of lists of characters, which we mean when we say "strings" in the context of Scryer Prolog. A key advantage of the efficient encoding is that DCGs can be used for describing the string, since it is simply a list.

A good infrastructure for processing JSON with Scryer Prolog uses this representation, and describes JSON format with a DCG. With such a nonterminal, we can use phrase/2 and phrase_from_file/2 to read JSON from a string or a file, and also phrase/2 or a future predicate phrase_to_file/2/phrase_to_stream/2 to write JSON. See #691.

Scryer Prolog's string representation is so efficient that it subsumes several features that other Prolog systems provide with more ad hoc datatypes and predicates. For instance, library(memfile) may not be needed at all in Scryer Prolog: Simply use a string instead, which is internally represented as a sequence of raw bytes in memory.

[triska]

It would be great to have a library that makes full use of Scryer's efficient internal string representation, since all future Prolog systems will have to use it in order to compete with Scryer on the task that Prolog was designed for: efficient text processing. Trealla Prolog has already adopted the same representation (at least for fully instantiated strings, not yet for partial strings). Relying on this representation in libraries will encourage other Prolog systems to also implement it, and also simplify the library implementation since it only depends on standard data structures that should be implemented efficiently anyways.

In addition, for compatibility with other Prolog systems, the JSON representation used in the library should conform to the Prolog ISO standard.

[panasenco]

@cduret It's a good thought, but we won't be able to port any GNU Prolog libraries due to license issues. The GPL is not compatible with Scryer Prolog's BSD license.

@triska What do you mean by "JSON representation used in the library should conform to the Prolog ISO standard"?

[mthom]

I ported SWI's tabling library to Scryer a while back. Also, Simon Forman's Thun interpreter was originally written for SWI. It might be helpful to compare the two pairs to spot the differences between SWI and Scryer Prolog.

[triska]

Regarding ISO: In Scryer Prolog, this will be automatically ensured if you keep the implementation to the Prolog level. I mention this in case someone develops a case of JavaScript envy and then would like to extend the syntax of Scryer itself in nonconforming ways, for example to access dictionaries or records. library(records) is a conforming extension, and it can be added to every Prolog system without introducing any case of ambiguity or contradiction with the standard.

[panasenco]

OK, gotcha. I was going to use library(assoc) to represent parsed JSON objects.

[panasenco]

I'll start working on my own json library as suggested by @triska. I'll leave this question open for others who might need to do some actual porting work.