Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.prolog > #14594
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Newsgroups | comp.lang.prolog |
| Subject | Example usage of new flag use_strict [DOG] (Was: Is there room to adopt a flag strict_iso?) |
| Date | 2025-06-24 18:06 +0200 |
| Message-ID | <103eidk$18c8n$1@solani.org> (permalink) |
| References | <103ei2s$18c05$1@solani.org> |
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..
Back to comp.lang.prolog | Previous | Next — Previous in thread | Find similar | Unroll thread
Is there room to adopt a flag strict_iso? Mild Shock <janburse@fastmail.fm> - 2025-06-24 18:00 +0200 Example usage of new flag use_strict [DOG] (Was: Is there room to adopt a flag strict_iso?) Mild Shock <janburse@fastmail.fm> - 2025-06-24 18:06 +0200
csiph-web