Performing compilation semantics, RFI Q99-027

[Ruvim]

On 2021-04-26 13:29, Ruvim wrote (news:s664n9$b7i$1...@dont-email.me [3])
> On 2021-04-25 11:32, Anton Ertl wrote:
>> Ruvim <ruvim...@gmail.com> writes:
>>>
>>> You can only face a problem when you apply Tick or POSTPONE to this
>>> word. Most probably, POSTPONE.
>>>
>>> The reason is that you expect that POSTPONE guarantees compilation
>>> state when the appended compilation semantics are performed. But your
>>> POSTPONE doesn't guarantee that.
>>>
>>> And the standard doesn't guarantees that. And according to the
>>> clarifications, you may perform compilation semantics only in
>>> compilation state (even if these semantics are a part of execution
>>> semantics by means of POSTPONE).
>>
>> Which clarifications?
>
> You should know, it was discussed many times. It's the official reply
> to RFI by Philip Preston, Q99-027 [1]

I have found the recent Anton's comment in this regard [4].
In short: "this RFI answer is no longer relevant".

On 2020-09-21 20:21, Anton Ertl wrote
(news:2020Sep2...@mips.complang.tuwien.ac.at [4]):
> Ruvim <ruvim...@gmail.com> writes:
>> You know, according to the TC reply on RFI by Philip Preston,
>> "it is an ambiguous condition for a program to perform compilation
>> semantics in the interpretation state".
>
> Whoever wrote that obviously knew that they could not argue that from
> the standard's text, so they announced to rewrite the text. That
> rewrite never materialized.
>
> My conclusion is that even if the Forth-94 TC's intention really was
> to answer yes to the two questions by Philip Preston, they did not
> follow up on that. Maybe they later had second thoughts about their
> answer. Their answer is taking a shot-gun approach at allowing
> STATE-smart implementations of standard words, with lots of colateral
> damage. E.g., it would de-standardize common practice like
>
> : (S POSTPONE ( ; IMMEDIATE
> (S ...)
>
> Forth200x has been working since 2004, and released Forth-2012,
> without changing the Forth-94 text defining compilation semantics
> etc., and without anybody even proposing a rewrite, or proposing to
> add these ambiguous conditions, so it seems that people are mostly
> happy with that part of the standard as it stands. So this RFI answer
> is no longer relevant.


All these points like "not argue that from the standard's text",
"shot-gun approach", "without changing the Forth-94", "common practice"
(NB: POSTPONE was introduced in Forth-94), etc, are very arguable
points. But the main issue is that from the point of standardization
process they are informal things.

Whilst the official TC answer to Q99-027 (as well as any other official
answer) is a formal thing. And it's a part of the standard, on the same
extent as the rationales, I think.

Such official clarification cannot be just thrown out as an outdated
thing. It should be obsolesced via the proper process, and the
corresponding changes should be made in the standard.




The answer to Q99-027 explicitly declares some restrictions on programs.

Actually, such restrictions can be found in the standard too, e.g.:
"'COMPILE,' will not be executed during interpretation"
But it doesn't matter at the moment.

A very strong argument against these restrictions that they can be
by-passed by mere redefinitions (Ewald Pfau, 1999-04-14, [5], PoC [6] is
found by me just yesterday).

It means that under the hood compilation semantics are still performed
only in compilation state, but a program isn't concerned. If it is
required, the system sets compilation state by itself, performs
compilation semantics, and reverts to interpretation state (if it wasn't
required to remain in compilation state).

If a system doesn't need to set compilation state in some cases when it
performs compilation semantics — it is its internal business. But a
program should not be able to detect it! It's a very consistent and
critical restriction.


With this approach we could remove the restriction of Q99-027, but then
we should also change the corresponding parts in the standard, e.g. make
"COMPILE," and a number of other words having default interpretation
semantics, change corresponding rationales, etc., and also we should
explicitly introduce an ambiguous condition if compilation semantics (or
may be just appending semantics) are performed when the current
definition is absent.






-----
Reference

[1] "Request for interpretation answered"
(Elizabeth D Rather, 1999-04-09, Message-ID:
<7eluqb$hb0$1...@oak.prod.itd.earthlink.net>#1/1)
The raw message:
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/RmsDuen7YkY/xDvW74uzi30J/
The message in the thread:
https://groups.google.com/g/comp.lang.forth/c/RmsDuen7YkY/m/xDvW74uzi30J

[3] "NDCS words", the message in the thread:
https://groups.google.com/g/comp.lang.forth/c/DqKOXm5BJo0/m/ej4_roUOAgAJ

[4] "Re: Semantics of POSTPONE and immediate words (was: State smart dot
quote)"
(Anton Ertl, 2020-09-21, news:2020Sep2...@mips.complang.tuwien.ac.at)
The raw message:
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/ildjR6oy6hg/5uXvZ9-zBQAJ/
The message in the thread:
https://groups.google.com/g/comp.lang.forth/c/ildjR6oy6hg/m/5uXvZ9-zBQAJ

[5] "Request for interpretation answered"
(Ewald Pfau, 1999-04-09, Message-ID:
<7eluqb$hb0$1...@oak.prod.itd.earthlink.net>#1/1)
The raw message:
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/RmsDuen7YkY/DWd9Qu_eL8gJ/
The message in the thread:
https://groups.google.com/g/comp.lang.forth/c/RmsDuen7YkY/m/DWd9Qu_eL8gJ

[6] PoC of creating "combined" versions of "STATE-smart" standard words
http://www.complang.tuwien.ac.at/forth/combined.zip


--
Ruvim