On 2022-10-03 21:52Z, Krishna Myneni wrote:
NAME>COMPILE should always return the compilation xt, which can be
independently set on a dual token system, or on a single token system
which supports "non-default compilation semantics".
In contrast, ticking a word on a standard system will return an
execution token corresponding to its interpretation semantics.
It sounds incorrectly. By this wording you revoke access to the
identifier of the execution semantics for a word.
Actually, ticking a word on a standard system returns the execution
token that identifies the execution semantics for *this* word.
If the standard does not specify execution semantics for the word then
the returned xt (if any) identifies implementation-dependent execution semantics for this word.
Yes, usually, this execution token is used by the system to *perform*
the interpretation semantics for the word.
But, for some words, this the same execution token may be also used to perform the compilation semantics for the word. Namely, if the word is
an immediate word.
Since, to perform the compilation semantics for an immediate word, its execution token shall be executed in compilation state, to perform the interpretation semantics — it shall be executed in interpretation state.
When you refer this execution token as one corresponding to the interpretation semantics of a word, you also make an impression that executing this token performs the interpretation semantics for the word regardless of STATE. But it's false in the general case.
--
Ruvim
This message continues in a new thread the topic:
"Custom xt compiler and compilation semantics (was: Extended VALUEs in
Forth 200x)" news://thi90o$2ofsa$1@dont-email.me https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/tv7Z8QsfBAAJ
Some time ago Anton defended one peculiar understanding (interpretation)
of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation semantics, which in turn are equivalent to the execution semantics (¹). There were many discussions in this regard [1]. I don't remember anyone
else defending this understanding, but it seems it has its share in the community. This message is addressed to the people who share this understanding.
[1] Just one example: https://groups.google.com/g/comp.lang.forth/c/ildjR6oy6hg/m/caArstkVBgAJ
It's very easy to implement (or redefine) "postpone" that correctly deal
with immediate words and does not impose any restriction on programs.
See: https://github.com/ForthHub/discussion/discussions/103#solution
Ruvim
This message continues in a new thread the topic:
"Custom xt compiler and compilation semantics (was: Extended VALUEs in
Forth 200x)" news://thi90o$2ofsa$1@dont-email.me >https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/tv7Z8QsfBAAJ
Some time ago Anton defended one peculiar understanding (interpretation)
of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation >semantics, which in turn are equivalent to the execution semantics (¹).
One consequence of the understanding (¹) is that compilation semantics
can depend on STATE. Since, if the execution semantics for an immediate
word are STATE-dependent, then the compilation semantics are either >STATE-dependent too or not equivalent to the execution semantics. If you >don't accept their inequivalence, you have to admit STATE-dependent >compilation semantics.
\ An example of immediate word for which execution semantics
\ are dependent on STATE, i.e. they produce different results
\ in interpretation state and in compilation state
: foo ( -- 132 | ) s" 123" evaluate ; immediate
' foo constant xt-foo
\ if xt-foo is executed interpretively, it places 123 on the stack
\ if xt-foo is executed compilatively, it compiles 123 as a literal
By this understanding, if I ask you to perform the compilation semantics
for an immediate word, you can do it by performing the execution
semantics of this word in interpretation state as well as in compilation >state.
But the results will vary if these execution semantics are
STATE-dependent. Should I really add that I ask for the variant of >compilation semantics that takes place namely in compilation state?
Actually, no. If I ask to perform the compilation semantics for a word,
I mean to perform that very behavior that takes place when the Forth
text interpreter encounters this word name in compilation state. No
other options.
Ditto for interpretation semantics.
Thus, the understanding (¹) produces a bunch of such excessive notions as:
- STATE-dependent compilation semantics,
- compilation semantics in compilation state,
- compilation semantics in interpretation state,
- STATE-dependent interpretation semantics,
- interpretation semantics in interpretation state,
- interpretation semantics in compilation state.
But they are not needed. They are nonsense.
The only possible reason for the understanding (¹) was to justify a >particular implementation of "postpone" (i.e., to proof that the
Forth-94 standard allegedly allows such implementations):
: postpone ( "name" -- )
bl word find case
-1 of lit, ['] compile, compile, endof
1 of compile, endof
-13 throw
endcase
; immediate
(²)
This "postpone", when it's applied to an immediate word, appends to the >current definition the execution semantics of the word (by applying >"compile," to their identifier), instead of the compilation semantics
(as it's defined in 2.1 Definitions of terms).
If you want to allow this implementation, it's better to just say that >"postpone", when it's applied to an immediate word, appends its
execution semantics. There's no need to skew the notion of compilation >semantics making it STATE-dependent.
But, anyway, if you allow this implementation, you introduce some
problems. And these problems remain regardless what and how you call.
If you don't restrict programs, the behavior variations of the
"postpone" implementation (²) when it is applied to immediate and >nonimmediate dual-semantics words become observable for programs. Hence,
the programmer has to know how an argument of "postpone" is implemented.
And it makes "postpone" *fail* in what it was designed for.
A.6.1.2033 POSTPONE >https://forth-standard.org/standard/rationale#rat:core:POSTPONE
| POSTPONE replaces most of the functionality
| of COMPILE and [COMPILE]. COMPILE and [COMPILE]
| are used for the same purpose: postpone
| the compilation behavior of the next word
| in the parse area. COMPILE was designed to be applied
| to non-immediate words and [COMPILE] to immediate words.
|
| This burdens the programmer with needing to know
| which words in a system are immediate. Consequently,
| Forth standards have had to specify the immediacy
| or non-immediacy of all words covered by the standard.
| This unnecessarily constrains implementors.
Ruvim <ruvim.pinka@gmail.com> writes:
This message continues in a new thread the topic:
"Custom xt compiler and compilation semantics (was: Extended VALUEs in
Forth 200x)" news://thi90o$2ofsa$1@dont-email.me
https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/tv7Z8QsfBAAJ
Some time ago Anton defended one peculiar understanding (interpretation)
of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation
semantics, which in turn are equivalent to the execution semantics (¹).
That follows straight from the standard:
A) Equivalence of execution and compilation semantics for immediate
words:
|2.1 Definitions of terms
|
|immediate word: A Forth word whose compilation semantics are to
|perform its execution semantics.
Do you want to argue that this does not mean that the compilation
semantics are equivalent to the execution semantics?
B) Equivalence of execution and interpretation semantics for immediate
words.
|3.4.3.2 Interpretation semantics
|
|Unless otherwise specified in an "Interpretation:" section of the
|glossary entry, the interpretation semantics of a Forth definition are
|its execution semantics.
This makes the execution and interpretation semantics of all
user-defined words equivalent; as for standard-defined words, none
those that are specified as immediate have an Interpretation: section
that specifies something else. I.e., for all immediate words, the
execution and interpretation semantics are equivalent.
C) Equivalence of interpretation and compilation semantics for
immediate words.
Follows from A, B, and the transitivity of equivalence.
Ruvim <ruvim.pinka@gmail.com> writes:
Some time ago Anton defended one peculiar understanding (interpretation)
of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation
semantics, which in turn are equivalent to the execution semantics (¹).
One consequence of the understanding (¹) is that compilation semantics
can depend on STATE. Since, if the execution semantics for an immediate
word are STATE-dependent, then the compilation semantics are either
STATE-dependent too or not equivalent to the execution semantics. If you
don't accept their inequivalence, you have to admit STATE-dependent
compilation semantics.
\ An example of immediate word for which execution semantics
\ are dependent on STATE, i.e. they produce different results
\ in interpretation state and in compilation state
: foo ( -- 132 | ) s" 123" evaluate ; immediate
' foo constant xt-foo
\ if xt-foo is executed interpretively, it places 123 on the stack
\ if xt-foo is executed compilatively, it compiles 123 as a literal
Please clarify "execute interpretively" and "execute compilatively".
Do you also use phrases like "execute decimally", "execute octally" or
the like to discuss the context-dependent (and often unwanted)
properties of this definition?
On 2022-10-09 10:07, Anton Ertl wrote:..
Ruvim <ruvim.pinka@gmail.com> writes:
Some time ago Anton defended one peculiar understanding (interpretation) >>> of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation
semantics, which in turn are equivalent to the execution semantics (¹).
That follows straight from the standard:
A) Equivalence of execution and compilation semantics for immediate
words:
|2.1 Definitions of terms
|
|immediate word: A Forth word whose compilation semantics are to
|perform its execution semantics.
Do you want to argue that this does not mean that the compilation
semantics are equivalent to the execution semantics?
Yes, it does not mean that.
...
On 10/16/22 15:42, Ruvim wrote:
On 2022-10-09 10:07, Anton Ertl wrote:..
Ruvim <ruvim.pinka@gmail.com> writes:
Some time ago Anton defended one peculiar understandingThat follows straight from the standard:
(interpretation)
of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation
semantics, which in turn are equivalent to the execution semantics (¹). >>>
A) Equivalence of execution and compilation semantics for immediate
words:
|2.1 Definitions of terms
|
|immediate word: A Forth word whose compilation semantics are to
|perform its execution semantics.
Do you want to argue that this does not mean that the compilation
semantics are equivalent to the execution semantics?
Yes, it does not mean that.
...
I'm trying to understand your interpretation. If I define the following
word,
: FOO STATE @ IF ." BAR" ELSE ." FOO" THEN ; IMMEDIATE
can you identify what you consider to be its execution semantics and
what you consider to be its compilation semantics?
Ruvim <ruvim.pinka@gmail.com> writes:
Some time ago Anton defended one peculiar understanding (interpretation)
of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation
semantics, which in turn are equivalent to the execution semantics (¹).
One consequence of the understanding (¹) is that compilation semantics
can depend on STATE.
If I ask to perform the compilation semantics for a word,
I mean to perform that very behavior that takes place when the Forth
text interpreter encounters this word name in compilation state. No
other options.
Ditto for interpretation semantics.
I assume with "this very behaviour" you mean that you want that
compilation semantics is performed only in compilation state,
Ruvim <ruvim.pinka@gmail.com> writes:
Some time ago Anton defended one peculiar understanding (interpretation) >>> of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation
semantics, which in turn are equivalent to the execution semantics (¹).
One consequence of the understanding (¹) is that compilation semantics
can depend on STATE.
[...]
If I ask to perform the compilation semantics for a word,
I mean to perform that very behavior that takes place when the Forth
text interpreter encounters this word name in compilation state. No
other options.
Ditto for interpretation semantics.
I assume with "this very behaviour" you mean that you want that
compilation semantics is performed only in compilation state,
No. I mean the following.
If the word "compile-name ( i*x nt -- j*x )" is a way to ask the system
to perform the compilation semantics for the word identified by an nt,
then execution of "compile-name" shall demonstrate the *same* behavior >*regardless* whether the system is in compilation state or in
interpretation state before this execution. And it is the very behavior
that the system demonstrates when it encounters the nt word name in >compilation state (³).
And it's a system's internal problem whether it needs (or doesn't need)
to enter in compilation state to perform the semantics that I ask.
And if you ask the system to perform the compilation semantics for a
word, you never need the system to perform a behavior that distinct from >(³). Hence, it's excessive to specify that you ask namely for the
behavior (³).
Counter examples are welcome.
--
Ruvim
In article <tis7e6$bmv6$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:[...]
On 2022-10-09 10:07, Anton Ertl wrote:
Ruvim <ruvim.pinka@gmail.com> writes:
Some time ago Anton defended one peculiar understanding (interpretation) >>>> of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation
semantics, which in turn are equivalent to the execution semantics (¹). >>
One consequence of the understanding (¹) is that compilation semantics >>>> can depend on STATE.
[...]
If I ask to perform the compilation semantics for a word,
I mean to perform that very behavior that takes place when the Forth
text interpreter encounters this word name in compilation state. No
other options.
Ditto for interpretation semantics.
I assume with "this very behaviour" you mean that you want that
compilation semantics is performed only in compilation state,
No. I mean the following.
If the word "compile-name ( i*x nt -- j*x )" is a way to ask the system
to perform the compilation semantics for the word identified by an nt,
then execution of "compile-name" shall demonstrate the *same* behavior
*regardless* whether the system is in compilation state or in
interpretation state before this execution. And it is the very behavior
that the system demonstrates when it encounters the nt word name in
compilation state (³).
And it's a system's internal problem whether it needs (or doesn't need)
to enter in compilation state to perform the semantics that I ask.
And if you ask the system to perform the compilation semantics for a
word, you never need the system to perform a behavior that distinct from
(³). Hence, it's excessive to specify that you ask namely for the
behavior (³).
Counter examples are welcome.
In ciforth DO is a normal IMMEDIATE word, and ISO doesn't specify
what it is supposed to do unless in deferring mode, building a definition.
A BASIC programmer could say that DO .. LOOP "behaves" the same
in interpretation or compilation mode. You have a hard time
argue with that, but it is not a cosher argument.
Ruvim <ruvim.pinka@gmail.com> writes:
Some time ago Anton defended one peculiar understanding (interpretation)
of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation
semantics, which in turn are equivalent to the execution semantics (¹).
One consequence of the understanding (¹) is that compilation semantics
can depend on STATE.
Just to check what systems do, I have written a small test (made
somewhat larger by prepending an implementation of FIND-NAME-IN:
---------------
\ find-name-in implementation from
\ <http://www.forth200x.org/reference-implementations/find-name.fs>
: >lower ( c1 -- c2 )
dup 'A' 'Z' 1+ within bl and or ;
: istr= ( addr1 u1 addr2 u2 -- flag )
rot over <> IF 2drop drop false EXIT THEN
bounds ?DO
dup c@ >lower I c@ >lower <> IF drop false unloop EXIT THEN
1+
LOOP drop true ;
: find-name-in-helper ( addr u wid -- nt / 0 )
dup >r name>string 2over istr= IF
rot drop r> -rot false
ELSE r> drop true THEN ;
: find-name-in ( addr u wid -- nt / 0 )
>r 0 -rot r>
['] find-name-in-helper
swap traverse-wordlist 2drop ;
\ the actual test
: [.state] state @ . ; immediate
: [execute] execute ; immediate
[.state] \ 0
] [.state] [ \ -1
s" [.state]" forth-wordlist find-name-in constant [.state]-nt
[.state]-nt name>interpret ] [execute] [ \ -1 [.state]-nt name>compile execute \ 0 ----------------
I have run this on gforth 0.7.9_20221005, lxf 1.6-982-823, SwiftForth 4.0.0-RC52, vfx 5.11RC2, and they all print "0 -1 -1 0", as I
expected.
What you want is that they print "0 -1 0 -1",
Ruvim <ruvim.pinka@gmail.com> writes:
Some time ago Anton defended one peculiar understanding (interpretation)
of immediate words and their semantics, namely that for any immediate
word the interpretation semantics are equivalent to the compilation
semantics, which in turn are equivalent to the execution semantics (¹).
One consequence of the understanding (¹) is that compilation semantics
can depend on STATE.
And actually even fans of STATE-smartness don't want the behaviour you advocate. They do things like define a state-smart LITERAL and then
: literal state @ if postpone literal then ; immediate
: ascii parse-name drop c@ postpone literal ; immediate
and expect ASCII to inherit the state-smartness of their LITERAL.
The words "name>interpret" and "name>compile" (along with "find-name")
were introduced as a replacement for "find".
But, the word "name>interpret" is also specified insufficiently in
Forth-2012 (so it's the same problem as for "find" in Forth-94). The
glossary entry for "name>interpret" does not describe how the returned
value should be used to perform the behavior that takes place when the
Forth text interpreter encounters the word name in interpretation state
— i.e., how to perform the interpretation semantics for a word
(regardless of the employed implementation approach in the system).
From various discussions I concluded, "name>interpret" should return
the same xt that Tick returns for a word (when it's applicable). It
means that "name>interpret" (despite of its name) returns the xt that identifies the execution semantics for the word, but this xt cannot be
used to perform the compilation semantics for the word in the general case.
The word "name>compile" is specified better, but many implementations
fall into the same problem as for "postpone" — they provide
STATE-dependent execution semantics in some cases. Therefore, a portable
way to perform the compilation semantics for a word via "name>compile"
is to execute the returned xt in compilation state.
But it's a bad API, since it forces the user to specify his intention
twice — via "name>compile", and via "state". It should not be acceptable.
OTOH, nobody has provided an example when a user need to use
"name>compile" to perform the behavior for a word that Forth system demonstrates when it encounters this word in *interpretation* state.
: foo" postpone ." ;
foo" xxx" \ this is ambiguous.
This rationale is applicable to any word for which interpretation
semantics are undefined by the standard. For example:
: if, postpone if ;
: bar [ if, ] ; \ this is ambiguous
\ according to A.3.4.3.2 and A.6.1.0190
And it is what RFI Q99-027/A99-027 says.
The only way to discard this restriction — is to implement a fully compliant "postpone". And the dual-xt approach cannot solve this problem.
On 10/25/22 10:43, Ruvim wrote:..
..
: foo" postpone ." ;
foo" xxx" \ this is ambiguous.
..
The only way to discard this restriction — is to implement a fully
compliant "postpone". And the dual-xt approach cannot solve this problem.
I've already shown how the above problem can be solved with a
dual-semantics (not necessarily dual-xt) approach.
Backtrace:foo"<<< xxx"
On 10/25/22 06:04, Ruvim wrote:
The words "name>interpret" and "name>compile" (along with "find-name")
were introduced as a replacement for "find".
The word "name>compile" is specified better, but many implementations
fall into the same problem as for "postpone" — they provide
STATE-dependent execution semantics in some cases. Therefore, a
portable way to perform the compilation semantics for a word via
"name>compile" is to execute the returned xt in compilation state.
Which implementations require STATE to be set in order to use
NAME>COMPILE correctly? The standard does not say that STATE must be set
to compile in order to obtain the compilation semantics.
I fail to see what your difficulty is with NAME>COMPILE and NAME>INTERPRET.
On 2022-10-25 21:57, Krishna Myneni wrote:
On 10/25/22 06:04, Ruvim wrote:
The words "name>interpret" and "name>compile" (along with
"find-name") were introduced as a replacement for "find".
[...]
The word "name>compile" is specified better, but many implementations
fall into the same problem as for "postpone" — they provide
STATE-dependent execution semantics in some cases. Therefore, a
portable way to perform the compilation semantics for a word via
"name>compile" is to execute the returned xt in compilation state.
Which implementations require STATE to be set in order to use
NAME>COMPILE correctly? The standard does not say that STATE must be
set to compile in order to obtain the compilation semantics.
Not to obtain, but to perform. It doesn't say that, and it's a problem.
[...]
I fail to see what your difficulty is with NAME>COMPILE and
NAME>INTERPRET.
Let I want to define a word "compile-word ( i*x sd.name -- j*x )" that performs the compilation for a word named sd.name.
Where sd.name is a pair (c-addr u), which is a string of a word name,
and "compilation semantics" is a standard term according to the term definitions (i.e. this behavior does not depend on STATE).
Usage example:
s" foo" compile-word
This phrase should perform the compilation semantics for the word "foo", regardless of state.
How "compile-word" can be defined via "name>compile" or "name>interpret"?
On 10/26/22 03:43, Ruvim wrote:
On 2022-10-25 21:57, Krishna Myneni wrote:
On 10/25/22 06:04, Ruvim wrote:
The words "name>interpret" and "name>compile" (along with
"find-name") were introduced as a replacement for "find".
[...]
The word "name>compile" is specified better, but many
implementations fall into the same problem as for "postpone" — they
provide STATE-dependent execution semantics in some cases.
Therefore, a portable way to perform the compilation semantics for a
word via "name>compile" is to execute the returned xt in compilation
state.
Which implementations require STATE to be set in order to use
NAME>COMPILE correctly? The standard does not say that STATE must be
set to compile in order to obtain the compilation semantics.
Not to obtain, but to perform. It doesn't say that, and it's a problem.
[...]
I fail to see what your difficulty is with NAME>COMPILE and
NAME>INTERPRET.
Let I want to define a word "compile-word ( i*x sd.name -- j*x )"
that performs the compilation for a word named sd.name.
Where sd.name is a pair (c-addr u), which is a string of a word name,
and "compilation semantics" is a standard term according to the term
definitions (i.e. this behavior does not depend on STATE).
Usage example:
s" foo" compile-word
This phrase should perform the compilation semantics for the word
"foo", regardless of state.
How "compile-word" can be defined via "name>compile" or "name>interpret"?
The following example illustrates:
: foo ." hello" ; ok
: compile-word ( caddr u -- ) find-name name>compile execute ;
immediate ok
: test1 [ s" foo" compile-word ] ; ok
: test2 [ s" foo" ] compile-word ; ok
On 2022-10-26 13:01, Krishna Myneni wrote:
On 10/26/22 03:43, Ruvim wrote:
On 2022-10-25 21:57, Krishna Myneni wrote:
On 10/25/22 06:04, Ruvim wrote:
The words "name>interpret" and "name>compile" (along with
"find-name") were introduced as a replacement for "find".
[...]
The word "name>compile" is specified better, but many
implementations fall into the same problem as for "postpone" — they >>>>> provide STATE-dependent execution semantics in some cases.
Therefore, a portable way to perform the compilation semantics for
a word via "name>compile" is to execute the returned xt in
compilation state.
Which implementations require STATE to be set in order to use
NAME>COMPILE correctly? The standard does not say that STATE must be
set to compile in order to obtain the compilation semantics.
Not to obtain, but to perform. It doesn't say that, and it's a problem.
[...]
I fail to see what your difficulty is with NAME>COMPILE and
NAME>INTERPRET.
Let I want to define a word "compile-word ( i*x sd.name -- j*x )"
that performs the compilation for a word named sd.name.
Where sd.name is a pair (c-addr u), which is a string of a word name,
and "compilation semantics" is a standard term according to the term
definitions (i.e. this behavior does not depend on STATE).
Usage example:
s" foo" compile-word
This phrase should perform the compilation semantics for the word
"foo", regardless of state.
How "compile-word" can be defined via "name>compile" or
"name>interpret"?
The following example illustrates:
: foo ." hello" ; ok
: compile-word ( caddr u -- ) find-name name>compile execute ;
immediate ok
Applying "immediate" is incorrect. I specify only the execution
semantics for "compile-word" ("When a definition has only one specified behavior, the label is omitted" by 3.4.3.1). It means this word is an ordinary word, which have default compilation semantics according to
3.4.3.3.
: bar s" foo" compile-word ;
bar \ it should perform the compilation semantics for the word "foo"
\ according to the current search order.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 46:44:27 |
Calls: | 6,710 |
Calls today: | 3 |
Files: | 12,243 |
Messages: | 5,354,357 |
Posted today: | 1 |