On 2021-05-14 07:03, dxforth wrote:
> On 14/05/2021 02:15, Ruvim wrote:
>> On 2021-05-13 16:07, dxforth wrote:
>>
>>> Go to the definitions:
>>>
>>>   interpretation semantics:
>>>     The behavior of a Forth definition when its name is encountered
>>>     by the text interpreter in interpretation state.
>>>
>>>   6.1.2250 STATE
>>>     ... STATE is true when in compilation state, false otherwise. ...
>>>
>>> So when ANS says 'interpretation semantics undefined' in POSTPONE it
>>> meant STATE=0 - irrespective of whether POSTPONE is being executed
>>> in a definition.
>>
>> It looks like you miss the part "name is encountered by the text
>> interpreter"
>>
>> Interpretation semantics are not about "a name is being execute", but
>> about "a name is being encountered".
>>
>> By your argument, the following definition of "within" [1]:
>>
>>     : within ( test low high -- flag )  over - >r - r> u< ;
>>
>> cannot work in interpretation state:
>>
>>     1  1 5 within . \ prints -1
>>
>> since interpretation semantics for ">r" are undefined.
>
> I can't ignore history and neither did ANS.  By ANS' own commentary
> in A.6.1.2033, POSTPONE is little more than a combination of COMPILE
> and [COMPILE].  Any restrictions on the standard use of POSTPONE is
> a consequence of the use of those historic words.

The problem not only in use of those historical words, but also in their
declared semantics.

In Forth-83 the words "COMPILE" and "[COMPILE]" append execution
semantics, but in Forth-94 the word "POSTPONE" appends compilation
semantics.

That is, the ES for "[COMPILE]" (as well as for "COMPILE") are to append
the ES of another definition to the current definition.

Whereas the CS for "POSTPONE" are to append the CS of another definition
to the current definition.

The differences due to this nuance are only detectable between a
single-xt system and a dual-xt system when these words are applied to
dual-semantics words.

In Forth-83 the only way of implementing dual-semantics words was the
immediacy mechanism. So all standard systems were compatible in this regard.

An example of a dual-semantics word from Forth-83 (appendix B) is the
word "ASCII". This word shows the behavior of the "CHAR" word in
interpretation state, and the behavior of the "[CHAR]" word in
compilation state. Forth-94 refers the first behavior as "interpretation
semantics", the second — as "compilation semantics" for "ASCII", and it
doesn't restrict implementation approaches to the immediacy mechanism.

(NB: By Anton's terminology, the IS and CS for the "ASCII" word are the
same if this word is implemented using the immediacy mechanism, and they
are distinct if this word is implemented in another way. But I find this
terminology deviation very confused.)

Forth-94 doesn't require to implement dual-semantics words using the
immediacy mechanism, and allows to use any other suitable mechanism (see
A.6.1.2033, A.6.1.1550). Thus the problem was to establish such
combination of restrictions on systems and on programs that guarantees
compatibility.

For example, the phrase:

POSTPONE ASCII

should show the same behavior in any standard program, independently how
the "ASCII" word is implemented (whether it's implemented using the
immediacy mechanism or not). I.e., the different systems should show the
same compile-time behavior, and the same run-time behavior in any
allowed conditions.

But a straightforward implementation of "POSTPONE" (that was
historically inherited from "[COMPILE]") in single-xt systems was to
append the ES (instead of the CS) of an immediate word in the argument
to the current definition. And it produces hard incompatibility in the
edge cases.

I can even guess that this issue was still missed out at the time of
Forth-94 release (and then the reason why applying "POSTPONE" to "TO"
was prohibited is not connected with this problem). Since nobody in TC
wanted to disallow single-xt systems (that comprised the majority), but
they only wanted to also allow dual-nt systems, and this intention is
reflected very clear in multiple places of the standard.

Whatever it was, formally the Forth-94 standard implicitly disallowed
the straightforward implementation of "POSTPONE" in single-xt systems.

Obviously, the committee didn't want to ignore the history, and they
eventually released a fix — the official reply to RFI Q99-027, that
restricts programs and allows the straightforward implementation of
"POSTPONE" in single-xt. After that compilation semantics may be
performed by a program only in compilation state.

--
Ruvim

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>If the original example is standard, namely,
>
>: foo postpone . ;
>: bar [ foo ] ;
>
>with the behavior, "1 bar" prints "1", then perhaps it is possible to
>write a word in standard code which can tell whether or not a definition
>is in progress, and may be continued.
>
>FOO is aware of an incomplete definition since FOO is able to append the
>execution semantics of "." to the incomplete definition, even when FOO
>is executed in interpretation state.

Awareness is not necessary. It's sufficient if the code is appended
correctly if there is an incomplete definition.

>There are two other ways, in Gforth, to obtain the same behavior for BAR.
>
>1.
>
>: foo postpone . ; immediate
>: bar foo ;
>
>2.
>
>: foo . ;
>: bar [ ' foo compile, ] ;
>
>Both will give behavior that "1 bar" prints "1". I believe there is no
>dispute that method 1 is consistent with most people's understanding of
>the Forth standard.
>
>For both "POSTPONE" and "COMPILE," the standard says,
>
>"interpretation semantics for this word are undefined"
>
>How do we reconcile the above statement with using POSTPONE and COMPILE,
>in interpretation state?

"using"? You need more terminological precision.

"interpretation semantics" does not mean "using in interpretation
state". A Forth system performs interpretation semantics of a word
primarily when text-interpreting the word in interpretation state. In
the "original example" and 1., POSTPONE is text-interpreted in
compilation state (during the compilation of FOO), so the undefined
interpretation semantics is irrelevant.

In 2., COMPILE, is text-interpreted in interpret state, so this
example is non-standard. However, this can be fixed as follows:

: compile, compile, ;
: foo . ;
: bar [ ' foo compile, ] ;

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

On 5/14/21 12:17 PM, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> If the original example is standard, namely,
>>
>> : foo postpone . ;
>> : bar [ foo ] ;
>>
>> with the behavior, "1 bar" prints "1", then perhaps it is possible to
>> write a word in standard code which can tell whether or not a definition
>> is in progress, and may be continued.
>>
>> FOO is aware of an incomplete definition since FOO is able to append the
>> execution semantics of "." to the incomplete definition, even when FOO
>> is executed in interpretation state.
>
> Awareness is not necessary. It's sufficient if the code is appended
> correctly if there is an incomplete definition.
>

Here, "awareness" implies that FOO has access to a valid pointer for
appending execution semantics of "dot", while in interpretation state,
for an incomplete definition. It is unexpected that the Forth standard
guarantees this to be the case, and perhaps the language of the standard
should be revised to state this explicitly. It is certainly clear that
once compilation state is restored, e.g. [ ... ], then compilation may
resume for an incomplete definition.

>> There are two other ways, in Gforth, to obtain the same behavior for BAR.
>>
>> 1.
>>
>> : foo postpone . ; immediate
>> : bar foo ;
>>
>> 2.
>>
>> : foo . ;
>> : bar [ ' foo compile, ] ;
>>
>> Both will give behavior that "1 bar" prints "1". I believe there is no
>> dispute that method 1 is consistent with most people's understanding of
>> the Forth standard.
>>
>> For both "POSTPONE" and "COMPILE," the standard says,
>>
>> "interpretation semantics for this word are undefined"
>>
>> How do we reconcile the above statement with using POSTPONE and COMPILE,
>> in interpretation state?
>
> "using"? You need more terminological precision.
>
> "interpretation semantics" does not mean "using in interpretation
> state". A Forth system performs interpretation semantics of a word
> primarily when text-interpreting the word in interpretation state. In
> the "original example" and 1., POSTPONE is text-interpreted in
> compilation state (during the compilation of FOO), so the undefined
> interpretation semantics is irrelevant.
>

Yes, that's true, and in fact, if one tries to do POSTPONE in
interpretation state in Gforth the text interpreter throws an error. I
think I was assuming that your claim of no issue with the standard for
the code of the original example, in which FOO appended code while in
interpretation state, extended to COMPILE, as well.

> In 2., COMPILE, is text-interpreted in interpret state, so this
> example is non-standard. However, this can be fixed as follows:
>
> : compile, compile, ;
> : foo . ;
> : bar [ ' foo compile, ] ;
>

As it stands then, code using "COMPILE,", which runs properly in Gforth,
may not be portable to Forth-2012 compliant systems per the standard. In
kForth, the non-standard example with COMPILE, above also works.

Krishna

On 14/05/2021 20:40, Anton Ertl wrote:
> ...
> It's unclear to me why you discuss this Forth-94 stuff as answer to my
> discussion of Forth-83, but anyway, here we go:
>
> No, it means that text-interpreting POSTPONE in interpret state is
> undefined. I.e.:
>
> : foo [ postpone . ] ;
>
> is non-standard, nothing more.

It wasn't the example you gave but I'll bite. Why should it be
non-standard? The following works on SwiftForth, VFX and even
Win32Forth which uses a COMPILE-based POSTPONE.

: foo [ postpone . ] ; immediate
: bar foo ;
1 bar 1 ok

It even works on gforth.

>
>>This restriction almost certainly comes from 79/83-COMPILE and the
>>most popular forth of the day Fig-Forth:
>
> Actually the "Implementation semantics is undefined" specification
> reflects the practice of cmForth to put words like IF into the
> COMPILER vocabulary, but not in the FORTH wordlist; so IF is only
> found by the text interpreter in interpret state (but it can still be
> run in interpret state).
>
> Interestingly, cmForth puts COMPILE in the FORTH wordlist, not in the
> compiler wordlist, even though text-interpreting COMPILE in interpret
> state is guaranteed to have unintended results. The Forth-94
> committee apparently thought that it is a good idea to undefine the
> interpretation semantics of POSTPONE, even though POSTPONE does not
> have this problem of COMPILE.

Who needs POSTPONE to work when STATE=0 ? ANS' view was nobody did.
The example above has little practical value. So ANS let Forth-83
systems keep their COMPILE with ?COMP and use it in POSTPONE.

>> SCR # 41
>> 0 ( COMPILE, SMUDGE, HEX, DECIMAL WFR-79APR20 )
>> 1
>> 2 : COMPILE ( COMPILE THE EXECUTION ADDRESS FOLLOWING *)
>> 3 ?COMP R> DUP 2+ >R @ , ;
>>
>>The ?COMP prevented COMPILE being executed outside a definition
>
> No, it does not, because in fig-Forth ?COMP only tests STATE. You can
> write
>
> ] COMPILE + [ \ without enclosing colon definition
>
> and the ?COMP will not prevent it.

That would be looking for trouble as opposed to making a simple mistake.

> ...
> ?COMP in IF AHEAD UNTIL AGAIN is not compiler security, either. If
> you want to prevent these words from being executed outside colon
> definitions, you need a way to identify whether you are inside a colon
> definition; STATE is not that way, and has not been ever since [ and ]
> were introduced.
>
> But is such a check practically useful? It seems that in Forth,
> Inc. experience it's not:
>
> SwiftForth i386-Linux 3.11.0 23-Feb-2021
> if ok
> .s
> 134761494 <-Top ok
> then ok
> .s
> <-Top ok

Is the result practically useful? It's a rare system that doesn't spit
out an error in this instance.

On 5/14/21 3:18 PM, Krishna Myneni wrote:
> On 5/14/21 12:17 PM, Anton Ertl wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>> If the original example is standard, namely,
>>>
>>> : foo postpone . ;
>>> : bar [ foo ] ;
>>>
>>> with the behavior, "1 bar" prints "1",
....
>>> There are two other ways, in Gforth, to obtain the same behavior for
>>> BAR.
>>>
>>> 1.
>>>
>>> : foo postpone . ; immediate
>>> : bar foo ;
>>>
>>> 2.
>>>
>>> : foo . ;
>>> : bar [ ' foo compile, ] ;
>>>
>>> Both will give behavior that "1 bar" prints "1".
....

Of course, all of this effort to unravel the meaning and validity of
POSTPONE and COMPILE, within the above example to give the desired
behavior to "bar" can be bypassed by going back to the roots of Forth.
No one disputes the validity of the code below, which should work pretty
much universally on all Forth systems over the past thirty years.

: foo . ;
: bar ['] foo execute ;

Perhaps there is a better example to illustrate when coding as in the
original example has some advantage.

Krishna

On 15/05/2021 03:18, Ruvim wrote:
> ...
> Whatever it was, formally the Forth-94 standard implicitly disallowed
> the straightforward implementation of "POSTPONE" in single-xt systems.

What was that? It's hard to imagine an implementation for threaded-code
systems simpler than this:

: defined bl word find ;
: ?defined 0= abort" is undefined" ;

: POSTPONE
defined dup ?defined 0< if compile compile then , ; immediate

In article <s7mptq$d6c$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
<SNIP>
>Of course, all of this effort to unravel the meaning and validity of
>POSTPONE and COMPILE, within the above example to give the desired
>behavior to "bar" can be bypassed by going back to the roots of Forth.
>No one disputes the validity of the code below, which should work pretty
>much universally on all Forth systems over the past thirty years.
>
>: foo . ;
>: bar ['] foo execute ;
>
>Perhaps there is a better example to illustrate when coding as in the
>original example has some advantage.

All this goes away in lucky7.
The example becomes
{ . } : foo
{ 'foo run } : bar

'foo is giving us back the recipe ("lambda" "quotation" "xt" ) { . }
'foo run is *by definition* what happens if encountering foo.
So bar has *by definition* the identical behaviour of foo

>
>Krishna
>
>
>
>
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 2021-05-15 08:45, dxforth wrote:
> On 15/05/2021 03:18, Ruvim wrote:
>> ... Whatever it was, formally the Forth-94 standard implicitly disallowed
>> the straightforward implementation of "POSTPONE" in single-xt systems.
>
> What was that?  It's hard to imagine an implementation for threaded-code
> systems simpler than this:
>
>  : defined  bl word find ;
>  : ?defined  0= abort" is undefined" ;
>
>  : POSTPONE
>    defined dup ?defined 0< if compile compile then , ; immediate

Yes, it's a simple straightforward implementation.

This "POSTPONE" appends ES. And it only works according to the
specification for "POSTPONE" when the appended ES are equivalent to the
CS for the word in the argument.

Therefore this implementation was (implicitly) disallowed by Forth-94,
but later it was (implicitly) allowed by the TC reply to RFI Q99-027
(A99-027).

The incompatibility problem can only arise when performing the ES in
interpretation state are not equivalent to performing the CS, but
A99-027 prohibits performing CS in interpretation state, and hence it
also prohibits performing the appended ES in interpretation state. In
this way A99-027 eliminates the incompatibility problem.

Another way to eliminate the incompatibility problem is a more
sophisticated implementation for "POSTPONE". An example that I mentioned
before: https://git.io/J30D6

--
Ruvim

On 5/14/21 4:17 PM, dxforth wrote:
> On 14/05/2021 20:40, Anton Ertl wrote:
>> ... It's unclear to me why you discuss this Forth-94 stuff as answer
>> to my
>> discussion of Forth-83, but anyway, here we go:
>>
>> No, it means that text-interpreting POSTPONE in interpret state is
>> undefined.  I.e.:
>>
>> : foo [ postpone . ] ;
>>
>> is non-standard, nothing more.
>
> It wasn't the example you gave but I'll bite.  Why should it be
> non-standard?  The following works on SwiftForth, VFX and even
> Win32Forth which uses a COMPILE-based POSTPONE.
>
> : foo [ postpone . ] ; immediate
> : bar foo ;
> 1 bar 1  ok
>
> It even works on gforth.
>

I thought this failed on Gforth, but it does work and outputs a WARNING
about POSTPONE being a compile-only word. However, "COMPILE," is not
treated as a compile-only word in Gforth.

One solution for the Forth standard might be to allow the interpretation
semantics of both POSTPONE and "COMPILE," to be defined when an open
definition, i.e. a definition to which code can be appended, exists. The
interpretation semantics would be undefined otherwise. I don't believe
this would constitute a type of STATE-smartness.

Krishna

On 15/05/2021 21:59, Ruvim wrote:
> On 2021-05-15 08:45, dxforth wrote:
>> On 15/05/2021 03:18, Ruvim wrote:
>>> ... Whatever it was, formally the Forth-94 standard implicitly disallowed
>>> the straightforward implementation of "POSTPONE" in single-xt systems.
>>
>> What was that?  It's hard to imagine an implementation for threaded-code
>> systems simpler than this:
>>
>>  : defined  bl word find ;
>>  : ?defined  0= abort" is undefined" ;
>>
>>  : POSTPONE
>>    defined dup ?defined 0< if compile compile then , ; immediate
>
>
> Yes, it's a simple straightforward implementation.
>
> This "POSTPONE" appends ES. And it only works according to the
> specification for "POSTPONE" when the appended ES are equivalent to the
> CS for the word in the argument.
>
> Therefore this implementation was (implicitly) disallowed by Forth-94,
> but later it was (implicitly) allowed by the TC reply to RFI Q99-027
> (A99-027).

It was the conclusion drawn from an interpretation of Forth-94 that
disallowed it. Had ANS upheld the interpretation it would likely
have created problems for Forth-83 systems implementing POSTPONE.

IMO when interpreting the standard there needs to be consideration for
consequences because it's unlikely ANS would shoot itself in the foot
by invalidating systems or making implementers jump through hoops.
There's plenty of scope to disagree with ANS if one thinks they got it
wrong. I could argue (successfully) that what I did with REPRESENT
was permitted by the standard, but to do so would only promote
fragmentation. Besides which, why should ANS get the credit :)

>
> The incompatibility problem can only arise when performing the ES in
> interpretation state are not equivalent to performing the CS, but
> A99-027 prohibits performing CS in interpretation state, and hence it
> also prohibits performing the appended ES in interpretation state. In
> this way A99-027 eliminates the incompatibility problem.
>
> Another way to eliminate the incompatibility problem is a more
> sophisticated implementation for "POSTPONE". An example that I mentioned
> before: https://git.io/J30D6
>
>
>
> --
> Ruvim
>

On 2021-05-16 06:09, dxforth wrote:
> On 15/05/2021 21:59, Ruvim wrote:
>> On 2021-05-15 08:45, dxforth wrote:
>>> On 15/05/2021 03:18, Ruvim wrote:
>>>> ... Whatever it was, formally the Forth-94 standard implicitly
>>>> disallowed
>>>> the straightforward implementation of "POSTPONE" in single-xt systems.
>>>
>>> What was that?  It's hard to imagine an implementation for threaded-code
>>> systems simpler than this:
>>>
>>>   : defined  bl word find ;
>>>   : ?defined  0= abort" is undefined" ;
>>>
>>>   : POSTPONE
>>>     defined dup ?defined 0< if compile compile then , ; immediate
>>
>>
>> Yes, it's a simple straightforward implementation.
>>
>> This "POSTPONE" appends ES. And it only works according to the
>> specification for "POSTPONE" when the appended ES are equivalent to the
>> CS for the word in the argument.
>>
>> Therefore this implementation was (implicitly) disallowed by Forth-94,
>> but later it was (implicitly) allowed by the TC reply to RFI Q99-027
>> (A99-027).
>
> It was the conclusion drawn from an interpretation of Forth-94 that
> disallowed it.  Had ANS upheld the interpretation it would likely
> have created problems for Forth-83 systems implementing POSTPONE.
>
> IMO when interpreting the standard there needs to be consideration for
> consequences because it's unlikely ANS would shoot itself in the foot
> by invalidating systems or making implementers jump through hoops.

Certainly it's unlikely. But then it's just a mistake: they did
something that was not desired.

If a thing is green, we cannot interpret it as grey. Even if other
things around this one are actually grey. Even if the author didn't want
to make it green, and thought that it's actually grey. Even if it
appeared the author just was wearing a monochromatic glasses. Whatever
it was, we cannot interpret this thing as it's grey.

If this thing should be grey, but actually it's green, then it just
should be repainted grey.

In A99-027 the TC correct a flaw. Eventually, they have rights to fix
any flaw or mistake.

> There's plenty of scope to disagree with ANS if one thinks they got it
> wrong.  I could argue (successfully) that what I did with REPRESENT
> was permitted by the standard, but to do so would only promote
> fragmentation.  Besides which, why should ANS get the credit :)
>
>>
>> The incompatibility problem can only arise when performing the ES in
>> interpretation state are not equivalent to performing the CS, but
>> A99-027 prohibits performing CS in interpretation state, and hence it
>> also prohibits performing the appended ES in interpretation state. In
>> this way A99-027 eliminates the incompatibility problem.
>>
>> Another way to eliminate the incompatibility problem is a more
>> sophisticated implementation for "POSTPONE". An example that I mentioned
>> before: https://git.io/J30D6
>>

--
Ruvim

On 16/05/2021 18:10, Ruvim wrote:
> On 2021-05-16 06:09, dxforth wrote:
>> On 15/05/2021 21:59, Ruvim wrote:
>>> On 2021-05-15 08:45, dxforth wrote:
>>>> On 15/05/2021 03:18, Ruvim wrote:
>>>>> ... Whatever it was, formally the Forth-94 standard implicitly
>>>>> disallowed
>>>>> the straightforward implementation of "POSTPONE" in single-xt systems.
>>>>
>>>> What was that?  It's hard to imagine an implementation for threaded-code
>>>> systems simpler than this:
>>>>
>>>>   : defined  bl word find ;
>>>>   : ?defined  0= abort" is undefined" ;
>>>>
>>>>   : POSTPONE
>>>>     defined dup ?defined 0< if compile compile then , ; immediate
>>>
>>>
>>> Yes, it's a simple straightforward implementation.
>>>
>>> This "POSTPONE" appends ES. And it only works according to the
>>> specification for "POSTPONE" when the appended ES are equivalent to the
>>> CS for the word in the argument.
>>>
>>> Therefore this implementation was (implicitly) disallowed by Forth-94,
>>> but later it was (implicitly) allowed by the TC reply to RFI Q99-027
>>> (A99-027).
>>
>> It was the conclusion drawn from an interpretation of Forth-94 that
>> disallowed it.  Had ANS upheld the interpretation it would likely
>> have created problems for Forth-83 systems implementing POSTPONE.
>>
>> IMO when interpreting the standard there needs to be consideration for
>> consequences because it's unlikely ANS would shoot itself in the foot
>> by invalidating systems or making implementers jump through hoops.
>
>
> Certainly it's unlikely. But then it's just a mistake: they did
> something that was not desired.
>
> If a thing is green, we cannot interpret it as grey. Even if other
> things around this one are actually grey. Even if the author didn't want
> to make it green, and thought that it's actually grey. Even if it
> appeared the author just was wearing a monochromatic glasses. Whatever
> it was, we cannot interpret this thing as it's grey.
>
> If this thing should be grey, but actually it's green, then it just
> should be repainted grey.
>
>
> In A99-027 the TC correct a flaw. Eventually, they have rights to fix
> any flaw or mistake.

The ANS TC disbanded and the document frozen in time along with any
outstanding ambiguities. Those wishing to claim compliance will need
to apply their best judgement.

On 2021-05-12 12:54, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-05-11 13:51, Anton Ertl wrote:
>> [...]
>>> 3) We have discussed POSTPONE repeatedly over the last
>>> quarter-century, and I have established repeatedly that according to
>>> the text of Forth-94 and Forth-2012
>>>
>>> : foo postpone . ;
>>> : bar [ foo ] ;
>>> 1 bar \ prints "1"
>>>
>>> conforms to these standards.
>>
>> According to the only wording in the specification for POSTPONE this
>> code conforms the standard, and it should print "1".
>>
>> But according to the official TC reply to RFI Q99-027, it's not
>> guaranteed that performing "foo" in interpretation state performs
>> compilation semantics for "." (dot), and then this code isn't compliant.
>
>>>> Is there a demonstrated need that it should
>>>> work that would justify amending or clarifying ANS' ruling?
>>>
>>> There is no need to amend or clarify.
>>> The text of the standard is clear.
>>
>> But RFI Q0009 and RFI Q99-027 demonstrate that clarifications were
>> needed in regard to POSTPONE. It means that the text of the standard is
>> not enough clear.
>
> Actually neither of these RFIs states that the text of the standard is
> unclear. On the contrary, Q0009 states that it is clear:
>
> <http://forth.sourceforge.net/std/dpans/q0009.htm>:
> |Nothing in the standard prevents you executing words with compilation
> |semantics from POSTPONE in interpretation state (it does not say that
> |it is ambiguous, so it looks like it is defined through the standard).

Well, you are right: the text of the standard is clear in regard to the
specification for "POSTPONE". But a problem arose despite of that. Since
the problem lies not in the specification for "POSTPONE" itself, but in
the integration of this specification with all other parts, including
the intention, the history, the existent Forth systems and how they
implemented "POSTPONE" at those time.

> The reason for these RFIs is that enough people made claims that did
> not agree with the text of the standard

And what? If you see a mistake, flaw, inconsistency, incompatibility, —
it's OK to disagree with that.

> that the people who asked the question wanted
> an official statement by the TC:
>
> <http://forth.sourceforge.net/std/dpans/q0009.htm>:
> |IMHO the confusion about this topic has reached a point where I need
> |an official statement.
> [...]
> |Opinions: Elizabeth Rather says that compilation semantics requires
> |to be in compilation state.
>
> <http://forth.sourceforge.net/std/dpans/a99-027.txt>:
> |Recent discussions on comp.lang.forth indicate there is a body of opinion
> |which holds that one or both the following are implied by the ANSI Forth
> |Standard:
> |
> | 1. It is an ambiguous condition for a program to perform compilation
> |semantics in the interpretation state.
> |
> | 2. It is an ambiguous condition for a program to append semantics to the
> |current definition in the interpretation state.

> The TC never answered Q0009.

Is it the single unanswered question? I guess, there are many unanswered
questions remained. Then this fact says nothing unique.

OTOH, A99-027 answers to Q0009 too.

> The TC answered Q99-027 without
> referring to the document at all, only to the TC's intent;

Yes. By my understanding, A99-027 is not a clarification per se (i.e.
it's not about how something should be interpreted), but it's the new
general rule. It's the rule that was intended, but was missed in the
normative text.

This rule is not intrinsic, it's not semantically obligated, and thus it
cannot be inducted from other normative parts.

Actually this rule is a concession to the existent Forth systems. We can
see the same concession in the glossary entries and rationales for
"COMPILE,", "CS-PICK", "CS-ROLL", "(LOCAL)", section D.6.7, etc.

These concessions have zero value without this general rule.

> instead of
> referring to the document, they stated that they have "plans to modify
> its terminology in an effort to avoid future misinterpretations of
> this sort [i.e., of TC intent]."

The document cannot be formally referred, since this rule is not
obligated, but just a concession that relaxes implementations and
restricts programs.

"POSTPONE" can be implemented according the specification in any system,
as I shown earlier: https://git.io/J30D6

> They never did. Nobody has proposed
> such a modification for Forth-200x (not before the release of
> Forth-2012 and not since).

But instead of that, somebody screwed the meaning of the "compilation
semantics" term over to show that the classic implementations of
"POSTPONE" are standard compliant for user-defined dual-semantics words
even without A99-027.

"POSTPONE" was proposed not later than 1989, and it appended the
execution semantics, as well as "[COMPILE]" or "COMPILE", in those time.

When the "compilation semantics" notion was introduced, and these words
were specified via this notion, the only way of backward compatibility
with existent systems, and compatibility between the single-xt systems
and dual-xt systems was the rule declared in A99-027.

> With every year of inaction the relevance
> of a99-027 became less, and with the release of Forth-2012 its
> relevance vanished completely.

I cannot agree with that.

Actually, any system that uses the classic implementation of "POSTPONE"
in a signle-xt system, or for user-defined dual-semantics words, relies
on this A99-027.

So the relevance of A99-027 will only begin to vanished when we remove
all the corresponding concessions from the standard and the systems
begin to provide the full fledged implementation for "POSTPONE".

Also, as I already mentioned in another message [1], the main argument
is that a thing that was accepted via a formal standardization process,
may be obsolesced via the same process only.

[1] the message on 2021-04-27, news:s68vue$h17$1@dont-email.me
- the raw message:
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/FjyAGu8EoBk/uw011XpjAgAJ/
- the message in the tread:
https://groups.google.com/g/comp.lang.forth/c/FjyAGu8EoBk/m/uw011XpjAgAJ

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-05-12 12:54, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2021-05-11 13:51, Anton Ertl wrote:
>>>> There is no need to amend or clarify.
>>>> The text of the standard is clear.
>>>
>>> But RFI Q0009 and RFI Q99-027 demonstrate that clarifications were
>>> needed in regard to POSTPONE. It means that the text of the standard is
>>> not enough clear.
>>
>> Actually neither of these RFIs states that the text of the standard is
>> unclear. On the contrary, Q0009 states that it is clear:
>>
>> <http://forth.sourceforge.net/std/dpans/q0009.htm>:
>> |Nothing in the standard prevents you executing words with compilation
>> |semantics from POSTPONE in interpretation state (it does not say that
>> |it is ambiguous, so it looks like it is defined through the standard).
>
>Well, you are right: the text of the standard is clear in regard to the
>specification for "POSTPONE". But a problem arose despite of that. Since
>the problem lies not in the specification for "POSTPONE" itself, but in
>the integration of this specification with all other parts, including
>the intention, the history, the existent Forth systems and how they
>implemented "POSTPONE" at those time.

If that is the case (and I think it is), we should be discussing that,
not A99-027.

>> The reason for these RFIs is that enough people made claims that did
>> not agree with the text of the standard
>
>And what? If you see a mistake, flaw, inconsistency, incompatibility, —
>it's OK to disagree with that.

Then you make a proposal to address the problem, as has been done for
many other things. But nobody has proposed a change to the standard
document that would reflect A99-027. The proof of an intention wrt
the standard is in actually incorporating a corresponding change in
the standard. No such change has been incorporated into Forth-2012.
A99-027 is dead, Jim.

Instead of flogging this dead horse, it's more productive to take a
look at existing practice.

>> that the people who asked the question wanted
>> an official statement by the TC:
>>
>> <http://forth.sourceforge.net/std/dpans/q0009.htm>:
>> |IMHO the confusion about this topic has reached a point where I need
>> |an official statement.
>> [...]
>> |Opinions: Elizabeth Rather says that compilation semantics requires
>> |to be in compilation state.
>>
>> <http://forth.sourceforge.net/std/dpans/a99-027.txt>:
>> |Recent discussions on comp.lang.forth indicate there is a body of opinion
>> |which holds that one or both the following are implied by the ANSI Forth
>> |Standard:
>> |
>> | 1. It is an ambiguous condition for a program to perform compilation
>> |semantics in the interpretation state.
>> |
>> | 2. It is an ambiguous condition for a program to append semantics to the
>> |current definition in the interpretation state.
>
>
>> The TC never answered Q0009.
>
>Is it the single unanswered question?

They also did not answer Q0008.

>I guess, there are many unanswered
>questions remained.

Only one other officially posed question remained.

>Then this fact says nothing unique.

Nobody claimed it did. Still, the committee did not answer it.

>OTOH, A99-027 answers to Q0009 too.

One may wonder about that. The Forth-94 committee could not answer
Q0009, so who knows what the intent was when that question was posed.

>> The TC answered Q99-027 without
>> referring to the document at all, only to the TC's intent;
>
>Yes. By my understanding, A99-027 is not a clarification per se (i.e.
>it's not about how something should be interpreted), but it's the new
>general rule.

It would have become the new general rule if they had followed up on
their announcement and actually changed the standard document. They
did not.

>It's the rule that was intended, but was missed in the
>normative text.

Nobody has missed it while we were working on Forth-2012.

>Actually this rule is a concession to the existent Forth systems. We can
>see the same concession in the glossary entries and rationales for
>"COMPILE,", "CS-PICK", "CS-ROLL", "(LOCAL)",

I don't see it. Which concessions to which existing implementations
do you mean? These four words were new in Forth-94.

>section D.6.7, etc.

Section D.6.7 discusses mainly the effect of also allowing
cmForth-like systems. The undefined interpretation semantics of
COMPILE, CS-PICK CS-ROLL and (LOCAL) are probably also intended for
cmForth-like systems.

>These concessions have zero value without this general rule.

Which general rule? Both answers in A99-027 are about STATE, but
cmForth does not even have STATE. cmForth certainly does not need a
concession that allows polluting everything with STATE-smartness.

>> instead of
>> referring to the document, they stated that they have "plans to modify
>> its terminology in an effort to avoid future misinterpretations of
>> this sort [i.e., of TC intent]."
>
>The document cannot be formally referred, since this rule is not
>obligated, but just a concession that relaxes implementations and
>restricts programs.

It's unclear to me what you want to say here. A standard document can
certainly give fewer guarantees to programs in order to allow
additional implementation techniques. That needs a good reason;
allowing STATE-smartness where it currently is not common practice is
not a good reason.

>"POSTPONE" can be implemented according the specification in any system,
>as I shown earlier: https://git.io/J30D6

At a quick glance this looks like a variant of the code I discussed in
<2019Jul18.134124@mips.complang.tuwien.ac.at> which fails these tests:

: foo state @ . ; immediate
: foo1 postpone foo ;
foo1 \ should print 0 (the current state)

: x] ] ; immediate
: y] postpone x] ;
: bar [ 2 2 + y] literal . ;
bar \ should print 4

Gforth, iForth, SwiftForth, and VFX (4.72 and 5.11) pass these tests.

>> They never did. Nobody has proposed
>> such a modification for Forth-200x (not before the release of
>> Forth-2012 and not since).
>
>But instead of that, somebody screwed the meaning of the "compilation
>semantics" term over to show that the classic implementations of
>"POSTPONE" are standard compliant for user-defined dual-semantics words
>even without A99-027.

I have no idea what you are referring to. Who "screwed the meaning"
and how is that reflected in the Forth-2012 document?

>"POSTPONE" was proposed not later than 1989, and it appended the
>execution semantics, as well as "[COMPILE]" or "COMPILE", in those time.
>
>When the "compilation semantics" notion was introduced, and these words
>were specified via this notion, the only way of backward compatibility
>with existent systems, and compatibility between the single-xt systems
>and dual-xt systems was the rule declared in A99-027.

Not in the least. The only real problem for single-XT systems in
Forth-94 is FILE S"; can be solved by only implementing CORE S".

There are several ways to deal with TO: not implement it (it's
optional); or implement it by passing a flag at run-time.

Forth-2012 is intended to allow STATE-smart implementations of TO, IS,
ACTION-OF, but systems that implement SEARCH-WORDLIST NAME>COMPILE
NAME>INTERPRET must not go there (contrary to the intention, so we
have to change the standard if we want to allow that, in the same
direction that my clarify-FIND proposal does).

If someone proposes a similar ambiguous condition to S" and S\" as
Forth-2012 has for TO, I would vote for it, so single-xt systems could
use a STATE-smart FILE S" and be standard.

>> With every year of inaction the relevance
>> of a99-027 became less, and with the release of Forth-2012 its
>> relevance vanished completely.
>
>I cannot agree with that.
>
>Actually, any system that uses the classic implementation of "POSTPONE"
>in a signle-xt system, or for user-defined dual-semantics words, relies
>on this A99-027.

POSTPONE is a Forth-94 innovation. What is the supposed classic
implementation? A single-xt system like SwiftForth certainly performs
compilation semantics nicely in interpret state and it also appends
semantics in interpret state:

: my+ postpone + ; immediate
: foo [ my+ ] ;
1 2 foo . \ prints 3

This example both performs the compilation semantics of + in
interpretation state as well as appending the execution semantics of +
to FOO in interpretation state. So SwiftForth obviously does not rely
on A99-027.

On 18/05/2021 00:31, Ruvim wrote:
> On 2021-05-12 12:54, Anton Ertl wrote:
> ...
>> The reason for these RFIs is that enough people made claims that did
>> not agree with the text of the standard
>
> And what? If you see a mistake, flaw, inconsistency, incompatibility, —
> it's OK to disagree with that.

That's not today's problem which seems to be politics - making claims
that alter practice and using the flawed text of the standard to do it.
Drafting an RFI would resolve the issue but first one needs the numbers :)

Let's try to go by little steps.
In this message I quote only parts that corresponds to one question:
what is classic (or initially implemented) behavior of POSTPONE.

On 2021-05-17 18:36, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
[...]

>> "POSTPONE" was proposed not later than 1989, and it appended the
>> execution semantics, as well as "[COMPILE]" or "COMPILE", in those time.
>>
>> When the "compilation semantics" notion was introduced, and these words
>> were specified via this notion, the only way of backward compatibility
>> with existent systems, and compatibility between the single-xt systems
>> and dual-xt systems was the rule declared in A99-027.
>
> Not in the least. The only real problem for single-XT systems in
> Forth-94 is FILE S"; can be solved by only implementing CORE S".
>
> There are several ways to deal with TO: not implement it (it's
> optional); or implement it by passing a flag at run-time.

I will show other problems later, if we continue this talk.

[...]
>> Actually, any system that uses the classic implementation of "POSTPONE"
>> in a signle-xt system, or for user-defined dual-semantics words, relies
>> on this A99-027.
>
> POSTPONE is a Forth-94 innovation. What is the supposed classic
> implementation?

The first meeting of the X3J14 TC concerning ANS Forth was in 1987, the
last in 1994. It was a quite long process.

As I can see, the "POSTPONE" word was proposed by John R. Hayes not
later then in 1989.

"POSTPONE" solved three problem in the Forth-83 (or alike) systems:
- non-portable COMPILE
- different set of immediate words in the different systems
- burdens of knowledge which words are immediate

It solves these problems in the single-xt systems, regardless
cmForth-like (or other dual-xt) systems at all.

In Forth-83 "[COMPILE]" and "COMPILE" operate on compilation addresses.
A compilation address identifies behavior that is called "execution
semantics" in Forth-94.

Initially "POSTPONE" was implemented in some Forth-83 systems (or
similar single-xt systems). And it was a long before Forth-94 was release.

So "POSTPONE" operated on compilation addresses too.

In FD-V11N4 (Forth Dimension Volume 11 Number 4, November/December
1989), pages 8-9, John R. Hayes shortly describes the new "POSTPONE"
word in the future Forth-94 and the reasons why it was introduced (it's
similar to A.6.1.2033). And he shows how "[COMPILE]" can be implemented
via "POSTPONE":

| For backward compatibility, COMPILE may be defined as:
| | : COMPILE POSTPONE POSTPONE ; IMMEDIATE
| | [COMPILE] may be defined (identically) as:
| | : [COMPILE] POSTPONE POSTPONE ; IMMEDIATE

That confirms that they all operated on the compilation addresses in a
single-xt system.

Are you agree with that?

--
Ruvim

On 2021-05-17 18:36, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-05-12 12:54, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>> On 2021-05-11 13:51, Anton Ertl wrote:
>>>>> There is no need to amend or clarify.
>>>>> The text of the standard is clear.
>>>>
>>>> But RFI Q0009 and RFI Q99-027 demonstrate that clarifications were
>>>> needed in regard to POSTPONE. It means that the text of the standard is
>>>> not enough clear.
>>>
>>> Actually neither of these RFIs states that the text of the standard is
>>> unclear. On the contrary, Q0009 states that it is clear:
>>>
>>> <http://forth.sourceforge.net/std/dpans/q0009.htm>:
>>> |Nothing in the standard prevents you executing words with compilation
>>> |semantics from POSTPONE in interpretation state (it does not say that
>>> |it is ambiguous, so it looks like it is defined through the standard).
>>
>> Well, you are right: the text of the standard is clear in regard to the
>> specification for "POSTPONE". But a problem arose despite of that. Since
>> the problem lies not in the specification for "POSTPONE" itself, but in
>> the integration of this specification with all other parts, including
>> the intention, the history, the existent Forth systems and how they
>> implemented "POSTPONE" at those time.
>
> If that is the case (and I think it is), we should be discussing that,
> not A99-027.

A99-027 was a quick (and probably temporary) solution for this problem.
So it is discussed too.

>>> The reason for these RFIs is that enough people made claims that did
>>> not agree with the text of the standard
>>
>> And what? If you see a mistake, flaw, inconsistency, incompatibility, —
>> it's OK to disagree with that.
>
> Then you make a proposal to address the problem, as has been done for
> many other things. But nobody has proposed a change to the standard
> document that would reflect A99-027. The proof of an intention wrt
> the standard is in actually incorporating a corresponding change in
> the standard. No such change has been incorporated into Forth-2012.

I agree. But, as I understand, the X3J14 TC disbanded, so they was
unable to incorporate the corresponding change into the standard. (1)

Concerning Forth-2012, the new TC was organized, and they didn't share
the intention of the previous TC, and hence they could not incorporate
this change too. (2)

> A99-027 is dead, Jim.
>
> Instead of flogging this dead horse, it's more productive to take a
> look at existing practice.

Existing practice has a flaw. One problem that POSTPONE should have
solved is eliminating the burdens of knowledge which words are
implemented via immediacy mechanism. But due to this flaw, it doesn't
solve this problem in the affected systems. (3)

>>> that the people who asked the question wanted
>>> an official statement by the TC:
>>>
>>> <http://forth.sourceforge.net/std/dpans/q0009.htm>:
>>> |IMHO the confusion about this topic has reached a point where I need
>>> |an official statement.
>>> [...]
>>> |Opinions: Elizabeth Rather says that compilation semantics requires
>>> |to be in compilation state.
>>>
>>> <http://forth.sourceforge.net/std/dpans/a99-027.txt>:
>>> |Recent discussions on comp.lang.forth indicate there is a body of opinion
>>> |which holds that one or both the following are implied by the ANSI Forth
>>> |Standard:
>>> |
>>> | 1. It is an ambiguous condition for a program to perform compilation
>>> |semantics in the interpretation state.
>>> |
>>> | 2. It is an ambiguous condition for a program to append semantics to the
>>> |current definition in the interpretation state.
>>
>>
>>> The TC never answered Q0009.
>>
>> Is it the single unanswered question?
>
> They also did not answer Q0008.

http://forth.sourceforge.net/standard/dpans/q0008.htm

But Q0008 is not so difficult. It can be answered in the ground of the
normative texts, and the rationale to "FIND".

>> I guess, there are many unanswered
>> questions remained.
>
> Only one other officially posed question remained.
>
>> Then this fact says nothing unique.
>
> Nobody claimed it did. Still, the committee did not answer it.
>

Only two unanswered questions — it's few enough to be notable.

>> OTOH, A99-027 answers to Q0009 too.
>
> One may wonder about that. The Forth-94 committee could not answer
> Q0009, so who knows what the intent was when that question was posed.

It doesn't matter. Eventually, nobody voted against A99-027.

>>> The TC answered Q99-027 without
>>> referring to the document at all, only to the TC's intent;
>>
>> Yes. By my understanding, A99-027 is not a clarification per se (i.e.
>> it's not about how something should be interpreted), but it's the new
>> general rule.
>
> It would have become the new general rule if they had followed up on
> their announcement and actually changed the standard document. They
> did not.

Yes, they have an excuse, see (1) above.

>> It's the rule that was intended, but was missed in the
>> normative text.
>
> Nobody has missed it while we were working on Forth-2012.

It's clear, but the new TC had the different intentions, see (2) above.

[...]

>> These concessions have zero value without this general rule.
>
> Which general rule? Both answers in A99-027 are about STATE,

I meant the both normative parts of the reply, and I referred them
together as the general rule.

[...]

>> Also, as I already mentioned in another message [1], the main argument
>> is that a thing that was accepted via a formal standardization process,
>> may be obsolesced via the same process only.
>
> They did not agree on any change to the standard document, so the
> document just continues to answer "no" to both questions of Q99-027.
> And we reaffirmed this with Forth-2012.

It looks like the TC just ignored the problem that caused RFI Q99-027.
And nothing was changed in this regard.

> So there is no need to "obsolesce" anything in order to get the answer
> "no" to these questions.

> OTOH, if you want to realize the intentions of the
> Forth-94 committee as stated in A99-027 and change the standard
> document such that it answers "yes", you would have to make a proposal
> that would make the existing guarantees and programs relying on them
> obsolescent.

It's reasonable. But I would move in the opposite direction, to solve
the problem itself that caused RFI Q99-027.

--
Ruvim

On 2021-05-17 18:36, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
[...]

Interpretation semantics (IS) for the words:
"COMPILE,", "CS-PICK", "CS-ROLL", "(LOCAL)"
are undefined by the standard, execution semantics (ES) are defined.

It's obvious that their execution semantics make sense only when the
current definition exists (i.e. some definition is being defined/compiled).

But the current definition can exist in interpretation state too, e.g.:

: bar [: ." (ABC)" ;] compile, ." (ABC compiled)" ; immediate
: foo [ ' bar compile, ] ;

And in these conditions their ES (and then the default IS) make sense.

Furthermore, the current definition can be absent in compilation state:

] bar [

And in these conditions their ES don't make sense.

So, if the default ES for them make sense in some cases, and without
additional efforts in implementation, what is the rationale to declare
IS for them undefined? (see (1) bellow)

One fact is that this choice relaxes implementations and constraints
programs.

>> By my understanding, A99-027 is not a clarification per se (i.e.
>> it's not about how something should be interpreted), but it's the new
>> general rule.
>>
>> It's the rule that was intended, but was missed in the
>> normative text.
>>
>> Actually this rule is a concession to the existent Forth systems. We can
>> see the same concession in the glossary entries and rationales for
>> "COMPILE,", "CS-PICK", "CS-ROLL", "(LOCAL)",
>
> I don't see it. Which concessions to which existing implementations
> do you mean? These four words were new in Forth-94.

By a concession I mean relaxing of an implementation. I.e., undefined
interpretation semantics for these words is a concession to the
implementers (I just don't sure that it's demanded). Obviously, it isn't
something intrinsic.

Forth-94 is not a spherical cow in a vacuum. It's rooted in Forth-83.
And it was designed in such a way to make a Forth-83 system compatible
with Forth-94 by adding just a compatibility layer (section C.4).

New words cannot be included into the standard just according to a
conception on a paper. They should be implemented and tested in the
different systems.

The restrictions on programs concerning new words should be grounded on
the possible implementation variations.

And what is that particular variation, for which IS are declared
undefined for these words? (1)

Another possible ground for this choice could be a general rule that the
compilation-related actions should be performed in compilation state
only (like A99-027). And then it makes sense to avoid exclusions from
the general rule.

So, if we don't have implementation variations that justifies undefined
IS for these words, the only possible ground is the general rule, that
was intended.

> The undefined interpretation semantics of
> COMPILE, CS-PICK CS-ROLL and (LOCAL) are probably also intended for
> cmForth-like systems.

It means that these words were intended to be implemented with non
default compilation semantics in a dual-nt system (i.e., in cmForth-like
system).

Could you provide an example implementation that shows some sense for that?

Since it looks like all possible profits are burned by simple redefinitions:

: compile, compile, ;
: cs-pick cs-pick ;
: cs-roll cs-roll ;
: (local) (local) ;

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-05-17 18:36, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>[...]
>
>
>Interpretation semantics (IS) for the words:
> "COMPILE,", "CS-PICK", "CS-ROLL", "(LOCAL)"
>are undefined by the standard, execution semantics (ES) are defined.
>
>It's obvious that their execution semantics make sense only when the
>current definition exists (i.e. some definition is being defined/compiled).
>
>But the current definition can exist in interpretation state too, e.g.:
>
> : bar [: ." (ABC)" ;] compile, ." (ABC compiled)" ; immediate
> : foo [ ' bar compile, ] ;
>
>And in these conditions their ES (and then the default IS) make sense.

Yes.

>Furthermore, the current definition can be absent in compilation state:
>
> ] bar [
>
>And in these conditions their ES don't make sense.

Yes.

>So, if the default ES for them make sense in some cases, and without
>additional efforts in implementation, what is the rationale to declare
>IS for them undefined? (see (1) bellow)

I don't think they gave a rationale.

My guess is that they undefined the interpretation semantics for they
kinds of words that would have gotten the C attribute in Forth-83; but
that attribute is not clearly defined (or maybe I have to learn a lot
more about Forth-83 to know what it means).

And thinking more about it, it's probably an ill-thought-out way to
protect programmers from using these words wrongly. Similar in spirit
(though not in semantics) to how dxforth pollutes his system with
?COMP, while SwiftForth demonstrates that this kind of paternalism is
unnecessary. Gforth used to be pretty strict on undefined
interpretation semantics of a number of words; we relaxed this in the
development release (all words have Gforth-defined interpretation
semantics), but we still warn about text-interpreting some words in
interpret state and ticking them, and this has led to complaints here
recently.

>> I don't see it. Which concessions to which existing implementations
>> do you mean? These four words were new in Forth-94.
>
>By a concession I mean relaxing of an implementation. I.e., undefined
>interpretation semantics for these words is a concession to the
>implementers (I just don't sure that it's demanded).

By "concession to existing implementations" I understand that there
existed (at the time) at least one implementation that either

1) implemented one of these words (maybe under a different name) and
had such a limitation.

2) Would have had difficulty implementing these words unless the
limitation was in place.

And my question was whether you can name a system for which the
standard made these consessions for one of these reasons. If you
cannot, then I think we should lay the "concession" speculation to
rest.

>The restrictions on programs concerning new words should be grounded on
>the possible implementation variations.

These particular restrictions are not, as is obvious from the easy
workarounds, e.g.

: compile, compile, ;

>Another possible ground for this choice could be a general rule that the
>compilation-related actions should be performed in compilation state
>only (like A99-027). And then it makes sense to avoid exclusions from
>the general rule.
>
>So, if we don't have implementation variations that justifies undefined
>IS for these words, the only possible ground is the general rule, that
>was intended.

Maybe parts of the Forth-94 committee had such intentions, and they
resulted in such pointless restrictions in the document, and A99-027.
I don't think that that was the intention of the whole Forth-94
committee, or we would be seeing STATE polluting the whole Forth-94
standard document.

>> The undefined interpretation semantics of
>> COMPILE, CS-PICK CS-ROLL and (LOCAL) are probably also intended for
>> cmForth-like systems.
>
>It means that these words were intended to be implemented with non
>default compilation semantics in a dual-nt system (i.e., in cmForth-like
>system).

Possibly, but not necessarily. Another option is to also use the
immediate flag when dealing with COMPILER words. So COMPILE, would
not have an immediate flag, but IF would.

>Since it looks like all possible profits are burned by simple redefinitions:
>
> : compile, compile, ;
> : cs-pick cs-pick ;
> : cs-roll cs-roll ;
> : (local) (local) ;

I don't see any benefits from undefining the interpretation semantics
of these words, so the fact that these limitations are so easy to work
around is a benefit.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-05-17 18:36, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2021-05-12 12:54, Anton Ertl wrote:
>>>> The reason for these RFIs is that enough people made claims that did
>>>> not agree with the text of the standard
>>>
>>> And what? If you see a mistake, flaw, inconsistency, incompatibility, —
>>> it's OK to disagree with that.
>>
>> Then you make a proposal to address the problem, as has been done for
>> many other things. But nobody has proposed a change to the standard
>> document that would reflect A99-027. The proof of an intention wrt
>> the standard is in actually incorporating a corresponding change in
>> the standard. No such change has been incorporated into Forth-2012.
>
>I agree. But, as I understand, the X3J14 TC disbanded, so they was
>unable to incorporate the corresponding change into the standard. (1)

And in 2005 Forth-200x formed, and we have picked up the standard
where they dropped it, and have a process where everyone, including
former Forth-94 TC members could submit proposals. In over 15 years
none of them has gotten around to submitting a proposal that does what
they announced.

>Concerning Forth-2012, the new TC was organized, and they didn't share
>the intention of the previous TC, and hence they could not incorporate
>this change too. (2)

Which reinforces:

>> A99-027 is dead, Jim.

If A99-027 was rooted in common practice, the Forth-200x committee
would have realized the change. An intention that's not based on
common practice really needs something more than A99-027 to be taken
seriously.

>> Instead of flogging this dead horse, it's more productive to take a
>> look at existing practice.
>
>Existing practice has a flaw. One problem that POSTPONE should have
>solved is eliminating the burdens of knowledge which words are
>implemented via immediacy mechanism. But due to this flaw, it doesn't
>solve this problem in the affected systems. (3)

It solves this problem nicely. Words like + are "immediate" (in the
text-interpreter sense, i.e., they have to be EXECUTEd when compiled)
in cmForth's compiler wordlist; you can POSTPONE it just fine. EXIT
is immediate in Gforth, and not immediate in some other Forth systems;
POSTPONE EXIT works nicely.

BTW, if "(3)" is supposed to point to a footnote, the footnote is missing.

But what I mean with "existing practice" is that there are systems
that implement S" S\" TO IS ACTION-OF in a state-smart way, and we
want to allow this, and also allow SEARCH-WORDLIST NAME>COMPILE
NAME>INTERPRET to be implemented in these systems, and the standard
document currently does not.

>> They also did not answer Q0008.
>
>http://forth.sourceforge.net/standard/dpans/q0008.htm
>
>But Q0008 is not so difficult. It can be answered in the ground of the
>normative texts, and the rationale to "FIND".

Apparently those who knew the text well enough for such answers were
no longer active on the Forth-94 TC in 1996.

And I see now <http://forth.sourceforge.net/std/dpans/>, they also did
not answer three other questions after Q0009 and answered two.

>>> OTOH, A99-027 answers to Q0009 too.
>>
>> One may wonder about that. The Forth-94 committee could not answer
>> Q0009, so who knows what the intent was when that question was posed.
>
>It doesn't matter. Eventually, nobody voted against A99-027.

Why do you think so? I don't see any vote results in
<http://forth.sourceforge.net/std/dpans/a99-027.htm>; so I also don't
see that anybody voted for it.

In any case, really eventually nobody realized the announced plans to
modify the terminology.

>>>> The TC answered Q99-027 without
>>>> referring to the document at all, only to the TC's intent;
>>>
>>> Yes. By my understanding, A99-027 is not a clarification per se (i.e.
>>> it's not about how something should be interpreted), but it's the new
>>> general rule.
>>
>> It would have become the new general rule if they had followed up on
>> their announcement and actually changed the standard document. They
>> did not.
>
>Yes, they have an excuse, see (1) above.

Since the start of Forth-200x, they no longer have this excuse.

>It's clear, but the new TC had the different intentions, see (2) above.

So why worry about the intentions of a disbanded TC? The standard
document is clear wrt. the two questions in Q99-027: No and no.

>> They did not agree on any change to the standard document, so the
>> document just continues to answer "no" to both questions of Q99-027.
>> And we reaffirmed this with Forth-2012.
>
>It looks like the TC just ignored the problem that caused RFI Q99-027.

The problem was that some people made claims that contradicted the
text of the standard.

>And nothing was changed in this regard.

Actually, this discussion had pretty much died down, now you are
trying to rekindle the flames, but few are biting.

>> OTOH, if you want to realize the intentions of the
>> Forth-94 committee as stated in A99-027 and change the standard
>> document such that it answers "yes", you would have to make a proposal
>> that would make the existing guarantees and programs relying on them
>> obsolescent.
>
>It's reasonable. But I would move in the opposite direction, to solve
>the problem itself that caused RFI Q99-027.

That certainly sounds more productive. What is the problem IYO? My
impression is that there are some people who are used to thinking in
terms of STATE-smart stuff like ?COMP, who misinterpret
"interpretation semantics are undefined" to mean "execution in
interpretation state is undefined". This problem can only be solved
by going back with a time machine and fixing the Forth systems that
these people grew up on. Even if I finish fforth and it will become
popular among newcomers, I don't think it will help much to convince
staunch STATE-smartness fans.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

> And thinking more about it, it's probably an ill-thought-out way to
> protect programmers from using these words wrongly.

A better approach could be sth. similar to olden' smudge bit: it's on
while there's a definition being built.

Checking compiler state sure isn't the correct thing to do in order to
prevent "rogue" compilation.

On 5/23/21 10:00 AM, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
....
>
>> Since it looks like all possible profits are burned by simple redefinitions:
>>
>> : compile, compile, ;
>> : cs-pick cs-pick ;
>> : cs-roll cs-roll ;
>> : (local) (local) ;
>
> I don't see any benefits from undefining the interpretation semantics
> of these words, so the fact that these limitations are so easy to work
> around is a benefit.
>

This sort of trick to provide interpretation semantics (I.S.) to words
for which I.S. is undefined, gives the appearance of a hack. If these
words actually have a demonstrable need to have interpretation
semantics, just propose that the undefined I.S. be removed. However, as
I tried to point out earlier, this requires the Forth system to be able
to detect an uncompleted definition, or a definition to which it is
appropriate to append additional execution semantics.

Krishna

On 23/05/2021 21:59, Ruvim wrote:
> On 2021-05-17 18:36, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
> [...]
>
>
> Interpretation semantics (IS) for the words:
> "COMPILE,", "CS-PICK", "CS-ROLL", "(LOCAL)"
> are undefined by the standard, execution semantics (ES) are defined.
>
> It's obvious that their execution semantics make sense only when the
> current definition exists (i.e. some definition is being defined/compiled).
>
> But the current definition can exist in interpretation state too, e.g.:
>
> : bar [: ." (ABC)" ;] compile, ." (ABC compiled)" ; immediate
> : foo [ ' bar compile, ] ;
>
> And in these conditions their ES (and then the default IS) make sense.

Make sense to whom? Why would anyone define foo that way when ANS
has drummed it into everybody they can write:

: foo postpone bar ;

IMO it's clearer what's going on (because the alternative is rarely
if ever seen) - and it works on VFX. What's not to like?

dxforth <dxforth@gmail.com> wrote:

> On 23/05/2021 21:59, Ruvim wrote:

> > But the current definition can exist in interpretation state too, e.g.:
> >
> > : bar [: ." (ABC)" ;] compile, ." (ABC compiled)" ; immediate
> > : foo [ ' bar compile, ] ;
> >
> > And in these conditions their ES (and then the default IS) make sense.
>
> Make sense to whom?

To people thinking a step further.

> Why would anyone define foo that way when ANS
> has drummed it into everybody they can write:
>
> : foo postpone bar ;

In this simplistic example - yes.
But let's make this sth like

: foe [ 'bar compile, ] ;

Now postpone wouldn't work, because it's parsing.

> What's not to like?

That.

In article <2021May23.170041@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>And thinking more about it, it's probably an ill-thought-out way to
>protect programmers from using these words wrongly. Similar in spirit
>(though not in semantics) to how dxforth pollutes his system with
>?COMP, while SwiftForth demonstrates that this kind of paternalism is
>unnecessary.

: test [ IF ] "TRUE" TYPE ELSE "FALSE" TYPE THEN ;
: test [ IF ? ciforth ERROR # 17 : COMPILATION ONLY, USE IN DEFINITION
WANT -plain-control-
-plain-control- : (WARNING) NOT PRESENT, THOUGH WANTED
OK
: test [ IF ] "TRUE" TYPE ELSE "FALSE" TYPE THEN ;
OK
0 test
FALSE OK
1 test
TRUE OK

I don't think this is paternalism, as long as you can switch it off,
but the benefits are slim.
I think more of them as training wheels for novices.
The only word where `?COMP would have helped me is in `; .
As in editing errors like
: double
2 * ;
;
but fig-Forth did not have a `?COMP in `; and neither do I.
Come to think of it. Everywhere where in the ISO 94 standard I see
"interpretation is undefined", it seems to mean:
"using this word while not building a definition is an ambiguous
condition."
Interestingly `STATE doesn't come into this.

<SNIP>
>
>- anton

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst