Digest #219 2023-03-12
Contributions
referenceImplementation - Possible Reference Implementation
Maybe this?:
: constant
>r : r>
postpone literal
postpone ;
;
Replies
Add the word
DEFINE ( xt c-addr u -- )
Sure, such a word should be standardized — many systems have it under names like aka, alias, naming, enroll-name, etc.
as a deferred word
A deferred word is a bad choice for an API, since a deferred word cannot be redefined, since the system's words to, action-of, defer@, defer! are not applicable to the redefined word. Therefore, a separate getter and setter should be used in APIs.
the system's own wordlist mechanic can be leveraged to provide the user with arbitrary named storage capability, storing user data as xt.
Why not to expose such a mechanic under its own general API, which is not connected to execution tokens and immediacy? It can be even implemented as a portable library.
We might also want a
DELETE-WORDLIST ( wid -- ), to clean up later.
I think, this functionality cannot be implemented in most systems. In some cases marker can be used instead.
@AidanPitt-Brooke, thank you for your effort in this convoluted topic.
As I understand, "data object" is a primitive notion in the standard (as well as a similar notion "set of information"). It's not an object in OOP sense. A data object is a sequence of bits, from which you can infer neither its length nor its data type in the general case (i.e., it does not know its type).
The standard considers only data objects that can be placed on some stack (among the data stack, control-flow stack, floating-point stack, return stack, exception stack). It means that any data object (which is available for a program) can be represented as a tuple of the stack items, on which this data object is placed. NB: in some cases the length of a tuple is unknown for a program, and this length can be even zero (e.g. for nest-sys on the return stack).
Of course, actual implementations might operate on compound data objects in memory, but these data objects are usually unavailable for a program, and formally (in the standard) they are represented by other data objects — opaque identifiers (which are tuples). For example, an identifier of execution semantics, word list identifier, file identifier, result of save-input ( i*x u.i ). NB: obviously, some data objects don't have a numeric interpretation at all — formally, they are not numbers (in algebraic sense).
"An ambiguous condition exists if an incorrectly typed data object is encountered" — what a word, during execution, consumes from a stack or produces on the stack are just data objects only.
Then, what does the term "value" mean in this context? As I can see, it is either a synonym for "data object", or an interpretation of a data object as a number (a numeric value).
Anyway, it's unclear what does "a set of permissible values for a data object" mean? What different values can a single concrete data object have?
Author
Ruv
Change Log
- 2023-03-07 Better wordings in several places, correction some typos
- 2023-03-06 Initial version
Problem
In the draft 2020-01, the section A.17.6.1.2212 SLITERAL conflicts with the section 6.1.2165 S".
In 2017 it was decided to merge the words FILE S" and S\" into the corresponding words in CORE/CORE-EXT (see the minutes 2017 and preceding discussion "Core-ext S\" should reference File-ext S\""). It was implemented in the draft 2020-01.
However, the section A.17.6.1.2212 has not been updated, and it shows an implementation for the version of CORE S" before 2017, which leads to confusions (it was noticed by Anthony Howe in "Confusion over S" and SLITERAL").
Solution
Update the section A.17.6.1.2212 according to the new 6.1.2165. Take into account A.6.1.0190 .".
Proposal
Replace the content of the section A.17.6.1.2212 SLITERAL by the following:
The current functionality of 6.1.2165
S"may be provided by the following definition:: S" ( "ccc\<quote\>" -- c-addr u | ) [CHAR] " PARSE STATE @ IF POSTPONE SLITERAL THEN ; IMMEDIATEDepending on the Forth system implementation, this definition can lead to the following environmental restrictions:
- the lifetime of the string returned by the interpretation semantics for
S"is only valid until the input buffer has been refilled or the input source is not the same;- the compilation semantics for
S"that are appended by applyingPOSTPONEtoS"cannot be performed if the system in interpretation state (due to a possible restriction ofPOSTPONE).
In the section 6.1.2165 S", add into the last paragraph, which starts with "See:", at the end before the dot:
, A.17.6.1.2212
SLITERAL
The phrase "the input source is changed" is slightly ambiguous, since it can mean:
- "the state of the input source is changed";
- "the identity of the input source is changed" (i.e., another source is used as the input source, with its own state).
The phrase "the input source is not the same" (which is used in A.6.2.2182 SAVE-INPUT) means that identity of the input source is changed.
Therefore, in the version 2023-03-07 the form "is not the same" is used, instead of "is changed".
proposal - Relax documentation requirements of Ambiguous Conditions
By the way, the introduction of Chapter 4 already allows to not specify a particular behavior in an ambiguous condition case, but it still requires to explain reasons.
The section 3.4.1 Parsing says: "Parsing may change the contents of >IN, but shall not affect the contents of the input buffer". It means, CHAR, doing parsing, shall not refill the input buffer.
On the other hand, 4.1.2 Ambiguous conditions says that an ambiguous condition can occur due to "unexpected end of input buffer, resulting in an attempt to use a zero-length string as a name". NB: "name" is not necessary a word name. It's a special parsed text abbreviation, which means "a token delimited by space" (actually a lexeme).
Due to this ambiguous condition, CHAR may do anything if name is empty string, including refilling the input buffer. Probably a good choice is just to throw an exception.