A poll about equivalences for the "postpone x" expression.

Definition: a phrase is a fragment of a program expressed in the Forth
source code form.

Definition: two phrases are equivalent in a given context iff each of
them in this context always produces the same effects as other. By
default, in any given context, each lexeme that is encountered by the
Forth text interpreter is recognized as either a standard word, or a
mentioned word, or a number.

NB: a proposition that contains free variables is true iff it's true for
any possible values for the free variable.

Let "foo" is a word that doesn't perform any parsing, doesn't access the
parse area, and doesn't enter into compilation or interpretation state
(i.e., any such behavior is not a part of any semantics for "foo").

Let the word "compile-foo" is defined as:
: compile-foo postpone foo ;
and it has the same scope as the word "foo".

Proposition 1.
The phrase:
[ compile-foo ]
is equivalent to the phrase:
foo
in any such context when the phrase is encountered by the Forth
text interpreter in compilation state.

Proposition 2.
The phrase:
[ postpone foo ]
is equivalent to the phrase:
foo
in any such context when the phrase is encountered by the Forth
text interpreter in compilation state.

Please evaluate each proposition, according to your understanding/view,
by the following statements:

a. The proposition shall be true in a standard system.

b. It's better if the proposition is true in a system.

c. In a standard system the proposition may be true or false,
depending on the definition "foo".

d. In a standard system the first phrase (the left part of the
equivalency) may throw an exception for any "foo".

Multiple choice is admissible.

It's enough to indicate (separately for the propositions 1 and 2) the
letters where your choice is "yes". E.g. P1: ac, P2: bcd.

--
Ruvim

On Saturday, 19 June 2021 at 22:03:54 UTC+2, Ruvim wrote:
> A poll about equivalences for the "postpone x" expression.
>
>
> Definition: a phrase is a fragment of a program expressed in the Forth
> source code form.
>
> Definition: two phrases are equivalent in a given context iff each of
> them in this context always produces the same effects as other. By
> default, in any given context, each lexeme that is encountered by the
> Forth text interpreter is recognized as either a standard word, or a
> mentioned word, or a number.
>
> NB: a proposition that contains free variables is true iff it's true for
> any possible values for the free variable.
>
>
>
> Let "foo" is a word that doesn't perform any parsing, doesn't access the
> parse area, and doesn't enter into compilation or interpretation state
> (i.e., any such behavior is not a part of any semantics for "foo").
>
> Let the word "compile-foo" is defined as:
> : compile-foo postpone foo ;
> and it has the same scope as the word "foo".
>
>
>
> Proposition 1.
> The phrase:
> [ compile-foo ]
> is equivalent to the phrase:
> foo
> in any such context when the phrase is encountered by the Forth
> text interpreter in compilation state.
>
>
>
> Proposition 2.
> The phrase:
> [ postpone foo ]
> is equivalent to the phrase:
> foo
> in any such context when the phrase is encountered by the Forth
> text interpreter in compilation state.
>
This is what I get from lxf

: foo noop ; ok
: compile-foo postpone foo ; ok
: t1 [ compile-foo ] ; ok
: t2 foo ; ok
see t1
A4A2B8 4099BB 5 C80000 5 normal T1

4099BB E9E6FFFFFF jmp FOO
ok
see t2
A4A2CC 4099C0 5 C80000 5 normal T2

4099C0 E9E1FFFFFF jmp FOO
ok
: t3 [ postpone foo ] ; ok
see t3
A4A2E0 4099C5 16 C80000 5 normal T3

4099C5 895DFC mov [ebp-4h] , ebx
4099C8 BBA6994000 mov ebx , # 4099A6h
4099CD 8D6DFC lea ebp , [ebp-4h]
4099D0 E92B668700 jmp COMPILE,
ok
: t4 [ ' foo compile, ] ; ok
see t4
A4A2F4 4099D5 5 C80000 5 normal T4

4099D5 E9CCFFFFFF jmp FOO
ok

>
> Please evaluate each proposition, according to your understanding/view,
> by the following statements:
>
> a. The proposition shall be true in a standard system.
>
> b. It's better if the proposition is true in a system.
>
> c. In a standard system the proposition may be true or false,
> depending on the definition "foo".
>
> d. In a standard system the first phrase (the left part of the
> equivalency) may throw an exception for any "foo".
>
>
> Multiple choice is admissible.
>
> It's enough to indicate (separately for the propositions 1 and 2) the
> letters where your choice is "yes". E.g. P1: ac, P2: bcd.

In my opinion compiling code while not in compilation state should
not be done in a standard system. It might work in some systems
but not all.

I really do not understand why you are pursuing this type of coding.

If you want to call foo in a definition why not use foo directly.

: test foo ; will always work!

BR
Peter

> --
> Ruvim

In article <salij8$m2m$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>A poll about equivalences for the "postpone x" expression.
>
>
>Definition: a phrase is a fragment of a program expressed in the Forth
>source code form.
>
>Definition: two phrases are equivalent in a given context iff each of
>them in this context always produces the same effects as other. By
>default, in any given context, each lexeme that is encountered by the
>Forth text interpreter is recognized as either a standard word, or a
>mentioned word, or a number.
>
>NB: a proposition that contains free variables is true iff it's true for
>any possible values for the free variable.
>
>
>
>Let "foo" is a word that doesn't perform any parsing, doesn't access the
>parse area, and doesn't enter into compilation or interpretation state
>(i.e., any such behavior is not a part of any semantics for "foo").
>
>Let the word "compile-foo" is defined as:
> : compile-foo postpone foo ;
>and it has the same scope as the word "foo".
>
>
>
>Proposition 1.
> The phrase:
> [ compile-foo ]
> is equivalent to the phrase:
> foo
> in any such context when the phrase is encountered by the Forth
> text interpreter in compilation state.
>
>
>
>Proposition 2.
> The phrase:
> [ postpone foo ]
> is equivalent to the phrase:
> foo
> in any such context when the phrase is encountered by the Forth
> text interpreter in compilation state.
>
>
>
>
>Please evaluate each proposition, according to your understanding/view,
>by the following statements:
>
> a. The proposition shall be true in a standard system.
>
> b. It's better if the proposition is true in a system.
>
> c. In a standard system the proposition may be true or false,
>depending on the definition "foo".
>
> d. In a standard system the first phrase (the left part of the
>equivalency) may throw an exception for any "foo".
>
e. Avoid POSTPONE like the plague. Always find a way around it.

>
>Multiple choice is admissible.
>
>It's enough to indicate (separately for the propositions 1 and 2) the
>letters where your choice is "yes". E.g. P1: ac, P2: bcd.
>
>
>--
>Ruvim
--
"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-06-20 10:20, P Falth wrote:
> On Saturday, 19 June 2021 at 22:03:54 UTC+2, Ruvim wrote:
>> A poll about equivalences for the "postpone x" expression.
[...]
>> Let "foo" is a word that doesn't perform any parsing, doesn't access the
>> parse area, and doesn't enter into compilation or interpretation state
>> (i.e., any such behavior is not a part of any semantics for "foo").
>>
>> Let the word "compile-foo" is defined as:
>> : compile-foo postpone foo ;
>> and it has the same scope as the word "foo".
>>
>>
>>
>> Proposition 1.
>> The phrase:
>> [ compile-foo ]
>> is equivalent to the phrase:
>> foo
>> in any such context when the phrase is encountered by the Forth
>> text interpreter in compilation state.
>>
>>
>>
>> Proposition 2.
>> The phrase:
>> [ postpone foo ]
>> is equivalent to the phrase:
>> foo
>> in any such context when the phrase is encountered by the Forth
>> text interpreter in compilation state.
>>
> This is what I get from lxf
>
> : foo noop ; ok
> : compile-foo postpone foo ; ok
> : t1 [ compile-foo ] ; ok
> : t2 foo ; ok
> see t1
> A4A2B8 4099BB 5 C80000 5 normal T1
>
> 4099BB E9E6FFFFFF jmp FOO
> ok
> see t2
> A4A2CC 4099C0 5 C80000 5 normal T2
>
> 4099C0 E9E1FFFFFF jmp FOO
> ok

What if "foo" is a dual semantics word? What if "foo" is also an
immediate? Does the system still hold this equivalence for such cases?

> : t3 [ postpone foo ] ; ok
> see t3
> A4A2E0 4099C5 16 C80000 5 normal T3
>
> 4099C5 895DFC mov [ebp-4h] , ebx
> 4099C8 BBA6994000 mov ebx , # 4099A6h
> 4099CD 8D6DFC lea ebp , [ebp-4h]
> 4099D0 E92B668700 jmp COMPILE,
> ok
> : t4 [ ' foo compile, ] ; ok
> see t4
> A4A2F4 4099D5 5 C80000 5 normal T4
>
> 4099D5 E9CCFFFFFF jmp FOO
> ok

Then, you don't support equivalence for "compile," that it is equivalent
to "postpone literal postpone execute", do you?

>>
>> Please evaluate each proposition, according to your understanding/view,
>> by the following statements:
>>
>> a. The proposition shall be true in a standard system.
>>
>> b. It's better if the proposition is true in a system.
>>
>> c. In a standard system the proposition may be true or false,
>> depending on the definition "foo".
>>
>> d. In a standard system the first phrase (the left part of the
>> equivalency) may throw an exception for any "foo".
>>
>>
>> Multiple choice is admissible.
>>
>> It's enough to indicate (separately for the propositions 1 and 2) the
>> letters where your choice is "yes". E.g. P1: ac, P2: bcd.
>
> In my opinion compiling code while not in compilation state should
> not be done in a standard system.

It seems you wanted to say "in a standard program".

Then, you support [a99-027], don't you?

> It might work in some systems but not all.

If you think the standard allows that it doesn't work regardless "foo",
then your choice is the option "d".

>
> I really do not understand why you are pursuing this type of coding.

It's not a type of coding.

It's a problem of the language consistency and equivalences of different
expressions. In what cases the language meets a user's expectations in
this regard, and it what cases it doesn't. And why the language doesn't
meet them, if any. And what are the clear rules in this regard.

[a99-027] provides a clear rule, but many people don't follow it.

Actually, any standard system can support the expected equivalences,
(while they are consistent). But they should be clear verbalized.

>
> If you want to call foo in a definition why not use foo directly.
>
> : test foo ; will always work!

[a99-027] that performing compilation semantics in the interpretation
state is ambiguous.
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/RmsDuen7YkY/xDvW74uzi30J/

--
Ruvim

On 2021-06-20 11:30, albert wrote:
[...]

> e. Avoid POSTPONE like the plague. Always find a way around it.

It's impossible in too many cases.

For example, how do you define a well known but non standard word "rdrop"?

: rdrop postpone r> postpone drop ; immediate

It's impossible do define "rdrop" without "postpone" in a standard
program. Don't suggest to use "evaluate".

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
> : rdrop postpone r> postpone drop ; immediate
>
> It's impossible do define "rdrop" without "postpone" in a standard
> program. Don't suggest to use "evaluate".

Is this nonstandard?

: rdrop r> r> drop ;

On 2021-06-20 12:32, Paul Rubin wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> : rdrop postpone r> postpone drop ; immediate
>>
>> It's impossible do define "rdrop" without "postpone" in a standard
>> program. Don't suggest to use "evaluate".
>
> Is this nonstandard?
>
> : rdrop r> r> drop ;
>

Yes, this code isn't standard.

See 3.2.3.3 Return stack
https://forth-standard.org/standard/usage#usage:returnstack

Two excerpts:

A program shall not access values on the return stack (using "R@",
"R>", "2R@", "2R>" or "NR>") that it did not place there using ">R",
"2>R" or "N>R";

All values placed on the return stack within a definition shall be
removed before the definition is terminated or before EXIT is executed.

--
Ruvim

On Sunday, 20 June 2021 at 11:06:44 UTC+2, Ruvim wrote:
> On 2021-06-20 10:20, P Falth wrote:
> > On Saturday, 19 June 2021 at 22:03:54 UTC+2, Ruvim wrote:
> >> A poll about equivalences for the "postpone x" expression.
> [...]
> >> Let "foo" is a word that doesn't perform any parsing, doesn't access the
> >> parse area, and doesn't enter into compilation or interpretation state
> >> (i.e., any such behavior is not a part of any semantics for "foo").
> >>
> >> Let the word "compile-foo" is defined as:
> >> : compile-foo postpone foo ;
> >> and it has the same scope as the word "foo".
> >>
> >>
> >>
> >> Proposition 1.
> >> The phrase:
> >> [ compile-foo ]
> >> is equivalent to the phrase:
> >> foo
> >> in any such context when the phrase is encountered by the Forth
> >> text interpreter in compilation state.
> >>
> >>
> >>
> >> Proposition 2.
> >> The phrase:
> >> [ postpone foo ]
> >> is equivalent to the phrase:
> >> foo
> >> in any such context when the phrase is encountered by the Forth
> >> text interpreter in compilation state.
> >>
> > This is what I get from lxf
> >
> > : foo noop ; ok
> > : compile-foo postpone foo ; ok
> > : t1 [ compile-foo ] ; ok
> > : t2 foo ; ok
> > see t1
> > A4A2B8 4099BB 5 C80000 5 normal T1
> >
> > 4099BB E9E6FFFFFF jmp FOO
> > ok
> > see t2
> > A4A2CC 4099C0 5 C80000 5 normal T2
> >
> > 4099C0 E9E1FFFFFF jmp FOO
> > ok
> What if "foo" is a dual semantics word? What if "foo" is also an
> immediate? Does the system still hold this equivalence for such cases?

: foo1 noop ; immediate ok
: compile-foo1 postpone foo1 ; ok
: t6 [ compile-foo1 ] ; ok
see t6
A4A408 409A3F 1 C80000 5 normal T6

409A3F C3 ret near
ok

:p foo2 ." compiling" ;p ok
:r foo2 ." interpreting" ;r ok
foo2 interpreting ok
: compile-foo2 postpone foo2 ; ok
: t7 [ compile-foo2 ] ; compiling ok
see t7
A4A3D4 409A39 1 C80000 5 normal T7

409A39 C3 ret near
ok

> > : t3 [ postpone foo ] ; ok
> > see t3
> > A4A2E0 4099C5 16 C80000 5 normal T3
> >
> > 4099C5 895DFC mov [ebp-4h] , ebx
> > 4099C8 BBA6994000 mov ebx , # 4099A6h
> > 4099CD 8D6DFC lea ebp , [ebp-4h]
> > 4099D0 E92B668700 jmp COMPILE,
> > ok
> > : t4 [ ' foo compile, ] ; ok
> > see t4
> > A4A2F4 4099D5 5 C80000 5 normal T4
> >
> > 4099D5 E9CCFFFFFF jmp FOO
> > ok
> Then, you don't support equivalence for "compile," that it is equivalent
> to "postpone literal postpone execute", do you?

: t5 [ ' foo ] literal execute ; ok
see t5
A4A308 4099DA 8 C80000 5 normal T5

4099DA B8A6994000 mov eax , # 4099A6h
4099DF FFD0 call eax
4099E1 C3 ret near
ok

Looks to do the same thing but using 3 more bytes

> >>
> >> Please evaluate each proposition, according to your understanding/view,
> >> by the following statements:
> >>
> >> a. The proposition shall be true in a standard system.
> >>
> >> b. It's better if the proposition is true in a system.
> >>
> >> c. In a standard system the proposition may be true or false,
> >> depending on the definition "foo".
> >>
> >> d. In a standard system the first phrase (the left part of the
> >> equivalency) may throw an exception for any "foo".
> >>
> >>
> >> Multiple choice is admissible.
> >>
> >> It's enough to indicate (separately for the propositions 1 and 2) the
> >> letters where your choice is "yes". E.g. P1: ac, P2: bcd.
> >
> > In my opinion compiling code while not in compilation state should
> > not be done in a standard system.
> It seems you wanted to say "in a standard program".
>
> Then, you support [a99-027], don't you?
> > It might work in some systems but not all.
> If you think the standard allows that it doesn't work regardless "foo",
> then your choice is the option "d".
> >
> > I really do not understand why you are pursuing this type of coding.
> It's not a type of coding.
>
> It's a problem of the language consistency and equivalences of different
> expressions. In what cases the language meets a user's expectations in
> this regard, and it what cases it doesn't. And why the language doesn't
> meet them, if any. And what are the clear rules in this regard.
>
> [a99-027] provides a clear rule, but many people don't follow it.
>
> Actually, any standard system can support the expected equivalences,
> (while they are consistent). But they should be clear verbalized.
> >
> > If you want to call foo in a definition why not use foo directly.
> >
> > : test foo ; will always work!
> [a99-027] that performing compilation semantics in the interpretation
> state is ambiguous.

Yes to this I agree

Peter

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

In article <87mtrkrie6.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>Ruvim <ruvim.pinka@gmail.com> writes:
>> : rdrop postpone r> postpone drop ; immediate
>>
>> It's impossible do define "rdrop" without "postpone" in a standard
>> program. Don't suggest to use "evaluate".
>
>Is this nonstandard?
>
> : rdrop r> r> drop ;

: rdrop "R> DROP" EVALUATE ;
There, I did it. One could save the search order and establish
forthwordlist as the only wordlist and one would be pretty safe.

Now Ruvim threaten me with ... because it is tabu and not pc.
With what? Problems? I have done some maintenance programming
in my life and face worse problems than those that could be
caused by that.

Alternatively:
If someone forced me to use a Forth without RDROP and I had to compile
a program with RDROP , I just would go to my boss, and say "hey, your
programs are not standard" and propose to replace all occurrences in
the application with the equivalent standard sequence. He would agree.

Alternatively:
CODE RDROP
LEA, SI'| BO| [SI] 8 B,
NEXT,

Alternatively:
: RDROP 'R> , 'DROP , ; IMMEDIATE

Alternatively:
Pseudo PC.
: RDROP ['] R> COMPILE, ['] DROP COMPILE, ; IMMEDIATE

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 20/06/2021 06:03, Ruvim wrote:
>
> Let "foo" is a word that doesn't perform any parsing, doesn't access the
> parse area, and doesn't enter into compilation or interpretation state
> (i.e., any such behavior is not a part of any semantics for "foo").
>
> Let the word "compile-foo" is defined as:
> : compile-foo postpone foo ;
> and it has the same scope as the word "foo".
>
> Proposition 1.
> The phrase:
> [ compile-foo ]
> is equivalent to the phrase:
> foo
> in any such context when the phrase is encountered by the Forth
> text interpreter in compilation state.
>
> Proposition 2.
> The phrase:
> [ postpone foo ]
> is equivalent to the phrase:
> foo
> in any such context when the phrase is encountered by the Forth
> text interpreter in compilation state.

DX-Forth 4.45 2021-06-14

Software floating-point (separate stack)

Using FORTH.SCR

: foo noop ; ok
: compile-foo postpone foo ; COMPILE is system ok

: t1 [ compile-foo ] ;
Error: "compile-foo" compilation only

: t2 [ postpone foo ] ;
Error: "foo" compilation only

If POSTPONE is based on COMPILE, it typically can compile inside [ ] ;
if based on COMPILE it typically can not. Under ANS neither POSTPONE
nor COMPILE, is guaranteed to work inside [ ] . Disambigufiers for
them aren't guaranteed to work as they only work at the user level.

AFAICS the rule is: Don't attempt to compile while inside [ ] . Is there
a compelling reason why one should be able to?

dxforth <dxforth@gmail.com> writes:
>: t1 [ compile-foo ] ;
>Error: "compile-foo" compilation only
....
>AFAICS the rule is: Don't attempt to compile while inside [ ] . Is there
>a compelling reason why one should be able to?

If I want to lay down code in interpret state, it's not the Forth
system's job to tell me I can't. Just delete ?COMP from your system.
Not only will your system work better, it will also be smaller.

- 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 2021: https://euro.theforth.net/2021

On 2021-06-20 13:48, P Falth wrote:
> On Sunday, 20 June 2021 at 11:06:44 UTC+2, Ruvim wrote:
>> On 2021-06-20 10:20, P Falth wrote:
>>> On Saturday, 19 June 2021 at 22:03:54 UTC+2, Ruvim wrote:
>>>> A poll about equivalences for the "postpone x" expression.
>> [...]
>>>> Let "foo" is a word that doesn't perform any parsing, doesn't access the
>>>> parse area, and doesn't enter into compilation or interpretation state
>>>> (i.e., any such behavior is not a part of any semantics for "foo").
>>>>
>>>> Let the word "compile-foo" is defined as:
>>>> : compile-foo postpone foo ;
>>>> and it has the same scope as the word "foo".
>>>>
>>>>
>>>>
>>>> Proposition 1.
>>>> The phrase:
>>>> [ compile-foo ]
>>>> is equivalent to the phrase:
>>>> foo
>>>> in any such context when the phrase is encountered by the Forth
>>>> text interpreter in compilation state.
>>>>
>>>>
>>>>
>>>> Proposition 2.
>>>> The phrase:
>>>> [ postpone foo ]
>>>> is equivalent to the phrase:
>>>> foo
>>>> in any such context when the phrase is encountered by the Forth
>>>> text interpreter in compilation state.
>>>>
[...]
>> What if "foo" is a dual semantics word? What if "foo" is also an
>> immediate? Does the system still hold this equivalence for such cases?
>
> : foo1 noop ; immediate ok
> : compile-foo1 postpone foo1 ; ok
> : t6 [ compile-foo1 ] ; ok
> see t6
> A4A408 409A3F 1 C80000 5 normal T6
>
> 409A3F C3 ret near
> ok
>
> :p foo2 ." compiling" ;p ok
> :r foo2 ." interpreting" ;r ok
> foo2 interpreting ok
> : compile-foo2 postpone foo2 ; ok
> : t7 [ compile-foo2 ] ; compiling ok
> see t7
> A4A3D4 409A39 1 C80000 5 normal T7
>
> 409A39 C3 ret near
> ok

According to the proposition, the equivalence takes place in compilation
state, so in this case the effects are also the same for:

] foo2 [
and
] [ compile-foo2 ] [

So, P1 is held for a single-semantics immediate word, and for a
dual-semantics word that is not immediate.

I suspect, P1 in your system is not held for a dual-semantics immediate
word. I.e., if you make foo2 STATE-dependent.

>>> : t3 [ postpone foo ] ; ok
>>> see t3
>>> A4A2E0 4099C5 16 C80000 5 normal T3
>>>
>>> 4099C5 895DFC mov [ebp-4h] , ebx
>>> 4099C8 BBA6994000 mov ebx , # 4099A6h
>>> 4099CD 8D6DFC lea ebp , [ebp-4h]
>>> 4099D0 E92B668700 jmp COMPILE,
>>> ok
>>> : t4 [ ' foo compile, ] ; ok
>>> see t4
>>> A4A2F4 4099D5 5 C80000 5 normal T4
>>>
>>> 4099D5 E9CCFFFFFF jmp FOO
>>> ok
>> Then, you don't support equivalence for "compile," that it is equivalent
>> to "postpone literal postpone execute", do you?
>
> : t5 [ ' foo ] literal execute ; ok
> see t5
> A4A308 4099DA 8 C80000 5 normal T5
>
> 4099DA B8A6994000 mov eax , # 4099A6h
> 4099DF FFD0 call eax
> 4099E1 C3 ret near
> ok
>
> Looks to do the same thing but using 3 more bytes

Yes, but in this example you replace the phrase:
compile, ]
by the phrase:
] literal execute

So, you show equivalence not for "compile," but for "compile, ]"

[...]
>>> I really do not understand why you are pursuing this type of coding.
>> >> It's not a type of coding.
>>
>> It's a problem of the language consistency and equivalences of different
>> expressions. In what cases the language meets a user's expectations in
>> this regard, and it what cases it doesn't. And why the language doesn't
>> meet them, if any. And what are the clear rules in this regard.
>>
>> [a99-027] provides a clear rule, but many people don't follow it.
>>
[...]
>> [a99-027] that performing compilation semantics in the interpretation
>> state is ambiguous.
>
> Yes to this I agree

It's good to know!

It looks like more systems rely on a99-027 than it seemed.

--
Ruvim

On 2021-06-20 14:55, dxforth wrote:
> On 20/06/2021 06:03, Ruvim wrote:
>>
>> Let "foo" is a word that doesn't perform any parsing, doesn't access the
>> parse area, and doesn't enter into compilation or interpretation state
>> (i.e., any such behavior is not a part of any semantics for "foo").
>>
>> Let the word "compile-foo" is defined as:
>>     : compile-foo postpone foo ;
>> and it has the same scope as the word "foo".
>>
>> Proposition 1.
>>     The phrase:
>>       [ compile-foo ]
>>     is equivalent to the phrase:
>>         foo
>>     in any such context when the phrase is encountered by the Forth
>>     text interpreter in compilation state.
>>
>> Proposition 2.
>>     The phrase:
>>       [ postpone foo ]
>>     is equivalent to the phrase:
>>         foo
>>     in any such context when the phrase is encountered by the Forth
>>     text interpreter in compilation state.
>
> DX-Forth 4.45 2021-06-14
>
> Software floating-point (separate stack)
>
> Using FORTH.SCR
>
> : foo noop ; ok
> : compile-foo postpone foo ; COMPILE is system ok
>
> : t1 [ compile-foo ] ;
> Error: "compile-foo" compilation only
>
> : t2 [ postpone foo ] ;
> Error: "foo" compilation only

It's the option "d" in my list.

BTW, a more appropriate error message should mention not "foo" but
"postpone" (perhaps I already said that before :).

> If  POSTPONE  is based on  COMPILE,  it typically can compile inside [ ] ;
> if based on  COMPILE  it typically can not.  Under ANS neither  POSTPONE
> nor  COMPILE,  is guaranteed to work inside  [ ] .  Disambigufiers for
> them aren't guaranteed to work as they only work at the user level.

A standard program can access only the user level. Hence, if you
guarantee that it works on the user level, it's enough. I provided a PoC
for that.

> AFAICS the rule is: Don't attempt to compile while inside [ ] .  Is there
> a compelling reason why one should be able to?

So you as an implementer rely on a99-027, and as a user you follow the
a99-027 rule (both its parts).

--
Ruvim

On 20/06/2021 22:53, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>: t1 [ compile-foo ] ;
>>Error: "compile-foo" compilation only
> ...
>>AFAICS the rule is: Don't attempt to compile while inside [ ] . Is there
>>a compelling reason why one should be able to?
>
> If I want to lay down code in interpret state, it's not the Forth
> system's job to tell me I can't. Just delete ?COMP from your system.
> Not only will your system work better, it will also be smaller.

I know how to save memory. What are your reasons for compiling code
in interpret state given ANS saw none?

On 6/19/21 3:03 PM, Ruvim wrote:
> A poll about equivalences for the "postpone x" expression.
>
>
> Definition: a phrase is a fragment of a program expressed in the Forth
> source code form.
>
> Definition: two phrases are equivalent in a given context iff each of
> them in this context always produces the same effects as other. By
> default, in any given context, each lexeme that is encountered by the
> Forth text interpreter is recognized as either a standard word, or a
> mentioned word, or a number.
>
> NB: a proposition that contains free variables is true iff it's true for
> any possible values for the free variable.
>
>
>
> Let "foo" is a word that doesn't perform any parsing, doesn't access the
> parse area, and doesn't enter into compilation or interpretation state
> (i.e., any such behavior is not a part of any semantics for "foo").
>
> Let the word "compile-foo" is defined as:
>   : compile-foo postpone foo ;
> and it has the same scope as the word "foo".
>
>
>
> Proposition 1.
>   The phrase:
>     [ compile-foo ]
>   is equivalent to the phrase:
>       foo
>   in any such context when the phrase is encountered by the Forth
>   text interpreter in compilation state.
>
>
>
> Proposition 2.
>   The phrase:
>     [ postpone foo ]
>   is equivalent to the phrase:
>       foo
>   in any such context when the phrase is encountered by the Forth
>   text interpreter in compilation state.
>
>
>
>
> Please evaluate each proposition, according to your understanding/view,
> by the following statements:
>
>  a. The proposition shall be true in a standard system.
>
>  b. It's better if the proposition is true in a system.
>
>  c. In a standard system the proposition may be true or false,
> depending on the definition "foo".
>
>  d. In a standard system the first phrase (the left part of the
> equivalency) may throw an exception for any "foo".
>
>
> Multiple choice is admissible.
>
> It's enough to indicate (separately for the propositions 1 and 2) the
> letters where your choice is "yes". E.g.  P1: ac, P2: bcd.
>
>

I will select position (b) tentatively for now. These phrases in Props 1
and 2 currently do not work in kForth, but I can't see a reason for them
not to work, provided that they are part of a definition.

Alternative ways to accomplish the same thing in kForth are the following:

: foo ." xxxx " ;
ok
: t1 [ ' foo compile, ] ;
ok
t1
xxxx ok
..s
<empty>
ok
: t2 [ ' foo ] literal execute ;
ok
t2
xxxx ok

Using POSTPONE to define RDROP works, of course, as it should per the
standard.

I might go a bit further than you in suggesting that FOO is allowed to
be a definition which contains anonymous definitions (quotations or
nested :NONAME definitions), for greater applicability. That might be a
bridge too far for some Forth system implementors, but, as a Forth
programmer as well as system implementor, I don't wish to be needlessly
restricted in how to code my problem. The changes required to accomplish
this do not appear to me to be too great a burden.

Krishna

On 6/20/21 9:17 AM, dxforth wrote:
> On 20/06/2021 22:53, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>> : t1 [ compile-foo ] ;
>>> Error: "compile-foo" compilation only
>> ...
>>> AFAICS the rule is: Don't attempt to compile while inside [ ] .  Is
>>> there
>>> a compelling reason why one should be able to?
>>
>> If I want to lay down code in interpret state, it's not the Forth
>> system's job to tell me I can't.  Just delete ?COMP from your system.
>> Not only will your system work better, it will also be smaller.
>
> I know how to save memory.  What are your reasons for compiling code
> in interpret state given ANS saw none?

The old saying about "penny-wise but pound-foolish" comes to mind. There
are problems where coding with nested anonymous definitions can make the
application more understandable and factorable. One way to implement
such definitions is to switch to interpretation state within a
definition and then begin compiling an anonymous definition.

Krishna

On Sunday, 20 June 2021 at 15:40:30 UTC+2, Ruvim wrote:
> On 2021-06-20 13:48, P Falth wrote:
> > On Sunday, 20 June 2021 at 11:06:44 UTC+2, Ruvim wrote:
> >> On 2021-06-20 10:20, P Falth wrote:
> >>> On Saturday, 19 June 2021 at 22:03:54 UTC+2, Ruvim wrote:
> >>>> A poll about equivalences for the "postpone x" expression.
> >> [...]
> >>>> Let "foo" is a word that doesn't perform any parsing, doesn't access the
> >>>> parse area, and doesn't enter into compilation or interpretation state
> >>>> (i.e., any such behavior is not a part of any semantics for "foo").
> >>>>
> >>>> Let the word "compile-foo" is defined as:
> >>>> : compile-foo postpone foo ;
> >>>> and it has the same scope as the word "foo".
> >>>>
> >>>>
> >>>>
> >>>> Proposition 1.
> >>>> The phrase:
> >>>> [ compile-foo ]
> >>>> is equivalent to the phrase:
> >>>> foo
> >>>> in any such context when the phrase is encountered by the Forth
> >>>> text interpreter in compilation state.
> >>>>
> >>>>
> >>>>
> >>>> Proposition 2.
> >>>> The phrase:
> >>>> [ postpone foo ]
> >>>> is equivalent to the phrase:
> >>>> foo
> >>>> in any such context when the phrase is encountered by the Forth
> >>>> text interpreter in compilation state.
> >>>>
> [...]
> >> What if "foo" is a dual semantics word? What if "foo" is also an
> >> immediate? Does the system still hold this equivalence for such cases?
> >
> > : foo1 noop ; immediate ok
> > : compile-foo1 postpone foo1 ; ok
> > : t6 [ compile-foo1 ] ; ok
> > see t6
> > A4A408 409A3F 1 C80000 5 normal T6
> >
> > 409A3F C3 ret near
> > ok
> >
> > :p foo2 ." compiling" ;p ok
> > :r foo2 ." interpreting" ;r ok
> > foo2 interpreting ok
> > : compile-foo2 postpone foo2 ; ok
> > : t7 [ compile-foo2 ] ; compiling ok
> > see t7
> > A4A3D4 409A39 1 C80000 5 normal T7
> >
> > 409A39 C3 ret near
> > ok
> According to the proposition, the equivalence takes place in compilation
> state, so in this case the effects are also the same for:
>
> ] foo2 [
> and
> ] [ compile-foo2 ] [

: t8 foo2 ; compiling ok
see t8
A4A41C 409A40 1 C80000 5 normal T8

409A40 C3 ret near
ok

Compiling out side a started definition is not supported in lxf.
only
] foo2 [
might crash the system

> So, P1 is held for a single-semantics immediate word, and for a
> dual-semantics word that is not immediate.
>
> I suspect, P1 in your system is not held for a dual-semantics immediate
> word. I.e., if you make foo2 STATE-dependent.

This is correct.

> >>> : t3 [ postpone foo ] ; ok
> >>> see t3
> >>> A4A2E0 4099C5 16 C80000 5 normal T3
> >>>
> >>> 4099C5 895DFC mov [ebp-4h] , ebx
> >>> 4099C8 BBA6994000 mov ebx , # 4099A6h
> >>> 4099CD 8D6DFC lea ebp , [ebp-4h]
> >>> 4099D0 E92B668700 jmp COMPILE,
> >>> ok
> >>> : t4 [ ' foo compile, ] ; ok
> >>> see t4
> >>> A4A2F4 4099D5 5 C80000 5 normal T4
> >>>
> >>> 4099D5 E9CCFFFFFF jmp FOO
> >>> ok
> >> Then, you don't support equivalence for "compile," that it is equivalent
> >> to "postpone literal postpone execute", do you?
> >
> > : t5 [ ' foo ] literal execute ; ok
> > see t5
> > A4A308 4099DA 8 C80000 5 normal T5
> >
> > 4099DA B8A6994000 mov eax , # 4099A6h
> > 4099DF FFD0 call eax
> > 4099E1 C3 ret near
> > ok
> >
> > Looks to do the same thing but using 3 more bytes
> Yes, but in this example you replace the phrase:
> compile, ]
> by the phrase:
> ] literal execute
>
> So, you show equivalence not for "compile," but for "compile, ]"

: comp, postpone literal postpone execute ; ok
: t9 [ ' foo comp, ] ; ok
see t9
A4A448 409A4B 8 C80000 5 normal T9

409A4B B8A6994000 mov eax , # 4099A6h
409A50 FFD0 call eax
409A52 C3 ret near
ok

works also in that case

Peter

> [...]
> >>> I really do not understand why you are pursuing this type of coding.
> >> >> It's not a type of coding.
> >>
> >> It's a problem of the language consistency and equivalences of different
> >> expressions. In what cases the language meets a user's expectations in
> >> this regard, and it what cases it doesn't. And why the language doesn't
> >> meet them, if any. And what are the clear rules in this regard.
> >>
> >> [a99-027] provides a clear rule, but many people don't follow it.
> >>
> [...]
> >> [a99-027] that performing compilation semantics in the interpretation
> >> state is ambiguous.
> >
> > Yes to this I agree
> It's good to know!
>
> It looks like more systems rely on a99-027 than it seemed.
>
>
> --
> Ruvim

On 21/06/2021 00:05, Ruvim wrote:
> On 2021-06-20 14:55, dxforth wrote:
>> On 20/06/2021 06:03, Ruvim wrote:
>>>
>>> Let "foo" is a word that doesn't perform any parsing, doesn't access the
>>> parse area, and doesn't enter into compilation or interpretation state
>>> (i.e., any such behavior is not a part of any semantics for "foo").
>>>
>>> Let the word "compile-foo" is defined as:
>>>     : compile-foo postpone foo ;
>>> and it has the same scope as the word "foo".
>>>
>>> Proposition 1.
>>>     The phrase:
>>>       [ compile-foo ]
>>>     is equivalent to the phrase:
>>>         foo
>>>     in any such context when the phrase is encountered by the Forth
>>>     text interpreter in compilation state.
>>>
>>> Proposition 2.
>>>     The phrase:
>>>       [ postpone foo ]
>>>     is equivalent to the phrase:
>>>         foo
>>>     in any such context when the phrase is encountered by the Forth
>>>     text interpreter in compilation state.
>>
>> DX-Forth 4.45 2021-06-14
>>
>> Software floating-point (separate stack)
>>
>> Using FORTH.SCR
>>
>> : foo noop ; ok
>> : compile-foo postpone foo ; COMPILE is system ok
>>
>> : t1 [ compile-foo ] ;
>> Error: "compile-foo" compilation only
>>
>> : t2 [ postpone foo ] ;
>> Error: "foo" compilation only
>
> It's the option "d" in my list.
>
> BTW, a more appropriate error message should mention not "foo" but
> "postpone" (perhaps I already said that before :).
>
>
>
>> If  POSTPONE  is based on  COMPILE,  it typically can compile inside [ ] ;
>> if based on  COMPILE  it typically can not.  Under ANS neither  POSTPONE
>> nor  COMPILE,  is guaranteed to work inside  [ ] .  Disambigufiers for
>> them aren't guaranteed to work as they only work at the user level.
>
> A standard program can access only the user level. Hence, if you
> guarantee that it works on the user level, it's enough. I provided a PoC
> for that.

A disambigufier for COMPILE, at the user level won't fix the COMPILE,
that results in T1 succeeding when the intention was it should fail.

>
>
>> AFAICS the rule is: Don't attempt to compile while inside [ ] .  Is there
>> a compelling reason why one should be able to?
>
> So you as an implementer rely on a99-027, and as a user you follow the
> a99-027 rule (both its parts).

I barely understand it. As an implementer I know about COMPILE and
common practice. As a user I know what turns on interpreting and what
turns it off. I assumed that was enough. Perhaps ANS did too.

On 2021-06-20 18:00, P Falth wrote:
> On Sunday, 20 June 2021 at 15:40:30 UTC+2, Ruvim wrote:
>> On 2021-06-20 13:48, P Falth wrote:
[...]

>>> :p foo2 ." compiling" ;p ok
>>> :r foo2 ." interpreting" ;r ok

BTW, in my scratch it was:

: foo2 ." interpreting" ;
c: foo2 ." compiling" ;

And in the first version the special ";c" also was used.

Concerning naming conventions. If a word starts new definition and it's
a parsing word, give it a name in the from "xxx:". But if the word
starts new definition and it isn't a parsing word, give it a name in the
form ":xxx" (like in the case of the ":noname" word).

So I chose "c:" over ":c". It also has a slightly better readability.

>>> foo2 interpreting ok
>>> : compile-foo2 postpone foo2 ; ok
>>> : t7 [ compile-foo2 ] ; compiling ok
>>> see t7
>>> A4A3D4 409A39 1 C80000 5 normal T7
>>>
>>> 409A39 C3 ret near
>>> ok
>> According to the proposition, the equivalence takes place in compilation
>> state, so in this case the effects are also the same for:
>>
>> ] foo2 [
>> and
>> ] [ compile-foo2 ] [
>
> : t8 foo2 ; compiling ok
> see t8
> A4A41C 409A40 1 C80000 5 normal T8
>
> 409A40 C3 ret near
> ok
>
> Compiling out side a started definition is not supported in lxf.
> only
> ] foo2 [
> might crash the system

Yes, in the general case. And if it crashes the system, then it should
crash it in the both cases, and then the same effects are shown in both
cases.

OTOH, in this particular case "foo2" doesn't append anything to the
current definition, so it's unclear why it might crash the system?

>> So, P1 is held for a single-semantics immediate word, and for a
>> dual-semantics word that is not immediate.
>>
>> I suspect, P1 in your system is not held for a dual-semantics immediate
>> word. I.e., if you make foo2 STATE-dependent.
>
> This is correct.

If P1 is not held for some words (from the given domain), then P1 is
false (in the given conditions) in your system.

It's OK if you rely on a99-027, but it's a problem otherwise.

[...]
>>>> Then, you don't support equivalence for "compile," that it is equivalent
>>>> to "postpone literal postpone execute", do you?
>>>
>>> : t5 [ ' foo ] literal execute ; ok
>>> see t5
>>> A4A308 4099DA 8 C80000 5 normal T5
>>>
>>> 4099DA B8A6994000 mov eax , # 4099A6h
>>> 4099DF FFD0 call eax
>>> 4099E1 C3 ret near
>>> ok
>>>
>>> Looks to do the same thing but using 3 more bytes
>> Yes, but in this example you replace the phrase:
>> compile, ]
>> by the phrase:
>> ] literal execute
>>
>> So, you show equivalence not for "compile," but for "compile, ]"
>
> : comp, postpone literal postpone execute ; ok
> : t9 [ ' foo comp, ] ; ok
> see t9
> A4A448 409A4B 8 C80000 5 normal T9
>
> 409A4B B8A6994000 mov eax , # 4099A6h
> 409A50 FFD0 call eax
> 409A52 C3 ret near
> ok
>
> works also in that case

Yes. It means that "compile," is equivalent to "comp,", that is defined
as shown. It's useful equivalency too.

But it still doesn't show that:
compile,
is equivalent to:
postpone literal postpone execute

by the definition of equivalency that I provided in the starting post :-)

--
Ruvim

On 21/06/2021 00:17, dxforth wrote:
> On 20/06/2021 22:53, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>>: t1 [ compile-foo ] ;
>>>Error: "compile-foo" compilation only
>> ...
>>>AFAICS the rule is: Don't attempt to compile while inside [ ] . Is there
>>>a compelling reason why one should be able to?
>>
>> If I want to lay down code in interpret state, it's not the Forth
>> system's job to tell me I can't. Just delete ?COMP from your system.
>> Not only will your system work better, it will also be smaller.
>
> I know how to save memory. What are your reasons for compiling code
> in interpret state given ANS saw none?
>

I discovered one. I amended my COMPILE, to include ?COMP.
Recompiling my system it choked on the following:

:noname ... [ ... ( xt) compile, ] ;

To make that work under ANS would require:

:noname ... [ ... ( xt) ] literal execute ;

which is non-optimum.

So was ANS wrong to specify no interpretation for COMPILE, - or did
they have a reason it couldn't? Classically COMPILE, was just , so
it would have to be for reasons other than ITC/DTC.

On 2021-06-20 17:33, Krishna Myneni wrote:
> On 6/19/21 3:03 PM, Ruvim wrote:
>> A poll about equivalences for the "postpone x" expression.
>>
[...]
>>
>> Let "foo" is a word that doesn't perform any parsing, doesn't access
>> the parse area, and doesn't enter into compilation or interpretation
>> state (i.e., any such behavior is not a part of any semantics for "foo").
>>
>> Let the word "compile-foo" is defined as:
>>    : compile-foo postpone foo ;
>> and it has the same scope as the word "foo".
>>
>>
>>
>> Proposition 1.
>>    The phrase:
>>      [ compile-foo ]
>>    is equivalent to the phrase:
>>        foo
>>    in any such context when the phrase is encountered by the Forth
>>    text interpreter in compilation state.
>>
>>
>>
>> Proposition 2.
>>    The phrase:
>>      [ postpone foo ]
>>    is equivalent to the phrase:
>>        foo
>>    in any such context when the phrase is encountered by the Forth
>>    text interpreter in compilation state.
>>
>>
>>
>>
>> Please evaluate each proposition, according to your
>> understanding/view, by the following statements:
>>
>>   a. The proposition shall be true in a standard system.
>>
>>   b. It's better if the proposition is true in a system.
>>
>>   c. In a standard system the proposition may be true or false,
>> depending on the definition "foo".
>>
>>   d. In a standard system the first phrase (the left part of the
>> equivalency) may throw an exception for any "foo".
>>
>>
>> Multiple choice is admissible.
>>
>> It's enough to indicate (separately for the propositions 1 and 2) the
>> letters where your choice is "yes". E.g.  P1: ac, P2: bcd.
>>
>>
>
> I will select position (b) tentatively for now.

I also on this side.

But some programs assume that P1 is not held in some specific cases.

For example, your definition for "∋" is not compatible with a system
that holds P1 (and its generalization).

Some excerpts from kForth-64/forth-src/modules.fs
at https://git.io/Jnos8

: module-do-ref ( ... xt 1 | xt -1 -- ...)
-1 = state @ and IF compile, ELSE execute THEN ;

: [m] ( ... "module-name" "word-name" -- ? )
member-find
?dup IF module-do-ref ELSE member-not-found THEN
; immediate

: ∋ postpone [m] ; immediate

If a system holds P2, and the equivalence for "compile,", then "∋" can
be defined as:

: ∋ [ ' [m] compile, ] ; immediate

Also, in this case it's possible to use "synonym".

A compatible way In a syst A compatibile wah

: ∋ postpone [m] ; immediate

[...]
> I might go a bit further than you in suggesting that FOO is allowed to
> be a definition which contains anonymous definitions (quotations or
> nested :NONAME definitions), for greater applicability.

It's allowed. I restricted only the semantics for "foo" to have simpler
test cases (the phrases in P1 and P2). These restrictions on "foo" can
be eliminated, by the cost of more complicated test cases.

> That might be a
> bridge too far for some Forth system implementors, but, as a Forth
> programmer as well as system implementor, I don't wish to be needlessly
> restricted in how to code my problem. The changes required to accomplish
> this do not appear to me to be too great a burden.

--
Ruvim

On Sunday, 20 June 2021 at 18:32:00 UTC+2, Ruvim wrote:
> On 2021-06-20 18:00, P Falth wrote:
> > On Sunday, 20 June 2021 at 15:40:30 UTC+2, Ruvim wrote:
> >> On 2021-06-20 13:48, P Falth wrote:
> [...]
> >>> :p foo2 ." compiling" ;p ok
> >>> :r foo2 ." interpreting" ;r ok
> BTW, in my scratch it was:
>
> : foo2 ." interpreting" ;
> c: foo2 ." compiling" ;
>
> And in the first version the special ";c" also was used.
>
> Concerning naming conventions. If a word starts new definition and it's
> a parsing word, give it a name in the from "xxx:". But if the word
> starts new definition and it isn't a parsing word, give it a name in the
> form ":xxx" (like in the case of the ":noname" word).

I know that was a mistake done 20 years ago!
having it like p: makes it also easier to search for a definition of a word in a source file.
I do not remember why I chose these words! I think p was for primitive and
r definitely for runtime. The ;p and ;r are needed.
Important for me was that the compile action was defined first and
independently from the interpretation action.

> So I chose "c:" over ":c". It also has a slightly better readability.
> >>> foo2 interpreting ok
> >>> : compile-foo2 postpone foo2 ; ok
> >>> : t7 [ compile-foo2 ] ; compiling ok
> >>> see t7
> >>> A4A3D4 409A39 1 C80000 5 normal T7
> >>>
> >>> 409A39 C3 ret near
> >>> ok
> >> According to the proposition, the equivalence takes place in compilation
> >> state, so in this case the effects are also the same for:
> >>
> >> ] foo2 [
> >> and
> >> ] [ compile-foo2 ] [
> >
> > : t8 foo2 ; compiling ok
> > see t8
> > A4A41C 409A40 1 C80000 5 normal T8
> >
> > 409A40 C3 ret near
> > ok
> >
> > Compiling out side a started definition is not supported in lxf.
> > only
> > ] foo2 [
> > might crash the system
> Yes, in the general case. And if it crashes the system, then it should
> crash it in the both cases, and then the same effects are shown in both
> cases.
>
> OTOH, in this particular case "foo2" doesn't append anything to the
> current definition, so it's unclear why it might crash the system?

In fact it will not, for that reason. But something like ] dup [ will if no definitions
has been done since the start of the system., as the code generator is not
initialized.

> >> So, P1 is held for a single-semantics immediate word, and for a
> >> dual-semantics word that is not immediate.
> >>
> >> I suspect, P1 in your system is not held for a dual-semantics immediate
> >> word. I.e., if you make foo2 STATE-dependent.
> >
> > This is correct.
> If P1 is not held for some words (from the given domain), then P1 is
> false (in the given conditions) in your system.
>
> It's OK if you rely on a99-027, but it's a problem otherwise.
It is a problem for someone writing state smart words.
I will not do that.
In LXF64 I have postexecute that will execute a postponed immediate word
with state set to compiling.

>
>
> [...]
> >>>> Then, you don't support equivalence for "compile," that it is equivalent
> >>>> to "postpone literal postpone execute", do you?
> >>>
> >>> : t5 [ ' foo ] literal execute ; ok
> >>> see t5
> >>> A4A308 4099DA 8 C80000 5 normal T5
> >>>
> >>> 4099DA B8A6994000 mov eax , # 4099A6h
> >>> 4099DF FFD0 call eax
> >>> 4099E1 C3 ret near
> >>> ok
> >>>
> >>> Looks to do the same thing but using 3 more bytes
> >> Yes, but in this example you replace the phrase:
> >> compile, ]
> >> by the phrase:
> >> ] literal execute
> >>
> >> So, you show equivalence not for "compile," but for "compile, ]"
> >
> > : comp, postpone literal postpone execute ; ok
> > : t9 [ ' foo comp, ] ; ok
> > see t9
> > A4A448 409A4B 8 C80000 5 normal T9
> >
> > 409A4B B8A6994000 mov eax , # 4099A6h
> > 409A50 FFD0 call eax
> > 409A52 C3 ret near
> > ok
> >
> > works also in that case
> Yes. It means that "compile," is equivalent to "comp,", that is defined
> as shown. It's useful equivalency too.
>
> But it still doesn't show that:
> compile,
> is equivalent to:
> postpone literal postpone execute
> by the definition of equivalency that I provided in the starting post :-)

But how could I do that?
: T9 [ ' foo postpone literal postpone execute ] ;
will produce a completely different result!

Peter

>
> --
> Ruvim

On 20/06/2021 08:20, P Falth wrote:
> In my opinion compiling code while not in compilation state should
> not be done in a standard system. It might work in some systems
> but not all.

If [ ... ] is in the middle of a colon definition I don't see any
problem with the code in interpretation mode compiling code into the
incomplete colon definition.

Executing immediate code during compilation is part of the standard and
has always been in Forth. Why is compiling code when interpreting
regarded as wrong?

As Q99-027 making it ambiguous never made it into the standard it is
irrelevant and so isn't forbidden as are the opinions of people who are
no longer involved with the standard.

--
Gerry

On 6/20/21 12:34 PM, Ruvim wrote:
> On 2021-06-20 17:33, Krishna Myneni wrote:
>> On 6/19/21 3:03 PM, Ruvim wrote:
>>> A poll about equivalences for the "postpone x" expression.
>>>
> [...]
>>>
>>> Let "foo" is a word that doesn't perform any parsing, doesn't access
>>> the parse area, and doesn't enter into compilation or interpretation
>>> state (i.e., any such behavior is not a part of any semantics for
>>> "foo").
>>>
>>> Let the word "compile-foo" is defined as:
>>>    : compile-foo postpone foo ;
>>> and it has the same scope as the word "foo".
>>>
>>>
>>>
>>> Proposition 1.
>>>    The phrase:
>>>      [ compile-foo ]
>>>    is equivalent to the phrase:
>>>        foo
>>>    in any such context when the phrase is encountered by the Forth
>>>    text interpreter in compilation state.
>>>
>>>
>>>
>>> Proposition 2.
>>>    The phrase:
>>>      [ postpone foo ]
>>>    is equivalent to the phrase:
>>>        foo
>>>    in any such context when the phrase is encountered by the Forth
>>>    text interpreter in compilation state.
>>>
>>>
>>>
>>>
>>> Please evaluate each proposition, according to your
>>> understanding/view, by the following statements:
>>>
>>>   a. The proposition shall be true in a standard system.
>>>
>>>   b. It's better if the proposition is true in a system.
>>>
>>>   c. In a standard system the proposition may be true or false,
>>> depending on the definition "foo".
>>>
>>>   d. In a standard system the first phrase (the left part of the
>>> equivalency) may throw an exception for any "foo".
>>>
>>>
>>> Multiple choice is admissible.
>>>
>>> It's enough to indicate (separately for the propositions 1 and 2) the
>>> letters where your choice is "yes". E.g.  P1: ac, P2: bcd.
>>>
>>>
>>
>> I will select position (b) tentatively for now.
>
> I also on this side.
>
> But some programs assume that P1 is not held in some specific cases.
>
> For example, your definition for "∋" is not compatible with a system
> that holds P1 (and its generalization).
>

Ok, I see what you mean. Gforth holds to proposition 1 (P1):

-------
: foo ." xxx " ; ok
: compile-foo postpone foo ; ok
: t0 foo ; ok
: t1 [ compile-foo ] ; ok

see t0
: t0
foo ; ok
see t1
: t1
foo ; ok

include modules.fs ok
Module: modcheck ok
Begin-Module ok
Public: ok
: foo ." xxxx " ; ok
End-Module ok
Also modcheck ok
[m] modcheck foo xxxx ok
∋ modcheck foo xxxx ok
: test [ ∋ modcheck foo ] ; xxxx ok
------

However, this is in fact the intended behaviour of the module member
reference syntax. The underlying word, MODULE-DO-REF , is state-smart so
that [M] and its graphic equivalent ∋ will always execute the referenced
module member function when in interpretation state. kForth gives the
same behavior as above for the modcheck modules example.

In the use setting of data acquistion and control, it is necessary to be
able to execute module member functions directly from the interpreter.
For such applications, no use cases have come up in which a phrase such
as [ ∋ modcheck foo ] is used inside of a definition, particularly for
the purpose of compiling module member functions. However, it is
certainly possible that there may exist use cases for compilation
behavior of such phrases when used inside of a definition. In such a
case, a different word is needed.

> Some excerpts from kForth-64/forth-src/modules.fs
> at https://git.io/Jnos8
>
>   : module-do-ref ( ... xt 1 | xt -1 -- ...)
>     -1 = state @ and IF  compile, ELSE execute THEN ;
>
>   : [m] ( ... "module-name"  "word-name" -- ? )
>      member-find
>      ?dup IF  module-do-ref  ELSE  member-not-found  THEN
>   ; immediate
>
>   : ∋ postpone [m] ; immediate
>
> If a system holds P2, and the equivalence for "compile,", then "∋" can
> be defined as:
>
>   : ∋ [ ' [m] compile, ] ; immediate
>
>
> Also, in this case it's possible to use "synonym".
>

I believe we will find many cases in which we need to use a different
word to reference a module member function when compilation behavior is
explicitly needed. It is cases like these in which dual-semantics Forth
systems may possess a clear advantage for predicting what source code
will do.

Krishna

On 6/20/21 8:45 PM, Krishna Myneni wrote:
> On 6/20/21 12:34 PM, Ruvim wrote:
>> On 2021-06-20 17:33, Krishna Myneni wrote:
>>> On 6/19/21 3:03 PM, Ruvim wrote:
>>>> A poll about equivalences for the "postpone x" expression.
>>>>
>> [...]
>>>>
>>>> Let "foo" is a word that doesn't perform any parsing, doesn't access
>>>> the parse area, and doesn't enter into compilation or interpretation
>>>> state (i.e., any such behavior is not a part of any semantics for
>>>> "foo").
>>>>
>>>> Let the word "compile-foo" is defined as:
>>>>    : compile-foo postpone foo ;
>>>> and it has the same scope as the word "foo".
>>>>
>>>>
>>>>
>>>> Proposition 1.
>>>>    The phrase:
>>>>      [ compile-foo ]
>>>>    is equivalent to the phrase:
>>>>        foo
>>>>    in any such context when the phrase is encountered by the Forth
>>>>    text interpreter in compilation state.
>>>>
>>>>
>>>>
>>>> Proposition 2.
>>>>    The phrase:
>>>>      [ postpone foo ]
>>>>    is equivalent to the phrase:
>>>>        foo
>>>>    in any such context when the phrase is encountered by the Forth
>>>>    text interpreter in compilation state.
>>>>
>>>>
>>>>
>>>>
>>>> Please evaluate each proposition, according to your
>>>> understanding/view, by the following statements:
>>>>
>>>>   a. The proposition shall be true in a standard system.
>>>>
>>>>   b. It's better if the proposition is true in a system.
>>>>
>>>>   c. In a standard system the proposition may be true or false,
>>>> depending on the definition "foo".
>>>>
>>>>   d. In a standard system the first phrase (the left part of the
>>>> equivalency) may throw an exception for any "foo".
>>>>
>>>>
>>>> Multiple choice is admissible.
>>>>
>>>> It's enough to indicate (separately for the propositions 1 and 2)
>>>> the letters where your choice is "yes". E.g.  P1: ac, P2: bcd.
>>>>
>>>>
>>>
>>> I will select position (b) tentatively for now.
>>
>> I also on this side.
>>
>> But some programs assume that P1 is not held in some specific cases.
>>
>> For example, your definition for "∋" is not compatible with a system
>> that holds P1 (and its generalization).
>>
>
> Ok, I see what you mean. Gforth holds to proposition 1 (P1):
>
> -------
> : foo ." xxx " ;  ok
> : compile-foo postpone foo ;  ok
> : t0 foo ;  ok
> : t1 [ compile-foo ] ;  ok
>
> see t0
> : t0
>   foo ; ok
> see t1
> : t1
>   foo ; ok
>
> include modules.fs  ok
> Module: modcheck  ok
> Begin-Module  ok
> Public:  ok
> : foo ." xxxx " ;  ok
> End-Module  ok
> Also modcheck  ok
> [m] modcheck foo xxxx  ok
> ∋ modcheck foo xxxx  ok
> : test [ ∋ modcheck foo ] ; xxxx  ok
> ------
>
> However, this is in fact the intended behaviour of the module member
> reference syntax. The underlying word, MODULE-DO-REF , is state-smart so
> that [M] and its graphic equivalent ∋ will always execute the referenced
> module member function when in interpretation state. kForth gives the
> same behavior as above for the modcheck modules example.
>
> In the use setting of data acquistion and control, it is necessary to be
> able to execute module member functions directly from the interpreter.
> For such applications, no use cases have come up in which a phrase such
> as [ ∋ modcheck foo ] is used inside of a definition, particularly for
> the purpose of compiling module member functions. However, it is
> certainly possible that there may exist use cases for compilation
> behavior of such phrases when used inside of a definition. In such a
> case, a different word is needed.
> ...

Ok, we have the word [M'] to provide compiling behavior, e.g., for the
modcheck module example,

-----
: test [m] modcheck foo ; \ ok
test xxxx ok
: test ∋ modcheck foo ; \ ... ok
test xxxx ok

: test [m'] modcheck foo execute ; \ ... ok
test xxxx ok
: test [ [m'] modcheck foo ] execute ; \ ... ok
test xxxx ok
-----

The last definition of TEST does not work in kForth, owing to the fact
that it does not obey Proposition 1. It does work in Gforth, however.

Krishna