mthom
WIP: add de facto standard dialect and version_data read-only flags
Reason for the WIP mark: Is there a way to set the version_data flag definition from the version data in the Cargo.toml?
Not without an ugly kludge, no; cargo is very limited in this way.
I'm hesitant to approve this pull request for a few reasons. The first is that, as you observe, there's no good way to synchronize version information between builtins.pl and Cargo.toml. The second is that strict ISO conformance means that the code in builtins.pl should be portable across all ISO-compliant implementations (on that note, I will eventually move the forall/2 predicate into a different module). I don't think the version_data flag exists as part of the ISO standard, but that's not to say it couldn't exist in some other form.
@UWN cited part of the ISO standard that talks about offering a strict conforming mode, and ushering the non-conformant parts into a separate library (by the sound of it). I'll have a look at it later today when I get home from work.
These two flags originated from the Prolog Commons work and were specified in the last ISO Prolog Core revision proposal where I served as editor back in 2009 (http://logtalk.org/plstd/core.pdf). By that time, these flags were already implemented by most Prolog systems, hence their inclusion in the proposal. But these flags were left out in the final approved corrigenda. Same for the forall/2 predicate. Moving de facto standard predicates such as forall/2 to a separate library or module works. But that becomes trickier/cumbersome for de facto standard flags and arithmetic functions.
Many of these features were rejected in 2009 Pasadena and 2010 Edinburgh. And thus were not included in neither Cor.2:2012 nor Cor.3:2017.
In any case, don´t get sucked up by such petty items, Instead there are much more important things than this.
Many of these features were rejected in 2009 Pasadena and 2010 Edinburgh. And thus were not included in neither Cor.2:2012 nor Cor.3:2017.
With the exception of the call/N specification, the document linked above reflects the decisions in the 2009 Pasadena meeting. I know. I was there. I was the official editor of the Core revision proposal at that time.
In any case, don´t get sucked up by such petty items, Instead there are much more important things than this.
There are not petty items. They are simple features, trivial to implement, that facilitate writing of portable code by allowing an application to query which system and which system version it is running on and act accordingly.
Once the discontiguous directive is implemented, it should be possible to add the additional flags outside of builtins.
They are simple features, trivial to implement, that facilitate writing of portable code by allowing an application to query which system and which system version it is running on and act accordingly.
Other effects include: For Prolog application programmers, to unnecessarily increase the tendency to think in terms of systems and versions instead of supported features. For new Prolog systems, to then also require adaptations in existing application code, even though they may support all necessary features to run the code. Further, it counterproductively removes pressure from implementors to implement common and standard functionality, because it shifts the pressure from a few system implementors to many more application programmers.
An example of the detrimental effects of such a flag can be seen in https://github.com/mthom/scryer-prolog/issues/583#issuecomment-660266675: Having heard of such a flag, application programmers now ask for the flag instead of standard functionality that should be implemented instead.
Regarding the topic of politics that was brought up in https://github.com/mthom/scryer-prolog/issues/511#issuecomment-660223670 about this flag, I would like to note that even though some may benefit from a fragmentation of Prolog systems into different systems and versions, many application programmers do not, and personally, I would strongly prefer flags that let me test for features instead of specific systems. A good example to test for functionality is the ISO flag bounded to test whether unbounded integers are available. This works reliably in all existing and future conforming systems, and is therefore a general and in my view preferable way to solve portability issues.
Standardization is first and foremost about finding common ground and formalizing it. The two flags in this proposal are universal and have been for a very long time. But more than four years passed since this merge request was created and no progress have been made. No point in keeping it open.