Digest #213 2023-02-20
Contributions
Bracket-id prefixed for all contribution subjects for easier communication [\<id\>] \<subject\> (was just used for proposals before).
Search supports finding contributions, just put brackets around the desired id. Search for [140] will jump you to the overhaul-contribution of 2020.
To further simplify referring to contributions, one can use the /jump-to/\<id\> link (this is also used by the search). https://forth-standard.org/jump-to/140 will also take you search result from above.
Replies
A data type identifies the set of permissible values for a data object. (1)
It seems to imply that the same data object may have different values. Then it means that a data object also identifies the set (namely, the set of its values). And then the set identified by a data type is a subset of the set identified by a data object.
I'm not sure what you meant by the last sentence here, but I would interpret (1) as, "A data type identifies the set of permissible values for an object of that type"; that is, a data object of a given type must have a value within that type's set/range of permissible values. For Standard Forth, in general, a type is not really a property of an object/value, but rather of how that value is handled. A double-cell integer, for example, is treated as "an object" despite consisting of two separate stack items.
Moving a data object shall not affect its type. (2)
But this makes an impression that a data object is an element of the set identified by a data type.
A data type "identifies" two distinct sets. On the one hand, its definition in the Standard or in a concrete implementation declares its set of permissible values. On the other, its existence implies the set of data objects which are its members. You can't conflate the two (even though there may be a one-to-one correspondence between them) because the same value can be represented in two incompatible ways, and thus belong to two disjoint types. (By "disjoint" I mean that they have no members/instances in common.)
Take double-cell integers again. Assuming that a system provides the Double-Number word set, 127 and 127. are two different, incompatible objects, despite having the same numerical value.
Granted, I also find (2) confusing. In my case, it's because it implies that objects somehow "know" their type. It further implies that an object has/belongs to exactly one type. Both of those might be true for the system types that may or may not have a tangible representation, and they probably are true for floating-point numbers if a system provides the Floating-Point word set, but they're both explicitly false for ordinary one-cell and two-cell data types.
Then a better wording for (1) would be: A data type identifies the set of data objects.
This proposed wording is definitely missing information that the original version conveys; it also uses the wrong kind of article for "set", resulting in the absurd proposition that any data type identifies the set of all data objects. I'm sure you meant "a data type identifies a set of data objects", but that's kind of self-evident.
If I had to propose a new wording for (1), I'd go with: A data type defines the set of permissible values for objects of that type.
I think some of the confusion actually comes from the term "data object" itself. I understand why it's used; it's important to be able to draw a distinction between abstract values and the data structures that represent those values. But for those of us who began programming with high-level object-oriented languages, seeing cells and cell-pairs being called "objects" is pretty alien.
requestClarification - The specification of CATCH
Just to make sure that I understand correctly:
In GerryJackson's example, it looks like CATCH returns to a strange place because ' is a parsing word. CATCH is thus "infixed" between the xt it executes and the text that the xt parses; CATCH transfers control back to the interpreter without restoring the parse area to its original state because that's not a reasonable thing to require. Given the following definitions:
: cstr' ( c-addr -- xt )
FIND 0= IF DROP -13 THROW THEN ;
: foo-str ( -- c-addr ) C" foo" ; /The standard doesn't require C" to be interpretable
then foo-str cstr' is equivalent to ' foo, except that it doesn't parse (and is guaranteed, rather than generally agreed, to throw). We can thus replace ' ' CATCH foo in GerryJackson's example with foo-str ' cstr' CATCH to illustrate that control is indeed transferred to the point immediately after CATCH.
Have I got all that right?
requestClarification - 3.4.5 conflicts with [: … ;]
By my understanding, the resolution to this apparent conflict is that quotations aren't part of the Forth-2012 standard, which this document represents.
It also feels like there should be some mention of an ambiguous condition if n<0.
This part is already made clear in the stack effect: the symbol +n means "non-negative number". Giving any word a value of an inappropriate type always results in an ambiguous condition, so I don't think it needs to be re-stated in the prose. (It would probably be wise for standard systems to declare how they handle this particular case, but standard programs will respect the type constraints of the standard.)