From Newsgroup: comp.lang.prolog

**iso_strict** is ISO-conforming strict mode, providing
only ISO features and no implementation specific ones

Maybe a good name would then be "use_strict", instead
of "strict_iso", if a permutation of it is already
used in the form "iso_strict" by ECLiPSe Prolog.
"use_strict" would be motivated from JavaScript:

JavaScript's strict mode is a way to *opt in* to a

restricted variant of JavaScript, thereby implicitly
opting-out of "sloppy mode". Strict mode isn't just a subset:
it *intentionally* has different semantics from normal
code. Strict mode code and non-strict mode code can
coexist, so scripts can opt into strict mode incrementally.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode

In JavaScript the mode is local. You can place the
"use_strict" directive inside any function you want, and
opt in to this function and all sub functions.
So "use_strict=on" would mean ISO conforming.

This would solve the problem that some Prolog systems
have an "iso" flag, but setting it to true does not
imply they become 100% ISO conforming. It rather tells
the system to have the behaviour of some

predicates change to ISO conforming. So the "use_strict"
would be a conformity flag, and not a scope flag. It
would not reduce the scope of a Prolog system or a
Prolog modul to use less built-ins, flags etc..
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog


So it would only change the conformity of those built-ins,
flags etc.. mentioned in the ISO core standard. But
otherwise it would be open to extensions. Its a
missing row in @jschimpf table:

Mode Description Origin
eclipse_language ISO heavily violating and implementation specific ECL
iso ISO conforming and implementation specific ECL
iso_strict ISO conforming and no implementation specific ECL
~use_strict ISO sloppy conforming, combineable with iso / iso_strict DOG

Here is a hypothetical scenario in ECLiPSe Prolog
if it had this flag:

[eclipse 1]: X is floor(1).
type error: expected float, found 1 in floor(1, X)
Abort

[eclipse 2]: set_prolog_flag(use_strict, off).
Yes (0.00s cpu)

[eclipse 1]: X is floor(1).
X = 1
Yes (0.00s cpu)

In JavaScript type=“module” the system starts with
use_strict opted in. Only JavaScript without type=“module”,
for example the extension .js and not the extension .mjs,
start with use_strict off, and can opt in.

Typically a JavaScript top-level such as the
Chrome console, starts with use_strict off.

Mild Shock schrieb:

**iso_strict** is ISO-conforming strict mode, providing
only ISO features and no implementation specific ones

Maybe a good name would then be "use_strict", instead
of "strict_iso", if a permutation of it is already
used in the form "iso_strict" by ECLiPSe Prolog.
"use_strict" would be motivated from JavaScript:

JavaScript's strict mode is a way to *opt in* to a

restricted variant of JavaScript, thereby implicitly
opting-out of "sloppy mode". Strict mode isn't just a subset:
it *intentionally* has different semantics from normal
code. Strict mode code and non-strict mode code can
coexist, so scripts can opt into strict mode incrementally.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode

In JavaScript the mode is local. You can place the
"use_strict" directive inside any function you want, and
opt in to this function and all sub functions.
So "use_strict=on" would mean ISO conforming.

This would solve the problem that some Prolog systems
have an "iso" flag, but setting it to true does not
imply they become 100% ISO conforming. It rather tells
the system to have the behaviour of some

predicates change to ISO conforming. So the "use_strict"
would be a conformity flag, and not a scope flag. It
would not reduce the scope of a Prolog system or a
Prolog modul to use less built-ins, flags etc..

--- Synchronet 3.21a-Linux NewsLink 1.2