On 2021-07-12 16:19, P Falth wrote:
> On Monday, 12 July 2021 at 14:46:34 UTC+2, Ruvim wrote:
>> On 2021-07-10 14:42, Krishna Myneni wrote:
>>> On 7/7/21 11:57 AM, Ruvim wrote:
>>>> On 2021-06-21 14:42, Krishna Myneni wrote:
>>>>> On 6/19/21 3:03 PM, Ruvim wrote:
>>>>> ...
>>>>>>
>>>>>> Let "foo" is a word that doesn't perform any parsing, doesn't access
>>>>>> the parse area, and doesn't enter into compilation or interpretation
>>>>>> state (i.e., any such behavior is not a part of any semantics for
>>>>>> "foo").
(1)

>>>>>>
>>>>>> Let the word "compile-foo" is defined as:
>>>>>> : compile-foo postpone foo ;
>>>>>> and it has the same scope as the word "foo".
>>>>>>
>>>>>>
>>>>>>
>>>>>> Proposition 1.
>>>>>> The phrase:
>>>>>> [ compile-foo ]
>>>>>> is equivalent to the phrase:
>>>>>> foo
>>>>>> in any such context when the phrase is encountered by the Forth
>>>>>> text interpreter in compilation state.
>>>>>>
>>>>>>
>>>>>
>>>>> What is your expectation for use of the phrase "[ COMPILE-FOO ]"
>>>>> inside of a definition, when COMPILE-FOO is tagged as an immediate word?
>>>>>
>>>>> : compile-foo postpone foo ; immediate
>>>>>
>>>>> In this case the compilation semantics of COMPILE-FOO should be the
>>>>> same as its runtime semantics.
>>>>
>>>>
>>>> In the phrase "[ compile-foo ]" in compilation state, the
>>>> interpretation semantics for "compile-foo" are performed, since "["
>>>> enters interpretation state. So in this context it doesn't matter
>>>> whether "compile-foo" is immediate or not, and what its compilation
>>>> semantics.
>>>>
>>>>
>>>>
>>>> Regarding the compilation semantics for an immediate word in general.
>>>>
>>>> I assume, by "runtime semantics" you meant "execution semantics".
>>>>
>>>
>>> Yes.
>>>
>>>> In some cases, the execution semantics (ES) of an immediate word can
>>>> be nonequivalent to its compilation semantics (CS). If you make them
>>>> equivalent, you break the equivalence in P1.
>>>>
>>>> NB: Anton Ertl claimed that ES and CS should be equivalent for any
>>>> immediate word (and then P1 is false, what I consider as
>>>> inconsistency). Don't sure whether he still insist on that.
>>>>
>>>
>>> If an IMMEDIATE word does not have ES = CS, how would dual-xt systems
>>> determine the immediacy of a word?
>> First of all, a system is not obligated to determine whether a word is
>> immediate (in the standard notion) or not. It's enough to determine
>> whether a word is ordinary or not [1].
>>
>> Secondly, I don't see any technical problem with that. Various solutions
>> can be employed depending on a particular implementation. For example, a
>> separate flag can be introduced for that.
>>
>>
>>
>> As I can guess, the question is about a system where two execution
>> tokens are associated with each name token.
>>
>> One execution token (xt-int) is *used* to perform the IS for the word,
>> and another execution token (xt-comp) is *used* to perform the CS for
>> the word. If a word has default CS, then xt-comp is 0.
>
> Not necessarily. In my system a word with default CS has xt-comp=COMPILE,

Yes, it is possible too. Hence you need to compare xt-comp with xt of
"COMPILE,", instead of zero.

Anyway, this variation doesn't affect my reasoning.

>> For an immediate word xt-int and xt-comp are the same and they both are
>> equal to the xt-exec that identifies the ES for the word. And it's for
>> any immediate words. So, to determine whether a word is immediate, the
>> system compares xt-int and xt-comp.
>
> Yes this works in my system
>
>> It's wrong to assume that if CS <> ES, then xt-comp should be unequal to
>> the xt-exec (they still can be the same in some cases). Since xt-comp
>> (in general case) doesn't identify CS. It's only *used* to perform CS.
>>
>>
>> Any execution token (xt) always identifies some ES, and these ES are
>> performed by applying "EXECUTE" to this xt. It's impossible that an
>> execution token doesn't identify some ES.
>>
>>
>> In the same time, some ES can be equivalent (possibly in some
>> conditions) to the CS for some word, or to the IS for some word [2]. In
>> such case, by performing these ES (possibly in those conditions) you
>> perform the corresponding CS or IS.
>
> Yes this is true for IF, ELSE etc in my system
>
>>
>> If the CS are (unconditionally) equivalent to the ES for some word
>> "foo", then the phrase:
>> [ xt-comp(foo) EXECUTE ]
>> is equivalent to the phrase:
>> [ ' foo EXECUTE ]
>> that is equivalent to the phrase:
>> foo
>> in compilation state, where "xt-comp(foo)" returns xt-comp for the word
>> "foo" in the considered system implementation.
>>
>> Hence, if for some word "foo" this phrases are not equivalent, then
>> CS(foo) are not equivalent to the ES(foo). Obviously, it's a possible
>> case — the case of an immediate STATE-dependent word. And in the
>> considered system implementation xt-int = xt-comp in this case.
>>> Would that not make dual-xt systems
>>> inconsistent with the standard?
>> Not in this part. But it depends.
>>
>> At the moment, if "NAME>COMPILE" returns xt-int(foo) and xt-int(EXECUTE)
>> for an immediate STATE-dependent word "foo", then it's incorrect, I think.
>>
>> But the specification for "NAME>COMPILE" can be clarified to relax
>> implementations. Since at the moment it controverts it's own rationale,
>> when it says: "xt2 is the xt of EXECUTE (for immediate words)" [3].
>
> As I read the standard there are no restrictions on what NAME>COMPILE
> can return except that when applying EXECUTE to the returned x xt the CS
> is performed.
>
> In the rational, that you refer to, it is written:
> "In a traditional xt+immediate-flag system, the x xt returned by NAME>COMPILE is typically xt1 xt2,"
> the typically tells us that there can also be implementations where this is not true.
> And it only applies to traditional xt+immediate flag systems, not dual-xt as discussed here.

The problem I refer to is the same for any system implementation that
meets the mentioned conditions. Yes, "NAME>COMPILE" may return any xt at
the top. But it violates the specification *if* it returns xt of the
word and xt of "EXECUTE" for the nt of an immediate STATE-dependent
word. In the same time the rationale implies that this case meets the
specification (i.e., it's correct).

The specification says:
"Executing xt consumes x and performs the compilation semantics of
the word represented by nt".

It says nothing about any additional conditions. It means that in
compilation state the phrase:

[ "foo" find-name name>compile execute ]

should perform the CS for *any* available word "foo" that meets (1)
above. Hence, this phrase should be equivalent to the phrase:

foo

in compilation state (2).

According to the rationale, "name>compile" may return xt of the word and
xt of "EXECUTE" for an immediate word. But this equivalence is not held
*if* this immediate word is STATE-dependent.

For example, if "foo" is defined as

: foo state @ 0<> . ; immediate

and "name>compile" returns ( xt(foo) xt(execute) ) -- according to the
rationale, then the phrases above produce the different results [4].

So we have two options for "name>compile" glossary entry:

a) update the specification to relax implementations and tight
programs (specify that the returned xt should be performed in
compilation state);

b) update the rationale, remove the incorrect case, describe
implementation options for traditional xt+immediate-flag system.

[4] The Anton's position was that the compilation semantics for a word
may include such behavior that cannot be observed in compilation state.
And therefore the consequence (2) is incorrect.

Actually, the standard notion of "execution semantic" doesn't allow such
behavior for compilation semantics:

compilation semantics: The behavior of a Forth definition when its
name is encountered by the text interpreter in compilation state.

So it looks like Anton used another notion of CS. Also, this position
makes impossible some useful equivalences with "postpone" (like P1
above), since the specification for "postpone" relies on "compilation
semantics" notion.

I don't sure whether Anton still sticks on this position.

--
Ruvim