On 10/21/22 10:11, Krishna Myneni wrote:
...
> Also, you may want to apply my test of your word DUAL` in other standard
> systems to see what they do.
>
...

Also, here is the test under VfxLin64 (Vfx Forth for Linux;
noncommercial version). It appears to be missing the word FIND-NAME but
the nt of a word may be obtained through its xt via >NAME. Then, the
sequence " ' foo >NAME" is equivalent to s" foo" FIND-NAME.

: compilation state @ 0<> ; ok
: dual` 2>r : 2r> postpone 2literal
[: compilation if nip else drop then execute ;]
compile, postpone ; immediate ; ok
:noname ." foo" ; ok-1
:noname ." bar" ; ok-2
dual` foo ok

\ The test prints FOO
' foo >name name>compile execute foo ok

A dual-semantics word may be defined in Vfx Forth using NDCS: as follows:

: foo ." foo" ; ok
ndcs: ." bar" ; ok

Then,

' foo >name name>compile execute bar ok

gives the correct output, "bar".

Thus, Gforth, Vfx Forth, and kForth all give the same test output for
the test. kForth, being a single-xt system, does not presently allow for
dual-semantics; however, Gforth and Vfx Forth do provide a way to define
arbitrary compilation semantics for a word. NAME>COMPILE returns the
proper xt for the compilation semantics of a word, when the word's
compilation semantics is set (using COMPSEM: in Gforth, and NDCS: in Vfx
Forth).

--
Krishna

On 2022-10-21 15:11, Krishna Myneni wrote:
> On 10/21/22 06:23, Ruvim wrote:
>> On 2022-10-20 22:01, Krishna Myneni wrote:
>>> On 10/20/22 15:25, Ruvim wrote:
>> [...]
>>>> And it's an expected behavior for your test, regardless how a word
>>>> "foo" is defined. Isn't it?
>>
>> Regardless how the word "foo" is defined, should your test demonstrate
>> the same behavior that the system demonstrates when the Forth text
>> interpreter encounters the word name "foo" in compilation state?
>>
>
> Perhaps you can pose your question in the form of a test, using only
> standard words, so that there is no possibility of misunderstanding.

Actually this my question is close to my another one[1], where I ask for
a counter example to my statement. Maybe that question is more clear for
understanding.

[1] Re: POSTPONE and semantics of immediate words, 2022-10-20 19:26Z
news://tis7e6$bmv6@dont-email.me
https://groups.google.com/g/comp.lang.forth/c/rjbRkJPLMpY/m/UwKFSswDAAAJ

My point is that for *some* definitions of "foo", and your test in
interpretation state:

s" foo" find-name name>compile execute

this test on your Forth system (and many other) demonstrates a behavior
that is substantively distinct from a behavior that the Forth system
demonstrates when the text interpreter encounters the word "foo" in
compilation state. (even with reservation concerning the different input
source, that can be easy made identical).

Whether such a difference is acceptable or not (according to the current
wording of the "name>compile" glossary entry) depends on understanding
of the "compilation semantics" notion (see the mentioned thread
"POSTPONE and semantics of immediate words").

-----

If you want a test, it's following.

Let us have the helpers:

: leave-compilation ( -- ) postpone [ ;
: enter-compilation ( -- ) ] ;

The behavior that the Forth system demonstrates when the text
interpreter encounters the word name "foo" in compilation state can be
identified by the execution semantics of the following word:

: behave-via-evaluate ( i*x -- j*x )
enter-compilation \ start in compilation state
s" foo" evaluate
leave-compilation \ revert interpretation state at the end
;

The behavior of your test can be identified by the word:

: behave-via-name-compile ( i*x -- j*x )
leave-compilation \ ensure interpretation state
s" foo" find-name name>compile execute-foo
leave-compilation \ ensure interpretation state at the end
;

We ensure interpretation state at the beginning of this word since your
test is started in interpretation state:

s" foo" find-name name>compile execute

For the sake of simplicity, the input source was not made identical in
these two ways of performing the behavior, but it can easy corrected.

According the the term definitions for the term "compilation semantics",
the words "behave-via-evaluate" and "behave-via-name-compile" should
always produce the same effects (with mentioned reservation about
different input sources).

--
Ruvim

On 2022-10-24 19:16, Ruvim wrote:
[...]

>
> If you want a test, it's following.
>
> Let us have the helpers:
>
>   : leave-compilation ( -- ) postpone [ ;
>   : enter-compilation ( -- ) ] ;
>
> The behavior that the Forth system demonstrates when the text
> interpreter encounters the word name "foo" in compilation state can be
> identified by the execution semantics of the following word:
>
>   : behave-via-evaluate ( i*x -- j*x )
>     enter-compilation \ start in compilation state
>     s" foo" evaluate
>     leave-compilation \ revert interpretation state at the end
>   ;
>
> The behavior of your test can be identified by the word:
>
>   : behave-via-name-compile ( i*x -- j*x )
>     leave-compilation \ ensure interpretation state
>     s" foo" find-name name>compile execute-foo
>     leave-compilation \ ensure interpretation state at the end
>   ;
>
> We ensure interpretation state at the beginning of this word since your
> test is started in interpretation state:
>
>   s" foo" find-name name>compile execute
>
> For the sake of simplicity, the input source was not made identical in
> these two ways of performing the behavior, but it can easy corrected.
>
>
> According the the term definitions for the term "compilation semantics",
> the words "behave-via-evaluate" and "behave-via-name-compile" should
> always produce the same effects (with mentioned reservation about
> different input sources).

.... regardless how "foo" is defined, if it can be a part of a standard
program, and there is no ambiguous conditions.

--
Ruvim

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>On 10/14/22 02:21, Anton Ertl wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>> On 10/13/22 10:30, Anton Ertl wrote:
>>>> If SET-OPTIMIZER would not change COMPILE,, it would not work (it
>>>> would fail to set the optimizer). For Gforth's current
>>>> implementation, if SET-COMPSEM did not change NAME>COMPILE, it would
>>>> not work (it would fail to change the compilation semantics).
>>>>
>>>
>>> In the case of standard "COMPILE," the problem is that on a dual-xt
>>> system, "COMPILE," operating on an xt is a fundamentally incorrect way
>>> of compiling a named definition (word).
>>
>> If you mean that, e.g.,
>>
>> : [compile,] compile, ; immediate
>> : foo [ ' s" ] [compile,] bla" ;
>>
>> is not (and must not be) equivalent to
>>
>> : foo s" bla" ;
>>
>> i.e., performing the compilation semantics of S", you are correct.
>>
>> It's also incorrect for performing the compilation semantics of
>>
>> : bar ." bar" ; immediate
>>
>> But
>>
>> : foo1 [ ' bar ] [compile,] ;
>>
>> appends the execution=interpretation=compilation semantics to foo1, so
>> it is equivalent to
>>
>> : foo1 postpone bar ;
>>
>> Ticking named words is unambiguous for most named words, and
>> COMPILE,ing the resulting xt is just as standard as EXECUTEing it.
>>
>
>The above is only true when you are not talking about dual-semantics
>words, where the compilation semantics is not simply that of "ordinary
>words" or of immediate words.

I give concrete examples examples involving S" (a word with
non-default non-immediate compilation semantics) and the immediate
word BAR. What is not true in your opinion?

>Dual-semantics systems permit extended
>compilation semantics. I think your term for such words is "combined
>words". "COMPILE," is inadequate for combined words.

I fail to see the inadequacy.

>>> I understand
>>> your "hack" in Gforth is for the purpose of maintaining backwards
>>> compatibility.
>>
>> I don't know what you mean with '"hack"'. Forth has COMPILE, for
>> appending semantics to the current definition, and NAME>COMPILE for
>> getting the compilation semantics of a named word. These are two
>> different jobs, and Gforth provides SET-OPTIMIZER and SET->COMP,
>> respectively, to provide implementations for these words for the
>> current definition. And that's the right way to do it.
>>
>
>I haven't implemented a dual-semantics system, so I won't strongly opine
>on this other than to say, at the present time it does not seem to me
>the right way to do it. "COMPILE," when used with NAME>INTERPRET, or
>equivalently with '(tick) is fine when it is desired to append the
>interpretation semantics, but for appending the compilation semantics of
>a "combined word", one should use NAME>COMPILE and EXECUTE.

Sure, but that does not make COMPILE, "inadequate". In particular, in
Gforth NAME>COMPILE for words with default compilation semantics is

: default-name>comp ( nt -- w xt )
name>interpret ['] compile, ;

[Actually, this is not quite true. With the current Gforth header
layout NAME>INTERPRET is a noop for the words with DEFAULT-NAME>COMP
as NAME>COMPILE implementation, so the code above has been simplified
to

' compile, AConstant default-name>comp ( nt -- w xt )
]

Essentially, NAME>COMPILE and COMPILE, are two words for two different
purposes that work at two different times. When you text-interpret,
e.g., DUP in compilation state, the text interpreter first gets the NT
of DUP, then performs NAME>COMPILE on that, and then EXECUTEs the
result of that; this EXECUTE performs "COMPILE," and that then appends
the execution semantics of DUP to the current definition (in an
optimized way, thanks to SET-OPTIMIZER).

For another example, if you text-interpret IF in compilation state,
NAME>COMPILE produces the xt1 xt2, where xt2 is the xt of EXECUTE and
xt1 is the xt of

: IF ( compilation -- orig ; run-time f -- ) \ core
POSTPONE ?branch >mark? ; immediate restrict

No COMPILE, involved, right? Wrong! When xt1 is performed, it
performs the compilation semantics of ?BRANCH, which leads to
COMPILE,ing the xt of ?BRANCH.

>> Because one often follows the other, there have been attempts to use
>> one mechanism for both purposes:
>>
>> * It is incorrect to use SET-OPTIMIZER for changing the compilation
>> semantics.
>>
>> * If you use SET->COMP for changing the code generation, you don't
>> cover the cases that COMPILE, xts directly instead of going through
>> NAME>COMPILE, and you have to provide a fallback mechanism for
>> COMPILE,ing that; and if you implement [COMPILE], you also have to
>> tell it which uses of SET->COMP change the default compilation
>> semantics and which don't. You may think that you are saving
>> complexity by eliminating SET-OPTIMIZER, but the complexity pops up
>> elsewhere.
>>
>
>I think what I'm advocating is that, in a dual-semantics system, the
>programmer should be aware of when to use "COMPILE," and when not to use
>it -- namely use it only for those definitions for which a name token is
>meaningless,

There is no reason for this restriction.

>and for words (named definitions) always use a compilation
>chain which starts with the name token.

Apart from the rare (and non-standard) uses of LASTXT, you can always
follow a chain back to the name token: The only way to get xts of such
words are NAME>INTERPRET, NAME>COMPILE, and '/[']; and the latter can
be seen as using NAME>INTERPRET as its factor.

>>When I use "COMPILE,"
>deliberately I don't want the Forth system to alter the xt I give to
>"COMPILE," behind the scenes due to the presence of arbitrary
>compilation semantics.

I have no idea why you would be worried about that.

>> I think that providing both mechanisms is a good solution, because it
>> also provides a nice separation of concerns: If you want to change the
>> generated code without changing the semantics (i.e., if you want to
>> optimize), use SET-OPTIMIZER; if you want to change the compilation
>> semantics, use SET->COMP (or, by extension, SET-COMPSEM).
>>
>
>Optimization is simply one rationale for changing the compilation
>semantics.

It should not be.

>I don't feel strongly about SET-OPTIMIZER as a substitute for
>SET-COMPSEM.

It's not a substitute for SET-COMPSEM. Using SET-OPTIMIZER where
SET-COMPSEM is appropriate (i.e., for changing compilation semantics)
is incorrect.

>What concerns me is that it modifies the behavior of
>"COMPILE,". That seems to me to be unnecessary.

If "," is fine for your system as implementation of "COMPILE,", you
don't need SET-OPTIMIZER (and you can implement it as

: set-optimizer drop ;

). Otherwise, that's what it is there for.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>What I should have said is that
>compilation of a word should not be done with '(tick) and "COMPILE," but
>start with the name token, e.g. S" <name>" FIND-NAME and then use
>NAME>COMPILE and EXECUTE to append the appropriate semantics.

These are two different operations in general:

: foo [ ' <word> compile, ] ;

makes FOO perform the interpretation semantics of <word>.

: bar [ s" <word>" find-name name>compile execute ] ;

is equivalent to

: bar <word> ;

If you want to perform the former operation, you will in general not
get it by doing the latter operation. So you cannot replace the
former usage with the latter usage (or vice versa) in the general
case.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>It is further worth noting that on an *ideal* dual-xt system, as opposed
>to a system which allows for dual-semantics, NAME>COMPILE would simply
>have the following stack diagram for all three cases:
>
>nt -- xt-comp xt-execute \ xt-comp represents the compilation semantics
>
>Then the xt-execute may be dispensed with and NAME>INTERPRET and some
>differently named NAME>COMPILE both would simply return a single xt. In
>the *ideal* dual-xt system, we should be able to define
>
>: NAME>COMPSEM ( nt -- xt-comp ) NAME>COMPILE DROP ;
>
>EXECUTE(ing) xt-comp will perform the compilation semantics. This is not
>how Gforth works at present (see case I). But, in my opinion, it would
>be a cleaner and more consistent design, and easier to understand for
>the programmer.

I thought so at some time (maybe 20 years ago). I no longer do so.
The reasons are:

* Implementation cost: For every word X with default compilation
semantics, you would need something like:

:noname ['] X compile, ;

to have an xt-comp that NAME>COMPSEM would return. Ok, one can work
out ways to make this more space-efficient, but that eats up the
little understandability advantage that NAME>COMPSEM gives over
NAME>COMPILE.

* This approach emphasizes words with non-default non-immediate
compilation semantics. I think that such words should be avoided,
and with recognizers we have found ways to get rid of most of them;
unfortunately, they rear their ugly heads in people wanting
interpretive quotations and closures, so we may not be able to get
rid of them (and of course we still need them for backwards
compatibility with Forth-2012).

* And while we are at backwards compatibility, there is still
[COMPILE]. In Gforth it can recognize that a word has default
compilation semantics by looking at xt2 returned by
NAME>COMPILE ( nt -- xt1 xt2 )
EXIT is the exception that proves the rule.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

On 10/29/22 08:41, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> What I should have said is that
>> compilation of a word should not be done with '(tick) and "COMPILE," but
>> start with the name token, e.g. S" <name>" FIND-NAME and then use
>> NAME>COMPILE and EXECUTE to append the appropriate semantics.
>
> These are two different operations in general:
>
> : foo [ ' <word> compile, ] ;
>
> makes FOO perform the interpretation semantics of <word>.
>

It is not true that FOO will perform the interpretation semantics of
<word> in Gforth if SET-OPTIMIZER has been used to change the
implementation of its compilation semantics. This is exactly my
objection to SET-OPTIMIZER -- it changes what COMPILE, does.

--
Krishna

On 2022-10-29 13:41, Anton Ertl wrote:
[...]

>
> : bar [ s" <word>" find-name name>compile execute ] ;
>
> is equivalent to
>
> : bar <word> ;

Yes, they shall be equivalent according to the specification for
"name>compile", but in Gforth v0.7.9_20221027 these expressions are not
equivalent (in some cases, e.g. for immediate STATE-dependent words).

For example:

: foo state @ 0= lit, ; immediate

: bar [ s" foo" find-name name>compile execute ] ; \ (1)
bar . \ prints "-1" in Gforth

: bar foo ; \ (2)
bar . \ prints "0" in Gforth

So, equivalence of the given expressions does not hold in Gforth.

A practical question: do you have an example when you need the
expression (1) to produce a different result than the expression (2)?

--
Ruvim

On 2022-10-29 16:10, Krishna Myneni wrote:
> On 10/29/22 08:41, Anton Ertl wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>> What I should have said is that
>>> compilation of a word should not be done with '(tick) and "COMPILE," but
>>> start with the name token, e.g. S" <name>" FIND-NAME and then use
>>> NAME>COMPILE and EXECUTE to append the appropriate semantics.
>>
>> These are two different operations in general:
>>
>> : foo [ ' <word> compile, ] ;
>>
>> makes FOO perform the interpretation semantics of <word>.
>>
>
> It is not true that FOO will perform the interpretation semantics of
> <word> in Gforth if SET-OPTIMIZER has been used to change the
> implementation of its compilation semantics. This is exactly my
> objection to SET-OPTIMIZER -- it changes what COMPILE, does.

It's a weak argument, since it can be easily eliminated by a proper
specification for "set-optimizer" (or a similar word).

For example:

set-xt-compiler ( xt.compiler xt -- )

Associate xt.compiler with xt. After that xt.compiler is performed to
append the execution semantics identified by xt to the current definition.
An ambiguous condition exists if the execution semantics identified by
xt.compiler are not equivalent to appending the execution semantics
identified by xt to the current definition.

In this variant we don't change compilation semantics of any word, and
it's impossible without falling into an ambiguous condition.

My objection is to the Anton's (and your also) wording only — the use of
"interpretation semantics" in the sense of "execution semantics".

If we use the term "interpretation semantics" in the meaning that is
distinct from its normative notion (according to the Definitions of
terms), we have to introduce other name for this original normative
notion. It only produces more confusions and forces us to use more
verbose wordings to clarify what namely is meant.

--
Ruvim

On 10/29/22 16:41, Ruvim wrote:
> On 2022-10-29 16:10, Krishna Myneni wrote:
>> On 10/29/22 08:41, Anton Ertl wrote:
>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>>> What I should have said is that
>>>> compilation of a word should not be done with '(tick) and "COMPILE,"
>>>> but
>>>> start with the name token, e.g. S" <name>" FIND-NAME and then use
>>>> NAME>COMPILE and EXECUTE to append the appropriate semantics.
>>>
>>> These are two different operations in general:
>>>
>>> : foo [ ' <word> compile, ] ;
>>>
>>> makes FOO perform the interpretation semantics of <word>.
>>>
>>
>> It is not true that FOO will perform the interpretation semantics of
>> <word> in Gforth if SET-OPTIMIZER has been used to change the
>> implementation of its compilation semantics. This is exactly my
>> objection to SET-OPTIMIZER -- it changes what COMPILE, does.
>
> It's a weak argument, since it can be easily eliminated by a proper
> specification for "set-optimizer" (or a similar word).
> ...

You can't unbreak "COMPILE," with a specification for SET-OPTIMIZER. I
expect "COMPILE," per the standard, to append exactly the semantics
given by xt, in this case the xt corresponding to the interpretation
semantics of the word. Although you are fixed on the term "execution
semantics", for a dual-semantics system, '(tick) returns the
interpretation semantics for the word.

The user (or programmer) must rely on "COMPILE," appending exactly the
semantics of the xt that is specified, and not substitute some other xt.

6.2.0945
COMPILE, “compile-comma” CORE EXT
Interpretation: Interpretation semantics for this word are undefined.
Execution: ( xt – – )
Append the execution semantics of the definition represented by xt to
the execution semantics of the current definition.

Not doing so causes problems such as the incompatibility I ran into
between using COMPSEM: in Gforth vs NDCS: in Vfx Forth. Gforth's
COMPSEM: does not change the action of "COMPILE," but Vfx Forth's NDCS:
does, making changing the compilation semantics non-portable between the
two systems if "COMPILE," is used to define the new semantics.

--
Krishna

On 2022-10-29 23:14, Krishna Myneni wrote:
> On 10/29/22 16:41, Ruvim wrote:
>> On 2022-10-29 16:10, Krishna Myneni wrote:
>>> On 10/29/22 08:41, Anton Ertl wrote:
>>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>>>> What I should have said is that
>>>>> compilation of a word should not be done with '(tick) and
>>>>> "COMPILE," but
>>>>> start with the name token, e.g. S" <name>" FIND-NAME and then use
>>>>> NAME>COMPILE and EXECUTE to append the appropriate semantics.
>>>>
>>>> These are two different operations in general:
>>>>
>>>> : foo [ ' <word> compile, ] ;
>>>>
>>>> makes FOO perform the interpretation semantics of <word>.
>>>>
>>>
>>> It is not true that FOO will perform the interpretation semantics of
>>> <word> in Gforth if SET-OPTIMIZER has been used to change the
>>> implementation of its compilation semantics. This is exactly my
>>> objection to SET-OPTIMIZER -- it changes what COMPILE, does.
>>
>> It's a weak argument, since it can be easily eliminated by a proper
>> specification for "set-optimizer" (or a similar word).
>> ...
>
> You can't unbreak "COMPILE," with a specification for SET-OPTIMIZER.
> I expect "COMPILE," per the standard, to append exactly the semantics
> given by xt,

In what case does it append the semantics given by xt *inexactly*? Could
you provide an example?

Have a look:

: tuck ( x2 x1 -- x1 x2 x1 ) swap over ;

: compile-tuck-v1 ['] tuck compile, ;

: compile-tuck-v2 ['] swap compile, ['] over compile, ;

Are you agree that "compile-tuck-v1" and "compile-tuck-v2" both append
the same semantics?

> in this case the xt corresponding to the interpretation
> semantics of the word.

It makes impression that (according to your understanding) the
interpretation semantics of this word and the execution semantics of
this word are *not* the same in this case. It is right?

If they are the same, could you provide an example when they are not the
same?

> Although you are fixed on the term "execution
> semantics", for a dual-semantics system, '(tick) returns the
> interpretation semantics for the word.

I just use the language of the standard, and the terminology of the
standard.

The language of the standard is agnostic on whether a system employs the
dual-xt or single-xt approach. There is no one reason to expose the
internal details of an dual-xt system when we talk about behavior of a
system that is observable by a standard program.

> The user (or programmer) must rely on "COMPILE," appending exactly the
> semantics of the xt that is specified, and not substitute some other xt.
>
> 6.2.0945
> COMPILE, “compile-comma” CORE EXT
> Interpretation: Interpretation semantics for this word are undefined.
> Execution: ( xt – – )
> Append the execution semantics of the definition represented by xt to
> the execution semantics of the current definition.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

BTW, take a look, during compilation of a definition, namely the
execution semantics of this definition are created. And Tick returns an
identifier namely of these semantics (this behavior).

Please, don't tell me that in a dual-xt system it creates the
interpretation semantics — it does not matter how your system
intertwists things under the hood — it's its internal business.

From a standard program point of view, this behavior is execution
semantics of the word, which in some cases can be equivalent to the
interpretation semantics of the word, of course. But there is no one
case when it's incorrect to call this behavior "execution semantics".

--
Ruvim

On 10/30/22 03:17, Ruvim wrote:
> On 2022-10-29 23:14, Krishna Myneni wrote:
>> On 10/29/22 16:41, Ruvim wrote:
>>> On 2022-10-29 16:10, Krishna Myneni wrote:
>>>> On 10/29/22 08:41, Anton Ertl wrote:
>>>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>>>>> What I should have said is that
>>>>>> compilation of a word should not be done with '(tick) and
>>>>>> "COMPILE," but
>>>>>> start with the name token, e.g. S" <name>" FIND-NAME and then use
>>>>>> NAME>COMPILE and EXECUTE to append the appropriate semantics.
>>>>>
>>>>> These are two different operations in general:
>>>>>
>>>>> : foo [ ' <word> compile, ] ;
>>>>>
>>>>> makes FOO perform the interpretation semantics of <word>.
>>>>>
>>>>
>>>> It is not true that FOO will perform the interpretation semantics of
>>>> <word> in Gforth if SET-OPTIMIZER has been used to change the
>>>> implementation of its compilation semantics. This is exactly my
>>>> objection to SET-OPTIMIZER -- it changes what COMPILE, does.
>>>
>>> It's a weak argument, since it can be easily eliminated by a proper
>>> specification for "set-optimizer" (or a similar word).
>>> ...
>>
>> You can't unbreak "COMPILE," with a specification for SET-OPTIMIZER.
>> I expect "COMPILE," per the standard, to append exactly the semantics
>> given by xt,
>
> In what case does it append the semantics given by xt *inexactly*? Could
> you provide an example?
>

See

https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/YQVN1g-kBAAJ

...
>
>> in this case the xt corresponding to the interpretation semantics of
>> the word.
>
> It makes impression that (according to your understanding) the
> interpretation semantics of this word and the execution semantics of
> this word are *not* the same in this case. It is right?
>
> If they are the same, could you provide an example when they are not the
> same?
>

Even in a single-xt system with only one xt per word, it makes sense to
talk of interpretation semantics and compilation semantics. Depending on
the immediate flag, the compilation semantics are derived from either
executing or compiling the xt. Both involve using the single xt as an
argument to the xt of EXECUTE or COMPILE, . Thus tick can always simply
return the single xt.

For a dual-xt system, one must choose which xt, xt-interp or xt-comp is
returned by '(tick). It makes sense for backwards compatibility to
return xt-interp for application of '(tick) (and for [']). Here it makes
no sense to say that '(tick) returns the "execution semantics" of the
word. '(tick) specifically returns xt-interp. The language of the
standard is insufficient (imprecise) to describe the action of '(tick)
for a dual-xt system.

6.1.0070
6. CORE Word Set
“tick”
’
CORE
( “<spaces>name” – – xt )
Skip leading space delimiters. Parse name delimited by a space. Find
name and return xt, the execution token for name. An ambiguous condition
exists if name is not found. When interpreting, ’ xyz EXECUTE is
equivalent to xyz.

>
>
>
>> Although you are fixed on the term "execution semantics", for a
>> dual-semantics system, '(tick) returns the interpretation semantics
>> for the word.
>
> I just use the language of the standard, and the terminology of the
> standard.
>
> The language of the standard is agnostic on whether a system employs the
> dual-xt or single-xt approach. There is no one reason to expose the
> internal details of an dual-xt system when we talk about behavior of a
> system that is observable by a standard program.
>

It may be agnostic, but it is not sufficiently precise for a dual-xt
implementation.

>
>
>> The user (or programmer) must rely on "COMPILE," appending exactly the
>> semantics of the xt that is specified, and not substitute some other xt.
>>
>> 6.2.0945
>> COMPILE, “compile-comma” CORE EXT
>> Interpretation: Interpretation semantics for this word are undefined.
>> Execution: ( xt – – )
>> Append the execution semantics of the definition represented by xt to
>> the execution semantics of the current definition.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> BTW, take a look, during compilation of a definition, namely the
> execution semantics of this definition are created. And Tick returns an
> identifier namely of these semantics (this behavior).
>
> Please, don't tell me that in a dual-xt system it creates the
> interpretation semantics — it does not matter how your system
> intertwists things under the hood — it's its internal business.
>
> From a standard program point of view, this behavior is execution
> semantics of the word, which in some cases can be equivalent to the
> interpretation semantics of the word, of course.  But there is no one
> case when it's incorrect to call this behavior "execution semantics".
>

I've pretty much said all I have to say on both the matters of how I
think "COMPILE," should behave, and why "execution semantics" is no
longer an adequate term to use in the specification of some words, if
the standard is to be applicable to both single-xt and dual-xt system.
My views are expressed within my last three topical posts on c.l.f.

There appears to be no immediate resolution for a consensus on these
topics, which is fine. However, I won't engage in an endless discussion
of these topics.

--
Krishna

On 2022-10-30 20:02, Krishna Myneni wrote:
> On 10/30/22 03:17, Ruvim wrote:
>> On 2022-10-29 23:14, Krishna Myneni wrote:
>>> On 10/29/22 16:41, Ruvim wrote:
>>>> On 2022-10-29 16:10, Krishna Myneni wrote:
>>>>> On 10/29/22 08:41, Anton Ertl wrote:
>>>>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>>>>>> What I should have said is that
>>>>>>> compilation of a word should not be done with '(tick) and
>>>>>>> "COMPILE," but
>>>>>>> start with the name token, e.g. S" <name>" FIND-NAME and then use
>>>>>>> NAME>COMPILE and EXECUTE to append the appropriate semantics.
>>>>>>
>>>>>> These are two different operations in general:
>>>>>>
>>>>>> : foo [ ' <word> compile, ] ;
>>>>>>
>>>>>> makes FOO perform the interpretation semantics of <word>.
>>>>>>
>>>>>
>>>>> It is not true that FOO will perform the interpretation semantics
>>>>> of <word> in Gforth if SET-OPTIMIZER has been used to change the
>>>>> implementation of its compilation semantics. This is exactly my
>>>>> objection to SET-OPTIMIZER -- it changes what COMPILE, does.
>>>>
>>>> It's a weak argument, since it can be easily eliminated by a proper
>>>> specification for "set-optimizer" (or a similar word).
>>>> ...
>>>
>>> You can't unbreak "COMPILE," with a specification for SET-OPTIMIZER.
>>> I expect "COMPILE," per the standard, to append exactly the semantics
>>> given by xt,
>>
>> In what case does it append the semantics given by xt *inexactly*?
>> Could you provide an example?
>>
>
> See
>
> https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/YQVN1g-kBAAJ

| If SET-OPTIMIZER is used to alter
| the compilation semantics of a word

If "set-optimizer" is proper specified, it's impossible to use it to
alter the compilation semantics for a word in a standard program.
Concerning nonstandard programs — they are not in the scope of the
standard at all.

> ..
>>
>>> in this case the xt corresponding to the interpretation semantics of
>>> the word.
>>
>> It makes impression that (according to your understanding) the
>> interpretation semantics of this word and the execution semantics of
>> this word are *not* the same in this case. It is right?
>>
>> If they are the same, could you provide an example when they are not
>> the same?
>>
>
> Even in a single-xt system with only one xt per word, it makes sense to
> talk of interpretation semantics and compilation semantics. Depending on
> the immediate flag, the compilation semantics are derived from either
> executing or compiling the xt. Both involve using the single xt as an
> argument to the xt of EXECUTE or COMPILE, . Thus tick can always simply
> return the single xt.
>

> For a dual-xt system, one must choose which xt, xt-interp or xt-comp is
> returned by '(tick).

In my dual-xt system one xt identifies the execution semantics of a
word, and another one is used to perform the compilation semantics for
the word. This way better fits the standard model.

> It makes sense for backwards compatibility to
> return xt-interp for application of '(tick) (and for [']). Here it makes
> no sense to say that '(tick) returns the "execution semantics" of the
> word. '(tick) specifically returns xt-interp.

> The language of the
> standard is insufficient (imprecise) to describe the action of '(tick)
> for a dual-xt system.

The standard should not describe a particular dual-xt system. But the
system, to be a standard system, should fit what the standard describes.
If the system does not fit that, then the system just is not standard.

[...]
>
> I've pretty much said all I have to say on both the matters of how I
> think "COMPILE," should behave, and why "execution semantics" is no
> longer an adequate term to use in the specification of some words, if
> the standard is to be applicable to both single-xt and dual-xt system.
> My views are expressed within my last three topical posts on c.l.f.

If it is no longer adequate, it's unclear since what a moment (and what
was changed in that moment).

I still don't understand your grounds. And some simple closed questions
(yes/no) have remained unanswered.

From my point of view, "compile," and "execution semantics" are pretty
adequate in the model that the standard describes.

> There appears to be no immediate resolution for a consensus on these
> topics, which is fine. However, I won't engage in an endless discussion
> of these topics.

Thank you for the discussion, it was useful anyway :)

--
Ruvim

On 11/1/22 03:18, Ruvim wrote:
> On 2022-10-30 20:02, Krishna Myneni wrote:

>   | If SET-OPTIMIZER is used to alter
>   | the compilation semantics of a word
>
> If "set-optimizer" is proper specified, it's impossible to use it to
> alter the compilation semantics for a word in a standard program.
> Concerning nonstandard programs — they are not in the scope of the
> standard at all.
> ...

Anton corrected me earlier when I claimed SET-OPTIMIZER (in Gforth) is
used to alter the compilation semantics of a word. Although it *can*
alter the compilation semantics of a word, it is intended to be used to
change the implementation of the compilation semantics, i.e. append the
same semantics but which executes more efficiently. In Gforth,
SET-COMPSEM is used to change the compilation semantics of a word in a
dual-semantics system. Doing so may well be outside of the scope of the
current standard, but, as we have seen it can be a useful tool to extend
the capabilities of a Forth system.

> From my point of view,  "compile," and "execution semantics" are pretty
> adequate in the model that the standard describes.
>
>
>> There appears to be no immediate resolution for a consensus on these
>> topics, which is fine. However, I won't engage in an endless
>> discussion of these topics.
>
>
> Thank you for the discussion, it was useful anyway :)
>
>

Finding a commonly agreed-upon way of talking about topics like
dual-semantics systems seems to be challenging. I have no doubt the
discussion will come up again, but it's worthwhile to take a break from
it too.

--
Krishna