On 2022-10-03 01:08, Krishna Myneni wrote:(¹)
On 10/2/22 11:14, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
On 10/2/22 00:00, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
On 10/1/22 02:06, Anton Ertl wrote:
SET-OPTIMIZER sets the implementation of COMPILE, ( xt -- ) for
the current word. A correct implementation of COMPILE, does not >>>>>>> change the semantics in any way, only the implementation of the
semantics.
(²)So if you instead do
[: postpone literal postpone execute ;] set-optimizer
the behaviour stays the same.
I not seeing the difference.
I can put any arbitrary sequence inside the
quotation for SET-OPTIMIZER. Then the compilation
semantics (behavior) can be different from that
of a word defined without SET-OPTIMIZER.
Yes, you can shoot yourself in the foot with SET-OPTIMIZER. This is >>>>> Forth. But once you have done that, COMPILE, does no longer work as >>>>> specified (and, more importantly, as used in most places where
COMPILE, is used).
[...]* COMPILE,ing the xt of N2 now does not optimize. The result is
correct, but not as fast as what you get with the SET-OPTIMIZER
variant.
In short, I think using SET-COMPSEMP is a more transparent way of
achieving optimization and your BROKEN-VALUE definition would be my
preferred way to go about it.
Probably you actually thought about something like "compile-nt"
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
But this word cannot replace "compile," due to the following reasons:
1. There is a common standard-compliant pattern to compile an ordinary
word:
['] foo compile,
And this pattern should remain valid.
2. Anonymous definitions don't have associated nt (name token), and the
only way to compile them is to use "compile,".
BTW, in my system I associate a custom compilation procedure not with
nt, but with xt. So, an optimized compiler can be specified for an
anonymous definition too.
Also, it's less confusing, since the notion of compilation semantics is
not applicable to execution tokens. And when you set a compiler for xt,
you cannot think like you define compilation semantics by that for some
word at all.
On a dual token system (one which provides a reference to
interpretation semantics and a separate reference to compilation
semantics) I want to avoid thinking about whether the compilation
semantics are default or non-default.
There is only "compilation
semantics" for a word, at any given instance in time. The system
provides compilation semantics for the word upon definition but it may
be changed later, if desired. Similarly, for words which CREATE other
words, there should be a mechanism for setting the compilation
semantics of the created words immediately after creation, if desired.
In such a case you have to eliminate execution tokens, "execute" and "compile," from your system (i.e., make them inaccessible for a user).
But the notion of anonymous definition and execution semantics are
essential in Forth. It's a rock other conceptions are based on.
On 10/3/22 04:35, Ruvim wrote:
On 2022-10-03 01:08, Krishna Myneni wrote:
1.
On a dual token system (one which provides a reference to
interpretation semantics and a separate reference to compilation
semantics) I want to avoid thinking about whether the compilation
semantics are default or non-default. There is only "compilation
semantics" for a word, at any given instance in time. The system
provides compilation semantics for the word upon definition but it may
be changed later, if desired. Similarly, for words which CREATE other
words, there should be a mechanism for setting the compilation
semantics of the created words immediately after creation, if desired.
In such a case you have to eliminate execution tokens, "execute" and
"compile," from your system (i.e., make them inaccessible for a user).
No, a dual token system by definition contains execution tokens, one for interpretation and one for compilation. There is no suggestion that
execution tokens should be eliminated.
2.
Probably you actually thought about something like "compile-nt"
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
But this word cannot replace "compile," due to the following reasons:
1. There is a common standard-compliant pattern to compile an ordinary
word:
['] foo compile,
And this pattern should remain valid.
2. Anonymous definitions don't have associated nt (name token), and the
only way to compile them is to use "compile,".
I actually have such a word in kForth (which is not presently a
dual-token system) called "COMPILE-NAME", which performs the equivalent
of NAME>COMPILE EXECUTE . One can still use expressions such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL COMPILE,".
On a dual-token system, COMPILE-NAME (or whatever name one wants to give
it) would be guaranteed to compile the xt referencing the extra token referencing the compilation semantics of a word.
The sequence "['] <name>"
would still perform its usual action of returning the
interpretation xt for the word, so there are no changes in this regard. '(tick) and ['] return what are expected in standard Forth.
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.
On 2022-10-04 01:52, Krishna Myneni wrote:..
No, a dual token system by definition contains execution tokens, one
for interpretation and one for compilation. There is no suggestion
that execution tokens should be eliminated.
I just wanted to say that it's impossible to avoid the notion of default compilation semantics without avoiding ordinary words. I also mentioned
this idea my another message yesterday: https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/_C_XjZ60AwAJ
2.
Probably you actually thought about something like "compile-nt"
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
But this word cannot replace "compile," due to the following reasons:
1. There is a common standard-compliant pattern to compile an ordinary
word:
['] foo compile,
And this pattern should remain valid.
2. Anonymous definitions don't have associated nt (name token), and the
only way to compile them is to use "compile,".
I actually have such a word in kForth (which is not presently a
dual-token system) called "COMPILE-NAME", which performs the
equivalent of NAME>COMPILE EXECUTE . One can still use expressions
such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL COMPILE,".
On a dual-token system, COMPILE-NAME (or whatever name one wants to
give it) would be guaranteed to compile the xt referencing the extra
token referencing the compilation semantics of a word.
Should it compile the xt, or perform the compilation semantics for the word? Sometimes these actions are different.
The sequence "['] <name>" would still perform its usual action of
returning the interpretation xt for the word, so there are no changes
in this regard. '(tick) and ['] return what are expected in standard
Forth.
[...]
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.
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.
On 10/4/22 16:36, Ruvim wrote:
On 2022-10-04 01:52, Krishna Myneni wrote:..
No, a dual token system by definition contains execution tokens, one
for interpretation and one for compilation. There is no suggestion
that execution tokens should be eliminated.
I just wanted to say that it's impossible to avoid the notion of default
compilation semantics without avoiding ordinary words. I also mentioned
this idea my another message yesterday:
https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/_C_XjZ60AwAJ
You may want to call it default compilation semantics, but on a dual
token system I would simply think of it as initial compilation semantics >assigned by the system when the word has been defined, i.e. when the
colon definition specifies the interpretation semantics.
--
Krishna
In article <thj4hv$2tjb2$4...@dont-email.me>,
Krishna Myneni <krishna...@ccreweb.org> wrote:
On 10/4/22 16:36, Ruvim wrote:
On 2022-10-04 01:52, Krishna Myneni wrote:..
No, a dual token system by definition contains execution tokens, one
for interpretation and one for compilation. There is no suggestion
that execution tokens should be eliminated.
I just wanted to say that it's impossible to avoid the notion of default >> compilation semantics without avoiding ordinary words. I also mentioned
this idea my another message yesterday:
https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/_C_XjZ60AwAJ >>
You may want to call it default compilation semantics, but on a dualRegarding those two token system. Chuck Moore experimented with that,
token system I would simply think of it as initial compilation semantics >assigned by the system when the word has been defined, i.e. when the
colon definition specifies the interpretation semantics.
and has abandoned in favor of a multi color system.
In more mundane terms every object has multiple methods identified
by color. Two is not enough.
I want to go back to recipees. Recipees have no name and can be coupled
to a name by a dictionary. (Sort of noname definitions.)
A recipee can (but need not be) be coupled to one name, but subject to manipulation and search order. Recipees can be immediate which affects deferred mode, but they behave the same in either mode.
No smart words, only smart literals like numbers.
Note that a denotation for a recipee is also a literal, ("quotation").
On 10/4/22 16:36, Ruvim wrote:
On 2022-10-04 01:52, Krishna Myneni wrote:
Probably you actually thought about something like "compile-nt"
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
I actually have such a word in kForth (which is not presently a
dual-token system) called "COMPILE-NAME", which performs the
equivalent of NAME>COMPILE EXECUTE . One can still use expressions
such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL COMPILE,".
On a dual-token system, COMPILE-NAME (or whatever name one wants to
give it) would be guaranteed to compile the xt referencing the extra
token referencing the compilation semantics of a word.
Should it compile the xt, or perform the compilation semantics for the
word? Sometimes these actions are different.
The compilation semantics of the word corresponding to nt is performed
when COMPILE-NAME executes.
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.
Not really. In a dual-token system there are explicitly two types of execution semantics: "interpretation semantics" or "compilation
semantics." It is easier to understand which one we are talking about.
In contrast, for a traditional system, we have to determine whether the single xt representing execution semantics for a word corresponds to compilation semantics or to interpretation semantics by checking the precedence flag for the word.
Your points above about execution token not always representing the interpretation semantics are valid for a traditional Forth system, but
when you tick a word name, how do you know which semantics are being returned?
In contrast, with the sequence "nt NAME>INTERPRET" or "nt
NAME>COMPILE", you know precisely to which semantics the result
corresponds.
On 2022-10-05 09:26, Krishna Myneni wrote:
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
I actually have such a word in kForth (which is not presently a
dual-token system) called "COMPILE-NAME", which performs the
equivalent of NAME>COMPILE EXECUTE . One can still use expressions
such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL COMPILE,".
Does it perform compilation semantics regardless of the STATE?
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.
What does "corresponding" mean? How is this execution token connected
with the execution semantics of the word? How can the interpretation semantics be performed? (again, should interpretation state be set or not).
It sounds incorrectly. By this wording you revoke access to the
identifier of the execution semantics for a word.
Not really. In a dual-token system there are explicitly two types of
execution semantics: "interpretation semantics" or "compilation
semantics." It is easier to understand which one we are talking about.
In contrast, for a traditional system, we have to determine whether
the single xt representing execution semantics for a word corresponds
to compilation semantics or to interpretation semantics by checking
the precedence flag for the word.
The standard allows the single-xt approach in implementations as well as dual-xt or dual-nt approach. And it specifies an abstract model over all possible implementation variants. And it specifies (should specify) only
APIs that don't depend on a particular implementation or approach. And a standard program is not bothered whether it runs on a single-xt system,
or on a dual-xt system.
The standard specifies the execution semantics term, and the Tick method (among other) to obtain an execution token for a word that identifies
the execution semantics of the word. To perform the interpretation
semantics for the word, "execute" should be applied to this token in interpretation state. It's true for any standard system, regardless
whether it's a single-xt system or dual-xt system.
Sure, we can classify execution semantics by some types, according to
their internal properties. For example, execution semantics can be
either STATE-dependent or STATE-independent.
But "interpretation semantics" and "compilation semantics" are not types
of execution semantics. These terms are already occupied and defined in
the standard. Don't clutter them with other meanings. Choose other names.
[...]
Your points above about execution token not always representing the
interpretation semantics are valid for a traditional Forth system, but
when you tick a word name, how do you know which semantics are being
returned?
Actually, I may tick only ordinary or immediate word.
Anyway, when I Tick a word, it returns an identifier of the execution semantics for the word.
In contrast, with the sequence "nt NAME>INTERPRET" or "nt
NAME>COMPILE", you know precisely to which semantics the result
corresponds.
It's questionable, but my questions are above.
I was a bit sloppy in my description above. In a single-xt system like kForth, NAME>COMPILE returns the compilation semantics as follows:
For nt corresponding to an IMMEDIATE word, the returned compilation
semantics are given by two xt's:
( nt-word -- xt-word xt-execute )
When EXECUTE is applied to the stack diagram above, xt-word is
immediately executed.
For nt corresponding to a non-immediate word, the returned compilation semantics are given by an nt and an xt:
( nt-word -- nt xt-compile-name )
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
I actually have such a word in kForth (which is not presently a
dual-token system) called "COMPILE-NAME", which performs the
equivalent of NAME>COMPILE EXECUTE . One can still use expressions
such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL COMPILE,".
Does it perform compilation semantics regardless of the STATE?
As I have stated above, COMPILE-NAME may be represented exactly in
standard code as your COMPILE-NT.
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.
What does "corresponding" mean? How is this execution token connected
with the execution semantics of the word? How can the interpretation
semantics be performed? (again, should interpretation state be set or
not).
I was a bit sloppy in my description above. In a single-xt system like kForth, NAME>COMPILE returns the compilation semantics as follows:
For nt corresponding to an IMMEDIATE word, the returned compilation
semantics are given by two xt's:
( nt-word -- xt-word xt-execute )
When EXECUTE is applied to the stack diagram above, xt-word is
immediately executed.
For nt corresponding to a non-immediate word, the returned compilation semantics are given by an nt and an xt:
( nt-word -- nt xt-compile-name )
When EXECUTE is applied to the above stack diagram, the system compiles
the execution semantics for xt-word. Thus far no use has been made of
STATE.
On 2022-10-07 03:01, Krishna Myneni wrote:
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
I actually have such a word in kForth (which is not presently a
dual-token system) called "COMPILE-NAME", which performs the
equivalent of NAME>COMPILE EXECUTE . One can still use expressions >>>>>> such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL COMPILE,".
Does it perform compilation semantics regardless of the STATE?
As I have stated above, COMPILE-NAME may be represented exactly in
standard code as your COMPILE-NT.
It does not answer to my question, since your "name>compile" can return
xt that always identifies STATE-independent execution semantics.
Therefore, I provided a test to check how it works:
: translate-123 s" 123" evaluate ; immediate
: test-123
[ "translate-123" find-name compile-name ]
;
0 test-123 . . \ should print "0 123"
On 2022-10-07 03:01, Krishna Myneni wrote:
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
I actually have such a word in kForth (which is not presently a
dual-token system) called "COMPILE-NAME", which performs the
equivalent of NAME>COMPILE EXECUTE . One can still use expressions >>>>>> such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL COMPILE,".
Does it perform compilation semantics regardless of the STATE?
As I have stated above, COMPILE-NAME may be represented exactly in
standard code as your COMPILE-NT.
It does not answer to my question, since your "name>compile" can return
xt that always identifies STATE-independent execution semantics.
Therefore, I provided a test to check how it works:
: translate-123 s" 123" evaluate ; immediate
: test-123
[ "translate-123" find-name compile-name ]
;
0 test-123 . . \ should print "0 123"
I guess, this test fails in your system.
On 10/7/22 04:38, Ruvim wrote:
On 2022-10-07 03:01, Krishna Myneni wrote:
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
I actually have such a word in kForth (which is not presently a
dual-token system) called "COMPILE-NAME", which performs the
equivalent of NAME>COMPILE EXECUTE . One can still use
expressions such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL >>>>>>> COMPILE,".
Does it perform compilation semantics regardless of the STATE?
As I have stated above, COMPILE-NAME may be represented exactly in
standard code as your COMPILE-NT.
It does not answer to my question, since your "name>compile" can
return xt that always identifies STATE-independent execution semantics.
Therefore, I provided a test to check how it works:
: translate-123 s" 123" evaluate ; immediate
: test-123
[ "translate-123" find-name compile-name ]
;
0 test-123 . . \ should print "0 123"
I guess, this test fails in your system.
Yes, it does fail:
----
: translate-123 s" 123" evaluate ; immediate
ok
: test-123 [ s" translate-123" find-name compile-name ] ;
ok
0 test-123 .
0 ok
On 10/7/22 04:38, Ruvim wrote:
On 2022-10-07 03:01, Krishna Myneni wrote:
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
I actually have such a word in kForth (which is not presently a >>>>>> dual-token system) called "COMPILE-NAME", which performs the
equivalent of NAME>COMPILE EXECUTE . One can still use expressions >>>>>> such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL COMPILE,". >>>>>>
Does it perform compilation semantics regardless of the STATE?
As I have stated above, COMPILE-NAME may be represented exactly in
standard code as your COMPILE-NT.
It does not answer to my question, since your "name>compile" can return
xt that always identifies STATE-independent execution semantics.
Therefore, I provided a test to check how it works:
: translate-123 s" 123" evaluate ; immediate
: test-123
[ "translate-123" find-name compile-name ]
;
0 test-123 . . \ should print "0 123"
I guess, this test fails in your system.
Yes, it does fail:
----
: translate-123 s" 123" evaluate ; immediate
ok
: test-123 [ s" translate-123" find-name compile-name ] ;
ok
0 test-123 .
0 ok
On Friday, 7 October 2022 at 20:58:51 UTC+2, Krishna Myneni wrote:
On 10/7/22 04:38, Ruvim wrote:
On 2022-10-07 03:01, Krishna Myneni wrote:Yes, it does fail:
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
I actually have such a word in kForth (which is not presently a >>>>>>>> dual-token system) called "COMPILE-NAME", which performs the
equivalent of NAME>COMPILE EXECUTE . One can still use expressions >>>>>>>> such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL COMPILE,". >>>>>>>>
Does it perform compilation semantics regardless of the STATE?
As I have stated above, COMPILE-NAME may be represented exactly in
standard code as your COMPILE-NT.
It does not answer to my question, since your "name>compile" can return
xt that always identifies STATE-independent execution semantics.
Therefore, I provided a test to check how it works:
: translate-123 s" 123" evaluate ; immediate
: test-123
[ "translate-123" find-name compile-name ]
;
0 test-123 . . \ should print "0 123"
I guess, this test fails in your system.
----
: translate-123 s" 123" evaluate ; immediate
ok
: test-123 [ s" translate-123" find-name compile-name ] ;
ok
0 test-123 .
0 ok
Also my two systems ntf/lxf a dual xt system and ntf64/lxf64 a single xt system
fails this test.
I think that is correct as the test in my opinion is flawed!
translate-123 will correctly get executed by compile-name.
As the system is in interpretative state when this happens
123 just gets placed on the stack. This is the correct behavior.
To pass Ruvim's test you can define compile-name as
: compile-name name>compile ] execute postpone [ ;
Krishna, I introduced the two XT header over 20 years ago. It works like you have described. No set-optimizer and a compile, that just compiles a call to the xt.
The syntax is different:
:p name ...... ;p defines the compilation semantics
:r name ....... ;r defines the interpretative semantics
In the general case, there can be standard words, which the system
provides, that are neither immediate nor ordinary.
For example, the word S" in a standard system can be implemented in such
a way that if you tick this word, and executes the returned xt in
compilation state — it will not perform the compilation semantics for
this word. Hence, this word is nonimmediate in such a case.
--
Ruvim
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
It sounds incorrectly. By this wording you revoke access to the
identifier of the execution semantics for a word.
Not really. In a dual-token system there are explicitly two types of
execution semantics: "interpretation semantics" or "compilation
semantics." It is easier to understand which one we are talking
about. In contrast, for a traditional system, we have to determine
whether the single xt representing execution semantics for a word
corresponds to compilation semantics or to interpretation semantics
by checking the precedence flag for the word.
The standard allows the single-xt approach in implementations as well
as dual-xt or dual-nt approach. And it specifies an abstract model
over all possible implementation variants. And it specifies (should
specify) only APIs that don't depend on a particular implementation or
approach. And a standard program is not bothered whether it runs on a
single-xt system, or on a dual-xt system.
The standard specifies the execution semantics term, and the Tick
method (among other) to obtain an execution token for a word that
identifies the execution semantics of the word. To perform the
interpretation semantics for the word, "execute" should be applied to
this token in interpretation state. It's true for any standard system,
regardless whether it's a single-xt system or dual-xt system.
Sure, we can classify execution semantics by some types, according to
their internal properties. For example, execution semantics can be
either STATE-dependent or STATE-independent.
But "interpretation semantics" and "compilation semantics" are not
types of execution semantics. These terms are already occupied and
defined in the standard. Don't clutter them with other meanings.
Choose other names.
Yes, both "interpretation semantics" and "compilation semantics" are
types of execution semantics, which should be obvious by the fact that
they can be represented by tokens on the stack which, when EXECUTEd will perform the behavior required in the appropriate STATE, as illustrated
by the one-line text interpreter.
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
In contrast, in dual-xt systems, there is no need for the term
"execution semantics".
Your points above about execution token not always representing the
interpretation semantics are valid for a traditional Forth system,
but when you tick a word name, how do you know which semantics are
being returned?
Actually, I may tick only ordinary or immediate word.
Anyway, when I Tick a word, it returns an identifier of the execution
semantics for the word.
In a dual-xt system, which xt do you expect tick or ['] to return?
xt-interp or xt-comp? It should return xt-interp for backward
compatibility with single-xt systems.
On Friday, 7 October 2022 at 20:58:51 UTC+2, Krishna Myneni wrote:
On 10/7/22 04:38, Ruvim wrote:
On 2022-10-07 03:01, Krishna Myneni wrote:Yes, it does fail:
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
: compile-nt ( i*x nt -- j*x ) name>compile execute ;
I actually have such a word in kForth (which is not presently a >>>>>>>> dual-token system) called "COMPILE-NAME", which performs the
equivalent of NAME>COMPILE EXECUTE . One can still use expressions >>>>>>>> such as "['] FOO COMPILE," or " ... [ ' FOO ] LITERAL COMPILE,". >>>>>>>>
Does it perform compilation semantics regardless of the STATE?
As I have stated above, COMPILE-NAME may be represented exactly in
standard code as your COMPILE-NT.
It does not answer to my question, since your "name>compile" can return
xt that always identifies STATE-independent execution semantics.
Therefore, I provided a test to check how it works:
: translate-123 s" 123" evaluate ; immediate
: test-123
[ "translate-123" find-name compile-name ]
;
0 test-123 . . \ should print "0 123"
I guess, this test fails in your system.
----
: translate-123 s" 123" evaluate ; immediate
ok
: test-123 [ s" translate-123" find-name compile-name ] ;
ok
0 test-123 .
0 ok
Also my two systems ntf/lxf a dual xt system and ntf64/lxf64 a single xt system
fails this test.
I think that is correct as the test in my opinion is flawed!
translate-123 will correctly get executed by compile-name.
As the system is in interpretative state when this happens
123 just gets placed on the stack. This is the correct behavior.
To pass Ruvim's test you can define compile-name as
: compile-name name>compile ] execute postpone [ ;
On 2022-10-07 03:01, Krishna Myneni wrote:
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
[...]
In a dual-xt system, which xt do you expect tick or ['] to return?
xt-interp or xt-comp? It should return xt-interp for backward
compatibility with single-xt systems.
The standard does not specify a notion of xt-interp or xt-comp.
...
I would not provide the "name>interpret" and "name>compile" words since
they are flawed by design and insufficiently specified to be usable on
any standard system.
Actually, ticking a word on a standard system returns the execution
token that identifies the execution semantics for *this* 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.
On 10/4/22 16:36, Ruvim wrote:[...]
In a dual-token system there are explicitly two types of
execution semantics: "interpretation semantics" or "compilation
semantics."
It is easier to understand which one we are talking about.
In contrast, for a traditional system, we have to determine whether the >single xt representing execution semantics for a word corresponds to >compilation semantics or to interpretation semantics by checking the >precedence flag for the 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.
A particular example of where this is important is array indexing, e.g.
A{ I }
with the indexing word "}" -- one needs "}" to work in both the
interpreter and from within a definition, but the compilation semantics >usually need to be different from the interpretation semantics to obtain
the best possible efficiency.
The question remains where you get the payoff for increasing complexity in >the compiler (by adding "multiple methods") only to cover some obscure
corner cases that nobody uses in reality
Simplicity is a virtue by itself!
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
On 10/4/22 16:36, Ruvim wrote:[...]
In a dual-token system there are explicitly two types of
execution semantics: "interpretation semantics" or "compilation
semantics."
I would say: There is interpretation semantics and there is
compilation semantics. There have been some arguments that execution semantics is a third entity, but given that there are no words that
have defined execution semantics and defined interpretation semantics
where these two differ, I view execution semantics for a named word as
a helper concept for defining interpretation and/or compilation
semantics.
It is easier to understand which one we are talking about.
In contrast, for a traditional system, we have to determine whether the
single xt representing execution semantics for a word corresponds to
compilation semantics or to interpretation semantics by checking the
precedence flag for the word.
Actually, in a traditional single-xt+immediate-flag system, the xt
always represents the interpretation semantics, and is always part of
the compilation semantics: if the word is immediate, the compilation semantics are to EXECUTE the xt (immediate compilation semantics),
otherwise they are to COMPILE, the xt (default compilation semantics).
There is no way to create words with compilation semantics that are
neither default nor immediate.
A particular example of where this is important is array indexing, e.g.
A{ I }
with the indexing word "}" -- one needs "}" to work in both the
interpreter and from within a definition, but the compilation semantics
usually need to be different from the interpretation semantics to obtain
the best possible efficiency.
This sounds like you want to optimize, not change the default
compilation semantics.
... although compilation semantics may be
initialized in a dual-xt system to provide the same behavior as the interpretation semantics.
...
Yes, both "interpretation semantics" and "compilation semantics" are
types of execution semantics, which should be obvious by the fact that
they can be represented by tokens on the stack which, when EXECUTEd will >perform the behavior required in the appropriate STATE, as illustrated
by the one-line text interpreter.
In a dual-xt system, which xt do you expect tick or ['] to return?
xt-interp or xt-comp? It should return xt-interp for backward
compatibility with single-xt systems.
Ruvim <ruvim.pinka@gmail.com> writes:
Actually, ticking a word on a standard system returns the execution
token that identifies the execution semantics for *this* word.
Not in the case of words with undefined interpretation semantics,
thanks to
|4.1.2 Ambiguous conditions
...
|attempting to obtain the execution token, (e.g., with 6.1.0070 ',
|6.1.1550 FIND, etc. of a definition with undefined interpretation |semantics;
And given
|6.1.0070 '
...
|When interpreting, ' xyz EXECUTE is equivalent to xyz.
one can argue that ' should return the xt representing the
interpretation semantics of the word.
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
Yes, both "interpretation semantics" and "compilation semantics" are
types of execution semantics, which should be obvious by the fact that
they can be represented by tokens on the stack which, when EXECUTEd will
perform the behavior required in the appropriate STATE, as illustrated
by the one-line text interpreter.
I don't think it is particularly useful to think of interpretation
semantics as a type of execution semantics, just because it is
represented by an xt. And looking at <https://forth-standard.org/proposals/reword-the-term-execution-token-?hideDiff#reply-742>,
all voting members in the 2021 Forth200x meeting agreed.
Yes, you can argue that for :noname definitions we talk only about
execution semantics (and they are represented by an xt), and therefore
the xt we get from NAME>INTERPRET for a named word also represents
some kind of execution semantics, but what would be the point?
Concerning compilation semantics, they are represented by ( x xt ),
not just by an xt, so it's much harder to argue that there is some (anonymous) word around that has these compilation semantics as
execution semantics. E.g., the compilation semantics of + might be represented by
' + ' compile,
On 10/9/22 02:51, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
On 10/4/22 16:36, Ruvim wrote:[...]
In a dual-token system there are explicitly two types of
execution semantics: "interpretation semantics" or "compilation
semantics."
I would say: There is interpretation semantics and there is
compilation semantics. There have been some arguments that execution
semantics is a third entity, but given that there are no words that
have defined execution semantics and defined interpretation semantics
where these two differ, I view execution semantics for a named word as
a helper concept for defining interpretation and/or compilation
semantics.
Yes, it should be "interpretation semantics" and "compilation
semantics". Execution semantics, in concrete form, is represented by an
xt.
When the xt is EXECUTEd, the "execution semantics" are performed.
Likewise, "interpretation semantics" and "compilation semantics" may be >represented by xt's. They are simply particular types of execution
semantics.
It is easier to understand which one we are talking about.
In contrast, for a traditional system, we have to determine whether the
single xt representing execution semantics for a word corresponds to
compilation semantics or to interpretation semantics by checking the
precedence flag for the word.
Actually, in a traditional single-xt+immediate-flag system, the xt
always represents the interpretation semantics, and is always part of
the compilation semantics: if the word is immediate, the compilation
semantics are to EXECUTE the xt (immediate compilation semantics),
otherwise they are to COMPILE, the xt (default compilation semantics).
There is no way to create words with compilation semantics that are
neither default nor immediate.
I don't see any distinction between your description and mine
For other cases, the compilation semantics may differ from the
initialized compilation semantics, e.g. when the new compilation
semantics includes the older one but provides additional behavior to >instrument the word's usage.
On 2022-10-07 03:01, Krishna Myneni wrote:
In a dual-xt system, which xt do you expect tick or ['] to return?
xt-interp or xt-comp? It should return xt-interp for backward
compatibility with single-xt systems.
The standard does not specify a notion of xt-interp or xt-comp.
On any standard system Tick shall return an xt that identifies the
execution semantics of a word.
When execution semantics are not specified for a standard word, the
system may provide implementation-dependent execution semantics for the
word. But it's ambiguous to perform these execution semantics in the
general case, and it's ambiguous even to apply Tick to such a standard word.
I would not provide the "name>interpret" and "name>compile" words since
they are flawed by design and insufficiently specified to be usable on
any standard system.
On 2022-10-07 03:01, Krishna Myneni wrote:
On 10/6/22 15:40, Ruvim wrote:
On 2022-10-05 09:26, Krishna Myneni wrote:
[...]
It sounds incorrectly. By this wording you revoke access to the
identifier of the execution semantics for a word.
Not really. In a dual-token system there are explicitly two types of
execution semantics: "interpretation semantics" or "compilation
semantics." It is easier to understand which one we are talking
about. In contrast, for a traditional system, we have to determine
whether the single xt representing execution semantics for a word
corresponds to compilation semantics or to interpretation semantics
by checking the precedence flag for the word.
The standard allows the single-xt approach in implementations as well
as dual-xt or dual-nt approach. And it specifies an abstract model
over all possible implementation variants. And it specifies (should
specify) only APIs that don't depend on a particular implementation
or approach. And a standard program is not bothered whether it runs
on a single-xt system, or on a dual-xt system.
The standard specifies the execution semantics term, and the Tick
method (among other) to obtain an execution token for a word that
identifies the execution semantics of the word. To perform the
interpretation semantics for the word, "execute" should be applied to
this token in interpretation state. It's true for any standard
system, regardless whether it's a single-xt system or dual-xt system.
Sure, we can classify execution semantics by some types, according to
their internal properties. For example, execution semantics can be
either STATE-dependent or STATE-independent.
But "interpretation semantics" and "compilation semantics" are not
types of execution semantics. These terms are already occupied and
defined in the standard. Don't clutter them with other meanings.
Choose other names.
Yes, both "interpretation semantics" and "compilation semantics" are
types of execution semantics, which should be obvious by the fact that
they can be represented by tokens on the stack which, when EXECUTEd
will perform the behavior required in the appropriate STATE, as
illustrated by the one-line text interpreter.
Well, then please provide definitions of these types, and criteria — how
to detect whether an xt identifies execution semantics of one or another type.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 36:30:13 |
| Calls: | 6,707 |
| Files: | 12,239 |
| Messages: | 5,353,437 |