On 2021-04-30 14:43, albert wrote:
> In article <s6gos1$7jf$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>> On 2021-04-30 02:47, dxforth wrote:
>>> On 29/04/2021 21:09, Ruvim wrote:
>>>> On 2021-04-29 11:54, Anton Ertl wrote:
>>>>> dxforth <dxforth@gmail.com> writes:
>>>>>>> This POSTPONE is not STATE-"smart".
>>>>>>
>>>>>> Would you have an example of use where it would matter?
>>>>>
>>>>> : postpone postpone postpone ; immediate
>>>>> : foo [ postpone . ] ; immediate
>>>>
>>>> It's ambiguous. It should be admitted, at the moment the standard
>>>> doesn't allow to perform compilation semantics in interpretation state.
>>>
>>> Has the case been made that it should?  That something now works
>>> that previously didn't is a curiosity - not a demonstrated need.
>>> The functionality described above can almost certainly be duplicated
>>> by other means.  I just haven't been able to find the many examples
>>> of use that would justify changing POSTPONE to do it.  Why I asked.
>>> The same for POSTPONEing literals.  I've just spent 21 bytes on
>>> something I don't know I'll ever use.  When forth's hacks start
>>> thinking like Moore, the language may gain some credibility but
>>> not until then.
>>
>>
>> So the question is why do we have (or why do we need to provide) some
>> features that are very rarely used and have the alternatives?
>>
>> I see this problem as a problem of integrality and consistency.
>>
>> A user expects that the system/language is (or should be) integral and
>> consistent. A user mentally builds a model of the system, and this model
>> allows to predict the system's behavior in edge case, or to extrapolate
>> behavior from one set of situations into another set.
>>
>> If some prediction fails, the reason should be sound, convincing, and
>> clear to correct the model. Otherwise it will look like a bug or a flaw.
>>
>>
>>
>> If POSTPONE works for words, why it cannot work for numbers? What is a
>> sound reason for that? Does it have some intrinsic uncertainty? Is it
>> difficult to implement?
>>
>> If nothing of that, it's better to not break a more general model and
>> support applying POSTPONE to numbers.
>>
>>
>>
>>
>> Ditto about performing compilation semantics in interpretation state.
>> If a user (a program) explicitly directs a system to perform some
>> compilation semantics, why he should be concerned to also set
>> compilation state? The system can set compilation state by itself. It's
>> not difficult. And all required information is available for the system.
>>
>> A small nuance is that the system should not revert the state if it was
>> explicitly directed to change the state. But it's also a simple thing,
>> see my the same example https://git.io/J3331
>>
>>
>> So there is no any sound reason to break (i.e. to not support) a more
>> general model.
>
> Your reasoning is sound. My conclusion is that with the kind of
> abstraction POSTPONE offers we took a wrong turn.

What makes you think so?

> Instead of supporting POSTPONE for numbers,
> I want to get rid of POSTPONE altogether.

But then you have to get rid something from FIND [ ] and COMPILE,
since otherwise POSTPONE can be implemented using these words.

So, do you want to lock the metaprogramming capabilities, or just
suggest a better alternative to POSTPONE like like "c{ ... }c" construct?

--
Ruvim

In article <s6h94c$1s7$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2021-04-30 14:43, albert wrote:
>> In article <s6gos1$7jf$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
<SNIP>
>> Your reasoning is sound. My conclusion is that with the kind of
>> abstraction POSTPONE offers we took a wrong turn.
>
>What makes you think so?

I need more time reading all the discussions about POSTPONE than I
have ever spent in using it.

>
>
>> Instead of supporting POSTPONE for numbers,
>> I want to get rid of POSTPONE altogether.
>
>But then you have to get rid something from FIND [ ] and COMPILE,
>since otherwise POSTPONE can be implemented using these words.
>
>So, do you want to lock the metaprogramming capabilities, or just
>suggest a better alternative to POSTPONE like like "c{ ... }c" construct?

There is one meta programming facility in lucky thus far.

{ _does ! _build ! '{ RUN 'NAME , 'DEA , 'dodoe , 'SWAP , '>CFA , '! ,
_does @ 'LITERAL RUN '>DFA , '@ , ', , _build @ , '} RUN : } : META

An immediate word is "postpone"d 1) by e.g.
'{ RUN
and a word is compiled by e.g.
'SWAP ,

-All words have one behaviour.
-If you meta compile you have to look up immediacy
- , is approximately COMPILE, and RUN is approximately EXECUTE
- For literals just use good old LITERAL

POSTPONE saves you from looking up immediacy, that is not worth it
in my book.

>--
>Ruvim

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

On 30/04/2021 21:15, Ruvim wrote:
> On 2021-04-30 02:47, dxforth wrote:
>> On 29/04/2021 21:09, Ruvim wrote:
>>> On 2021-04-29 11:54, Anton Ertl wrote:
>>>> dxforth <dxforth@gmail.com> writes:
>>>>>> This POSTPONE is not STATE-"smart".
>>>>>
>>>>> Would you have an example of use where it would matter?
>>>>
>>>> : postpone postpone postpone ; immediate
>>>> : foo [ postpone . ] ; immediate
>>>
>>> It's ambiguous. It should be admitted, at the moment the standard
>>> doesn't allow to perform compilation semantics in interpretation state.
>>
>> Has the case been made that it should?  That something now works
>> that previously didn't is a curiosity - not a demonstrated need.
>> The functionality described above can almost certainly be duplicated
>> by other means.  I just haven't been able to find the many examples
>> of use that would justify changing POSTPONE to do it.  Why I asked.
>> The same for POSTPONEing literals.  I've just spent 21 bytes on
>> something I don't know I'll ever use.  When forth's hacks start
>> thinking like Moore, the language may gain some credibility but
>> not until then.
>
>
> So the question is why do we have (or why do we need to provide) some
> features that are very rarely used and have the alternatives?
>
> I see this problem as a problem of integrality and consistency.
>
> A user expects that the system/language is (or should be) integral and
> consistent. A user mentally builds a model of the system, and this model
> allows to predict the system's behavior in edge case, or to extrapolate
> behavior from one set of situations into another set.
>
> If some prediction fails, the reason should be sound, convincing, and
> clear to correct the model. Otherwise it will look like a bug or a flaw.
>
>
>
> If POSTPONE works for words, why it cannot work for numbers? What is a
> sound reason for that? Does it have some intrinsic uncertainty? Is it
> difficult to implement?
>
> If nothing of that, it's better to not break a more general model and
> support applying POSTPONE to numbers.
>
>
>
>
> Ditto about performing compilation semantics in interpretation state.
> If a user (a program) explicitly directs a system to perform some
> compilation semantics, why he should be concerned to also set
> compilation state? The system can set compilation state by itself. It's
> not difficult. And all required information is available for the system.
>
> A small nuance is that the system should not revert the state if it was
> explicitly directed to change the state. But it's also a simple thing,
> see my the same example https://git.io/J3331
>
>
> So there is no any sound reason to break (i.e. to not support) a more
> general model.
>

I imagine a new user wants a concise, easily comprehended, language that
lets them do what needs to be done. Fooling compilers into doing weird
and wonderful things is one thing, but arguing entitlement another.

I wouldn't have a clue what the postpone/foo example shown above is meant
to do (and I'm supposed to know forth). In extending POSTPONE to handle
literals one might argue it's simple to understand, less clumsy than
POSTPONE LITERAL et al and costs little to implement. It's something that
could - possibly should - have been incorporated into POSTPONE from the
beginning, had someone thought of it. Can Standard Forth and users get by
without it? I imagine they can.

On 2021-04-30 23:17, albert wrote:
> In article <s6h94c$1s7$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>> On 2021-04-30 14:43, albert wrote:
>>> In article <s6gos1$7jf$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
> <SNIP>
>>> Your reasoning is sound. My conclusion is that with the kind of
>>> abstraction POSTPONE offers we took a wrong turn.
>>
>> What makes you think so?
>
> I need more time reading all the discussions about POSTPONE than I
> have ever spent in using it.
>
>>
>>
>>> Instead of supporting POSTPONE for numbers,
>>> I want to get rid of POSTPONE altogether.
>>
>> But then you have to get rid something from FIND [ ] and COMPILE,
>> since otherwise POSTPONE can be implemented using these words.
>>
>> So, do you want to lock the metaprogramming capabilities, or just
>> suggest a better alternative to POSTPONE like like "c{ ... }c" construct?
>
> There is one meta programming facility in lucky thus far.
>
> { _does ! _build ! '{ RUN 'NAME , 'DEA , 'dodoe , 'SWAP , '>CFA , '! ,
> _does @ 'LITERAL RUN '>DFA , '@ , ', , _build @ , '} RUN : } : META

I see. It seems, it can be refactored as the following:

{ 'LITERAL RUN } : LIT,

{ _does ! _build ! '{ RUN { NAME DEA dodoe SWAP >CFA ! } ,
_does @ LIT, { >DFA @ , } , _build @ , '} RUN : } : META:

Or an even better variant:

\ If the control flow stack is separated from the data stack
{ ( xt1 -- xt2 ) '{ RUN RUN '} RUN } : DEF-BY

\ If the control flow stack is not separated
{ ( xt1 -- xt2 ) '{ RUN-EFFECT N>R RUN NR> DROP '} RUN } : DEF-BY

{ ( xt-build xt-does )
{ { NAME DEA dodoe SWAP >CFA ! } , LIT, { >DFA @ , } , , } DEF-BY
} : META

\ Usage:
\ { ...build } { ...does } META : X:

> An immediate word is "postpone"d 1) by e.g.
> '{ RUN
> and a word is compiled by e.g.
> 'SWAP ,
>
> -All words have one behaviour.
> -If you meta compile you have to look up immediacy
> - , is approximately COMPILE, and RUN is approximately EXECUTE
> - For literals just use good old LITERAL
>
> POSTPONE saves you from looking up immediacy, that is not worth it
> in my book.

Is it possible to define the word P in such a way that

'{ P 'NAME P

is equivalent to

'{ RUN 'NAME ,

?

Or maybe the prefix P: that

P:{ P:NAME

is equivalent to

'{ RUN 'NAME ,

?

> 1) Actually it is not postponed, it is run immediately.

But it's running is postponed!

--
Ruvim

On 2021-05-01 05:48, dxforth wrote:
> On 30/04/2021 21:15, Ruvim wrote:
>> On 2021-04-30 02:47, dxforth wrote:
>>> On 29/04/2021 21:09, Ruvim wrote:
>>>> On 2021-04-29 11:54, Anton Ertl wrote:
>>>>> dxforth <dxforth@gmail.com> writes:
>>>>>>> This POSTPONE is not STATE-"smart".
>>>>>>
>>>>>> Would you have an example of use where it would matter?
>>>>>
>>>>> : postpone postpone postpone ; immediate
>>>>> : foo [ postpone . ] ; immediate
>>>>
>>>> It's ambiguous. It should be admitted, at the moment the standard
>>>> doesn't allow to perform compilation semantics in interpretation state.
>>>
>>> Has the case been made that it should?  That something now works
>>> that previously didn't is a curiosity - not a demonstrated need.
>>> The functionality described above can almost certainly be duplicated
>>> by other means.  I just haven't been able to find the many examples
>>> of use that would justify changing POSTPONE to do it.  Why I asked.
>>> The same for POSTPONEing literals.  I've just spent 21 bytes on
>>> something I don't know I'll ever use.  When forth's hacks start
>>> thinking like Moore, the language may gain some credibility but
>>> not until then.
>>
>>
>> So the question is why do we have (or why do we need to provide) some
>> features that are very rarely used and have the alternatives?
>>
>> I see this problem as a problem of integrality and consistency.
>>
>> A user expects that the system/language is (or should be) integral and
>> consistent. A user mentally builds a model of the system, and this model
>> allows to predict the system's behavior in edge case, or to extrapolate
>> behavior from one set of situations into another set.
>>
>> If some prediction fails, the reason should be sound, convincing, and
>> clear to correct the model. Otherwise it will look like a bug or a flaw.
>>
>>
>>
>> If POSTPONE works for words, why it cannot work for numbers? What is a
>> sound reason for that? Does it have some intrinsic uncertainty? Is it
>> difficult to implement?
>>
>> If nothing of that, it's better to not break a more general model and
>> support applying POSTPONE to numbers.
>>
>>
>>
>>
>> Ditto about performing compilation semantics in interpretation state.
>> If a user (a program) explicitly directs a system to perform some
>> compilation semantics, why he should be concerned to also set
>> compilation state? The system can set compilation state by itself. It's
>> not difficult. And all required information is available for the system.
>>
>> A small nuance is that the system should not revert the state if it was
>> explicitly directed to change the state. But it's also a simple thing,
>> see my the same example https://git.io/J3331
>>
>>
>> So there is no any sound reason to break (i.e. to not support) a more
>> general model.
>>
>
> I imagine a new user wants a concise, easily comprehended, language that
> lets them do what needs to be done.  Fooling compilers into doing weird
> and wonderful things is one thing, but arguing entitlement another.

Agreed.

> I wouldn't have a clue what the postpone/foo example shown above is meant
> to do (and I'm supposed to know forth).

By common expectations, the following definition of foo

: p postpone postpone ; immediate \ (1)
: foo [ p . ] ; immediate \ (2)

should be equivalent to

: foo p . ; immediate \ (3)

that is equivalent to

: foo postpone . ; immediate \ (4)

That is equivalent to

: foo ['] . compile, ; immediate \ (5)

since "." (Dot) is an ordinary word.

By definition (1), ES(p) is to perform CS(postpone).

The problem is that in the point (2) the program performs ES(p) in
interpretation state, that means it performs CS(postpone) in
interpretation state, and it is ambiguous. A standard program is not
allowed to perform CS in interpretation state.

Nevertheless, the expectation that a system can properly handle this
case is very sound. The system knows that it's directed to performs CS
(since they were appended via POSTPONE), and thus the system can set
compilation state by themself to perform these semantics.

> In extending POSTPONE to handle
> literals one might argue it's simple to understand, less clumsy than
> POSTPONE LITERAL et al and costs little to implement.  It's something that
> could - possibly should - have been incorporated into POSTPONE from the
> beginning, had someone thought of it.  Can Standard Forth and users get by
> without it?  I imagine they can.

Of course they can. Moreover, it's possible to redefine POSTPONE to
handle literals. Moreover, the major part of the standard words can be
implemented via the rest part, so users can get by without the former part.

The question is in a criterion — what is worth standardizing, and what
isn't.

--
Ruvim

In article <s6jnv4$g4b$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2021-04-30 23:17, albert wrote:
>> In article <s6h94c$1s7$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>>> On 2021-04-30 14:43, albert wrote:
>>>> In article <s6gos1$7jf$1@dont-email.me>, Ruvim
><ruvim.pinka@gmail.com> wrote:
>> <SNIP>
>>>> Your reasoning is sound. My conclusion is that with the kind of
>>>> abstraction POSTPONE offers we took a wrong turn.
>>>
>>> What makes you think so?
>>
>> I need more time reading all the discussions about POSTPONE than I
>> have ever spent in using it.
>>
>>>
>>>
>>>> Instead of supporting POSTPONE for numbers,
>>>> I want to get rid of POSTPONE altogether.
>>>
>>> But then you have to get rid something from FIND [ ] and COMPILE,
>>> since otherwise POSTPONE can be implemented using these words.
>>>
>>> So, do you want to lock the metaprogramming capabilities, or just
>>> suggest a better alternative to POSTPONE like like "c{ ... }c" construct?
>>
>> There is one meta programming facility in lucky thus far.
>>
>> { _does ! _build ! '{ RUN 'NAME , 'DEA , 'dodoe , 'SWAP , '>CFA , '! ,
>> _does @ 'LITERAL RUN '>DFA , '@ , ', , _build @ , '} RUN : } : META
>
>
>I see. It seems, it can be refactored as the following:
>
> { 'LITERAL RUN } : LIT,
>
> { _does ! _build ! '{ RUN { NAME DEA dodoe SWAP >CFA ! } ,
> _does @ LIT, { >DFA @ , } , _build @ , '} RUN : } : META:
>
>
>Or an even better variant:
>
>\ If the control flow stack is separated from the data stack
> { ( xt1 -- xt2 ) '{ RUN RUN '} RUN } : DEF-BY
>
>\ If the control flow stack is not separated
> { ( xt1 -- xt2 ) '{ RUN-EFFECT N>R RUN NR> DROP '} RUN } : DEF-BY
>
>
> { ( xt-build xt-does )
> { { NAME DEA dodoe SWAP >CFA ! } , LIT, { >DFA @ , } , , } DEF-BY
> } : META
>
> \ Usage:
> \ { ...build } { ...does } META : X:
>
>
>> An immediate word is "postpone"d 1) by e.g.
>> '{ RUN
>> and a word is compiled by e.g.
>> 'SWAP ,
>>
>> -All words have one behaviour.
>> -If you meta compile you have to look up immediacy
>> - , is approximately COMPILE, and RUN is approximately EXECUTE
>> - For literals just use good old LITERAL
>>
>> POSTPONE saves you from looking up immediacy, that is not worth it
>> in my book.
>
>
>Is it possible to define the word P in such a way that
>
> '{ P 'NAME P
>
>is equivalent to
>
> '{ RUN 'NAME ,
>
>?

I invented this system to simplify things.
So { } is supposed to be used in pairs, even if it is
'{ RUN ..... '} RUN
If you don't comply, the warranty stops.

>
>Or maybe the prefix P: that
>
> P:{ P:NAME
>
>is equivalent to
>
> '{ RUN 'NAME ,

A prefix that postpones? It tries to be clever like postpone
and I'm against it. It was the cleverness (IMMEDIATE-smartness)
that I'm railing against.

>
>?
>
>
>
>> 1) Actually it is not postponed, it is run immediately.
>
>But it's running is postponed!
>
>
>--
>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 2/05/2021 17:02, Ruvim wrote:
> ...
> Nevertheless, the expectation that a system can properly handle this
> case is very sound. The system knows that it's directed to performs CS
> (since they were appended via POSTPONE), and thus the system can set
> compilation state by themself to perform these semantics.

It may be your expectation. (2) fails on my system. I get certain
advantages continuing to use a POSTPONE that's based on COMPILE and
thus far none using POSTPONE in immediate mode - which has always
been counter-intuitive.

>
>> In extending POSTPONE to handle
>> literals one might argue it's simple to understand, less clumsy than
>> POSTPONE LITERAL et al and costs little to implement.  It's something that
>> could - possibly should - have been incorporated into POSTPONE from the
>> beginning, had someone thought of it.  Can Standard Forth and users get by
>> without it?  I imagine they can.
>
> Of course they can. Moreover, it's possible to redefine POSTPONE to
> handle literals.

Not easily I presume?

> Moreover, the major part of the standard words can be
> implemented via the rest part, so users can get by without the former part.
>
> The question is in a criterion — what is worth standardizing, and what
> isn't.

The committee decides that. You make the choice whether you can use
it or not.

On 2021-05-03 07:58, dxforth wrote:
> On 2/05/2021 17:02, Ruvim wrote:
>> ...
>> Nevertheless, the expectation that a system can properly handle this
>> case is very sound. The system knows that it's directed to performs CS
>> (since they were appended via POSTPONE), and thus the system can set
>> compilation state by themself to perform these semantics.
>
> It may be your expectation.

Yes, such behavior from a Forth system is expected by me. But not only
me. It seems to me the majority of the users have the same expectation.
And one of the reason that people have so many discussion concerning
POSTPONE is that this expectation is not met, I believe.

> (2) fails on my system.

At the moment such fail is compliant with the standard.

BTW, in the Anton's edition you system will pass (2) in this particular
case (i.e., it will meet the expectation when POSTPONE is argument of
POSTPONE). But it doesn't have much sense, since in many other cases the
system will still not meet this expectation.

> I get certain advantages continuing to use a POSTPONE that's based
> on COMPILE and thus far none using POSTPONE in immediate mode - which
> has always been counter-intuitive.

Please take a note that in (2) POSTPONE is not used in immediate mode!
But only its compilation semantics are indirectly performed. It means
that even if interpretation semantics would be specified/defined for
POSTPONE, they are not taken into account in (2), according the
mentioned expectation.

>>> In extending POSTPONE to handle
>>> literals one might argue it's simple to understand, less clumsy than
>>> POSTPONE LITERAL et al and costs little to implement.  It's something
>>> that could - possibly should - have been incorporated into POSTPONE
>>> from the beginning, had someone thought of it.  Can Standard Forth and
>>> users get by without it? I imagine they can.
>> Of course they can. Moreover, it's possible to redefine POSTPONE to
>> handle literals.
>
> Not easily I presume?

If you have recognizers for numbers — it's very easy.

Even implementing standard POSTPONE via FIND from the scratch (in a
portable manner) is possible and quite easy.

Could you test this implementation in your system: https://git.io/J30D6

It's surprising how many systems provide broken FIND.

>>
>> The question is in a criterion — what is worth standardizing, and what
>> isn't.
>
> The committee decides that.  You make the choice whether you can use
> it or not.

Well, then even if users can get by without something, it isn't an
argument to not standardize this thing.

And the committee should also have some criteria or at least grounds.

--
Ruvim

On Monday, May 3, 2021 at 1:52:11 AM UTC-7, Ruvim wrote:
> Even implementing standard POSTPONE via FIND from the scratch (in a
> portable manner) is possible and quite easy.

This is not possible in ANS-Forth without the disambiguifiers already available
because FIND is ambiguous (sometimes fails completely) for about 51 words
in ANS-Forth. This is described here:
https://groups.google.com/g/comp.lang.forth/c/T-yYkpVwYew/m/C6uvd8djAgAJ
Ironically however, disambiguifiers are defined using POSTPONE --- so you can't
define POSTPONE on the assumption that the disambiguifiers are already available.

I don't think Ruvim knows any more about ANS-Forth than Stephen Pelc does,
which is nothing.

On 3/05/2021 18:52, Ruvim wrote:
> On 2021-05-03 07:58, dxforth wrote:
>
>>>> In extending POSTPONE to handle
>>>> literals one might argue it's simple to understand, less clumsy than
>>>> POSTPONE LITERAL et al and costs little to implement.  It's something
>>>> that could - possibly should - have been incorporated into POSTPONE
>>>> from the beginning, had someone thought of it.  Can Standard Forth and
>>>> users get by without it? I imagine they can.
>>> Of course they can. Moreover, it's possible to redefine POSTPONE to
>>> handle literals.
>>
>> Not easily I presume?
>
> If you have recognizers for numbers — it's very easy.
>
> Even implementing standard POSTPONE via FIND from the scratch (in a
> portable manner) is possible and quite easy.
>
> Could you test this implementation in your system: https://git.io/J30D6

Compiling your definition of POSTPONE under VFX causes it to fails
when attempting:

: OF POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP ; IMMEDIATE

: TEST 2 OF ." two " ELSE . THEN ;

Which is the problem I encountered attempting a 'portable' POSTPONE
based on my expectations.

On 4/05/2021 12:44, Hugh Aguilar wrote:
> On Monday, May 3, 2021 at 1:52:11 AM UTC-7, Ruvim wrote:
>> Even implementing standard POSTPONE via FIND from the scratch (in a
>> portable manner) is possible and quite easy.
>
> This is not possible in ANS-Forth without the disambiguifiers already available
> because FIND is ambiguous (sometimes fails completely) for about 51 words
> in ANS-Forth. This is described here:
> https://groups.google.com/g/comp.lang.forth/c/T-yYkpVwYew/m/C6uvd8djAgAJ
> Ironically however, disambiguifiers are defined using POSTPONE --- so you can't
> define POSTPONE on the assumption that the disambiguifiers are already available.
>
> I don't think Ruvim knows any more about ANS-Forth than Stephen Pelc does,
> which is nothing.
>

There's certainly limits to what one can expect from a Standard.

On 2021-05-04 07:20, dxforth wrote:
> On 3/05/2021 18:52, Ruvim wrote:
>> On 2021-05-03 07:58, dxforth wrote:
>>
>>>>> In extending POSTPONE to handle
>>>>> literals one might argue it's simple to understand, less clumsy than
>>>>> POSTPONE LITERAL et al and costs little to implement.  It's
>>>>> something that could - possibly should - have been incorporated
>>>>> into POSTPONE
>>>>> from the beginning, had someone thought of it.  Can Standard Forth and
>>>>> users get by without it?  I imagine they can.
>>>> Of course they can. Moreover, it's possible to redefine POSTPONE to
>>>> handle literals.
>>>
>>> Not easily I presume?
>>
>> If you have recognizers for numbers — it's very easy.
>>
>> Even implementing standard POSTPONE via FIND from the scratch (in a
>> portable manner) is possible and quite easy.
>>
>> Could you test this implementation in your system: https://git.io/J30D6
>
> Compiling your definition of POSTPONE under VFX causes it to fails
> when attempting:
>
> : OF  POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP ; IMMEDIATE
>
> : TEST  2 OF ." two " ELSE . THEN ;
>
> Which is the problem I encountered attempting a 'portable' POSTPONE
> based on my expectations.

My implementation is only portable among the standard systems that
provide the words that are used.

FVX provides the broken (non standard compliant) "COMPILE," word.

: test-if
c" if" find dup 0= if ." unfound" 2drop exit then
1 = if ." executed" execute else ." compiled" compile, then
; immediate

] test-if [ .s

This test prints "compiled" and leave two numbers on the stack.

It's non standard. "COMPILE," shall have the stack effect ( xt -- )

--
Ruvim

On 2021-05-04 08:33, Ruvim wrote:
> On 2021-05-04 07:20, dxforth wrote:
>> On 3/05/2021 18:52, Ruvim wrote:
>>> On 2021-05-03 07:58, dxforth wrote:
>>>
>>>>>> In extending POSTPONE to handle
>>>>>> literals one might argue it's simple to understand, less clumsy than
>>>>>> POSTPONE LITERAL et al and costs little to implement.  It's
>>>>>> something that could - possibly should - have been incorporated
>>>>>> into POSTPONE
>>>>>> from the beginning, had someone thought of it.  Can Standard Forth
>>>>>> and
>>>>>> users get by without it?  I imagine they can.
>>>>> Of course they can. Moreover, it's possible to redefine POSTPONE to
>>>>> handle literals.
>>>>
>>>> Not easily I presume?
>>>
>>> If you have recognizers for numbers — it's very easy.
>>>
>>> Even implementing standard POSTPONE via FIND from the scratch (in a
>>> portable manner) is possible and quite easy.
>>>
>>> Could you test this implementation in your system: https://git.io/J30D6
>>
>> Compiling your definition of POSTPONE under VFX causes it to fails
>> when attempting:
>>
>> : OF  POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP ; IMMEDIATE
>>
>> : TEST  2 OF ." two " ELSE . THEN ;
>>
>> Which is the problem I encountered attempting a 'portable' POSTPONE
>> based on my expectations.
>
>
> My implementation is only portable among the standard systems that
> provide the words that are used.
>
> FVX provides the broken (non standard compliant) "COMPILE," word.
>
>  : test-if
>    c" if" find dup 0= if ." unfound" 2drop exit then
>    1 = if ." executed" execute else ." compiled" compile, then
>  ; immediate
>
>  ] test-if [ .s
>
> This test prints "compiled" and leave two numbers on the stack.
>
> It's non standard. "COMPILE," shall have the stack effect ( xt -- )

Regardless of this issue, "compile," doesn't return the consistent
values during compilation "if" (as an example).

The two following definitions shall be equivalent to "if" word when this
word is encountered by the Forth text interpreter.

: if-via-eval s" if" evaluate ; immediate

: if-via-find c" if" find dup 0= -13 and throw
state @ if dup -1 = if drop compile, exit then then drop execute
; immediate

It means that in any program we can replace "if" (that is not an
argument of any other word, like "postpone") by "if-via-eval" or
"if-via-find" and the results shall be the same.

Thus the following definitions for "foo" and "bar" should produce the
same results too.

: foo if-via-eval -1 else 0 then ;
t{ 1 foo 0 foo -> -1 0 }t

: bar if-via-find -1 else 0 then ;
t{ 1 bar 0 bar -> -1 0 }t

But compilation of "bar" produces error -22 "Control structure
mismatch", since "compile," leaves an excessive value that is not
consumed by else/then.

If we remove this excessive value, the code works correctly:

: bar if-via-find [ .s cr nip ] -1 else 0 then ;
1 bar . \ prints "-1"
0 bar . \ prints "0"

--
Ruvim

On Tue, 4 May 2021 14:20:20 +1000, dxforth <dxforth@gmail.com> wrote:

>Compiling your definition of POSTPONE under VFX causes it to fails
>when attempting:
>
>: OF POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP ; IMMEDIATE
>
>: TEST 2 OF ." two " ELSE . THEN ;

Compiles fine on both 32 bit and 64 bit versions of the current v5.11.

dis test
TEST
( 000E5F70 4883FB02 ) CMP RBX, # 02
( 000E5F74 0F851B000000 ) JNZ/NE 000E5F95
( 000E5F7A 488B5D00 ) MOV RBX, [RBP]
( 000E5F7E 488D6D08 ) LEA RBP, [RBP+08]
( 000E5F82 E8E180F3FF ) CALL 0001E068 (.") "two "
( 000E5F90 E905000000 ) JMP 000E5F9A
( 000E5F95 E8DE76F3FF ) CALL 0001D678 .
( 000E5F9A C3 ) RET/NEXT
( 43 bytes, 8 instructions )
ok

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
web: http://www.mpeforth.com - free VFX Forth downloads

On Tue, 4 May 2021 08:33:46 +0300, Ruvim <ruvim.pinka@gmail.com>
wrote:

>My implementation is only portable among the standard systems that
>provide the words that are used.
>
>FVX provides the broken (non standard compliant) "COMPILE," word.
>
> : test-if
> c" if" find dup 0= if ." unfound" 2drop exit then
> 1 = if ." executed" execute else ." compiled" compile, then
> ; immediate
>
> ] test-if [ .s
>
>This test prints "compiled" and leave two numbers on the stack.
>
>It's non standard. "COMPILE," shall have the stack effect ( xt -- )

It's perfectly fine. Under VFX, IF is NDCS and non-immediate. COMPILE,
executes the compilation behaviour, which as for many versions of IF
returns an address to patch during compilation.

If you want these tests to behave correctly, you actually have
to test an IF ... THEN pair and check stack actions a bit more
carefully.

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
web: http://www.mpeforth.com - free VFX Forth downloads

stephen@mpeforth.com (Stephen Pelc) writes:
>On Tue, 4 May 2021 08:33:46 +0300, Ruvim <ruvim.pinka@gmail.com>
>wrote:
>>FVX provides the broken (non standard compliant) "COMPILE," word.
>>
>> : test-if
>> c" if" find dup 0= if ." unfound" 2drop exit then
>> 1 = if ." executed" execute else ." compiled" compile, then
>> ; immediate
>>
>> ] test-if [ .s
>>
>>This test prints "compiled" and leave two numbers on the stack.
>>
>>It's non standard. "COMPILE," shall have the stack effect ( xt -- )
>
>It's perfectly fine. Under VFX, IF is NDCS and non-immediate. COMPILE,
>executes the compilation behaviour, which as for many versions of IF
>returns an address to patch during compilation.

The standard stack effect of COMPILE, is ( xt -- ). If COMPILE,
behaves differently on your system, it's non-standard. I reported
this bug to you in 2015
<20151009073554.GA9015@a4.complang.tuwien.ac.at>. I had the
impression that you would fix it in VFX 5, but given your reaction,
this is now questionable; I work at a university, so I cannot test VFX
5 myself.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

On 2021-05-05 13:14, Stephen Pelc wrote:
> On Tue, 4 May 2021 08:33:46 +0300, Ruvim <ruvim.pinka@gmail.com>
> wrote:
>
>> My implementation is only portable among the standard systems that
>> provide the words that are used.
>>
>> FVX provides the broken (non standard compliant) "COMPILE," word.
>>
>> : test-if
>> c" if" find dup 0= if ." unfound" 2drop exit then
>> 1 = if ." executed" execute else ." compiled" compile, then
>> ; immediate
>>
>> ] test-if [ .s
>>
>> This test prints "compiled" and leave two numbers on the stack.
>>
>> It's non standard. "COMPILE," shall have the stack effect ( xt -- )
>
> It's perfectly fine. Under VFX, IF is NDCS and non-immediate. COMPILE,
> executes the compilation behaviour, which as for many versions of IF
> returns an address to patch during compilation.

Perhaps it's fine for VFX, but I can't agree it's standard compliant.

| COMPILE,
| Interpretation: Interpretation semantics for this word are undefined.
| Execution: ( xt -- )
| Append the execution semantics of the definition represented
| by xt to the execution semantics of the current definition.

Appending execution semantics cannot have any other side effects, except
specified here.

"COMPILE," is not allowed to perform compilation semantics for IF.

It's similar to POSTPONE

| Compilation: ( "<spaces>name" -- )
| Skip leading space delimiters. Parse name delimited by a space.
| Find name. Append the compilation semantics of name to the
| current definition. An ambiguous condition exists if name
| is not found.

POSTPONE just appends compilation semantics, and doesn't have any other
side effects on the stacks.

> If you want these tests to behave correctly, you actually have
> to test an IF ... THEN pair and check stack actions a bit more
> carefully.

I suppose you already notice, I did that.

--
Ruvim

On 4/05/2021 15:33, Ruvim wrote:
> On 2021-05-04 07:20, dxforth wrote:
>> On 3/05/2021 18:52, Ruvim wrote:
>>> On 2021-05-03 07:58, dxforth wrote:
>>>
>>>>>> In extending POSTPONE to handle
>>>>>> literals one might argue it's simple to understand, less clumsy than
>>>>>> POSTPONE LITERAL et al and costs little to implement.  It's
>>>>>> something that could - possibly should - have been incorporated
>>>>>> into POSTPONE
>>>>>> from the beginning, had someone thought of it.  Can Standard Forth and
>>>>>> users get by without it?  I imagine they can.
>>>>> Of course they can. Moreover, it's possible to redefine POSTPONE to
>>>>> handle literals.
>>>>
>>>> Not easily I presume?
>>>
>>> If you have recognizers for numbers — it's very easy.
>>>
>>> Even implementing standard POSTPONE via FIND from the scratch (in a
>>> portable manner) is possible and quite easy.
>>>
>>> Could you test this implementation in your system: https://git.io/J30D6
>>
>> Compiling your definition of POSTPONE under VFX causes it to fails
>> when attempting:
>>
>> : OF  POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP ; IMMEDIATE
>>
>> : TEST  2 OF ." two " ELSE . THEN ;
>>
>> Which is the problem I encountered attempting a 'portable' POSTPONE
>> based on my expectations.
>
>
> My implementation is only portable among the standard systems that
> provide the words that are used.
>
> FVX provides the broken (non standard compliant) "COMPILE," word.
>
> : test-if
> c" if" find dup 0= if ." unfound" 2drop exit then
> 1 = if ." executed" execute else ." compiled" compile, then
> ; immediate
>
> ] test-if [ .s
>
> This test prints "compiled" and leave two numbers on the stack.
>
> It's non standard. "COMPILE," shall have the stack effect ( xt -- )

A less problematic test might be:

: test test-if ." non-zero" then ;

This fails on VFX. But was it reasonable? I doubt it - just as
redefining POSTPONE and expecting it to work on every system wasn't
reasonable. Only a TC can declare what is standard - so ask them.

On Wed, 05 May 2021 11:46:26 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>The standard stack effect of COMPILE, is ( xt -- ). If COMPILE,
>behaves differently on your system, it's non-standard. I reported
>this bug to you in 2015
><20151009073554.GA9015@a4.complang.tuwien.ac.at>.

NDCS = non default compilation semantics, e.g. IF

And that's probably what triggered my NDCS esploration. The base
problem comes from the standard's definitions of words. There are
three cases:
1) normal words
2) immediate words
3) NDCS words

The standard only says how to handle cases 1) and 2). So the answer
to Ruvim's problem is "Don't do that".

Until the standard encompasses NDCS words, the standard is incomplete.
The standard deliberately does not mandate implementation techniques
and VFX uses a technique for NDCS words that is useful, but breaks
careless tests. The EuroForth papers are there to read, and nobody has
said that my analysis is wrong.

My conclusion from all this is that the standard has a bug in it.
Unfortunately, fixing the bug will be a real pain.

> I had the
>impression that you would fix it in VFX 5, but given your reaction,
>this is now questionable; I work at a university, so I cannot test VFX
>5 myself.

It is fixed. The standard is broken. You can test it, I hereby give
you and other educators an exemption for university use. The licence
will change for university educators in due course. As you well know,
you only had to ask.

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
web: http://www.mpeforth.com - free VFX Forth downloads

dxforth <dxforth@gmail.com> writes:
>Only a TC can declare what is standard - so ask them.

Standardization committees declare what is standard through the
standard document. There may be cases where the standard document is
unclear or contradictory, in which case clarification may be needed,
but the stack effect or COMPILE, is not one of these cases.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

On 2021-05-05 17:37, Stephen Pelc wrote:
> On Wed, 05 May 2021 11:46:26 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
>> The standard stack effect of COMPILE, is ( xt -- ). If COMPILE,
>> behaves differently on your system, it's non-standard. I reported
>> this bug to you in 2015
>> <20151009073554.GA9015@a4.complang.tuwien.ac.at>.
>
> NDCS = non default compilation semantics, e.g. IF
>
> And that's probably what triggered my NDCS esploration. The base
> problem comes from the standard's definitions of words. There are
> three cases:
> 1) normal words
> 2) immediate words
> 3) NDCS words

It's unclear do you mean the glossary entries, or the implementations in
particular Forth system?

In which group does the EXIT word fall?

The immediate words have non default compilation semantics. Probably you
wanted to place in the group 3 the NDCS words that are not implemented
as immediate words. And then the distribution of the words per these
three groups is system/implementation dependent. In some systems the
group 3 is empty.

> The standard only says how to handle cases 1) and 2).

You are right, the standard doesn't say how to perform compilation
semantics for NDCS words that are not immediate words.

The standard also doesn't say how to perform interpretation semantics
for the words with non default interpretation semantics.

It's the internal matters of a Forth system. And a Forth system even is
not obligated to use "COMPILE," or "EXECUTE" in its Forth text
interpreter at all.

But whatever matters a system does under the hood, it should not affect
the standard interfaces.

> So the answer to Ruvim's problem is "Don't do that".

This claim requires another ground.

> Until the standard encompasses NDCS words, the standard is incomplete.

Actually the standard does provide a mechanism to implement NDCS words —
it's the mechanism of immediacy — and this mechanism is capable to
implement any non default compilation semantics, and even default
compilation semantics in some exotic cases.

You also admit this in your "Special Words in Forth" paper, with
pointing to the problems in the popular implementations.

In the same time a system is allowed to use any other suitable mechanism
for that as well as the standard immediacy mechanism.

> The standard deliberately does not mandate implementation techniques
> and VFX uses a technique for NDCS words that is useful, but breaks
> careless tests.

Nothing internal implementation details can excuse a system in breaking
the specified interface of the "COMPILE," word.

> The EuroForth papers are there to read, and nobody has
> said that my analysis is wrong.

https://www.mpeforth.com/arena/SpecialWords3.pdf

It says that "COMPILE," may do optimization. It's correct.

Also it says that "COMPILE," can be used to perform compilation
semantics for the words like "IF", but then "COMPILE," will be broken:

| This technique can also be used for other words such as "IF",
| with the deliberate intention that the interpretation
| and compilation actions of a word can be separated.
| However, "COMPILE," is then broken as far as current standards
| are concerned because structure words such as "IF" produce
| or consume stack items, and string words parse the input stream.

It's also correct.

Even "IF" may be implemented as an ordinary word. The only requirement
is that the unspecified side effects of its compilation via "COMPILE,"
should be undetectable by a standard program. For example, a system can
use special internal stack for "orig". Or it can resolve "orig" in the
run-time.

> My conclusion from all this is that the standard has a bug in it.

Hope I can convince you that there mentioned issue is not a bug, but
something like misunderstanding.

> Unfortunately, fixing the bug will be a real pain.

A bug should be provable by an example.

--
Ruvim

On 6/05/2021 00:37, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>Only a TC can declare what is standard - so ask them.
>
> Standardization committees declare what is standard through the
> standard document. There may be cases where the standard document is
> unclear or contradictory, in which case clarification may be needed,
> but the stack effect or COMPILE, is not one of these cases.

The behaviour of test-if was ambiguous before it got to COMPILE, .
IMO once an ambiguous condition is in process, ANS has no say what
should happen.

On 2021-05-06 04:49, dxforth wrote:
> On 6/05/2021 00:37, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>> Only a TC can declare what is standard - so ask them.
>>
>> Standardization committees declare what is standard through the
>> standard document.  There may be cases where the standard document is
>> unclear or contradictory, in which case clarification may be needed,
>> but the stack effect or COMPILE, is not one of these cases.
>
> The behaviour of test-if was ambiguous before it got to COMPILE, .

Here it is:

: test-if
c" if" find dup 0= if ." unfound" 2drop exit then
1 = if ." executed" execute else ." compiled" compile, then
; immediate

In what place is it ambiguous? In "find"?

> IMO once an ambiguous condition is in process, ANS has no say what
> should happen.

Correct.

"The response of a Standard System to an ambiguous condition is left to
the discretion of the implementor" (A.2.1)

--
Ruvim

On 6/05/2021 16:19, Ruvim wrote:
> On 2021-05-06 04:49, dxforth wrote:
>> On 6/05/2021 00:37, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>>> Only a TC can declare what is standard - so ask them.
>>>
>>> Standardization committees declare what is standard through the
>>> standard document.  There may be cases where the standard document is
>>> unclear or contradictory, in which case clarification may be needed,
>>> but the stack effect or COMPILE, is not one of these cases.
>>
>> The behaviour of test-if was ambiguous before it got to COMPILE, .
>
> Here it is:
>
> : test-if
> c" if" find dup 0= if ." unfound" 2drop exit then
> 1 = if ." executed" execute else ." compiled" compile, then
> ; immediate
>
>
> In what place is it ambiguous? In "find"?

Using FIND to invoke IF is ambiguous. I've a good idea what will
happen on single-xt systems but that's all. Same for POSTPONE S" .
Dual-xt systems have muddied the waters. Today users have no way
to know what is portable - only what works on their system.

>
>
>
>> IMO once an ambiguous condition is in process, ANS has no say what
>> should happen.
>
> Correct.
>
> "The response of a Standard System to an ambiguous condition is left to
> the discretion of the implementor" (A.2.1)
>
>
> --
> Ruvim
>

On Thursday, 6 May 2021 at 10:52:00 UTC+2, dxforth wrote:
> On 6/05/2021 16:19, Ruvim wrote:
> > On 2021-05-06 04:49, dxforth wrote:
> >> On 6/05/2021 00:37, Anton Ertl wrote:
> >>> dxforth <dxf...@gmail.com> writes:
> >>>> Only a TC can declare what is standard - so ask them.
> >>>
> >>> Standardization committees declare what is standard through the
> >>> standard document. There may be cases where the standard document is
> >>> unclear or contradictory, in which case clarification may be needed,
> >>> but the stack effect or COMPILE, is not one of these cases.
> >>
> >> The behaviour of test-if was ambiguous before it got to COMPILE, .
> >
> > Here it is:
> >
> > : test-if
> > c" if" find dup 0= if ." unfound" 2drop exit then
> > 1 = if ." executed" execute else ." compiled" compile, then
> > ; immediate
> >
> >
> > In what place is it ambiguous? In "find"?
> Using FIND to invoke IF is ambiguous. I've a good idea what will
> happen on single-xt systems but that's all. Same for POSTPONE S" .
> Dual-xt systems have muddied the waters. Today users have no way
> to know what is portable - only what works on their system.
Yes I agree to this. My LXF is dual-xt. FIND on IF will return the interpretation
xt. When executed this will print an error message and abort.

In my opinion FIND was left in pre F94 state and not modified to align with
the execution, interpretation and compilation semantics definitions.

Of course you can get my IF to work with FIND by doing
: IF postpone IF ; immediate
As an alternative to FIND I can suggest
FIND-INTERPRET ( addr u -- addr u 0 | xt2 xt1 -1 )
FIND-COMPILE ( addr u -- addr u 0 | xt2 xt1 -1 )
FIND-POSTPONE ( addr u -- addr u 0 | xt2 xt1 -1 )

The result if found just needs to be executed to perform the respective actions
It also hides the implementation details ( single-xt, dual-xt, dual headers etc)

BR
Peter

> >> IMO once an ambiguous condition is in process, ANS has no say what
> >> should happen.
> >
> > Correct.
> >
> > "The response of a Standard System to an ambiguous condition is left to
> > the discretion of the implementor" (A.2.1)
> >
> >
> > --
> > Ruvim
> >