On 2021-05-23 18:40, Anton Ertl wrote:
> 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,

Actually, all official answers, clarifications and accepted RFIs are the
parts of the standardization process. They should not be ignored.

> 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.

They could just retire, change occupation, lose interest in the
standardization process, or whatever else. But it doesn't matter.

A mistake is to move properties of a whole to its parts.

When the parts interact in a wider whole, they (as a whole) have
properties that they don't have without these interactions (see
"emergence").

The former members of the Forth-94 TC don't bear any responsibility that
the TC had. So it's incorrect to appeal to the former members, that they
had to submit a proposal to prove they intention, etc. (4)

>> 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.

It is not necessary. They could have missed the problem, or ignored the
problem in common practice. (Concerning this problem I will write in a
separate message).

>>>> 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.

The original message contains the vote results. Elizabeth Rather wrote
on 1999-04-09:

| This was submitted with a proposed answer to the TC
| as a letter ballot, which has passed with a vote
| of 15/0/1/5 (yes/no/abstain/not voting).

https://groups.google.com/forum/message/raw?msg=comp.lang.forth/RmsDuen7YkY/xDvW74uzi30J/

Perhaps Bernd Paysan could include these vote results into the web-page
at forth.sourceforge.net

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

For the former members of the TC for Forth-94, it doesn't matter due to
(1) and (4).

>>>>> 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.

I still can't agree with you, due to (4).

[...]

--
Ruvim

On 5/28/21 6:26 AM, Ruvim wrote:
> On 2021-05-28 12:54, Stephen Pelc wrote:
> [...]
>> As with many things in VFX, the practice of making users happy
>> or happier predominated over theory.
>>
>> Given the presence of systems that handle NDCS words, (VFX and
>> gForth) it would appear that relaxing the constraints on COMPILE,
>> (stack effects and parsing) would be a sensible approach.
>
> Why don't propose just another word?
>
> At the moment, "COMPILE," is equivalent to " LIT, POSTPONE EXECUTE ".
>
> You suggest to break this very basic equivalence.
>
> In opposite, I would suggest to make this equivalence stronger.
>
>
>
>
>> For the vast majority of users, this is the minimal approach.
>>
>
>

"LIT," is not a standard word. Just to be clear, is "LIT," equivalent to
POSTPONE LITERAL ?

Krishna

On Friday, May 28, 2021 at 12:27:01 PM UTC+1, Ruvim wrote:
> On 2021-05-28 12:54, Stephen Pelc wrote:
> [...]
> > As with many things in VFX, the practice of making users happy
> > or happier predominated over theory.
> >
> > Given the presence of systems that handle NDCS words, (VFX and
> > gForth) it would appear that relaxing the constraints on COMPILE,
> > (stack effects and parsing) would be a sensible approach.
> Why don't propose just another word?
>
> At the moment, "COMPILE," is equivalent to " LIT, POSTPONE EXECUTE ".
>
> You suggest to break this very basic equivalence.
>
> In opposite, I would suggest to make this equivalence stronger.

I'm not quite sure what LIT, means here, but you are right that there
is a relationship between POSTPONE and COMPILE,

But since, in a system that implements NDCS, the insides of POSTPONE
have to change to handle non-default compilation semantics, this
relationship would be *preserved*, not destroyed, by changing COMPILE,
to match it.

So I think your conclusion may be the wrong way round, unless I have
misunderstood.

Paul

Paul Liles <pauldliles@btopenworld.com> writes:
>On Friday, May 28, 2021 at 12:27:01 PM UTC+1, Ruvim wrote:
>> On 2021-05-28 12:54, Stephen Pelc wrote:
>> [...]
>> > As with many things in VFX, the practice of making users happy
>> > or happier predominated over theory.
>> >
>> > Given the presence of systems that handle NDCS words, (VFX and
>> > gForth) it would appear that relaxing the constraints on COMPILE,
>> > (stack effects and parsing) would be a sensible approach.
>> Why don't propose just another word?
>>
>> At the moment, "COMPILE," is equivalent to " LIT, POSTPONE EXECUTE ".
>>
>> You suggest to break this very basic equivalence.
>>
>> In opposite, I would suggest to make this equivalence stronger.
>
>I'm not quite sure what LIT, means here, but you are right that there
>is a relationship between POSTPONE and COMPILE,

There is no particular relationship between POSTPONE and COMPILE,.
There is a relationship between EXECUTE and COMPILE,. In particular,
if you define COMPILE, as

: compile, postpone literal postpone execute ;

your system should continue to work.

If you want to plug such a definition into an existing deferred
"COMPILE,", you may have to work around usage of COMPILE, in the
run-time semantics of POSTPONE to avoid infinite recursion. E.g., in
Gforth, you can define it as

: (compile,) ( xt -- )
['] lit peephole-compile, , ['] execute peephole-compile, ;
' (compile,) is compile,

and you change all the existing uses of COMPILE, to use this
implementation, making the test much more pervasive.

Of course the result is slow (~factor 8 for development gforth-fast
when running brew), but that's beside the point; the point is that, if
you run the system with this known-correct COMPILE, and test some
code, and it gives the same behaviour as the system's "COMPILE,", the
system's COMPILE, behaves correctly (at least in the uses that occured
in the test).

A less system-specific variant of this is:

variable in-compile, false in-compile, !

: (compile,) ( xt -- )
in-compile, @ if [ ' compile, defer@ compile, ] exit then
true in-compile, ! postpone literal postpone execute false in-compile, ! ;
' (compile,) is compile,

except that development Gforth has an optimization rule that optimizes
POSTPONE LITERAL POSTPONE EXECUTE into "COMPILE," which subverts the
point of the test; if your system has such an optimization rule, you
have to disable this optimization in this place in a system-specific
way.

>But since, in a system that implements NDCS, the insides of POSTPONE
>have to change to handle non-default compilation semantics, this
>relationship would be *preserved*, not destroyed, by changing COMPILE,
>to match it.

As mentioned, there is no particular relationship between POSTPONE and
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 Friday, May 28, 2021 at 6:58:27 PM UTC+1, Anton Ertl wrote:
> There is no particular relationship between POSTPONE and COMPILE,.

Oops. Obviously I did misunderstand, I'm not relly surprised.
Sorry (and thank you for responding).

Paul

On 28/05/2021 21:41, Ruvim wrote:
> On 2021-05-23 18:40, Anton Ertl wrote:
>> 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,
>
> Actually, all official answers, clarifications and accepted RFIs are the
> parts of the standardization process. They should not be ignored.

Each TC has revoked aspects of the previous standard - all the while claiming
to support 'the standardization process'. The masses don't like change and
there are no votes in revolution. So when a TC contradicts predecessors it
is with soothing words such as 'obsolete', 'necessary' and 'order'.

On 2021-05-28 16:41, Krishna Myneni wrote:
> On 5/28/21 6:26 AM, Ruvim wrote:
>> On 2021-05-28 12:54, Stephen Pelc wrote:
>> [...]
>>> As with many things in VFX, the practice of making users happy
>>> or happier predominated over theory.
>>>
>>> Given the presence of systems that handle NDCS words, (VFX and
>>> gForth) it would appear that relaxing the constraints on COMPILE,
>>> (stack effects and parsing) would be a sensible approach.
>>
>> Why don't propose just another word?
>>
>> At the moment, "COMPILE," is equivalent to " LIT, POSTPONE EXECUTE ".
>>
>> You suggest to break this very basic equivalence.
>>
>> In opposite, I would suggest to make this equivalence stronger.
>>
>>

>>
>>
>
> "LIT," is not a standard word. Just to be clear, is "LIT," equivalent to
> POSTPONE LITERAL ?

Yes

: LIT, POSTPONE LITERAL ;

So,

COMPILE,

is also equivalent to

POSTPONE LITERAL POSTPONE EXECUTE

In some implementations this equivalence is not hold for some xt.

If we enforce this equivalence, "EXIT" cannot be implemented in such a
way that FIND returns n value -1 for "EXIT" in compilation state.

Since it's impossible to implement such word X that

['] X EXECUTE

performs execution semantics of "EXIT".

--
Ruvim

On 28/05/2021 19:54, Stephen Pelc wrote:
> On Wed, 26 May 2021 11:10:48 +1000, dxforth <dxforth@gmail.com> wrote:
>
>>> What position of MPE are you talking about?
>>
>>>> > : bar [: ." (ABC)" ;] compile, ." (ABC compiled)" ; immediate
>>>> > : foo [ ' bar compile, ] ;
>
> I suspect that there are two issues you are complaining about
> 1) Quotations required Examples/quotations.fth to be loaded
> 2) Compilation of FOO above barfed.

2) however it wasn't a complaint as an observation that 'standard' is
whatever the major systems permit which is frequently a moving target.

>
> Item 1) is fixed in the now-released VFX Forth 5.2 which contains
> quotations using [: ... ;] in the kernel and in the manual.
>
> Item 2) is fixed by making COMPILE, handle NDCS words which
> (according to Anton) it should not have to do.
>
> As with many things in VFX, the practice of making users happy
> or happier predominated over theory.

The theory that a Forth Standard would make users happy is now 40 years
old. It has certainly kept them busy.

>
> Given the presence of systems that handle NDCS words, (VFX and
> gForth) it would appear that relaxing the constraints on COMPILE,
> (stack effects and parsing) would be a sensible approach. For
> the vast majority of users, this is the minimal approach.
>
> Stephen
>
>

Ruvim <ruvim.pinka@gmail.com> writes:
>If we enforce this equivalence, "EXIT" cannot be implemented in such a
>way that FIND returns n value -1 for "EXIT" in compilation state.
>
>Since it's impossible to implement such word X that
>
> ['] X EXECUTE
>
>performs execution semantics of "EXIT".

In Gforth without locals it is possible, but the word is not called X
but ;S:

: foo ." before" execute ." after" ;
' ;s foo \ prints "before"

We spent quite a lot of time trying to make ' EXIT work with locals
[ertl15], but eventually (after publishing the paper) we came across
yet another special case we had overlooked, and decided that enough is
enough, and reverted the EXIT-related changes described in the paper.

With a less featureful locals implementation, and if you are not
particularly interested in the performance of words using locals,
there are tricks to make ' EXIT work with locals, in particular
pushing some additional stuff on the return stack such that the EXIT
returns to a thunk that cleans up the locals, then returns to the
actual return address. It's just that, with additional locals
features and/or if you try to get performance comparable to having a
compile-time EXIT, this stuff becomes more and more complicated.

But anyway, if a Forth system does not implement locals, or implements
just standard locals, it's entirely possible to implement EXIT as a
normal word.

@InProceedings{ertl15,
author = {M. Anton Ertl and Bernd Paysan},
title = {From \texttt{exit} to \texttt{set-does>} --- A Story of {Gforth} Re-Implementation},
crossref = {euroforth15},
pages = {41--47},
url = {http://www.euroforth.org/ef15/papers/ertl.pdf},
url-slides = {http://www.euroforth.org/ef15/papers/ertl-slides.pdf},
OPTnote = {not refereed},
abstract = {We changed \code{exit} from an immediate to a
non-immediate word; this requires changes in the
de-allocation of locals, which leads to changes in
the implementation of colon definitions, and to
generalizing \code{does>} into \code{set-does>}
which allows the defined word to call arbitrary
execution tokens. The new implementation of locals
cleanup can usually be optimized to similar
performance as the old implementation. The new
implementation of \code{does>} has performance
similar to the old implementation, while using
\code{set-does>} results in speedups in certain
cases.}
}

@Proceedings{euroforth15,
title = {31st EuroForth Conference},
booktitle = {31st EuroForth Conference},
year = {2015},
key = {EuroForth'15},
url = {http://www.complang.tuwien.ac.at/anton/euroforth/ef15/papers/},
url-pdf = {http://www.complang.tuwien.ac.at/anton/euroforth/ef15/papers/proceedings.pdf}
}

- 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-23 18:40, Anton Ertl wrote:
>> 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,
>
>Actually, all official answers, clarifications and accepted RFIs are the
>parts of the standardization process. They should not be ignored.

The Forth-94 document was the basis of the Forth-200x work. So
official answers based on the document are certainly relevant.
Answers that are not based on the document are not.

>The former members of the Forth-94 TC don't bear any responsibility that
>the TC had. So it's incorrect to appeal to the former members, that they
>had to submit a proposal to prove they intention, etc. (4)

And the Forth-200x committee has no responsibilities to realize plans
that the Forth-94 TC has not realized. It's wrong to appeal to the
Forth-200x committee to realize such plans.

If anyone wants such plans realized, they should submit a proposal,
with a proper problem statement; the intention of the Forth-94 TC is
an insufficient justification in my book; indeed, my guess is that
they did not implement their plan because when they tried to implement
it, they realized that it's a bad idea.

My take wrt this issue is that if the Forth-94 TC had different
intentions, their document is better than their intentions. It would
be a regression to realize their plans. We do have the problem of the
existing practice of single-xt+immediate-flag systems that want to
implement FILE S". We should solve that problem at the level of the
few affected words (S" and S\"), like we did for TO, IS and ACTION-OF.

- 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 2021-05-29 12:09, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> If we enforce this equivalence, "EXIT" cannot be implemented in such a
>> way that FIND returns n value -1 for "EXIT" in compilation state.
>>
>> Since it's impossible to implement such word X that
>>
>> ['] X EXECUTE
>>
>> performs execution semantics of "EXIT".

Here, "X" is just a placeholder, a metasyntactic variable that takes
value of some real word.

>
> In Gforth without locals it is possible, but the word is not called X
> but ;S:
>
> : foo ." before" execute ." after" ;
> ' ;s foo \ prints "before"
>
One problem is that this ";s" doesn't work if "execute" is redefined.

I thought about this problem when claimed that it's impossible.

: e execute ; ' ;s [: ." (before)" e ." (after)" ;] e
\ it prints: (before)(after)

So, if we redefine compile in another way, something like:

: compile, lit, [: ( some stuff) execute ;] compile, ;

Then a user-defined text interpreter will work incorrectly. And we don't
have a normative reason why it doesn't work correctly.

--
Ruvim

On 2021-05-26 11:16, Paul Liles wrote:
> On Thursday, May 13, 2021 at 11:48:41 AM UTC+1, Ruvim wrote:
>
>> This issue is addressed by the Recognizer API
>>
>> The most recently discussed variant can be found at:
>> https://forth-standard.org/proposals/minimalistic-core-api-for-recognizers?hideDiff#reply-515
>
> Ah, thank you for that. I will probably find it useful.
>
>> "compilation semantics of xt" is a nonsense.
>>
>> Compilation semantics make sense for only named definitions (words).
>> Ditto interpretation semantics.
>>
>> Please refer to 2.1 Definitions of terms
>> https://forth-standard.org/standard/notation#notation:terms
>
> I'm not sure that it is a nonsense at all. With the usual disclaimer that I may
> be completely wrong, surely any implementation of NDCS/dual words will
> allow at least *some* words, as identified by their xts, to have separately identifiable
> compilation semantics. So far as I can tell, this would be true of words
> defined with INTERPRET/COMPILE in Gforth or with :NDCS in VFX.

It's OK. But you wrote before: "I would propose changing the specification"

Then you have to use the language and the terminology of the standard.

The standard doesn't specify things that are true for only some systems
(e.g. for Gforth, or for VFX). The standard specifies things that should
be true for any standard Forth system.

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-05-29 12:09, Anton Ertl wrote:
>> : foo ." before" execute ." after" ;
>> ' ;s foo \ prints "before"
>>
>One problem is that this ";s" doesn't work if "execute" is redefined.
>
>I thought about this problem when claimed that it's impossible.
>
> : e execute ; ' ;s [: ." (before)" e ." (after)" ;] e
> \ it prints: (before)(after)
>
>
>So, if we redefine compile in another way, something like:
>
> : compile, lit, [: ( some stuff) execute ;] compile, ;
>
>Then a user-defined text interpreter will work incorrectly. And we don't
>have a normative reason why it doesn't work correctly.

Sure we have, at least for the E case: The initiation semantics of the
colon definition pushes nest-sys (the return address) on the return
stack, and EXIT's execution semantics consumes nest-sys. So you
cannot redefine EXECUTE in this way and expect it to work for words
that do something with the return stack, such as EXIT.

The quotations proposal is not precise enough to include mentioning of
nest-sys, but it should.

Of course, the other problem is that some Forth systems implement
EXECUTE in a way that puts stuff on the return stack around the
execution, so these systems work like your E. Given that nobody
complains about that, maybe EXECUTE's definition should be refined
appropriately, "solving" all the problems with "can I EXECUTE the xt of
<return-stack-accessing-word>".

- 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 2021-05-29 20:36, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-05-29 12:09, Anton Ertl wrote:
>>> : foo ." before" execute ." after" ;
>>> ' ;s foo \ prints "before"
>>>
>> One problem is that this ";s" doesn't work if "execute" is redefined.
>>
>> I thought about this problem when claimed that it's impossible.
>>
>> : e execute ; ' ;s [: ." (before)" e ." (after)" ;] e
>> \ it prints: (before)(after)
>>
>>
>> So, if we redefine compile in another way, something like:
>>
>> : compile, lit, [: ( some stuff) execute ;] compile, ;
>>
>> Then a user-defined text interpreter will work incorrectly. And we don't
>> have a normative reason why it doesn't work correctly.
>
> Sure we have, at least for the E case: The initiation semantics of the
> colon definition pushes nest-sys (the return address) on the return
> stack, and EXIT's execution semantics consumes nest-sys. So you
> cannot redefine EXECUTE in this way and expect it to work for words
> that do something with the return stack, such as EXIT.

Yes, for the case E it's obvious.

Moreover, the case of E is non-standard. A standard program cannot
obtain the xt for a word that consumes nest-sys or accesses/changes the
return stack. And then a redefined "EXECUTE" should continue to work in
any standard program.

So I didn't understand why did you try to make "['] EXIT EXECUTE" work,
when you implemented "EXIT" as a word with default CS. In this case it's
enough to make "['] EXIT COMPILE," work correctly.

> The quotations proposal is not precise enough to include mentioning of
> nest-sys, but it should.
>
> Of course, the other problem is that some Forth systems implement
> EXECUTE in a way that puts stuff on the return stack around the
> execution, so these systems work like your E. Given that nobody
> complains about that, maybe EXECUTE's definition should be refined
> appropriately, "solving" all the problems with "can I EXECUTE the xt of
> <return-stack-accessing-word>".

I think, this problem was solved via disallowance of obtaining the xt of
<return-stack-accessing-word> (since such words have undefined
interpretation semantics).

We have the following issue concerning "COMPILE,".

Proposition (1):
"COMPILE," is equivalent to "POSTPONE LITERAL POSTPONE EXECUTE"

If (1) is true, then a user (a standard program) is allowed to redefine
"COMPILE," in this way.

Proposition (2):
The phrase
POSTPONE LITERAL POSTPONE EXECUTE
is operationally equivalent to
POSTPONE LITERAL [: ( some stuff, e.g. logging ) EXECUTE ;] COMPILE,

If (1) and (2) are true, then a redefinition of "COMPILE," according to
(2) is also allowed. But using this variant for "COMPILE,", a
user-defined text interpreter will work incorrectly in some systems.

A possible explanation:
a. The proposition (1) is false (i.e., it isn't true for some
standard systems)
b. The proposition (2) is false (how to prove that?)
c. A system is non-standard if (2) is false (in some cases at the least).

A problem is that (2) is true by themself. I.e., without (1), a program
cannot detect that (2) is false. So, if you can only disprove (2) by
(1), a possible reason that (1) is false by themself.

I find that it's inconsistent that (1) makes (2) false. Therefore, if we
enforce the equivalence (1), some implementations for "EXIT" become non
standard.

--
Ruvim

On 2021-05-27 11:33, Anton Ertl wrote:
> "minf...@arcor.de" <minforth@arcor.de> writes:
>> Or make it two words, like CHAR and [CHAR] or ' and ['].
>
> Yes, that's certainly a good way to avoid the pitfalls of
> STATE-smartness (and while you may have avoided them, I fell into
> them).

Another ways is POSTPONE

>
> Or, for the cases like the above, another alternative is recognizing
> 'c' and `<word>.
>
> But there is the lure of cutting and pasting code from compiled to
> interpreted code. The two-word approach does not allow that; the
> recognizer approach allows it, but does not cover stuff like IF
> ... THEN or [: ... ;].

I'm curious is it possible to specify "[: ... ;]" in such a way that
allows to implement this construct via the Recognizer API?

> And that's where people who complain about
> theoretical cleanliness venture into the practical dirtyness of
> STATE-smartness or broken COMPILE,.

AFAIR, STATE-smartness is dirty by your definition. It's not a
STATE-smartness, if it doesn't have dirtiness.

But STATE-dependency can be clean and very useful.

For example, it allows to provide far better reusing factor, as I showed
at: https://forth-standard.org/proposals/recognizer#reply-548

Perhaps it's possible to achieve such extent of reusing in the dual-xt
approach too, but it seems to be more difficult.

> IMO Forth implementors should make a decision between
>
> 1) Single-xt-with-immediate-flag system with IF and [IF], [: and
> :NONAME, and (without the corresponding recognizer) with ' and ['].
>
> 2) A system that implements independent interpretation and compilation
> semantics.

It's a false dilemma (see in length in Wikipedia https://w.wiki/Er4 ).

The single-xt approach doesn't imply that "[:" cannot replace ":NONAME",
or that the interpretation semantics (IS) for "[']" cannot be equivalent
to the IS for "'" in a single-xt system.

The dual-xt approach doesn't solve the problem of interpretive "IF".

Recognizers can work in both approaches.

And the Forth standard allows these both approaches, and it is its strength.

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-05-29 20:36, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2021-05-29 12:09, Anton Ertl wrote:
>>>> : foo ." before" execute ." after" ;
>>>> ' ;s foo \ prints "before"
>>>>
>>> One problem is that this ";s" doesn't work if "execute" is redefined.
>>>
>>> I thought about this problem when claimed that it's impossible.
>>>
>>> : e execute ; ' ;s [: ." (before)" e ." (after)" ;] e
>>> \ it prints: (before)(after)
>>>
>>>
>>> So, if we redefine compile in another way, something like:
>>>
>>> : compile, lit, [: ( some stuff) execute ;] compile, ;
>>>
>>> Then a user-defined text interpreter will work incorrectly. And we don't
>>> have a normative reason why it doesn't work correctly.
>>
>> Sure we have, at least for the E case: The initiation semantics of the
>> colon definition pushes nest-sys (the return address) on the return
>> stack, and EXIT's execution semantics consumes nest-sys. So you
>> cannot redefine EXECUTE in this way and expect it to work for words
>> that do something with the return stack, such as EXIT.
>
>Yes, for the case E it's obvious.
>
>Moreover, the case of E is non-standard. A standard program cannot
>obtain the xt for a word that consumes nest-sys or accesses/changes the
>return stack.

There is no explicit rule for that; it's only implicit in the
undefinition of interpretation semantics of such words.

>So I didn't understand why did you try to make "['] EXIT EXECUTE" work,

The general idea is to avoid unnecessary restrictions; in this
particular case Bernd Paysan was the driving force, and I don't
remember the reason he gave.

>when you implemented "EXIT" as a word with default CS.

The standard specifies EXIT as a word with default compilation
semantics. I think it's confusing to describe implementations in
those terms. Gforth implements EXIT as an immediate compile-only word
(and there is no standard way to detect whether EXIT has default
compilation semantics).

>In this case it's
>enough to make "['] EXIT COMPILE," work correctly.

You lost me here. In any case, if you do this in Gforth, you probably
won't get what you expect.

>> Of course, the other problem is that some Forth systems implement
>> EXECUTE in a way that puts stuff on the return stack around the
>> execution, so these systems work like your E. Given that nobody
>> complains about that, maybe EXECUTE's definition should be refined
>> appropriately, "solving" all the problems with "can I EXECUTE the xt of
>> <return-stack-accessing-word>".
>
>I think, this problem was solved via disallowance of obtaining the xt of
><return-stack-accessing-word> (since such words have undefined
>interpretation semantics).

Yes, but I think we should put this possible effect of EXECUTE in
EXECUTE, and also put a related limitation on the text interpreter,
and delete the undefinition of the interpretation semantics of >R etc.
This would make

: foo [ ' >r compile, ] r> ;

standard.

>We have the following issue concerning "COMPILE,".
>
>Proposition (1):
> "COMPILE," is equivalent to "POSTPONE LITERAL POSTPONE EXECUTE"
>
>If (1) is true, then a user (a standard program) is allowed to redefine
>"COMPILE," in this way.
>
>
>Proposition (2):
> The phrase
> POSTPONE LITERAL POSTPONE EXECUTE
> is operationally equivalent to
> POSTPONE LITERAL [: ( some stuff, e.g. logging ) EXECUTE ;] COMPILE,
>
>If (1) and (2) are true, then a redefinition of "COMPILE," according to
>(2) is also allowed. But using this variant for "COMPILE,", a
>user-defined text interpreter will work incorrectly in some systems.
>
>A possible explanation:
> a. The proposition (1) is false (i.e., it isn't true for some
>standard systems)

Well, the way EXECUTE is specified, the equivalence holds, but it's
questionable if you can observe it for, e.g., the xt of >R in a
standard system. The way EXECUTE and >R are implemented in SwiftForth
3.11, the equivalence does not hold for the xt of >R.

In VFX64 5.11, the standalone version of >R compensates for the
return-stack push of EXECUTE, so e.g.,

: bla execute dup . r> ;
1 2 ' >r bla 2drop \ prints "1"

works.

Gforth uses an EXECUTE that does not do something to the return stack;
this works because Gforth maintains the Forth IP in a general-purpose
register (in the tradition of threaded-code systems), so no correction
in >R is needed.

For native-code systems the correction used by VFX seems like the
right approach.

> b. The proposition (2) is false (how to prove that?)

A properly specified [: ... ;] specifies that nest-sys is pushed.

As for "work incorrectly", despite the equivalence not being there for
>R in SwiftForth, I don't think that's a problem for a user-defined
text interpreter, because such text interpreters tend not to work when
you interpret >R etc. anyway.

- 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

In article <s903g0$p68$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
<SNIP>
>I'm curious is it possible to specify "[: ... ;]" in such a way that
>allows to implement this construct via the Recognizer API?

I have a single xt nt=xt system without smart words, but with
poor man's recognizers (PREFIX). (ciforth).
I have unified [: ;] and :NONAME ; into { } without needing
recognizers.
Anonymous pieces of code can be transported into definitions
no problem.
So i can't see what recognizers have to do with it.

>> And that's where people who complain about
>> theoretical cleanliness venture into the practical dirtyness of
>> STATE-smartness or broken COMPILE,.
>
>AFAIR, STATE-smartness is dirty by your definition. It's not a
>STATE-smartness, if it doesn't have dirtiness.
>
>But STATE-dependency can be clean and very useful.
>
>For example, it allows to provide far better reusing factor, as I showed
>at: https://forth-standard.org/proposals/recognizer#reply-548
>
>Perhaps it's possible to achieve such extent of reusing in the dual-xt
>approach too, but it seems to be more difficult.
>
>> IMO Forth implementors should make a decision between
>>
>> 1) Single-xt-with-immediate-flag system with IF and [IF], [: and
>> :NONAME, and (without the corresponding recognizer) with ' and ['].
>>
>> 2) A system that implements independent interpretation and compilation
>> semantics.
>
>It's a false dilemma (see in length in Wikipedia https://w.wiki/Er4 ).
>
>
>The single-xt approach doesn't imply that "[:" cannot replace ":NONAME",
>or that the interpretation semantics (IS) for "[']" cannot be equivalent
>to the IS for "'" in a single-xt system.
>
>The dual-xt approach doesn't solve the problem of interpretive "IF".
>
>Recognizers can work in both approaches.
>
>And the Forth standard allows these both approaches, and it is its strength.

lucky, my attempt at simplifying Forth, has no distinction between IF and [IF].
It has crossed a line, unlimited nesting of compilation and interpretation.

>--
>Ruvim

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

On 30/05/2021 23:21, Ruvim wrote:
> ...
> And the Forth standard allows these both approaches, and it is its strength.

200x has form when it comes to slashing approaches. Surely the strength
of Forth has been its ability to weather each attempt at a standard.

"You delight in laying down laws, yet you delight more in breaking them."
- Kahlil Gibran

On 2021-05-30 19:59, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
[...]

>> We have the following issue concerning "COMPILE,".
>>
>> Proposition (1):
>> "COMPILE," is equivalent to "POSTPONE LITERAL POSTPONE EXECUTE"
>>
>> If (1) is true, then a user (a standard program) is allowed to redefine
>> "COMPILE," in this way.
[...]
>> A possible explanation:
>> a. The proposition (1) is false (i.e., it isn't true for some
>> standard systems)
>
> Well, the way EXECUTE is specified, the equivalence holds, but it's
> questionable if you can observe it for, e.g., the xt of >R in a
> standard system.

A possible rationale: in some cases "COMPILE," may be applied to an xt,
but an ambiguous condition exists if "EXECUTE" is applied to this xt.

Since in some cases "FIND" guarantees the expected effect only when
"COMPILE," applied to the returned xt, and says nothing concerning
applying "EXECUTE".

> The way EXECUTE and >R are implemented in SwiftForth
> 3.11, the equivalence does not hold for the xt of >R.
>
> In VFX64 5.11, the standalone version of >R compensates for the
> return-stack push of EXECUTE, so e.g.,
>
> : bla execute dup . r> ;
> 1 2 ' >r bla 2drop \ prints "1"
>
> works.

A system may provide a separate stack to implement interpretation
semantics for R-words. In such a system this example can print 1, but it
will work still incorrectly.

> Gforth uses an EXECUTE that does not do something to the return stack;
> this works because Gforth maintains the Forth IP in a general-purpose
> register (in the tradition of threaded-code systems), so no correction
> in >R is needed.
>
> For native-code systems the correction used by VFX seems like the
> right approach.

>
>> b. The proposition (2) is false (how to prove that?)-
>
> A properly specified [: ... ;] specifies that nest-sys is pushed.

It doesn't matter in this case. Since we can avoid quotations.

Proposition (1):
the phrase
compile,
is equivalent to
postpone literal postpone execute

Proposition (3):
The phrase
postpone execute
is equivalent to
postpone e
where "e" is defined as
: e execute ;
(or its equivalent)

Without using (1) as a premise, (3) is true in any standard system/program.

The only way to detect that (3) is false is to use (1) as a premise, and
only in some implementation approaches (namely, where CS for R-related
words are performed via "COMPILE,").

But it doesn't mean that (3) is false, but that (1) and (3) are mutually
exclusive in some systems (i.e., only one from these propositions can be
true, and another is false in these systems).

Thus, we have three options:

a. Declare that (1) is false (i.e. its equivalency isn't always true)
b. Declare that (3) is false (i.e. its equivalency sometimes false)
c. Declare that in a standard system both (1) and (3) shall be true.

I'm inclined to "a" and more to "c". Since the proposition (3) is used
far more often than (1). But the best is to hold them both.

A test case is following.

\ find name; if n=-1, then return xt, otherwise throw an exception
: f{ ( "ccc" -- xt ) bl word '}' parse 2drop find dup 0= -13 and throw
dup 1 = abort" n/a" -1 <> abort" wrong find"
; immediate

variable _e \ to avoid tail call optimization
: e dup >r execute r> _e ! ;

\ This test is only valid in a system
\ that implements the CS for "exit" via "compile,"
] f{ exit } [ constant x

\ append the CS of exit in a standard way
: exit1, x compile, ;

\ append the CS of exit according to (1)
: exit2, x postpone literal postpone execute ;

\ append the CS of exit according to (1) and (3)
: exit3, x postpone literal postpone e ;

\ this shall print 0
:noname 0 [ exit1, ] drop 1 ; e .

\ if this prints 1, then (1) is false in the system,
\ otherwise we can say nothing re (1)
:noname 0 [ exit2, ] drop 1 ; e .

\ if this prints 1, then (1) or (3) is false in the system,
\ otherwise we can say nothing re (1) and (3)
:noname 0 [ exit3, ] drop 1 ; e .

>
> As for "work incorrectly", despite the equivalence not being there for
> >R in SwiftForth, I don't think that's a problem for a user-defined
> text interpreter, because such text interpreters tend not to work when
> you interpret >R etc. anyway.

Hope I was able to become clear about this quite complex logic.

The the last three definitions we do what the text interpreter does in
compilation state. Instead of "exit", the test case can be applied to
">r" or to other R-related word.

--
Ruvim

On Monday, May 31, 2021 at 12:26:54 PM UTC+2, Ruvim wrote:
> On 2021-05-30 19:59, Anton Ertl wrote:
[..]
>
> \ This test is only valid in a system
> \ that implements the CS for "exit" via "compile,"
> ] f{ exit } [ constant x

To make sense of it, I need the definition of f{ ... } . I assume you defined it somewhere in the last cartload of postings. Can you please restate it?

-marcel

On 2021-06-02 08:25, Marcel Hendrix wrote:
> On Monday, May 31, 2021 at 12:26:54 PM UTC+2, Ruvim wrote:
>> On 2021-05-30 19:59, Anton Ertl wrote:
> [..]
>>
>> \ This test is only valid in a system
>> \ that implements the CS for "exit" via "compile,"
>> ] f{ exit } [ constant x
>
> To make sense of it, I need the definition of f{ ... } . I assume you defined it somewhere in the last cartload of postings. Can you please restate it?

It was defined just above in my message, after the sentence "A test case
is following."

\ find name; if n=-1, then return xt, otherwise throw an exception
: f{ ( "ccc" -- xt ) bl word '}' parse 2drop find dup 0= -13 and throw
dup 1 = abort" n/a" -1 <> abort" wrong find"
; immediate

Concerning naming. I think, it should be visible and obvious that a word
takes some arguments from the input buffer (or input source), and what
exactly arguments it takes.

In this example, if you see "f{ xxx }" you understand that "xxx" is a
subject to "f".

--
Ruvim

On 2021-06-02 08:25, Marcel Hendrix wrote:
> On Monday, May 31, 2021 at 12:26:54 PM UTC+2, Ruvim wrote:
>> On 2021-05-30 19:59, Anton Ertl wrote:
> [..]
>>
>> \ This test is only valid in a system
>> \ that implements the CS for "exit" via "compile,"
>> ] f{ exit } [ constant x

NB: If a system doesn't provide a full-fledged "FIND", then this test is
also invalid for the system.

--
Ruvim

On Wednesday, June 2, 2021 at 8:40:27 AM UTC+2, Ruvim wrote:
> On 2021-06-02 08:25, Marcel Hendrix wrote:
> > On Monday, May 31, 2021 at 12:26:54 PM UTC+2, Ruvim wrote:
> >> On 2021-05-30 19:59, Anton Ertl wrote:
> > [..]
> >>
> >> \ This test is only valid in a system
> >> \ that implements the CS for "exit" via "compile,"
> >> ] f{ exit } [ constant x
> NB: If a system doesn't provide a full-fledged "FIND", then this test is
> also invalid for the system.

Here is the unabridged output for your test.

FORTH> \ find name; if n=-1, then return xt, otherwise throw an exception ok
FORTH> : f{ ( "ccc" -- xt ) bl word '}' parse 2drop find dup 0= -13 and throw
<3>[FORTH>] dup 1 = abort" n/a" -1 <> abort" wrong find"
<3>[FORTH>] ; immediate ok
FORTH> ok
FORTH> variable _e \ to avoid tail call optimization ok
FORTH> : e dup >r execute r> _e ! ; ok
FORTH> ok
FORTH> \ This test is only valid in a system ok
FORTH> \ that implements the CS for "exit" via "compile," ok
FORTH> ] f{ exit } [ constant x ok
FORTH> ok
FORTH> \ append the CS of exit in a standard way ok
FORTH> : exit1, x compile, ; ok
FORTH> ok
FORTH> \ append the CS of exit according to (1) ok
FORTH> : exit2, x postpone literal postpone execute ; ok
FORTH> ok
FORTH> \ append the CS of exit according to (1) and (3) ok
FORTH> : exit3, x postpone literal postpone e ; ok
FORTH> ok
FORTH> ok
FORTH> \ this shall print 0 ok
FORTH> :noname 0 [ exit1, ] drop 1 ; e . 0 ok
FORTH> ok
FORTH> \ if this prints 1, then (1) is false in the system, ok
FORTH> \ otherwise we can say nothing re (1) ok
FORTH> :noname 0 [ exit2, ] drop 1 ; e . 0 ok
FORTH> ok
FORTH> \ if this prints 1, then (1) or (3) is false in the system, ok
FORTH> \ otherwise we can say nothing re (1) and (3) ok
FORTH> :noname 0 [ exit3, ] drop 1 ; e .
Caught exception 0xc000001d
ILLEGAL INSTRUCTION
instruction pointer = $000000000134074A
RAX = $012BA900 RBX = $01340740
RCX = $00000000 RDX = $000004CC
RSI = $01155C00 RDI = $2CB0F790
RBP = $01125F40 RSP = $2CB0F7D8
R8 = $01155C20 R9 = $00000020
R10 = $01045F50 R11 = $011128A7
R12 = $01098AC0 R13 = $01157000
R14 = $01135FE8 R15 = $01110000
Hardware exception in ``exit3,''+$0000010A
**** RETURN STACK DUMP **** for MAIN-THREAD
_e (+$0000045E)
exit3, (+$00000100)
(;]) (+$0000025B)
$@@? (+$00000B79)
$00000000 (0)
$0122D710 (19060496)
$00000000 (0)
$00000016 (22)
$@@? (+$00000DEA)

-marcel

On 2021-06-03 09:05, Marcel Hendrix wrote:
> On Wednesday, June 2, 2021 at 8:40:27 AM UTC+2, Ruvim wrote:
>> On 2021-06-02 08:25, Marcel Hendrix wrote:
>>> On Monday, May 31, 2021 at 12:26:54 PM UTC+2, Ruvim wrote:
>>>> On 2021-05-30 19:59, Anton Ertl wrote:
>>> [..]
>>>>
>>>> \ This test is only valid in a system
>>>> \ that implements the CS for "exit" via "compile,"
>>>> ] f{ exit } [ constant x
>> NB: If a system doesn't provide a full-fledged "FIND", then this test is
>> also invalid for the system.
>
> Here is the unabridged output for your test.

Thank you for this!

> FORTH> \ this shall print 0 ok
> FORTH> :noname 0 [ exit1, ] drop 1 ; e . 0 ok
> FORTH> ok
> FORTH> \ if this prints 1, then (1) is false in the system, ok
> FORTH> \ otherwise we can say nothing re (1) ok
> FORTH> :noname 0 [ exit2, ] drop 1 ; e . 0 ok
> FORTH> ok
> FORTH> \ if this prints 1, then (1) or (3) is false in the system, ok
> FORTH> \ otherwise we can say nothing re (1) and (3) ok
> FORTH> :noname 0 [ exit3, ] drop 1 ; e .
> Caught exception 0xc000001d
> ILLEGAL INSTRUCTION

So, CS for "exit" is performed via "compile," in iForth

Also, the equivalences for "compile," and the equivalences for "execute"
are mutually exclusive in iForth. A program can rely only on one of them.

A program can rely either on the equivalence for "compile,":

"compile," ⇐⇒ "postpone literal postpone execute"

or on the equivalence for execute:

"postpone execute" ⇐⇒ "[: ( any stuff ) execute ;] compile,"
and then
"execute" ⇐⇒ "[: ( any stuff ) execute ;] execute"

But not on they both, in iForth.

--
Ruvim

On 2021-05-30 19:59, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-05-29 20:36, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> writes:
[...]
>>>> : e execute ; ' ;s [: ." (before)" e ." (after)" ;] e
[...]
>> Moreover, the case of E is non-standard. A standard program cannot
>> obtain the xt for a word that consumes nest-sys or accesses/changes the
>> return stack.
>
> There is no explicit rule for that; it's only implicit in the
> undefinition of interpretation semantics of such words.

Actually, I agree that the rules concerning restriction on obtaining xt
should be more explicit (and visible in the corresponding glossary
entries).

>> when you implemented "EXIT" as a word with default CS.
>
> The standard specifies EXIT as a word with default compilation
> semantics.

Yes. And in some plausible systems it's implemented as a word with
default compilation semantics. But it doesn't mean that "EXIT" shall be
implemented as a word with default CS.

> I think it's confusing to describe implementations in
> those terms.

Yes, it's slightly confusing. Although such description is admissible
from the formal point of view.

OTOH, while this form is used, we cannot effectively use the "defined
execution semantics" property to refer the certain group of words.

> Gforth implements EXIT as an immediate compile-only word
> (and there is no standard way to detect whether EXIT has default
> compilation semantics).

Just a side note for other people.

There is a standard way to detect whether the compilation semantics (CS)
for "EXIT" should be performed using "COMPILE," or "EXECUTE" — it's the
"FIND" word.

But performing the CS via "COMPILE," doesn't mean that the word has
default CS; and performing the CS via "EXECUTE" doesn't mean that the
word has non default CS.

>> In this case it's
>> enough to make "['] EXIT COMPILE," work correctly.
>
> You lost me here. In any case, if you do this in Gforth, you probably
> won't get what you expect.
>

If "EXIT" is implemented as a word with default CS, then the phrase

['] EXIT COMPILE,

performs the compilation semantics for "EXIT" (in this system).

But a program isn't allowed to perform " ['] EXIT EXECUTE "
and then this phrase may work incorrectly (i.e. in any unexpected way).
So, no need to implement any expected behavior for the case when
"EXECUTE" is applied to the xt of "EXIT".

[...]
>>> Of course, the other problem is that some Forth systems implement
>>> EXECUTE in a way that puts stuff on the return stack around the
>>> execution, so these systems work like your E. Given that nobody
>>> complains about that, maybe EXECUTE's definition should be refined
>>> appropriately, "solving" all the problems with "can I EXECUTE the xt of
>>> <return-stack-accessing-word>".
>>
>> I think, this problem was solved via disallowance of obtaining the xt of
>> <return-stack-accessing-word> (since such words have undefined
>> interpretation semantics).
>
> Yes, but I think we should put this possible effect of EXECUTE in
> EXECUTE,

It's not easy, since the behavior of "EXECUTE" should be broken up into
three phases for that.

Another question is, should this possible effect be also put in "CATCH",
"EVALUATE", "INCLUDED"?

> and also put a related limitation on the text interpreter,

That it shouldn't use the return stack? Or what the limitation?

> and delete the undefinition of the interpretation semantics of >R etc.
>
> This would make
>
> : foo [ ' >r compile, ] r> ;
>
> standard.

I dislike this latter idea, since it makes nonstandard the existing
dual-semantics implementations for R-words.

--
Ruvim