On 21/06/2021 00:38, Krishna Myneni wrote:
> 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.

Elizabeth's comment re nested anonymous definitions still resonates with me.
AFAIK to compile an anonymous definition requires executing :NONAME which
sets compilation state.

On 21/06/2021 05:49, Gerry Jackson wrote:
> 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?

Why is it right? Implicit in compiling code is the notion one is no
longer interpreting.

On 2021-06-20 20:54, P Falth wrote:
> 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:
[...]
>>>> 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 consider non-fulfilment of P1 as an inconsistency in the Forth
language/implementation, and as any inconsistency, this inconsistency
leads to some problems, depending on particular twists. And the problems
with "state smart" words is a result of this inconsistency too.

A method to define a dual semantics word via two definitions (and even
removing the "STATE" word) doesn't solve this inconsistency, but just
buries it deeper. It's possible to show this inconsistency anyway.

a99-027 also doesn't solve the problem, but makes a workaround: it
declares that any code that can detect this inconsistency, is ambiguous.

> I will not do that.

It also just a workaround. You know a problem, and avoid it. But the
language/implementation itself still contains this inconsistency.

> In LXF64 I have postexecute that will execute a postponed immediate word
> with state set to compiling.

There is a nuance. What if a request to enter into compilation state is
a part of some compilation semantics. At the moment, such behavior may
be a part of a standard program (see the "]" word). So, I don't revert
the state in such case (see: https://git.io/JnoHY ).

Maybe it makes sense to declare that such behavior is ambiguous.

>> [...]
>>>>>> 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!

Yes, in your system. It just means that in you system this equivalency
for "compile," is not held in interpretation state, but possibly it's
held in compilation state.

That is, the phrase:

compile,

is equivalent to the phrase:

postpone literal postpone execute

in any such context where these phrases are encountered by the Forth
text interpreter in *compilation state*.

(I don't sure that your system holds this in edge cases, but this is the
idea)

To also hold this equivalency in interpretation state, you have to
define the following interpretation semantics for "postpone".

"POSTPONE" Interpretation: Skip leading space delimiters. Parse
/name/ delimited by a space. Find /name/. Perform the compilation
semantics of /name/.

But it opposes to the conception that a program is not allowed to
perform compilation semantics in interpretation state.

--
Ruvim

On 21/06/2021 04:38, dxforth wrote:
> On 21/06/2021 05:49, Gerry Jackson wrote:
>> 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?
>
> Why is it right?  Implicit in compiling code is the notion one is no
> longer interpreting.

Perhaps I asked the wrong question. There is no absolute right and wrong
answer, just whether we should stick to purity and say do we want to
interpret while compiling. Purity is already blurred by the existence of
immediacy and built-in immediate words like IF. Immediacy is largely an
unnecessary convenience because there is an easy work around.

The question is what is the objection to compiling in interpreter mode
if it works and is harmless apart from possibly being wasteful if not in
the middle of a colon definition. The fact that it works in several, if
not all systems, seems to indicate that it requires a bit of extra code
to prevent it. I would have thought that all you KISS, 'don't like
ambiguity', 'don't like being told what to do', anti standard people
would approve :)

--
Gerry

On 21/06/2021 18:27, Gerry Jackson wrote:
> On 21/06/2021 04:38, dxforth wrote:
>> On 21/06/2021 05:49, Gerry Jackson wrote:
>>> 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?
>>
>> Why is it right?  Implicit in compiling code is the notion one is no
>> longer interpreting.
>
> Perhaps I asked the wrong question. There is no absolute right and wrong
> answer, just whether we should stick to purity and say do we want to
> interpret while compiling. Purity is already blurred by the existence of
> immediacy and built-in immediate words like IF. Immediacy is largely an
> unnecessary convenience because there is an easy work around.
>
> The question is what is the objection to compiling in interpreter mode
> if it works and is harmless apart from possibly being wasteful if not in
> the middle of a colon definition. The fact that it works in several, if
> not all systems, seems to indicate that it requires a bit of extra code
> to prevent it. I would have thought that all you KISS, 'don't like
> ambiguity', 'don't like being told what to do', anti standard people
> would approve :)
>

It benefits us all to be clear what we're doing and why. As I see it:

a) For a definition, compilation mode is entered by executing : and
remains so until ; is encountered. Words within : ; are compiled
by default. The exception is immediate words which do something
immediately and compile the result as executable code. [ ] plays
no part in compilation - rather it allows something to be put on
the data stack at compile-time for a compiling word to use.
Because compiling words are typically immediate (LITERAL POSTPONE
etc) there is no need to execute them within [ ]. More importantly,
nothing is gained by doing so. ANS has marked all code compiling
words as having 'no interpretation semantics' for that reason.

b) Outside a definition there's no reason to compile code and no way
to execute it even if one did. So no need to consider further.

c) ANS has included COMPILE, among the words having no interpretation
semantics. While it could be useful to execute COMPILE, within [ ]
it is not essential e.g. VFX will optimize: [ xt ] LITERAL EXECUTE

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

What is your expectation for use of the phrase "[ COMPILE-FOO ]" inside
of a definition, when COMPILE-FOO is tagged as an immediate word?

: compile-foo postpone foo ; immediate

In this case the compilation semantics of COMPILE-FOO should be the same
as its runtime semantics.

Krishna

On Sunday, June 20, 2021 at 9:33:41 AM UTC-5, Krishna Myneni wrote:
> 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

Anonymous compile in on-going definition:

: foo ." FOO "
[ smudge csp @
' branch compile, ahead
anon ." BOO " ;
swap resolve
swap csp !
] ." BAR " literal enter ;

foo \ => FOO BAR BOO

It seems I can but I won't.

--
me

On 21/06/2021 11:20, dxforth wrote:
> On 21/06/2021 18:27, Gerry Jackson wrote:
>> On 21/06/2021 04:38, dxforth wrote:
>>> On 21/06/2021 05:49, Gerry Jackson wrote:
>>>> 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?
>>>
>>> Why is it right?  Implicit in compiling code is the notion one is no
>>> longer interpreting.
>>
>> Perhaps I asked the wrong question. There is no absolute right and wrong
>> answer, just whether we should stick to purity and say do we want to
>> interpret while compiling. Purity is already blurred by the existence of
>> immediacy and built-in immediate words like IF. Immediacy is largely an
>> unnecessary convenience because there is an easy work around.
>>
>> The question is what is the objection to compiling in interpreter mode
>> if it works and is harmless apart from possibly being wasteful if not in
>> the middle of a colon definition. The fact that it works in several, if
>> not all systems, seems to indicate that it requires a bit of extra code
>> to prevent it. I would have thought that all you KISS, 'don't like
>> ambiguity', 'don't like being told what to do', anti standard people
>> would approve :)
>>
>
> It benefits us all to be clear what we're doing and why.  As I see it:
>
> a) For a definition, compilation mode is entered by executing : and
>    remains so until ; is encountered.  Words within : ; are compiled
>    by default.  The exception is immediate words which do something
>    immediately and compile the result as executable code.  [ ] plays
>    no part in compilation - rather it allows something to be put on
>    the data stack at compile-time for a compiling word to use.
>    Because compiling words are typically immediate (LITERAL POSTPONE
>    etc) there is no need to execute them within [ ]

It would be silly to execute them directly because their behaviour is
undefined in interpretation mode, but they can be executed by a call to
a colon definition that uses them.

>  More importantly, nothing is gained by doing so.

Never say never, someone may find it useful.

>  ANS has marked all code compiling
>    words as having 'no interpretation semantics' for that reason.

Not just for that reason, more likely for preventing execution of
compiling words outside a colon definition.

>
> b) Outside a definition there's no reason to compile code and no way
>    to execute it even if one did.  So no need to consider further.

Quite, it would silly to do so.

>
> c) ANS has included COMPILE, among the words having no interpretation
>    semantics.  While it could be useful to execute COMPILE, within [ ]
>    it is not essential e.g. VFX will optimize:  [ xt ] LITERAL EXECUTE

In general, the fact that one system optimises something proves nothing.
--
Gerry

On 22/06/2021 00:13, Gerry Jackson wrote:
> On 21/06/2021 11:20, dxforth wrote:
>> On 21/06/2021 18:27, Gerry Jackson wrote:
>>> On 21/06/2021 04:38, dxforth wrote:
>>>> On 21/06/2021 05:49, Gerry Jackson wrote:
>>>>> 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?
>>>>
>>>> Why is it right?  Implicit in compiling code is the notion one is no
>>>> longer interpreting.
>>>
>>> Perhaps I asked the wrong question. There is no absolute right and wrong
>>> answer, just whether we should stick to purity and say do we want to
>>> interpret while compiling. Purity is already blurred by the existence of
>>> immediacy and built-in immediate words like IF. Immediacy is largely an
>>> unnecessary convenience because there is an easy work around.
>>>
>>> The question is what is the objection to compiling in interpreter mode
>>> if it works and is harmless apart from possibly being wasteful if not in
>>> the middle of a colon definition. The fact that it works in several, if
>>> not all systems, seems to indicate that it requires a bit of extra code
>>> to prevent it. I would have thought that all you KISS, 'don't like
>>> ambiguity', 'don't like being told what to do', anti standard people
>>> would approve :)
>>>
>>
>> It benefits us all to be clear what we're doing and why.  As I see it:
>>
>> a) For a definition, compilation mode is entered by executing : and
>>    remains so until ; is encountered.  Words within : ; are compiled
>>    by default.  The exception is immediate words which do something
>>    immediately and compile the result as executable code.  [ ] plays
>>    no part in compilation - rather it allows something to be put on
>>    the data stack at compile-time for a compiling word to use.
>>    Because compiling words are typically immediate (LITERAL POSTPONE
>>    etc) there is no need to execute them within [ ]
>
> It would be silly to execute them directly because their behaviour is
> undefined in interpretation mode, but they can be executed by a call to
> a colon definition that uses them.

Their behaviour is undefined any time STATE=0. That didn't stop Ruvim
conducting a poll asking what different systems do in that instance:

https://groups.google.com/g/comp.lang.forth/c/QY-XBI8e3AE/m/Rn7EGtSuBAAJ

>
>>  More importantly, nothing is gained by doing so.
>
> Never say never, someone may find it useful.

When I'm shown something that doesn't flout ANS' rules on compiling words
then we can discuss whether it's useful.

On Monday, 21 June 2021 at 07:30:16 UTC+2, Ruvim wrote:
> On 2021-06-20 20:54, P Falth wrote:
> > 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:
> [...]
> >>>> 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 consider non-fulfilment of P1 as an inconsistency in the Forth
> language/implementation, and as any inconsistency, this inconsistency
> leads to some problems, depending on particular twists. And the problems
> with "state smart" words is a result of this inconsistency too.
>
> A method to define a dual semantics word via two definitions (and even
> removing the "STATE" word) doesn't solve this inconsistency, but just
> buries it deeper. It's possible to show this inconsistency anyway.
>
> a99-027 also doesn't solve the problem, but makes a workaround: it
> declares that any code that can detect this inconsistency, is ambiguous.
> > I will not do that.
> It also just a workaround. You know a problem, and avoid it. But the
> language/implementation itself still contains this inconsistency.
> > In LXF64 I have postexecute that will execute a postponed immediate word
> > with state set to compiling.
> There is a nuance. What if a request to enter into compilation state is
> a part of some compilation semantics. At the moment, such behavior may
> be a part of a standard program (see the "]" word). So, I don't revert
> the state in such case (see: https://git.io/JnoHY ).
>
> Maybe it makes sense to declare that such behavior is ambiguous.
> >> [...]
> >>>>>> 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!
> Yes, in your system. It just means that in you system this equivalency
> for "compile," is not held in interpretation state, but possibly it's
> held in compilation state.
>
> That is, the phrase:
>
> compile,
> is equivalent to the phrase:
> postpone literal postpone execute
>
> in any such context where these phrases are encountered by the Forth
> text interpreter in *compilation state*.
>
> (I don't sure that your system holds this in edge cases, but this is the
> idea)
>
>
>
> To also hold this equivalency in interpretation state, you have to
> define the following interpretation semantics for "postpone".
>
> "POSTPONE" Interpretation: Skip leading space delimiters. Parse
> /name/ delimited by a space. Find /name/. Perform the compilation
> semantics of /name/.
So you want to make postpone a dual semantics words or state-smart word!

Maybe it is better to give it a new name as the behavior changed
maybe [POSTPONE] or ]POSTPONE[

But I think I see what you want to achieve, will you suggest similar behavior for
other compile only words like IF etc.

I can see an alternative instead by changing [ and ]
[ suspends compilation and sets up a temporary code space and continues compilation
] ends the temporary definition, restores the suspended definition and executes
the code just compiled

I can't say it it is usefully. But neither I think it s useful to compile in interpret state!

BR
Peter

> But it opposes to the conception that a program is not allowed to
> perform compilation semantics in interpretation state.
>
>
>
> --
> Ruvim

On 2021-06-21 04:45, 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.
>>>>
[...]
>>>>
>>>>   b. It's better if the proposition is true in a system.
>>>>
[...]

>>> 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):

No, it doesn't.

In some cases — yes. But in general, Gforth doesn't hold P1.

--
Ruvim

On 6/22/21 6:34 AM, Ruvim wrote:
> On 2021-06-21 04:45, 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.
>>>>>
> [...]
>>>>>
>>>>>   b. It's better if the proposition is true in a system.
>>>>>
> [...]
>
>>>> 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):
>
> No, it doesn't.
>
> In some cases — yes. But in general, Gforth doesn't hold P1.

Perhaps you can provide some test code for checking whether or not P1 or
P2 holds for a Forth system. Without test code, it is difficult to
understand exactly what you are aiming for.

Krishna

On 2021-06-21 21:34, P Falth wrote:
> On Monday, 21 June 2021 at 07:30:16 UTC+2, Ruvim wrote:
>> On 2021-06-20 20:54, P Falth wrote:
[...]
>>> But how could I do that?
>>> : T9 [ ' foo postpone literal postpone execute ] ;
>>> will produce a completely different result!
>> Yes, in your system. It just means that in you system this equivalency
>> for "compile," is not held in interpretation state, but possibly it's
>> held in compilation state.
>>
>> That is, the phrase:
>>
>> compile,
>>
>> is equivalent to the phrase:
>>
>> postpone literal postpone execute
>>
>> in any such context where these phrases are encountered by the Forth
>> text interpreter in *compilation state*.
>>
>> (I don't sure that your system holds this in edge cases, but this is the
>> idea)
>>
>>
>> To also hold this equivalency in interpretation state, you have to
>> define the following interpretation semantics for "postpone".
>>
>> "POSTPONE" Interpretation: Skip leading space delimiters. Parse
>> /name/ delimited by a space. Find /name/. Perform the compilation
>> semantics of /name/.
>
> So you want to make postpone a dual semantics words or state-smart word!

I don't talk about standardization at the moment (see [1] below).

It's just a solution, how to hold the given equivalency in
interpretation state (NB: it's another one, neither P1 nor P2, but it's
connected with P2).

> Maybe it is better to give it a new name as the behavior changed
> maybe [POSTPONE] or ]POSTPONE[

A standard system is allowed to provide the given interpretation
semantics for "POSTPONE". Such "POSTPONE" can break nothing, why do we
need another name?

> But I think I see what you want to achieve, will you suggest similar behavior for
> other compile only words like IF etc.
>
> I can see an alternative instead by changing [ and ]
> [ suspends compilation and sets up a temporary code space and continues compilation
> ] ends the temporary definition, restores the suspended definition and executes
> the code just compiled

It's a nice idea!

But it's isn't compliant.
E.g., it fails on the following:

[ char | parse any text | 2drop ]

So in this case we need other names for these words.

> I can't say it it is usefully. But neither I think it s useful to compile in interpret state!

What about a Forth-assembler? It compiles in interpretation state. And
it seems, it very useful. Isn't it?

When we write something like:

[ ' x compile, ]

it can be considered as a kind of a Forth assembler, when you compile
something in interpretation state.

-----

[1] Concerning dual-semantics words.

According to the definition for the "dual-semantics word" term [2], if
you see the different effects when a non ordinary word is encountered by
the Forth text interpreter in interpretation state, and when it's
encountered in compilation state, then this word is a dual-semantics
word (by implementation).

So, if a system throws an exception when interpreting "postpone", then
"postpone" is implemented as a dual-semantics word.

It's a common case that the words for which the standard undefines
interpretation semantics are implemented as dual-semantics words.

[2] "Problem of FIND, rethinking", 2021-05-19
news:s81ftp$geg$1@dont-email.me
http://al.howardknight.net/?ID=162255657000

A dual-semantics word is a non ordinary word, for which the
interpretation semantics are not equivalent to the compilation semantics.

--
Ruvim

On 2021-06-21 11:27, Gerry Jackson wrote:

> Purity is already blurred by the existence of
> immediacy and built-in immediate words like IF.

The standard doesn't require to implement "IF" as an immediate word.

Perhaps you mean by "immediacy" something different.

> Immediacy is largely an
> unnecessary convenience because there is an easy work around.

What a work around do you mean?

By my understanding, immediacy (in the standard notion) is just a way to
implement non default compilation semantics and dual-semantics words.

--
Ruvim

On 2021-06-22 15:24, Krishna Myneni wrote:
> On 6/22/21 6:34 AM, Ruvim wrote:
>> On 2021-06-21 04:45, 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.
>>>>>>
>> [...]
>>>>>>
>>>>>>   b. It's better if the proposition is true in a system.
>>>>>>
>> [...]
>>
>>>>> 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):
>>
>> No, it doesn't.
>>
>> In some cases — yes. But in general, Gforth doesn't hold P1.
>
> Perhaps you can provide some test code for checking whether or not P1 or
> P2 holds for a Forth system. Without test code, it is difficult to
> understand exactly what you are aiming for.

A test code cannot prove that these propositions are held. In some
cases, by a chance, a test code can prove that they are not held.

So for these propositions, a test code either shows that a proposition
isn't held, or shows nothing.

The test cases are following.

\ some helpers
: execute-balance ( i*x xt -- j*x n )
depth 1- >r execute depth r> -
;
: qe{ ( i*x "ccc }" -- j*x n-balance-compiling )
\ Parse the input buffer up to "}",
\ create a quotation (one-liner), execute it,
\ place on the stack the difference in the depth during compilation.
\ CS: not implemented (abort)
\ qe{ [ 10 20 ] 30 } ( -- 10 20 30 2 )
state @ abort" not implemented"
['] :noname execute-balance n>r [char] } parse
['] evaluate execute-balance 2 +
nr> drop postpone ; swap >r execute r>
; immediate

\ some "foo" words for testing

: foo1 ( -- x ) 1 ;
: foo2 ( -- x ) 2 ; immediate
: foo3 ( -- x ) state @ 0<> ; immediate

\ testing some "foo"

: compile-foo1 postpone foo1 ;
t{
qe{ foo1 }
->
qe{ [ compile-foo1 ] }
}t

: compile-foo2 postpone foo2 ;
t{
qe{ foo2 }
->
qe{ [ compile-foo2 ] }
}t

: compile-foo3 postpone foo3 ;
t{
qe{ foo3 }
->
qe{ [ compile-foo3 ] }
}t

: compile-if postpone if ;
t{
0 1 qe{ if 10 or then }
->
0 1 qe{ [ compile-if ] 10 or then }
}t

Take into account that testing is blind concerning how "foo" is defined,
what its semantics, what its behavior in the different conditions, etc.

NB: a polyfill can be loaded into any standard system so the system will
pass this test.

--
Ruvim

On 22/06/2021 14:33, Ruvim wrote:
> On 2021-06-21 11:27, Gerry Jackson wrote:
>
>> Purity is already blurred by the existence of immediacy and built-in
>> immediate words like IF.
>
> The standard doesn't require to implement "IF" as an immediate word.
>
> Perhaps you mean by "immediacy" something different.

I qualified immediacy by 'built in' but I agree it's poorly worded

>
>
>> Immediacy is largely an unnecessary convenience because there is an
>> easy work around.
>
> What a work around do you mean?

: foo ... ; immediate
: bar ... foo ... ;
can be replaced by
: foo ... ;
: bar ... [ foo ] ... ;

unless FOO is state smart which is why I wrote 'largely'. Also if FOO
does things like POSTPONEing or COMPILE,ing I assume that will work.

>
> By my understanding, immediacy (in the standard notion) is just a way to
> implement non default compilation semantics and dual-semantics words.
>
>

--
Gerry

On 2021-06-22 21:43, Gerry Jackson wrote:
> On 22/06/2021 14:33, Ruvim wrote:
>> On 2021-06-21 11:27, Gerry Jackson wrote:
>>
>>> Purity is already blurred by the existence of immediacy and built-in
>>> immediate words like IF.
>>
>> The standard doesn't require to implement "IF" as an immediate word.
>>
>> Perhaps you mean by "immediacy" something different.
>
> I qualified immediacy by 'built in' but I agree it's poorly worded
>
>>
>>
>>> Immediacy is largely an unnecessary convenience because there is an
>>> easy work around.
>>
>> What a work around do you mean?
>
> : foo ... ; immediate
> : bar ... foo ... ;
> can be replaced by
> : foo ... ;
> : bar ... [ foo ] ... ;

Yes, it's just a convenience. But it's a useful and demanded convenience.

Without that a control flow can look as:

: bar [ if, ] baz [ then, ] qux [ ;

> unless FOO is state smart which is why I wrote 'largely'.

Instead of a dual-semantics word we have to use two ordinary words.

To compile a string literal, we can do:

[ s" test" slit, ]
or
[ s" test", ]

To compile a character 'x':

[ char x lit, ]

To compile "to x":

[ to x, ]

> Also if FOO
> does things like POSTPONEing or COMPILE,ing I assume that will work.

Yes, it's an expected behavior.

But if we don't have such a thing like non default compilation
semantics, then "postpone x" is equivalent to "['] x compile," that is
equivalent to "[ ' x lit, ] compile,"

That is,
: foo postpone x ; immediate
: bar foo ;
<=>
: foo postpone x ;
: bar [ foo ] ;
<=>
: foo [ ' x lit, ] compile, ;
: bar [ foo ] ;
<=>
: bar [ ' x compile, ] ;

>>
>> By my understanding, immediacy (in the standard notion) is just a way
>> to implement non default compilation semantics and dual-semantics words.
>>

--
Ruvim

On 2021-06-19 23:03, 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.
>

Proposition 3.
The phrase:
postpone literal postpone execute
is equivalent to the phrase:
compile,
in any context.

Rationale.

1. Creating a definition programmatically has nothing to do with
compilation state and STATE. So, it should be possible regardless of the
STATE.

2. The "code ... end-code" construct works in interpretation state.

3. Then "compile," can also work in interpretation state.

4. Then "compile-foo" (defined as it's shown above) should also work in
interpretation state, and P1 should be held.

5. Assuming that P3 (an equivalence for "compile,") is held, P2 should
be held too.

--
Ruvim

On 25/06/2021 00:20, Ruvim wrote:
> On 2021-06-19 23:03, 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.
>>
>
>
> Proposition 3.
> The phrase:
> postpone literal postpone execute
> is equivalent to the phrase:
> compile,
> in any context.
>
>
>
>
> Rationale.
>
> 1. Creating a definition programmatically has nothing to do with
> compilation state and STATE. So, it should be possible regardless of the
> STATE.
>
> 2. The "code ... end-code" construct works in interpretation state.
>
> 3. Then "compile," can also work in interpretation state.
>
> 4. Then "compile-foo" (defined as it's shown above) should also work in
> interpretation state, and P1 should be held.
>
> 5. Assuming that P3 (an equivalence for "compile,") is held, P2 should
> be held too.
>

"code ... end-code" 'comma in' data as opposed to compiling a high-level
forth definition which sets 'compilation mode' and therefore STATE. It's
comparing apples and oranges.

If the proposition is compiling words should be usable inside [ ] which
AFAIK currently isn't permitted in standard programs, it would be more
convincing to argue this from a needs/benefit basis rather than equivalence
(same result obtained differently) or dubious comparisons (assembler).

On 2021-06-25 01:49, dxforth wrote:
> On 25/06/2021 00:20, Ruvim wrote:
>> On 2021-06-19 23:03, 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.
>>>
>>
>>
>> Proposition 3.
>>     The phrase:
>>       postpone literal postpone execute
>>     is equivalent to the phrase:
>>       compile,
>>     in any context.
>>
>>
>>
>>
>> Rationale.
>>
>> 1. Creating a definition programmatically has nothing to do with
>> compilation state and STATE. So, it should be possible regardless of the
>> STATE.
>>
>> 2. The "code ... end-code" construct works in interpretation state.
>>
>> 3. Then "compile," can also work in interpretation state.
>>
>> 4. Then "compile-foo" (defined as it's shown above) should also work in
>> interpretation state, and P1 should be held.
>>
>> 5. Assuming that P3 (an equivalence for "compile,") is held, P2 should
>> be held too.
>>
>
> "code ... end-code" 'comma in' data as opposed to compiling a high-level
> forth definition which sets 'compilation mode' and therefore STATE.  It's
> comparing apples and oranges.

What is wrong to incrementally build a high-level forth definition in
interpretation state?

Well, what if we redefine "compile," and "postpone" in the following way:

: state-on ] ;
: state-off postpone [ ;

: execute-compiling ( ... xt -- ... )
state @ if execute exit then
state-on execute state-off
;
\ NB: the edge cases are not considered
\ for the sake of this example simplicity.

: compile, ( xt -- )
['] compile, execute-compiling
;
: postpone ( "name" -- )
postpone [: postpone postpone postpone ;]
postpone execute-compiling
; immediate

Now "compile," can be used interpretively, and a postponed code can be
started in interpretation state — from a program point of view. But from
the system's point of view (and the postponed code point of view), they
are performed in compilation state.

What a problem do you see now?

> If the proposition is compiling words should be usable inside [ ] which
> AFAIK currently isn't permitted in standard programs, it would be more
> convincing to argue this from a needs/benefit basis rather than equivalence
> (same result obtained differently) or dubious comparisons (assembler).

If we talk about consistency of a system, needs or benefits don't matter
at all.

But equivalency is a fundamental mechanism.

Why, in arithmetic, x^0 = 1 (for any x <> 0 ) ?

Since x^0 = x^(-1 + 1) = x^(-1) * x^(1) = 1/x * x = x/x = 1

It's just a consequence of equivalences that shall be held.

--
Ruvim

On 25/06/2021 21:25, Ruvim wrote:
> On 2021-06-25 01:49, dxforth wrote:
>> On 25/06/2021 00:20, Ruvim wrote:
>>> On 2021-06-19 23:03, 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.
>>>>
>>>
>>>
>>> Proposition 3.
>>>     The phrase:
>>>       postpone literal postpone execute
>>>     is equivalent to the phrase:
>>>       compile,
>>>     in any context.
>>>
>>>
>>>
>>>
>>> Rationale.
>>>
>>> 1. Creating a definition programmatically has nothing to do with
>>> compilation state and STATE. So, it should be possible regardless of the
>>> STATE.
>>>
>>> 2. The "code ... end-code" construct works in interpretation state.
>>>
>>> 3. Then "compile," can also work in interpretation state.
>>>
>>> 4. Then "compile-foo" (defined as it's shown above) should also work in
>>> interpretation state, and P1 should be held.
>>>
>>> 5. Assuming that P3 (an equivalence for "compile,") is held, P2 should
>>> be held too.
>>>
>>
>> "code ... end-code" 'comma in' data as opposed to compiling a high-level
>> forth definition which sets 'compilation mode' and therefore STATE.  It's
>> comparing apples and oranges.
>
> What is wrong to incrementally build a high-level forth definition in
> interpretation state?

: ', ' ] compile, postpone [ ;

: foo [ ', >r ', * ', r> ', / ] ;

vs.

: foo >r * r> / ;

>
>
> Well, what if we redefine "compile," and "postpone" in the following way:
>
> : state-on ] ;
> : state-off postpone [ ;
>
> : execute-compiling ( ... xt -- ... )
> state @ if execute exit then
> state-on execute state-off
> ;
> \ NB: the edge cases are not considered
> \ for the sake of this example simplicity.
>
> : compile, ( xt -- )
> ['] compile, execute-compiling
> ;
> : postpone ( "name" -- )
> postpone [: postpone postpone postpone ;]
> postpone execute-compiling
> ; immediate
>
>
> Now "compile," can be used interpretively, and a postponed code can be
> started in interpretation state — from a program point of view. But from
> the system's point of view (and the postponed code point of view), they
> are performed in compilation state.
>
> What a problem do you see now?
>
>
>
>> If the proposition is compiling words should be usable inside [ ] which
>> AFAIK currently isn't permitted in standard programs, it would be more
>> convincing to argue this from a needs/benefit basis rather than equivalence
>> (same result obtained differently) or dubious comparisons (assembler).
>
> If we talk about consistency of a system, needs or benefits don't matter
> at all.
>
> But equivalency is a fundamental mechanism.
>
> Why, in arithmetic, x^0 = 1 (for any x <> 0 ) ?
>
> Since x^0 = x^(-1 + 1) = x^(-1) * x^(1) = 1/x * x = x/x = 1
>
> It's just a consequence of equivalences that shall be held.

confusion <-- contravention

>
>
> --
> Ruvim
>

On 2021-06-25 15:55, dxforth wrote:
> On 25/06/2021 21:25, Ruvim wrote:
>> On 2021-06-25 01:49, dxforth wrote:
>>> On 25/06/2021 00:20, Ruvim wrote:
[...]
>>>> Rationale.
>>>>
>>>> 1. Creating a definition programmatically has nothing to do with
>>>> compilation state and STATE. So, it should be possible regardless of
>>>> the
>>>> STATE.
>>>>
>>>> 2. The "code ... end-code" construct works in interpretation state.
>>>>
>>>> 3. Then "compile," can also work in interpretation state.
>>>>
>>>> 4. Then "compile-foo" (defined as it's shown above) should also work in
>>>> interpretation state, and P1 should be held.
>>>>
>>>> 5. Assuming that P3 (an equivalence for "compile,") is held, P2 should
>>>> be held too.
>>>>
>>>
>>> "code ... end-code" 'comma in' data as opposed to compiling a high-level
>>> forth definition which sets 'compilation mode' and therefore STATE.
>>> It's
>>> comparing apples and oranges.
>>
>> What is wrong to incrementally build a high-level forth definition in
>> interpretation state?
>
> : ',  ' ] compile, postpone [ ;
>
> : foo  [ ', >r  ', *  ', r>  ', / ] ;
>
> vs.
>
> : foo  >r * r> / ;

As I can see, nothing wrong. It just works. Yes, it has more size. But
"compilation state" was introduced to make code shorter, I think. So
compilation state doesn't abolish incremental compilation in
interpretation state in principle.

BTW colorForth also compiles in interpretation state (it doesn't have
compilation state). In this sense, it's a kind of a Forth-assembler.

Your "'," prefix could be also a part of a colorless colorForth.

[...]
>> Now "compile," can be used interpretively, and a postponed code can be
>> started in interpretation state — from a program point of view. But from
>> the system's point of view (and the postponed code point of view), they
>> are performed in compilation state.
>>
>> What a problem do you see now?

>>> If the proposition is compiling words should be usable inside [ ] which
>>> AFAIK currently isn't permitted in standard programs, it would be more
>>> convincing to argue this from a needs/benefit basis rather than
>>> equivalence
>>> (same result obtained differently) or dubious comparisons (assembler).
>>
>> If we talk about consistency of a system, needs or benefits don't matter
>> at all.
>>
>> But equivalency is a fundamental mechanism.
>>
>> Why, in arithmetic, x^0 = 1 (for any x <> 0 ) ?
>>
>> Since x^0 = x^(-1 + 1) = x^(-1) * x^(1) = 1/x * x = x/x = 1
>>
>> It's just a consequence of equivalences that shall be held.
>
> confusion <-- contravention

What do you mean?

--
Ruvim

On Friday, 25 June 2021 at 15:21:48 UTC+2, Ruvim wrote:
> On 2021-06-25 15:55, dxforth wrote:
> > On 25/06/2021 21:25, Ruvim wrote:
> >> On 2021-06-25 01:49, dxforth wrote:
> >>> On 25/06/2021 00:20, Ruvim wrote:
> [...]
> >>>> Rationale.
> >>>>
> >>>> 1. Creating a definition programmatically has nothing to do with
> >>>> compilation state and STATE. So, it should be possible regardless of
> >>>> the
> >>>> STATE.
> >>>>
> >>>> 2. The "code ... end-code" construct works in interpretation state.
> >>>>
> >>>> 3. Then "compile," can also work in interpretation state.
> >>>>
> >>>> 4. Then "compile-foo" (defined as it's shown above) should also work in
> >>>> interpretation state, and P1 should be held.
> >>>>
> >>>> 5. Assuming that P3 (an equivalence for "compile,") is held, P2 should
> >>>> be held too.
> >>>>
> >>>
> >>> "code ... end-code" 'comma in' data as opposed to compiling a high-level
> >>> forth definition which sets 'compilation mode' and therefore STATE.
> >>> It's
> >>> comparing apples and oranges.
> >>
> >> What is wrong to incrementally build a high-level forth definition in
> >> interpretation state?
> >
> > : ', ' ] compile, postpone [ ;
> >
> > : foo [ ', >r ', * ', r> ', / ] ;
> >
> > vs.
> >
> > : foo >r * r> / ;
> As I can see, nothing wrong. It just works. Yes, it has more size. But
> "compilation state" was introduced to make code shorter, I think. So
> compilation state doesn't abolish incremental compilation in
> interpretation state in principle.

on lxf

: ', ' ] compile, postpone [ ; ok
: foo [ ', >r ', * ', r> ', / ] ; FOO redefined ok
: foo1 >r * r> / ; FOO1 redefined ok
see foo
A4A4E8 409AB3 20 C80000 5 normal FOO

409AB3 E8062C8800 call >R
409AB8 E8FA4E8800 call *
409ABD E8212C8800 call R>
409AC2 E91A4F8800 jmp /
ok
see foo1
A4A4FC 409AC7 16 C80000 5 normal FOO1

409AC7 8B4504 mov eax , [ebp+4h]
409ACA 0FAF4500 imul eax , dword [ebp]
409ACE 99 cdq
409ACF F7FB idiv ebx
409AD1 8BD8 mov ebx , eax
409AD3 8D6D08 lea ebp , [ebp+8h]
409AD6 C3 ret near
ok
10 2 5 foo1 . 4 ok
10 2 5 foo . 1 ok

more size, less efficient and wrong result.
I have some difficulty seeing the benefit!

To get the correct result

: foo [ >r ', * r> ', / ] ; FOO redefined ok
see foo
A4A514 409AD7 37 C80000 5 normal FOO

409AD7 895C24FC mov [esp-4h] , ebx
409ADB 8B5D00 mov ebx , [ebp]
409ADE 8D6D04 lea ebp , [ebp+4h]
409AE1 8D6424FC lea esp , [esp-4h]
409AE5 E8CD4E8800 call *
409AEA 895DFC mov [ebp-4h] , ebx
409AED 8B1C24 mov ebx , [esp]
409AF0 8D6DFC lea ebp , [ebp-4h]
409AF3 8D642404 lea esp , [esp+4h]
409AF7 E9E54E8800 jmp /
ok
10 2 5 foo . 4 ok

BR
Peter
>
> BTW colorForth also compiles in interpretation state (it doesn't have
> compilation state). In this sense, it's a kind of a Forth-assembler.
>
> Your "'," prefix could be also a part of a colorless colorForth.
>
>
>
> [...]
> >> Now "compile," can be used interpretively, and a postponed code can be
> >> started in interpretation state — from a program point of view.. But from
> >> the system's point of view (and the postponed code point of view), they
> >> are performed in compilation state.
> >>
> >> What a problem do you see now?
>
>
>
> >>> If the proposition is compiling words should be usable inside [ ] which
> >>> AFAIK currently isn't permitted in standard programs, it would be more
> >>> convincing to argue this from a needs/benefit basis rather than
> >>> equivalence
> >>> (same result obtained differently) or dubious comparisons (assembler)..
> >>
> >> If we talk about consistency of a system, needs or benefits don't matter
> >> at all.
> >>
> >> But equivalency is a fundamental mechanism.
> >>
> >> Why, in arithmetic, x^0 = 1 (for any x <> 0 ) ?
> >>
> >> Since x^0 = x^(-1 + 1) = x^(-1) * x^(1) = 1/x * x = x/x = 1
> >>
> >> It's just a consequence of equivalences that shall be held.
> >
> > confusion <-- contravention
> What do you mean?
>
>
> --
> Ruvim

On 2021-06-25 18:58, P Falth wrote:
> On Friday, 25 June 2021 at 15:21:48 UTC+2, Ruvim wrote:
>> On 2021-06-25 15:55, dxforth wrote:
>>> On 25/06/2021 21:25, Ruvim wrote:
>>>> On 2021-06-25 01:49, dxforth wrote:
>>>>> On 25/06/2021 00:20, Ruvim wrote:
>> [...]
>>>>>> Rationale.
>>>>>>
>>>>>> 1. Creating a definition programmatically has nothing to do with
>>>>>> compilation state and STATE. So, it should be possible regardless of
>>>>>> the
>>>>>> STATE.
>>>>>>
>>>>>> 2. The "code ... end-code" construct works in interpretation state.
>>>>>>
>>>>>> 3. Then "compile," can also work in interpretation state.
>>>>>>
>>>>>> 4. Then "compile-foo" (defined as it's shown above) should also work in
>>>>>> interpretation state, and P1 should be held.
>>>>>>
>>>>>> 5. Assuming that P3 (an equivalence for "compile,") is held, P2 should
>>>>>> be held too.
>>>>>>
>>>>>
>>>>> "code ... end-code" 'comma in' data as opposed to compiling a high-level
>>>>> forth definition which sets 'compilation mode' and therefore STATE.
>>>>> It's
>>>>> comparing apples and oranges.
>>>>
>>>> What is wrong to incrementally build a high-level forth definition in
>>>> interpretation state?
>>>
>>> : ', ' ] compile, postpone [ ;
>>>
>>> : foo [ ', >r ', * ', r> ', / ] ;
>>>
>>> vs.
>>>
>>> : foo >r * r> / ;
>> As I can see, nothing wrong. It just works. Yes, it has more size. But
>> "compilation state" was introduced to make code shorter, I think. So
>> compilation state doesn't abolish incremental compilation in
>> interpretation state in principle.
>
> on lxf
>
> : ', ' ] compile, postpone [ ; ok
> : foo [ ', >r ', * ', r> ', / ] ; FOO redefined ok
> : foo1 >r * r> / ; FOO1 redefined ok
> see foo
> A4A4E8 409AB3 20 C80000 5 normal FOO
>
> 409AB3 E8062C8800 call >R
> 409AB8 E8FA4E8800 call *
> 409ABD E8212C8800 call R>
> 409AC2 E91A4F8800 jmp /
> ok
> see foo1
> A4A4FC 409AC7 16 C80000 5 normal FOO1
>
> 409AC7 8B4504 mov eax , [ebp+4h]
> 409ACA 0FAF4500 imul eax , dword [ebp]
> 409ACE 99 cdq
> 409ACF F7FB idiv ebx
> 409AD1 8BD8 mov ebx , eax
> 409AD3 8D6D08 lea ebp , [ebp+8h]
> 409AD6 C3 ret near
> ok
> 10 2 5 foo1 . 4 ok
> 10 2 5 foo . 1 ok
>
> more size, less efficient and wrong result.

It's obvious, this "foo" is not standard. A standard program cannot tick
">r". It's a system specific definition, namely it's compliant with only
the systems where ">r" and "r>" are implemented as ordinary words. lxf
is not such a system.

> I have some difficulty seeing the benefit!

Compiling some (or all) parts of a definition in interpretation state
can benefit for debugging or learning purposes, or for meta programming
in rare cases.

Another possible application is bootstrapping of a system, but it isn't
standard compliant, in any case.

>
> To get the correct result
>
> : foo [ >r ', * r> ', / ] ; FOO redefined ok

This code is also system specific.

However, "'," can be implemented via "find" or via "find-name", in such
a way that the "foo" by dxforth will be standard compliant:

: foo [ ', >r ', * ', r> ', / ] ;

--
Ruvim

On 25/06/2021 23:21, Ruvim wrote:
> On 2021-06-25 15:55, dxforth wrote:
>> On 25/06/2021 21:25, Ruvim wrote:
>>> ...
>>> What is wrong to incrementally build a high-level forth definition in
>>> interpretation state?
>>
>> : ',  ' ] compile, postpone [ ;
>>
>> : foo  [ ', >r  ', *  ', r>  ', / ] ;
>>
>> vs.
>>
>> : foo  >r * r> / ;
>
> As I can see, nothing wrong. It just works. Yes, it has more size. But
> "compilation state" was introduced to make code shorter, I think. So
> compilation state doesn't abolish incremental compilation in
> interpretation state in principle.

Turning off compiling bypasses the compile, in the forth interpreter
requiring one to do it manually. It's a strange principle that breaks
what the interpreter was designed to do.