6 ms·

Apart from different implementation languages and techniques (Rust/JavaScript/C, WAM/AST interpretation etc.), one of the most striking and impactful difference

by triska 4y ago

Apart from different implementation languages and techniques (Rust/JavaScript/C, WAM/AST interpretation etc.), one of the most striking and impactful differences is that Scryer, Tau and Trealla Prolog aspire towards ISO conformance, i.e., they try to adhere to the Prolog standard, whereas SWI intentionally does not adhere to the standard: https://www.complang.tuwien.ac.at/ulrich/iso-prolog/SWI7_and_ISO https://www.complang.tuwien.ac.at/ulrich/iso-prolog/SWI7_and... Scryer already provides an interface for attributed variables that is compatible to SICStus Prolog, one of the most sophisticated Prolog systems, and uses it to implement various constraints such as dif/2 (also rudimentarily available in Trealla, but not yet in Tau), Boolean constraints etc., which I hope become available in Tau, Trealla and other upcoming systems such as ichiban/prolog in due time.

billfruit 4y ago
Is ISO adherence a big deal? Because SWI seems quite mature and featurefull. The impression I got is that SWI is to Prolog, what GHC is to Haskell.
- triska 4y ago
  Adherence to standards matters a lot for example in several kinds of governmental organizations, banks, the medical industry etc. If you want to use a Prolog system in safety-critical areas, it is best, and often in fact required by internal and external guidelines, to choose vendors who are committed to upholding standards: This simplifies procurement, settling legal disputes and warranty questions, it reduces the risk of depending on a single vendor etc. Standards are also important when creating teaching material, and obviously for compatibility and interoperability between systems. I therefore recommend to use and provide Prolog systems with strong commitment to the Prolog ISO standard.
  - billfruit 4y ago
    Standards aren't that much of a constraint for SQL/databases, for example. Mostly one works with the dialect that is used by the specific implementation. Moreover standard hasn't kept pace with innovation by various vendors. So in the case of SQL more than de-jure standards, it is the generalized set of features that popular implementations support that matters. Isn't that the case with Prolog? So I'd be more interested in reasons other than literal adherence to de-jure standards.
    - triska 4y ago
      Regarding SQL, we find for example in the Oracle SQL documentation https://docs.oracle.com/database/121/SQLRF/intro002.htm#SQLRF50933 https://docs.oracle.com/database/121/SQLRF/intro002.htm#SQLR...: "Oracle strives to comply with industry-accepted standards and participates actively in SQL standards committees." and also https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Oracle-and-Standard-SQL.html#GUID-330DEBBB-006E-4B35-A516-5C0AEFFE06B9 https://docs.oracle.com/en/database/oracle/oracle-database/1...: "This appendix declares Oracle's conformance to the SQL standards established by the American National Standards Institute (ANSI) and the International Organization for Standardization (ISO)." A similar notion of intent and self-assessment is highly desirable in Prolog systems, for warranty reasons alone already. The Prolog standard defines the minimum (not the maximum) of features that must be present in conforming implementations: Prolog implementations are free to provide extensions to the standard, as in SQL implementations. However, to still comply with the standard, all such extensions must be conforming extensions, i.e., they cannot render existing conforming Prolog code invalid or differently interpreted than the standard demands. Also, it must be possible to run the system without all such extensions. For example, in Scryer Prolog, this is achieved by not loading any modules. Valid candidates for conforming extensions are for example Prolog programs that would yield a syntax error without that extension.
  - zephyrfalcon 4y ago
    All true, but you make it sound boring. :( I was under the impression that the ISO standard was (arguably) the "best" way to write a Prolog implementation, providing a flexible foundation to build future features on top of. Was I misinformed?
- tannhaeuser 4y ago
  It's a very big deal, especially if you're actually implementing commercial Prolog solutions rather than toy code for learning or academic papers. SWI is historically quite slow and SWI's model of explicit threading control and other choices tends to degenerate Prolog code for SWI into quasi-procedural, script-like execution. Also, while not Prolog proper, certain commercial Prolog engines do have much more powerful facilities for constraint logic programming over the reals which make them a preferred choice in eg (legacy) financial optimization models.
- Avshalom 4y ago
  Unfortunately the iso standard for prolog is kind of inadequate. It doesn't include a module system for instance. It also doesn't define the attributed variable interface which is fundamental to constraint logic programming. It's kind of a Scheme r5rs situation.
  - tannhaeuser 4y ago
    Well, there is ISO 13211-2 - Prolog part 2: modules [1], but it was flawed, ignored, and didn't help portability. There was also the Prolog Commons [2] initiative to identify common ground for basic libs. The importance of these features are judged differently depending on whether you're belonging to those who want to use Prolog in the large (with types and libs, LogTalk being an extreme example) vs those who want to embed Prolog into a host language and use it just for what Prolog really excels at. Having ported a non-trivial Prolog code base to ISO Prolog [3], I can say that lack of modules/libs wasn't the problem in that particular case (I really should come around and write up a more comprehensive tutorial for common problems in porting Yap- and SWI-specific code to ISO Prolog based on the material I have). [1]: https://www.iso.org/standard/20775.html https://www.iso.org/standard/20775.html [2]: https://prolog-commons.org/ https://prolog-commons.org/ [3]: https://quantumprolog.sgml.io/bioinformatics-demo/part1.html https://quantumprolog.sgml.io/bioinformatics-demo/part1.html

by triska 4y ago

billfruit 4y ago

Is ISO adherence a big deal? Because SWI seems quite mature and featurefull. The impression I got is that SWI is to Prolog, what GHC is to Haskell.

triska 4y ago
Adherence to standards matters a lot for example in several kinds of governmental organizations, banks, the medical industry etc. If you want to use a Prolog system in safety-critical areas, it is best, and often in fact required by internal and external guidelines, to choose vendors who are committed to upholding standards: This simplifies procurement, settling legal disputes and warranty questions, it reduces the risk of depending on a single vendor etc. Standards are also important when creating teaching material, and obviously for compatibility and interoperability between systems. I therefore recommend to use and provide Prolog systems with strong commitment to the Prolog ISO standard.
- billfruit 4y ago
  Standards aren't that much of a constraint for SQL/databases, for example. Mostly one works with the dialect that is used by the specific implementation. Moreover standard hasn't kept pace with innovation by various vendors. So in the case of SQL more than de-jure standards, it is the generalized set of features that popular implementations support that matters. Isn't that the case with Prolog? So I'd be more interested in reasons other than literal adherence to de-jure standards.
  - triska 4y ago
    Regarding SQL, we find for example in the Oracle SQL documentation https://docs.oracle.com/database/121/SQLRF/intro002.htm#SQLRF50933 https://docs.oracle.com/database/121/SQLRF/intro002.htm#SQLR...: "Oracle strives to comply with industry-accepted standards and participates actively in SQL standards committees." and also https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Oracle-and-Standard-SQL.html#GUID-330DEBBB-006E-4B35-A516-5C0AEFFE06B9 https://docs.oracle.com/en/database/oracle/oracle-database/1...: "This appendix declares Oracle's conformance to the SQL standards established by the American National Standards Institute (ANSI) and the International Organization for Standardization (ISO)." A similar notion of intent and self-assessment is highly desirable in Prolog systems, for warranty reasons alone already. The Prolog standard defines the minimum (not the maximum) of features that must be present in conforming implementations: Prolog implementations are free to provide extensions to the standard, as in SQL implementations. However, to still comply with the standard, all such extensions must be conforming extensions, i.e., they cannot render existing conforming Prolog code invalid or differently interpreted than the standard demands. Also, it must be possible to run the system without all such extensions. For example, in Scryer Prolog, this is achieved by not loading any modules. Valid candidates for conforming extensions are for example Prolog programs that would yield a syntax error without that extension.
- zephyrfalcon 4y ago
  All true, but you make it sound boring. :( I was under the impression that the ISO standard was (arguably) the "best" way to write a Prolog implementation, providing a flexible foundation to build future features on top of. Was I misinformed?
tannhaeuser 4y ago
It's a very big deal, especially if you're actually implementing commercial Prolog solutions rather than toy code for learning or academic papers. SWI is historically quite slow and SWI's model of explicit threading control and other choices tends to degenerate Prolog code for SWI into quasi-procedural, script-like execution. Also, while not Prolog proper, certain commercial Prolog engines do have much more powerful facilities for constraint logic programming over the reals which make them a preferred choice in eg (legacy) financial optimization models.
Avshalom 4y ago
Unfortunately the iso standard for prolog is kind of inadequate. It doesn't include a module system for instance. It also doesn't define the attributed variable interface which is fundamental to constraint logic programming. It's kind of a Scheme r5rs situation.
- tannhaeuser 4y ago
  Well, there is ISO 13211-2 - Prolog part 2: modules [1], but it was flawed, ignored, and didn't help portability. There was also the Prolog Commons [2] initiative to identify common ground for basic libs. The importance of these features are judged differently depending on whether you're belonging to those who want to use Prolog in the large (with types and libs, LogTalk being an extreme example) vs those who want to embed Prolog into a host language and use it just for what Prolog really excels at. Having ported a non-trivial Prolog code base to ISO Prolog [3], I can say that lack of modules/libs wasn't the problem in that particular case (I really should come around and write up a more comprehensive tutorial for common problems in porting Yap- and SWI-specific code to ISO Prolog based on the material I have). [1]: https://www.iso.org/standard/20775.html https://www.iso.org/standard/20775.html [2]: https://prolog-commons.org/ https://prolog-commons.org/ [3]: https://quantumprolog.sgml.io/bioinformatics-demo/part1.html https://quantumprolog.sgml.io/bioinformatics-demo/part1.html