Is there room to adopt a flag strict_iso?

General discussions on Prolog
1

Interestingly a flag strict_iso could solve a few
vexing problems. For example the ISO core standard
did only mention floor/1 with signature F → I.

So in GNU Prolog I can do:

/* GNU Prolog 1.5.0 */

?- current_prolog_flag(strict_iso, X).
X = on
yes

?- X is floor(1).
uncaught exception: error(type_error(float,1),(is)/2)

?- set_prolog_flag(strict_iso, off).
yes

?- X is floor(1).
X = 1
yes

A few Prolog systems don’t share the above behavior,
like SWI-Prolog for example doesn’t throw the type error.
Also SWI-Prolog has nowhere a flag strict_iso.

The GNU Prolog definition is:

424140364-41ea98de-a57a-4884-9f41-a146e0d6a8fc
424140364-41ea98de-a57a-4884-9f41-a146e0d6a8fc605×231 26.9 KB

http://www.gprolog.org/manual/html_node/gprolog046.html#set-prolog-flag%2F2

2

I think it would be a good idea to agree on a common way to establish ISO strictness. It is a feature that is asked for in the standard and it would make sense if we can find a common way to do it. Ciao and Eclipse (and maybe others) use modules (a package in case of Ciao) such as iso_strict, classic, etc. to allow activating ISO strict compatibility on a per-module basis. A Prolog flag could also work, depending on flag scope (see, e.g., [1]), e.g., in Ciao flags are generally local to modules, but in other systems they are global and this may not be what we want, or at least not in all cases?

[1] D. Cabeza, M.V. Hermenegildo. A New Module System for Prolog. International Conference on Computational Logic, CL2000, LNAI, Num. 1861, pages 131-148, Springer-Verlag, July 2000.

4

As motivated in Is there room to adopt a flag strict_iso? - #2 by jan - General - SWI-Prolog, I’m not interested in this. The SWI-Prolog iso flag is not really usable as it breaks a lot of the libaries. A strict_iso would be even worse. I’m happy to add this flag as a read-only flag that claims false of course :slight_smile:

A module-local flag is also a cumbersome solution as it may make calling built-ins in that module iso compliant, but that does not stop affecting the behaviour of libraries. For example, max_member/2 gets the max of a list in the standard order of terms, but SWI-Prolog’s standard order is not ISO compatible. You’d have to make ISO and non-ISO versions of all built-ins affected by this as well as libraries that are affected by this. Well, ISO has no libraries :frowning:

This all gets hopelessly complicated and solves only a tiny part of the portability puzzle. And believe me, I’ve done quite a bit of porting.

6

Sorry for the late response. There seems to be some confusion about ISO compliance and the meaning of ISO strict mode. I’ll try to give my best understanding of what the standard says, and then make some suggestions.

What does ISO-Prolog compliance mean?

Any Prolog vendor/promoter can make (and is thus responsible for) a claim of ISO-Prolog compliance. No institution or person is authorised to certify ISO-Prolog compliance. The letter of the standard is the only normative reference, there are no authoritative further interpretations.

The requirements for ISO-Prolog compliance are listed in ISO/IEC 13211-1, section 5. They include requirements for the behaviour of a Prolog processor, and for its accompanying documentation(!).

What flexibility does a Prolog system have?

It is worth noting that the standard does not speak of Prolog systems, but only of Prolog processors. Any actual Prolog system contains much that is not covered by the standard (such as command line options, a compiler, a toplevel interpreter, a debugger, etc). This suggests that a single Prolog system can well contain both ISO-conforming and non-conforming Prolog processors, as long as the documentation explains how to operate the conforming processor(s).

A conforming processor

  • must implement all the explicit requirements of the standard
  • can implement and document additional implementation specific features, for example
    • additional built-ins
    • additional flags
    • additional syntax or behaviours in cases that are left undefined by the standard

A processor is non-conforming if it implements features that conflict with the requirements of the standard.

What is strict mode (and what is it good for)?

The provision of a “strictly conforming mode” is one of the requirements (5.1.e) for compliance – it is not optional! Its definition is

“A conforming Prolog processor shall … offer a strictly conforming mode which shall reject the use of an implementation specific feature in Prolog text or while executing a goal.”

In other words, strict mode means “just the ISO-defined features and nothing else”, i.e.

  • no non-standard built-ins
  • no non-standard flags
  • no syntax extensions
  • no non-standard behaviours

Obviously, this is not a practical basis for writing applications, but it can be a useful tool for analysing the portability of a Prolog program: if something works in strict mode, then, by virtue of using only ISO-defined features, it is guaranteed to be portable to other compliant Prologs.

What is strict mode not?

Some of the earlier postings (and also some Prolog implementations) seem to use the word “strict” when they just mean “fully ISO-conforming”, and “not strict” when they mean “allowing for some non-conformity”. This isn’t how the standard uses the word. When you violate an ISO requirement, you are non-conforming, not just non-strict.

As I understand things, that leaves us with 3 flavours of Prolog processors:

Status ISO-defined features Non-ISO features
not ISO-conforming may be completely unsupported or not fulfilling ISO requirements may conflict with ISO requirements
ISO-conforming fully implemented as specified by the standard documented as implementation-specific, must not conflict with ISO requirements
ISO-conforming, strict mode fully implemented as specified by the standard none

How to access strict mode?

The standard does not specify how to enable strict mode. Some possible solutions are

An environment setting or command line option for the whole system: Can be used to test standard conformity of the system or portability of application code. Otherwise of little use, because of strict mode’s limitations.

A prolog flag or a built-in for switching to strict mode: While this seems to be the most straightforward solution, it has a few drawbacks. Strict mode is extremely limited, so the mode should probably not have global scope. Also, because extra flags or built-ins are themselves a non-strict feature, the method cannot be used to switch strict mode off. This might not be a problem if the mode has only module-wide scope (see next point).

Mark individual modules as strict: This seems to be the cleanest approach, but requires a strong module system that can achieve the necessary isolation. It is the approach taken by Ciao and ECLiPSe (fortunately in a compatible way!) by employing “language modules/packages” and a module/3 directive [ECL, Ciao] to import them. For example

:- module(greeting, [hello/0], iso_strict).  % Following code uses strict ISO Prolog
hello :- write(hello), nl.

This solution obviously works for many kinds of language dialects, whether ISO-conforming or not.

In the case of ECLiPSe, because we wanted to provide a number of extensions that are in conflict with ISO requirements, we ended up needing these 3 “language modules”, corresponding to the 3 conformity flavours in the table above:

  • eclipse_language provides all extensions, and is not ISO-conforming for various reasons (e.g. double-quoted strings, floor/1 and friends returning their argument type rather than integer, various syntax extensions, etc).
  • iso is ISO-conforming, providing only those ECLiPSe features that do not conflict with ISO
  • iso_strict is ISO-conforming strict mode, providing only ISO features and no implementation specific ones

I would expect most systems to be in a similar situation.