Proposal: A better approach for SYNONYM wording
This page is dedicated to discussing this specific proposal
ruv
[309] A better approach for SYNONYM wordingProposal2023-09-22 17:06:27
Rationale
Instead of mentioning SYNONYM in many other glossary entries, it's better to use another wording, which does not require that.
In some cases, it's better to specify a glossary entry in a more general manner, than mention SYNONYM in it (see the proposal below).
According to 2.2.3 Parsed-text notation, "name" has the specified meaning when it's mentioned literally as "name" only. So, newname and oldname are not normative. Probably, we can use indexing as for data type symbols in stack diagrams. When an index not a number, it is concatenated via a dot.
We should ensure that system-defined semantics are the same for synonyms.
If the standard defines some semantics, system-defined semantics shall be equivalent to them, so it's enough to mention system-defined semantics.
In some plausible Forth system implementations the execution token for a word
is identical to the name token for this word,
and the execution tokens for the different words are always different. So
SYNONYM should not require the same execution token (if any) for name.new and name.old.
The part about deferred words is not enough formal.
Examples
A synonym of the word CREATE creates a word with the data field address due to the same execution semantics as of CREATE:
synonym mycreate create
mycreate foo 123 ,
A synonym of a word created via performing the execution semantics of CREATE returns the same data field address due to the same execution semantics as the original word:
synonym bar foo
bar foo = . \ prints -1
Consequently, the execution token for a synonym is associated with the same data field address (if any) as the xt of the original word:
' bar >body ' foo >body = . \ prints -1
A synonym of a word created via performing the execution semantics of VALUE returns the same value due to the same execution semantics as the original word:
1 value x
synonym y x
x y = . \ prints -1
Applying TO to a synonym of a word created via performing the execution semantics of VALUE changes the value assigned to the original word due to the same TO name Run-time semantics:
2 to y
x y = . \ prints -1
Proposal (draft)
Re data-field address
In
6.1.0550 >BODY,
6.1.1250 DOES>,
Replace the phrase:
defined via
CREATE
by the phrase:
defined via performing
CREATEexecution semantics
Replace the phrase:
defined with
CREATEor a user-defined word that callsCREATE.
by the phrase:
defined via performing
CREATEexecution semantics
Re deferred words
In
6.2.1725 IS,
6.2.0698 ACTION-OF,
6.2.1177 DEFER@,
6.2.1175 DEFER!,
Replace the phrase:
defined by
DEFER
by the phrase:
defined via performing
DEFERexecution semantics
Re SYNONYM
Replace the whole normative part of the glossary entry 15.6.2.2264 SYNONYM by the following paragraphs:
( "<spaces>name.new" "<spaces>name.old" -- )
Skip leading space delimiters, parse name.new delimited by a space, skip leading space delimiters, parse name.old delimited by a space.
Find name.old. Create a definition for name.new with the semantics defined below; name.new may be the same as name.old.
The execution token for name.new may differ from the execution token for name.old.
An ambiguous condition exists if name.old is not found or IMMEDIATE is performed when name.new is the most recent definition.
All the ambiguous conditions that exist when using name.old, also exist when using name.new.
If execution semantics are defined by the system for name.old:
name.new Execution: Perform the execution semantics of name.old.
If interpretation semantics are defined by the system for name.old:
name.new Interpretation: Perform the interpretation semantics for name.old.
If compilation semantics are defined by the system for name.old:
name.new Compilation: Perform the compilation semantics for name.old.
If "TO name.old Run-time" semantics are defined for name.old:
TO name.new Run-time: Perform TO name.old Run-time semantics.
If name.old are defined via performing the execution semantics of DEFER:
IS name.new
performs IS name.old
ACTION-OF name.new
performs ACTION-OF name.old
Applying DEFER@ to the xt of name.new
performs DEFER@ to the xt of name.old
Applying DEFER! to the xt of name.new
performs DEFER! to the xt of name.old
ruv
Probably, creating a synonym should not be allowed for a local variable (if it's too difficult to implement in some systems). Then, the corresponding ambiguous condition should be declared:
An ambiguous condition exists if name.old is a local variable.
ruvNew Version: A better approach for SYNONYM wording
Change Log
- 2020-09-23 Initial version
- 2020-09-23 Factor out Problem section, add a clause re the same data-field address, better wording, better formatting, fix typos
Problem
Some additional problems
According to 2.2.3 Parsed-text notation, "name" has the specified meaning when it's mentioned literally as "name" only. So, newname and oldname are not normative.
- We can use indexing as for data type symbols in stack diagrams, and when an index not a number, it can be concatenated via a dot.
The phrase "For both strings skip leading space delimiters" is unsound, since the operation to "skip leading space delimiters" is not defined for strings, but for the input buffer only (see 3.4.1.1 Delimiters).
Rationale
Instead of mentioning SYNONYM in many other glossary entries, it's better to use another wording, which does not require that.
In some cases, it's better to specify a glossary entry in a more general manner, than mention SYNONYM in it (see the proposal below).
In some cases, it's better to specify a glossary entry in a more general way, rather than mentioning SYNONYM in it (see the proposal below).
According to 2.2.3 Parsed-text notation, "name" has the specified meaning when it's mentioned literally as "name" only. So, newname and oldname are not normative. Probably, we can use indexing as for data type symbols in stack diagrams. When an index not a number, it is concatenated via a dot.
If the standard does not define some semantics, we should ensure that system-defined semantics are the same for synonyms.
We should ensure that system-defined semantics are the same for synonyms.
If the standard defines some semantics, system-defined semantics shall be equivalent to them, so it's enough to mention system-defined semantics.
In some plausible Forth system implementations the execution token for a word
is identical to the name token for this word,
and the execution tokens for the different words are always different. So
SYNONYM should not require the same execution token (if any) for name.new and name.old.
The part about deferred words is not enough formal.
The part about deferred words doesn't seem formal enough.
Examples
A synonym of the word CREATE creates a word with the data field address due to the same execution semantics as of CREATE:
synonym mycreate create
mycreate foo 123 ,
A synonym of a word created via performing the execution semantics of CREATE returns the same data field address due to the same execution semantics as the original word:
A synonym of a word, which is created via performing the execution semantics of CREATE, returns the same data field address due to the same execution semantics as the original word:
synonym bar foo
bar foo = . \ prints -1
Consequently, the execution token for a synonym is associated with the same data field address (if any) as the xt of the original word:
' bar >body ' foo >body = . \ prints -1
It is also true for a synonym of a synonym:
synonym baz bar
' baz >body ' bar >body = . \ prints -1
A synonym of a word created via performing the execution semantics of VALUE returns the same value due to the same execution semantics as the original word:
1 value x
synonym y x
x y = . \ prints -1
Applying TO to a synonym of a word created via performing the execution semantics of VALUE changes the value assigned to the original word due to the same TO name Run-time semantics:
Applying TO to a synonym of a word, which is created via performing the execution semantics of VALUE, changes the value assigned to the original word due to the same "TO name Run-time" semantics:
2 to y
x y = . \ prints -1
Proposal (draft)
Re data-field address
In
6.1.0550 >BODY,
6.1.1250 DOES>,
Replace the phrase:
defined via
CREATE
by the phrase:
with the phrase:
defined via performing
CREATEexecution semantics
Replace the phrase:
defined with
CREATEor a user-defined word that callsCREATE.
by the phrase:
with the phrase:
defined via performing
CREATEexecution semantics
Re deferred words
In
6.2.1725 IS,
6.2.0698 ACTION-OF,
6.2.1177 DEFER@,
6.2.1175 DEFER!,
Replace the phrase:
defined by
DEFER
by the phrase:
with the phrase:
defined via performing
DEFERexecution semantics
Re SYNONYM
Replace the whole normative part of the glossary entry 15.6.2.2264 SYNONYM by the following paragraphs:
( "<spaces>name.new" "<spaces>name.old" -- )
Skip leading space delimiters, parse name.new delimited by a space, skip leading space delimiters, parse name.old delimited by a space.
Find name.old.
Create a definition for name.new with the semantics defined below; name.new may be the same as name.old.
Create a definition for name.new with the semantics defined below.
The execution token for name.new may differ from the execution token for name.old.
name.new and name.old may be identical. The execution token for name.new may differ from the execution token for name.old.
An ambiguous condition exists if name.old is not found or IMMEDIATE is performed when name.new is the most recent definition.
An ambiguous condition exists in any of the following conditions:
- name.old is not found;
- name.old is for a local variable;
IMMEDIATEis performed when the definition for name.new is the most recent definition.
All the ambiguous conditions that exist when using name.old, also exist when using name.new.
If execution semantics are defined by the system for name.old:
name.new Execution: Perform the execution semantics of name.old.
If interpretation semantics are defined by the system for name.old:
name.new Interpretation: Perform the interpretation semantics for name.old.
If compilation semantics are defined by the system for name.old:
name.new Compilation: Perform the compilation semantics for name.old.
If "TO name.old Run-time" semantics are defined for name.old:
If "TO name.old Run-time" semantics are defined by the system for name.old:
TO name.new Run-time:
Perform TO name.old Run-time semantics.
Perform "TO name.old Run-time" semantics.
If name.old are defined via performing the execution semantics of DEFER:
If the data-field address is associated by the system with the xt for for name.old:
The data-field address associated with the xt for name.new is the same as the data-field address associated with the xt for name.old.
IS name.new
performs IS name.old
ACTION-OF name.new
performs ACTION-OF name.old
Applying DEFER@ to the xt of name.new
performs DEFER@ to the xt of name.old
Applying DEFER! to the xt of name.new
performs DEFER! to the xt of name.old
If name.old is defined via performing the execution semantics of DEFER, or is a synonym of such a word:
- "IS name.new": perform "IS name.old"
- "ACTION-OF name.new": perform "ACTION-OF name.old"
- Applying
DEFER@to the xt of name.new: performDEFER@to the xt of name.old - Applying
DEFER!to the xt of name.new: performDEFER!to the xt of name.old
BerndPaysan
With the catch-all phrase for ambiguous conditions of name.old and name.new being identical, you can drop all those child from executing one or another defining word: TO/IS/ACTION-OF name.new, etc. are identical to the same construct with name.old. That way, these combinations have to work even for non-standard extensions, like Gforth's, where you can define your own TO/IS semantics with SET-TO, regardless of the original definer.