Digest #204 2023-01-13
Contributions
A possible implementation:
: . dup abs 0 <# #s rot sign #> type space ;
Replies
proposal - Relax documentation requirements of Ambiguous Conditions
"Documenting all ambiguous conditions of a system can be burdensome for system implementers, while providing relatively little value to end-users."
As an end user, I want the documentation for all ambiguous conditions. I don't want to have to discover them while creating an application, then go to a support site, or, worse yet, have to read the source, for which I may not even have a license!
My guess is that this section was added due to the options and ambiguous conditions in the standard, so how do you differentiate between a minimal and a maximal system? In theory, a user compares the program documentation with the system documentation to find out if the program runs on the system. In practice, nobody does that, and people just try out if the program runs on the system. And if it does not, users use debugging techniques to find out why rather than consulting the documentation. At least that's how I do it, and I have never heard about people who do it differently.
Looking at the VFX documentation, I don't find the standard-required system documentation in it. Maybe it exists somewhere, but the fact that it is not easy to find indicates that it is not really needed (and if it does not exist, that's an even stronger indication).
One alternative would be to provide a way to supply the information in a way that a program can extract (and compare what the system provides with what the program requires. However, the environmental queries that have been a first step in that direction have been mostly implemented in the most useless way possible by a number of Forth systems, and programs have not made much use of them, so that approach is apparently not really attractive, either. So in Forth-2012 we decided to not introduce queries for the Forth-2012 variants of the wordsets and leave the existing ones as relating to the Forth-94 versions of the wordset.
An alternative theory is that the ENVIRONMENT? interface is just too cumbersome to be successful, but if there was really a big need for this kind of stuff, people would have jumped through that hoop.
Right... ENVIRONMENT? is a related topic indeed.
From my experience as software engineer, I know of two practical ways to make code portable between systems:
- avoid ambiguous behavior whenever possible.
- create a platform abstraction layer, that separates platform differences from the business logic.
As I see it, ENVIRONMENT? and section 4.1.2 do not really help towards either of those goals.
proposal - Relax documentation requirements of Ambiguous Conditions
znmeb, thank you for your feedback. Out of curiosity, could you give some example documentation of ambiguous conditions that you like to use?
proposal - Relax documentation requirements of Ambiguous Conditions
znmeb writes:
As an end user, I want the documentation for all ambiguous conditions.
Do you think that less systems will provide this documentation if this documentation will no longer be required (but only recommended) for a standard system?
znmeb writes:
I don't want to have to discover them while creating an application
Just take into account that if your application relies on some specific behavior in an ambiguous condition, then your application has an environmental dependency.
See Chapter 3: "A program that requires a system to provide words or techniques not defined in this standard has an environmental dependency". So, if a program requires a system to have some specific capability beyond minimal, or behavior, which is not defined by the standard, then this program has an environmental dependency.
A standard program without environmental dependencies does not need to know what is the system behavior in any ambiguous condition.
OTOH, to choose a system for use in production you probably need to know what is the system behavior in certain cases. For example, how to handle a case of "addressing a region not listed in 3.3.3 Data space" (including a case when the address is not mapped to physical memory at all).
If a system does not provide the documentation for a specific behavior or feature that a program requires, then this system just does not formally meet the environmental dependencies of the program. Why should it make the system non standard?
A possible implementation:
: . dup abs 0 <# #s rot sign #> type space ;