1. Forum
  2. Usenet
  3. COMP.LANG.PROLOG

  • Is there room to adopt a flag strict_iso?

    From Mild Shock@21:1/5 to All on Tue Jun 24 18:00:28 2025
    **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..

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mild Shock@21:1/5 to Mild Shock on Tue Jun 24 18:06:13 2025
    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..

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)