nested compilation in future standard

[Krishna Myneni]

With the ability to nest compilation of anonymous functions in a future
version of the Forth standard, through quotations, I am curious about
why the following code would not be considered standard:

: test 15 [ :NONAME 6 mod ; ] literal execute ;

I am assuming that the above will not be standard because executing TEST
causes a segmentation fault or other error condition in Gforth
0.7.9_20191121, depending on the prior input history.

It seems to me that the above definition of TEST should be equivalent to
the quotation version:

: test2 15 [: 6 mod ;] execute ;

TEST2 produces the correct output when invoked. Why are TEST and TEST2
not equivalent?

Krishna Myneni

[hughag...@gmail.com]

On Sunday, February 2, 2020 at 7:05:44 PM UTC-7, Krishna Myneni wrote:
> With the ability to nest compilation of anonymous functions in a future

> version of the Forth standard, through quotations...

You should really be more honest and refer to what Forth-200x has as:
"Paysan-faked quotations."

Tell me, Krishna Myneni, did you believe what Anton Ertl and Bernd Paysan
said in their EuroForth-2018 paper?
"the higher-order word that calls the rquotation must not use locals"
If so, why did you believe them? They are blatant liars!
Do you just want this bizarre and pointless restriction to be
imposed on the Forth community? Why would you want that?

Why do you refer to Forth-200x as a "standard"?
The Forth-200x committee have discredited themselves by lying.
Forth-200x is not a standard --- there is nobody on the Forth-200x
qualified to be my master and force me to my knees --- the committee
is composed entirely of liars and incompetents.

Get off your knees, Krishna Myneni!

[Ron AARON]

Off your meds again?

[dxforth]

The meds haven't changed in 20 years and some OT's have developed
a tolerance. It's hoped new inmates will arrive to replace them.

[Ron AARON]

My cure has been to apply 'ignore thread' liberally. That works for all
but the most perverse cases...

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>With the ability to nest compilation of anonymous functions in a future
>version of the Forth standard, through quotations, I am curious about
>why the following code would not be considered standard:
>
>: test 15 [ :NONAME 6 mod ; ] literal execute ;

The specification says that you must not nest definitions. Quotations
are an exception to this rule.

>It seems to me that the above definition of TEST should be equivalent to
>the quotation version:
>
>: test2 15 [: 6 mod ;] execute ;
>
>TEST2 produces the correct output when invoked. Why are TEST and TEST2
>not equivalent?

In implementation terms, there are a number of things systems have to
do on [: and ;], which "[ :noname" and "; ] literal" do not do.
Looking at Gforth's COMP-[: (the compilation semantics of [:), it
saves quite a bit of state of the current definition (the locals list,
the LEAVE stack, LATEST, LATESTNT, and the vt (a separated part of the
header)), switches to another section (most Forth systems have only
one section and compile a branch across the quotation instead), sets
up the locals list for the quotation, and finally performs :NONAME.
;] restores all the state.

One could change :NONAME to include all this functionality, but that
would not help for other defining words that you may want to nest.
One could change all the defining words in this way. The question is,
if there is a need for this kind of nesting beyond [:.

There have been some discussions between Bernd Paysan and me about
factoring out the wrapping stuff along with the [ ... ] into [{ ... }]
<2015Jul2...@mips.complang.tuwien.ac.at>. With that (and
interpretive use of the return stack) you could write the above as

: test 15 [{ :NONAME 6 mod ; >r }] [ r> ] literal execute ;

However, neither of us has needed this yet, and we have also not have
requests for it, so we have not implemented this idea yet.

- 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 2019: http://www.euroforth.org/ef19/papers/

[Gerry Jackson]

I implemented nested definitions a long time ago but haven't used them
much - that may be because I try to make my programs ANS/Forth 2012
compliant. But it did make implemention of quotations almost trivial. So
Krishna's TEST works in my system.

>
> There have been some discussions between Bernd Paysan and me about
> factoring out the wrapping stuff along with the [ ... ] into [{ ... }]
> <2015Jul2...@mips.complang.tuwien.ac.at>. With that (and
> interpretive use of the return stack) you could write the above as
>
> : test 15 [{ :NONAME 6 mod ; >r }] [ r> ] literal execute ;
>
> However, neither of us has needed this yet, and we have also not have
> requests for it, so we have not implemented this idea yet.

One thing I've wanted occasionally is for the xt of a quotation to be
available at compile time instead of being compiled as a literal in the
containing definition i.e. to have a factor of ;] available that left
the xt on the stack.


--
Gerry

[peter....@gmail.com]

I would suggest to get rid of :NONAME instead and use [: ;] also
while interpreting
:NONAME ... ; becomes
[: .... ;]

I am not a fan of nested definitions but this use would make for example
jump tables easier to read!

BR
Peter

[none albert]

In article <2020Feb...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Krishna Myneni <krishna...@ccreweb.org> writes:
>>With the ability to nest compilation of anonymous functions in a future
>>version of the Forth standard, through quotations, I am curious about
>>why the following code would not be considered standard:
>>
>>: test 15 [ :NONAME 6 mod ; ] literal execute ;
>
>The specification says that you must not nest definitions. Quotations
>are an exception to this rule.
>
>>It seems to me that the above definition of TEST should be equivalent to
>>the quotation version:
>>
>>: test2 15 [: 6 mod ;] execute ;
>>
>>TEST2 produces the correct output when invoked. Why are TEST and TEST2
>>not equivalent?
>
>In implementation terms, there are a number of things systems have to
>do on [: and ;], which "[ :noname" and "; ] literal" do not do.
>Looking at Gforth's COMP-[: (the compilation semantics of [:), it
>saves quite a bit of state of the current definition (the locals list,
>the LEAVE stack, LATEST, LATESTNT, and the vt (a separated part of the
>header)), switches to another section (most Forth systems have only
>one section and compile a branch across the quotation instead), sets
>up the locals list for the quotation, and finally performs :NONAME.
>;] restores all the state.

I have unified :NONAME and [: and call it { } .
You can't believe how much better my version of Schani's lisp
looks after introducing { } for anonymous definitions.

>
>One could change :NONAME to include all this functionality, but that
>would not help for other defining words that you may want to nest.

Right, one still needs [{ for e.g. static variables.

>One could change all the defining words in this way. The question is,
>if there is a need for this kind of nesting beyond [:.
>
>There have been some discussions between Bernd Paysan and me about
>factoring out the wrapping stuff along with the [ ... ] into [{ ... }]
><2015Jul2...@mips.complang.tuwien.ac.at>. With that (and
>interpretive use of the return stack) you could write the above as
>
>: test 15 [{ :NONAME 6 mod ; >r }] [ r> ] literal execute ;
>
>However, neither of us has needed this yet, and we have also not have
>requests for it, so we have not implemented this idea yet.


>
>- 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 2019: http://www.euroforth.org/ef19/papers/

Newsgroups: comp.lang.forth
Subject: Re: nested compilation in future standard
Summary:
Expires:
References: <r17v5h$uh1$1...@dont-email.me> <2020Feb...@mips.complang.tuwien.ac.at>
Sender:
Followup-To:
Distribution:
Organization:
Keywords:
Cc:

In article <2020Feb...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Krishna Myneni <krishna...@ccreweb.org> writes:
>>With the ability to nest compilation of anonymous functions in a future
>>version of the Forth standard, through quotations, I am curious about
>>why the following code would not be considered standard:
>>
>>: test 15 [ :NONAME 6 mod ; ] literal execute ;
>
>The specification says that you must not nest definitions. Quotations
>are an exception to this rule.
>
>>It seems to me that the above definition of TEST should be equivalent to
>>the quotation version:
>>
>>: test2 15 [: 6 mod ;] execute ;
>>
>>TEST2 produces the correct output when invoked. Why are TEST and TEST2
>>not equivalent?
>
>In implementation terms, there are a number of things systems have to
>do on [: and ;], which "[ :noname" and "; ] literal" do not do.
>Looking at Gforth's COMP-[: (the compilation semantics of [:), it
>saves quite a bit of state of the current definition (the locals list,
>the LEAVE stack, LATEST, LATESTNT, and the vt (a separated part of the
>header)), switches to another section (most Forth systems have only
>one section and compile a branch across the quotation instead), sets
>up the locals list for the quotation, and finally performs :NONAME.
>;] restores all the state.

I have unified :NONAME and [: and call it { } .
You can't believe how much better my version of Schani's lisp
looks after introducing { } for anonymous definitions.

>
>One could change :NONAME to include all this functionality, but that
>would not help for other defining words that you may want to nest.

Right, one still needs [{ for e.g. static variables.

>One could change all the defining words in this way. The question is,
>if there is a need for this kind of nesting beyond [:.
>
>There have been some discussions between Bernd Paysan and me about
>factoring out the wrapping stuff along with the [ ... ] into [{ ... }]
><2015Jul2...@mips.complang.tuwien.ac.at>. With that (and
>interpretive use of the return stack) you could write the above as
>
>: test 15 [{ :NONAME 6 mod ; >r }] [ r> ] literal execute ;
>
>However, neither of us has needed this yet, and we have also not have
>requests for it, so we have not implemented this idea yet.

The advantage of simple systems. Experimenting with these idea's is
easy. I have not "needed" this, but I have posted involved implementations
of QSORT that puts this to good use.

This gives an idea of the complexity in ciforth.
I have left out irrelevant words defined in those screens.

SCR # 179
..
2 \ Isolate the latest word from the dictionary. Leave its DEA.
3 : UNLINK-LATEST LATEST CURRENT @ >LFA DUP @ >LFA @ SWAP ! ;
4
5 \ Link DEA into the dictionary, as the latest.
6 : LINK-LATEST LATEST OVER >LFA ! CURRENT @ >LFA ! ;
..

SCR # 178
..
2 \ New context for definitions, maybe in the middle of a word.
3 : [{ POSTPONE SKIP (FORWARD R>
4 CSP @ >R DPL @ >R UNLINK-LATEST >R STATE @ >R
5 >R POSTPONE [ ; IMMEDIATE
6 : }] FORWARD) R>
7 R> STATE ! R> LINK-LATEST R> DPL ! R> CSP !
8 >R ;
..

>
>- anton

Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Krishna Myneni]

On 03-02-20 2:52 AM, Anton Ertl wrote:
> Krishna Myneni <krishna...@ccreweb.org> writes:
>> With the ability to nest compilation of anonymous functions in a future
>> version of the Forth standard, through quotations, I am curious about
>> why the following code would not be considered standard:
>>
>> : test 15 [ :NONAME 6 mod ; ] literal execute ;
>
> The specification says that you must not nest definitions. Quotations
> are an exception to this rule.
>

Perhaps the meaning of the specification should be clarified in the text
to specifically refer to named definitions not being nested. Quotations
allow anonyomous definitions to be nested (to a depth of 1?) within a
named definition.

>> It seems to me that the above definition of TEST should be equivalent to
>> the quotation version:
>>
>> : test2 15 [: 6 mod ;] execute ;
>>
>> TEST2 produces the correct output when invoked. Why are TEST and TEST2
>> not equivalent?
>
> In implementation terms, there are a number of things systems have to
> do on [: and ;], which "[ :noname" and "; ] literal" do not do.

Is the fact that :NONAME does not do specific state retention to allow
it to be nested within a colon definition currently in Gforth a feature
of the Forth-94/Forth-2012 standard, or a feature of a particular
implementation?

> Looking at Gforth's COMP-[: (the compilation semantics of [:), it
> saves quite a bit of state of the current definition (the locals list,
> the LEAVE stack, LATEST, LATESTNT, and the vt (a separated part of the
> header)), switches to another section (most Forth systems have only
> one section and compile a branch across the quotation instead), sets
> up the locals list for the quotation, and finally performs :NONAME.
> ;] restores all the state.
>
> One could change :NONAME to include all this functionality, but that
> would not help for other defining words that you may want to nest.
> One could change all the defining words in this way. The question is,
> if there is a need for this kind of nesting beyond [:.
>

It depends on how widely used functional programming may be within
Forth. I wouldn't dismiss it since I view Forth as a platform for
experimentation as well as for writing and running applications. Since
you have the functionality in Gforth for saving and restoring sufficient
state information to make an anonymous definition within a colon
definition, it seems like it would be logically consistent to extend
this to :NONAME definitions as well. But that might be just my view of a
:NONAME definition. With its recent introduction into kForth, I treat
:NONAME definitions as purely anonymous functions. They are not entered
into the dictionary, and once defined, if the xt is not saved, it is
also not retrievable. Does the existing Forth-2012 standard implicitly
differentiate between an anonymous definition (lambda function) and a
:NONAME definition? I don't see an advantage in making that distinction,
other than the cost to a compiler writer.

> There have been some discussions between Bernd Paysan and me about
> factoring out the wrapping stuff along with the [ ... ] into [{ ... }]
> <2015Jul2...@mips.complang.tuwien.ac.at>. With that (and
> interpretive use of the return stack) you could write the above as
>
> : test 15 [{ :NONAME 6 mod ; >r }] [ r> ] literal execute ;
>
> However, neither of us has needed this yet, and we have also not have
> requests for it, so we have not implemented this idea yet.
>

I don't understand why the >R is necessary. Does the xt on the stack
conflict with use of the stack for control structures?

Krishna

[Ruvim]

On 2020-02-03 13:11, Gerry Jackson wrote:
> On 03/02/2020 08:52, Anton Ertl wrote:
>> Krishna Myneni <krishna...@ccreweb.org> writes:
>>>
>>> : test 15 [ :NONAME 6 mod ; ] literal execute ;
>>
>> The specification says that you must not nest definitions.  Quotations
>> are an exception to this rule.

[...]

> I implemented nested definitions a long time ago but haven't used them
> much - that may be because I try to make my programs ANS/Forth 2012
> compliant. But it did make implemention of quotations almost trivial. So
> Krishna's TEST works in my system.

[...]

>> There have been some discussions between Bernd Paysan and me about
>> factoring out the wrapping stuff along with the [ ... ] into [{ ... }]
>> <2015Jul2...@mips.complang.tuwien.ac.at>.  With that (and
>> interpretive use of the return stack) you could write the above as
>>
>> : test 15 [{ :NONAME 6 mod ; >r }] [ r> ] literal execute ;
>>
>> However, neither of us has needed this yet, and we have also not have
>> requests for it, so we have not implemented this idea yet.

> One thing I've wanted occasionally is for the xt of a quotation to be
> available at compile time instead of being compiled as a literal in the
> containing definition i.e. to have a factor of ;] available that left
> the xt on the stack.

If we will find consensus about GERM word (or something alike) that
returns the xt of the current definition, it could be achieved as


variable my-nested-xt

: test 123 . [: 456 . [ germ my-xt ! ] ;] drop ;

my-nested-xt @ execute \ prints "456"


Although, I can't imagine a use-case for that.


One my use-case is to pass own xt into another word as :

[: ( -- xt ) 456 . [ germ lit, ] some-trick ;]



--
Ruvim

[Alex McDonald]

On 03-Feb-20 15:29, Krishna Myneni wrote:
> On 03-02-20 2:52 AM, Anton Ertl wrote:
>> Krishna Myneni <krishna...@ccreweb.org> writes:
>>> With the ability to nest compilation of anonymous functions in a future
>>> version of the Forth standard, through quotations, I am curious about
>>> why the following code would not be considered standard:
>>>
>>> : test 15 [ :NONAME 6 mod ; ] literal execute ;
>>
>> The specification says that you must not nest definitions.  Quotations
>> are an exception to this rule.
>>
>
> Perhaps the meaning of the specification should be clarified in the text
> to specifically refer to named definitions not being nested. Quotations
> allow anonyomous definitions to be nested (to a depth of 1?) within a
> named definition.

If implemented as I suspect most people have implemented it, you can
nest quotations inside quotations. For instance, I save all the state at
[: on the compilation stack and remove it on ;] .

>
>>> It seems to me that the above definition of TEST should be equivalent to
>>> the quotation version:
>>>
>>> : test2  15 [: 6 mod ;] execute ;
>>>
>>> TEST2 produces the correct output when invoked. Why are TEST and TEST2
>>> not equivalent?
>>
>> In implementation terms, there are a number of things systems have to
>> do on [: and ;], which "[ :noname" and "; ] literal" do not do.
>
> Is the fact that :NONAME does not do specific state retention to allow
> it to be nested within a colon definition currently in Gforth a feature
> of the Forth-94/Forth-2012 standard, or a feature of a particular
> implementation?

That implementation.

Yes. The XT generated by :NONAME ; needs saved temporarily.

>
> Krishna


--
Alex

[Gerry Jackson]

Yes it can be done that way. I was meaning that if we had two types of
quotation

: foo ... [: ... ;]xt ( compile-time -- xt ) <do something with xt> ;
and
: bar ... [: ... ;] ( compile-time -- ) execute ... ;

then we could define ;] by
: ;] ;]xt postpone literal ; immediate

>
> Although, I can't imagine a use-case for that.
>

I was thinking of Michael Gassanenko's CHOOSE statement, see
https://groups.google.com/forum/#!msg/comp.lang.forth/HwxAddZ54mg/76VTbPRiCQAJ

where the syntax is
: foo
choose
<values-1> when <action-1> end
...
<values-n> when <action-n> end
other <default-action> end
end
;
where the values could be compiled as quotations and the xt either left
on the stack or saved in a switch table of xts for use at run time.

>
> One my use-case is to pass own xt into another word as :
>
>   [: ( -- xt ) 456 . [ germ lit, ] some-trick ;]

Can't you pass a quotations own xt into another word by

: foo ... [: ( xt -- ? ) some-trick ;] dup execute ;

but what's the use case for that?

--
Gerry

[Gerry Jackson]

^^^^^^
Sorry I meant actions

[Krishna Myneni]

On 03-02-20 1:10 PM, Alex McDonald wrote:
> On 03-Feb-20 15:29, Krishna Myneni wrote:

...

>> Perhaps the meaning of the specification should be clarified in the
>> text to specifically refer to named definitions not being nested.
>> Quotations allow anonyomous definitions to be nested (to a depth of
>> 1?) within a named definition.
>
> If implemented as I suspect most people have implemented it, you can
> nest quotations inside quotations. For instance, I save all the state at
> [: on the compilation stack and remove it on ;] .

Even the [: and ;] notation is clunky and burdensome to the programmer.
It would be better, from the programmer's perspective, if "[" and "]"
were simply extended to save and restore the compilation context , i.e.

[ -- push the compilation state frame and switch to interpretation STATE

] -- pop the compilation state frame and enter compilation STATE

Then, it should be possible to write the "[x" and "y]" as shortcuts
which may be written in terms of core words -- I haven't thought this
statement through fully, so I may be mistaken. If it could be done, it
makes "[" and "]" less simple and efficient during compile time, but
vastly more flexible. Considering how little they are actually usually
used in code, the compilation efficiency may not matter.

Considering nesting quotations inside of quotations, it seems like after
the implementation for the first level is done, then the next billion or
so should be free.

...

>> Is the fact that :NONAME does not do specific state retention to allow
>> it to be nested within a colon definition currently in Gforth a
>> feature of the Forth-94/Forth-2012 standard, or a feature of a
>> particular implementation?
>
> That implementation.

Ok. Gerry Jackson mentioned that his implementation could do this
nesting. It's good to know that the standard does not explicitly
prohibit such an implementation.

>>> There have been some discussions between Bernd Paysan and me about
>>> factoring out the wrapping stuff along with the [ ... ] into [{ ... }]
>>> <2015Jul2...@mips.complang.tuwien.ac.at>.  With that (and
>>> interpretive use of the return stack) you could write the above as
>>>
>>> : test 15 [{ :NONAME 6 mod ; >r }] [ r> ] literal execute ;
>>>
>>> However, neither of us has needed this yet, and we have also not have
>>> requests for it, so we have not implemented this idea yet

[In reply to Anton: it seems to me that the factoring should be
incorporated into "[" and "]" if possible, rather than in :NONAME]

>>
>> I don't understand why the >R is necessary. Does the xt on the stack
>> conflict with use of the stack for control structures?
>
> Yes. The XT generated by :NONAME ; needs saved temporarily.

Ok. That's a disadvantage of using the data stack as the control stack,
but it is permitted by the standard. We've run into cases earlier where
such a use of the data stack leads to seemingly valid code not being
able to run under systems which implement the control stack in that way.

Krishna

[Ruvim]

I think, if we need so detailed access, a low level API like CONCEIVE
BIRTH words is a better variant.

But for the switch-choose use-case it is enough to have the interpretive
[: ;] variant that knows about the current definition:

: test 123 . [ [: 456 . ;] my-nest-xt ! ] 999 . ;

my-nest-xt @ execute \ "456"
test \ "123 999"

>>
>> Although, I can't imagine a use-case for that.
>>
>
> I was thinking of Michael Gassanenko's CHOOSE statement, see
> https://groups.google.com/forum/#!msg/comp.lang.forth/HwxAddZ54mg/76VTbPRiCQAJ
>
>
> where the syntax is
> : foo
>    choose
>       <values-1> when <action-1> end
>            ...
>       <values-n> when <action-n> end
>                  other <default-action> end
>    end
> ;
> where the values could be compiled as quotations and the xt either left
> on the stack or saved in a switch table of xts for use at run time.

I see.

I have created a proof of concept — it works fine https://git.io/JvGOu

>>
>> One my use-case is to pass own xt into another word as :
>>
>>    [: ( -- xt ) 456 . [ germ lit, ] some-trick ;]
>
> Can't you pass a quotations own xt into another word by
>
> : foo ... [: ( xt -- ? ) some-trick ;] dup execute ;
>
> but what's the use case for that?
>

I used it for puzzles in functional style.

Curry function [1]:

: curry ( xt u -- xt1 ) 1- 0 =? ?E itself partial1 swap curry2 co ;

Man-or-boy [2]:

: a ( x5 x4 x3 x2 x1 k -- x )
dup 1 < if 2drop 2drop e swap e + exit then
here swap , itself ( ... x1 ^k a )
p{ direct{ >r germ swap 6 nlit, }direct dup 1-! @ call{ r> }call }p
nip execute
;


where
: itself ( run-time: -- xt ) germ lit, ; immediate


1.
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/5n723nWfgWo/FYjqqeBrAwAJ

2. https://rosettacode.org/wiki/Man_or_boy_test


--
Ruvim

[hughag...@gmail.com]

On Monday, February 3, 2020 at 6:29:11 AM UTC-7, Krishna Myneni wrote:
> On 03-02-20 2:52 AM, Anton Ertl wrote:
> > Looking at Gforth's COMP-[: (the compilation semantics of [:), it
> > saves quite a bit of state of the current definition (the locals list,
> > the LEAVE stack, LATEST, LATESTNT, and the vt (a separated part of the
> > header)), switches to another section (most Forth systems have only
> > one section and compile a branch across the quotation instead), sets
> > up the locals list for the quotation, and finally performs :NONAME.
> > ;] restores all the state.
> >
> > One could change :NONAME to include all this functionality, but that
> > would not help for other defining words that you may want to nest.
> > One could change all the defining words in this way. The question is,
> > if there is a need for this kind of nesting beyond [:.
>
> It depends on how widely used functional programming may be within
> Forth. I wouldn't dismiss it since I view Forth as a platform for
> experimentation as well as for writing and running applications.

The purpose of "functional programming" is to support general-purpose
data-structures. I would dismiss your "experimentation" if you fail
to support general-purpose data-structures, and you have.

The purpose of general-purpose data-structures is to support
writing and running applications.

You seem to be quite impressed by Anton Ertl and Bernd Paysan, the
Forth-200x committee members who blatantly lied about the rquotations
in their EuroForth-2018.
Please point to any example of any Forth-200x committee member
succeeding at implementing a general-purpose data-structure.
Even a super-simple example such as a singly linked-list would be fine.
An example of you doing this would also be fine. Any example!

[Ruvim]

On 2020-02-04 04:26, Krishna Myneni wrote:
> On 03-02-20 1:10 PM, Alex McDonald wrote:
>> On 03-Feb-20 15:29, Krishna Myneni wrote:

> ....

>>> Perhaps the meaning of the specification should be clarified in the
>>> text to specifically refer to named definitions not being nested.
>>> Quotations allow anonyomous definitions to be nested (to a depth of
>>> 1?) within a named definition.
>>
>> If implemented as I suspect most people have implemented it, you can
>> nest quotations inside quotations. For instance, I save all the state
>> at [: on the compilation stack and remove it on ;] .
>
> Even the [: and ;] notation is clunky and burdensome to the programmer.
> It would be better, from the programmer's perspective, if "[" and "]"
> were simply extended to save and restore the compilation context , i.e.
>
> [   -- push the compilation state frame and switch to interpretation STATE
>
> ] -- pop the compilation state frame and enter compilation STATE

Do you want to say that this:

: foo [ :noname 123 . ; lit, ] ;

is less clunky and less burdensome to the programmer than this:

: foo [: 123 . ;] ;

? Or what do you mean?



In any case, these additional semantics cannot be added to the standard
[ ] words, since they are not compatible by the control-flow stack
signature, and since the calls of standard words might be not balanced
(not paired).

OTOH, even with other names, what problem these words solves? What is
their use-case? (except definition of [: ;] )

> Then, it should be possible to write the "[x" and "y]" as shortcuts
> which may be written in terms of core words -- I haven't thought this
> statement through fully, so I may be mistaken. If it could be done, it
> makes "[" and "]" less simple and efficient during compile time, but
> vastly more flexible. Considering how little they are actually usually
> used in code, the compilation efficiency may not matter.





> Considering nesting quotations inside of quotations, it seems like after
> the implementation for the first level is done, then the next billion or
> so should be free.

: foo [: 1 . [: 2 . ;] ;] ; foo execute execute \ prints "1 2"

This code is standard since it does not conflict with the quotations
specification http://www.forth200x.org/quotations-v3.txt

But this specification should also contain a clause like:

The count of maximum nesting levels is a system defined value. A
system shall allow at least 8 nesting levels. An ambiguous condition
exists if the current nesting level is more than the system defined maximum.



--
Ruvim

[Gerry Jackson]

Yes that would work but isn't permitted in the draft standard
http://www.forth200x.org/documents/forth18-1.pdf
Also it's a bit clunky


--
Gerry

[Krishna Myneni]

On 04-02-20 3:30 AM, Ruvim wrote:
> On 2020-02-04 04:26, Krishna Myneni wrote:

...

>> Even the [: and ;] notation is clunky and burdensome to the
>> programmer. It would be better, from the programmer's perspective, if
>> "[" and "]" were simply extended to save and restore the compilation
>> context , i.e.
>>
>> [   -- push the compilation state frame and switch to interpretation
>> STATE
>>
>> ] -- pop the compilation state frame and enter compilation STATE
>
> Do you want to say that this:
>
>   : foo [ :noname 123 . ; lit, ] ;
>
> is less clunky and less burdensome to the programmer than this:
>
>   : foo [: 123 . ;] ;
>
> ?  Or what do you mean?
>

I mean that it is less economical, less logically consistent, and less
elegant, from a language design perspective, to not allow use of
features already existing in the language. Forth-94 standardized
anonymous functions with :NONAME . A standard beyond Forth-2012 should
permit one to use this prior experience with :NONAME to create an
anonymous function nested within a named definition, or within another
anonymous function, if desired. A person who is familiar only with
Forth-94 can understand the meaning of

: foo [ :noname 123 . ; lit, ] ;

without having to know about quotations in Forth-20xx, even if LIT, is
unfamiliar.

>
>
> In any case, these additional semantics cannot be added to the standard
> [ ] words, since they are not compatible by the control-flow stack
> signature, and since the calls of standard words might be not balanced
> (not paired).

I don't know what you mean by the above. Gerry says that his Forth
system is capable of executing the TEST example I gave. So, it is
possible, in principle, for some particular control-flow stack
implementation.

> OTOH, even with other names, what problem these words solves? What is
> their use-case?  (except definition of [: ;] )
>

It allows me, as a system implementer, to not introduce non-essential
words into the Forth system. If a user needs them, they should be
implementable with the core words as factors ( :NONAME should be one of
those factors). It has more to do with clean language design, and
allowing the programmer to use what he/she already knows.

Krishna

[Ruvim]

(1)

>>
>>    my-nest-xt @ execute \ "456"
>>    test \ "123 999"
>>
>
> Yes that would work but isn't permitted in the draft standard
> http://www.forth200x.org/documents/forth18-1.pdf

It isn't permitted for a standard program only. But a Forth system is
permitted to implement interpretation semantics for "[:", and some
systems do it. And it can be standardized in the future.

> Also it's a bit clunky

Example (1) above is not an intended use-case, but just an illustration
and a test-case.

Intended use case is the following
(from the mentioned example https://git.io/JvGOu).


(a) interpretive

: other ( xt-other sys2 -- xt-other sys2 sys3 )
postpone [:
end{ ( xt-other sys2 sys3 -- xt-other2 sys2 )
postpone ;] ( xt )
-rot 2>r nip 2r>
}end
;

vs

(b) use special ";]xt"

: other ( xt-other sys2 -- xt-other sys2 sys3 )
state-on postpone [:
end{ ( xt-other sys2 sys3 -- xt-other2 sys2 )
postpone ;]xt state-off
-rot 2>r nip 2r>
}end
;


I can't say that (a) is more clunky than (b).



Although, variant (a) might not work in some systems,
since "postpone [:" should produce only compilation semantics.

So, I prefer "conceive" and "birth" regular words:

: other ( xt-other sys2 -- xt-other sys2 sys3 )
conceive state-on
end{ ( xt-other sys2 sys3 -- xt-other2 sys2 )
state-off birth ( xt )
-rot 2>r nip 2r>
}end
;



--
Ruvim

[Ruvim]

On 2020-02-04 15:30, Krishna Myneni wrote:
> On 04-02-20 3:30 AM, Ruvim wrote:
>> On 2020-02-04 04:26, Krishna Myneni wrote:

> ....

This is a standard code:

: foo [ [ 123 ] [ . 456 ] literal . ; foo \ prints "123 456"

But in your proposal it produces the compilation state frame leaking.
Moreover, if this frame is placed into the control-flow stack, and this
stack is implemented using the data stack, the code will be corrupted,
123 will not be passed to Dot, and 456 will not be passed to 'literal'.

> Gerry says that his Forth
> system is capable of executing the TEST example I gave. So, it is
> possible, in principle, for some particular control-flow stack
> implementation.

Yes, it is possible without changing [ and ] words.

>
>> OTOH, even with other names, what problem these words solves? What is
>> their use-case?  (except definition of [: ;] )
>>
>
> It allows me, as a system implementer, to not introduce non-essential
> words into the Forth system. If a user needs them, they should be
> implementable with the core words as factors ( :NONAME should be one of
> those factors). It has more to do with clean language design, and
> allowing the programmer to use what he/she already knows.

I like the idea of the common standard minimal basis that allows to
implement even Colon ":" and Semicolon ";". But I don't think that
:NONAME is a good factor.

Just try to implement ":" via ":NONAME".


--
Ruvim

[none albert]

The advantage of simple systems like ciforth is that
experimenting with these idea's is easy.

I have not "needed" this, but I have posted involved implementations
of QSORT that puts this to good use.

This gives an idea of the complexity in ciforth.
I have left out irrelevant words defined in those screens.

SCR # 179
..
2 \ Isolate the latest word from the dictionary. Leave its DEA.
3 : UNLINK-LATEST LATEST CURRENT @ >LFA DUP @ >LFA @ SWAP ! ;
4
5 \ Link DEA into the dictionary, as the latest.
6 : LINK-LATEST LATEST OVER >LFA ! CURRENT @ >LFA ! ;
..

SCR # 178
..
2 \ New context for definitions, maybe in the middle of a word.
3 : [{ POSTPONE SKIP (FORWARD R>
4 CSP @ >R DPL @ >R UNLINK-LATEST >R STATE @ >R
5 >R POSTPONE [ ; IMMEDIATE
6 : }] FORWARD) R>
7 R> STATE ! R> LINK-LATEST R> DPL ! R> CSP !
8 >R ;
..

SCR # 177
2 \ Denotation for lambda, ends with `}
3 : { 'SKIP , (FORWARD HERE 'TASK @ , HERE CELL+ ,
4 STATE @ 1 STATE ! ; IMMEDIATE
5 : } '(;) , STATE ! >R FORWARD) R> POSTPONE LITERAL
6 ; IMMEDIATE
7
8 \ Official 2012 standard quotation.
9 '{ ALIAS [: '} ALIAS ;]

{ ... } can also be used to replace :NONAME ... ;
That cannot be handled with ALIAS.
IT should have been named
:NONAME ... ;NONAME
Then I wouldn't have that problem.

In interpret mode the (FORWARD FORWARD) could be left out, like so:

: { HERE 'TASK @ , HERE CELL+ , STATE @ 1 STATE ! ; IMMEDIATE
: } '(;) , STATE ! POSTPONE LITERAL ; IMMEDIATE

Testing for STATE would make { } state-smart.
Of course this can nested:
{ { { 1 } EXECUTE } EXECUTE } EXECUTE OK
.S
S[ 1 ] OK


>--
>Ruvim

[Krishna Myneni]

The above is not standard code:
6.1.2500
“left-bracket”
[
CORE
Interpretation: Interpretation semantics for this word are undefined. ...

The first use of [ puts sets STATE in interpretation mode. The
subsequent use of [ is undefined per the standard.

>
>>
>>> OTOH, even with other names, what problem these words solves? What is
>>> their use-case?  (except definition of [: ;] )
>>>
>>
>> It allows me, as a system implementer, to not introduce non-essential
>> words into the Forth system. If a user needs them, they should be
>> implementable with the core words as factors ( :NONAME should be one
>> of those factors). It has more to do with clean language design, and
>> allowing the programmer to use what he/she already knows.
>
> I like the idea of the common standard minimal basis that allows to
> implement even Colon ":" and Semicolon ";".  But I don't think that
> :NONAME is a good factor.
>
> Just try to implement ":" via ":NONAME".
>

I suggested that :NONAME serves as a base factor for quotations, not for
named definitions, so you are perhaps reading more into my statement
than intended.

Krishna

[Ruvim]

On 2020-02-05 15:15, Krishna Myneni wrote:
> On 04-02-20 7:34 AM, Ruvim wrote:
>> On 2020-02-04 15:30, Krishna Myneni wrote:
>>> On 04-02-20 3:30 AM, Ruvim wrote:
>>>> On 2020-02-04 04:26, Krishna Myneni wrote:
>>> ....
>>>>> Even the [: and ;] notation is clunky and burdensome to the
>>>>> programmer. It would be better, from the programmer's perspective,
>>>>> if "[" and "]" were simply extended to save and restore the
>>>>> compilation context , i.e.
>>>>>
>>>>> [   -- push the compilation state frame and switch to
>>>>> interpretation STATE
>>>>>
>>>>> ] -- pop the compilation state frame and enter compilation STATE
>>>>

[...]

>>>> In any case, these additional semantics cannot be added to the
>>>> standard [ ] words, since they are not compatible by the
>>>> control-flow stack signature, and since the calls of standard words
>>>> might be not balanced (not paired).
>>>
>>> I don't know what you mean by the above.
>>
>> This is a standard code:
>>
>>    : foo [ [ 123 ]  [ . 456 ] literal . ; foo \ prints "123 456"
>>
>
> The above is not standard code:
> 6.1.2500
> “left-bracket”
> [
> CORE
> Interpretation: Interpretation semantics for this word are undefined. ...

Well, the correction:

: [ [compile] [ ; immediate

: foo [ [ 123 ] [ . 456 ] literal . ; foo \ prints "123 456"

Now it is a standard code that is not compatible with your suggestion.

The idea is that *execution* of '[' and ']' words might be not paired
(not balanced).

>>>
>>>> OTOH, even with other names, what problem these words solves? What
>>>> is their use-case?  (except definition of [: ;] )
>>>>
>>>
>>> It allows me, as a system implementer, to not introduce non-essential
>>> words into the Forth system. If a user needs them, they should be
>>> implementable with the core words as factors ( :NONAME should be one
>>> of those factors). It has more to do with clean language design, and
>>> allowing the programmer to use what he/she already knows.
>>
>> I like the idea of the common standard minimal basis that allows to
>> implement even Colon ":" and Semicolon ";".  But I don't think that
>> :NONAME is a good factor.
>>
>> Just try to implement ":" via ":NONAME".
>>
>
> I suggested that :NONAME serves as a base factor for quotations, not for
> named definitions, so you are perhaps reading more into my statement
> than intended.

OK. Then I suggest to go even deeper ^_-

--
Ruvim

[Krishna Myneni]

Executing FOO is nonstandard. Any time you execute two left-brackets
without an intervening right-bracket, it is non-standard code. The
behavior on your system is not guaranteed by the standard to do the same
thing on another system.

KM

[Ruvim]

>>S

>>    : [ [compile] [ ; immediate
>>    : foo [ [ 123 ]  [ . 456 ] literal . ; foo \ prints "123 456"
>>
>> Now it is a standard code that is not compatible with your suggestion.
>>
>
> Executing FOO is nonstandard. Any time you execute two left-brackets
> without an intervening right-bracket, it is non-standard code. The
> behavior on your system is not guaranteed by the standard to do the same
> thing on another system.

1. Could you please proof it by the standard?

2. What about execution of right-brackets two times one after another
(or executing it in interpretation state)?

A standard program may do anything that is not prohibited by the
standard. And I don't see any even implicit ambiguous conditions that
are connected with executing of "[" and "]" words.


--
Ruvim

[Krishna Myneni]

On 05-02-20 6:22 PM, Ruvim wrote:
> : foo [ [ 123 ]  [ . 456 ] literal . ;

> 1. Could you please proof it by the standard?

See 6.1.2500 in the Forth-2012 standard.
Interpretation semantics for [ are "undefined". Unfortunately, the
standard does not say what "undefined" means. I read it to mean a
condition worse than "ambiguous condition", calling for a compiler
error. However, someone from the committee should clarify its meaning.
At the least, it suggests that when you use "[" in interpretation mode,
you cannot expect the code to be portable. Indeed this is the case. For
example, in Gforth, one obtains:
------
: [ [compile] [ ; immediate
*terminal*:1:17: warning: redefined [
*terminal*:1:3: warning: original location ok
: foo [ [ 123 ] [ . 456 ] literal . ; foo 123
*terminal*:2:38: warning: redefined foo
*terminal*:2:4: warning: original location456 ok
-----
The messages indicate FOO is redefined.

> 2. What about execution of right-brackets two times one after > another
> (or executing it in interpretation state)?

Right-bracket is supposed to be executed in interpretation state, to
return STATE to compilation. The standard does not say anything about
use of right-bracket in compilation mode.

> A standard program may do anything that is not prohibited by
> the standard. And I don't see any even implicit ambiguous
> conditions that are connected with executing of "[" and "]"
> words.

It's possible that it is not explicitly prohibited by the standard.
However, your code cannot be considered portable per the standard.
Furthermore, the standard does not explicitly prohibit [ from pushing a
compilation frame (onto the return stack, for example) and ] from
popping a compilation frame. Pushing and popping need not involve the
data stack at all.

By the way, FOO's behavior would be considered undefined on the first
execution of [ since the state of the system is intrepretation at that
point.

KM

[hughag...@gmail.com]

On Tuesday, February 4, 2020 at 5:30:11 AM UTC-7, Krishna Myneni wrote:
> On 04-02-20 3:30 AM, Ruvim wrote:
> > Do you want to say that this:
> >
> >   : foo [ :noname 123 . ; lit, ] ;
> >
> > is less clunky and less burdensome to the programmer than this:
> >
> >   : foo [: 123 . ;] ;
> >
> > ?  Or what do you mean?
>
> I mean that it is less economical, less logically consistent, and less
> elegant, from a language design perspective, to not allow use of
> features already existing in the language. Forth-94 standardized
> anonymous functions with :NONAME . A standard beyond Forth-2012 should
> permit one to use this prior experience with :NONAME to create an
> anonymous function nested within a named definition, or within another
> anonymous function, if desired. A person who is familiar only with
> Forth-94 can understand the meaning of
>
> : foo [ :noname 123 . ; lit, ] ;
>
> without having to know about quotations in Forth-20xx, even if LIT, is
> unfamiliar.

Krishna Myneni is making a fool out of himself!
:NONAME is defined to allow local variables, similar to a colon word.
If the :NONAME has its own local variables, then how is it going to
access the local variables in the parent function???
So, Krishna Myneni is effectively saying that it is illegal for the
quotation to access the parent function's local variables.
This is the primary feature that makes quotations useful for supporting
general-purpose data-structures, so Krishna Myneni is effectively
preventing quotations from being used for the one purpose they have!

I have rquotations that access the parent function's local variables.
The HOF may or may not have local variables of its own, as rquotations
work either way (the HOF uses REX to execute the rquotation if the HOF
has locals of its own, or uses REX0 if it does not have locals).

I really don't believe that anybody in the Forth-200x cult knows how
to implement a general-purpose data-structure. Give any example of
doing this! You can't, because you don't know how. Peter Knaggs tried
to implement a linked-list, and he wrote a EuroForth paper on the subject,
but he failed badly. He didn't have any working code. His design was just
a jumble of bugs and nonsense. He really didn't know anything about the
subject. None of the Forth-200x committee members have ever succeeded
in implementing a general-purpose data-structure, and none of the
ANS-Forth committee members succeeded either. This is four decades
of failure at implementing general-purpose data-structures!

This is the thread where I introduced my upgrade on
HumptyDumpty's rquotations that provide the crucial feature
of the rquotation accessing the parent function's local variables
despite the HOF (that the parent function calls and that executes
the rquotation) having local variables of its own:
https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B76-100%5D
I have made the code a little cleaner since then, but the basic
feature was essentially there then (July of 2016).

The same idiotic blather that Krishna Myneni is spouting now, was
being spouted by the Forth-200x cult then too:

On Saturday, July 9, 2016 at 11:11:06 PM UTC-7, hughag...@gmail.com wrote:
> On Saturday, July 9, 2016 at 9:59:23 PM UTC-7, Julian Fondren wrote:
> > On Saturday, July 9, 2016 at 2:58:27 PM UTC-5, Håkan Thörngren wrote:
> > >
> > > Why do we need to invent new syntax (words) for this?
> > >
> > > Would it not be possible to just use the already existing :NONAME
> > > inside a definition?
> > >
> >
> > :noname is already usable inside a definition. Where it has a
> > different meaning. So we can't use it again for this. It would have
> > to look something like
> >
> > : foo ( -- )
> > 0 IF [ :noname ." a" ; ] THEN LITERAL ;
> >
> >
> > -- Julian
>
> You don't test your code, do you Julien?
>
> Don't worry! So long as you brown-nose Elizabeth Rather,
> you still get to be considered an ANS-Forth programmer --- ANS-Forth
> is a cult --- writing code that works [has] never been required
> or even expected, but loyalty is demanded.

The ANS-Forth and Forth-200x cult never learns anything!
They just continue to spout the same idiotic blather, year after year.
They just continue to fail in the same way, decade after decade.
This embarrassing behavior never ceases, but it just goes on and on...

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>On 05-02-20 6:22 PM, Ruvim wrote:
>> : foo [ [ 123 ]  [ . 456 ] literal . ;
> > 1. Could you please proof it by the standard?
>
>See 6.1.2500 in the Forth-2012 standard.
>Interpretation semantics for [ are "undefined". Unfortunately, the
>standard does not say what "undefined" means.

It means that the standard does not define what a standard Forth
system should do. Consequently, a standard program cannot rely on any
particular behaviour.

>I read it to mean a
>condition worse than "ambiguous condition", calling for a compiler
>error.

There is no such requirement, and many systems implement non-error
interpretation semantics for some or all words where the standard does
not define interpretation semantics.

> > 2. What about execution of right-brackets two times one after > another
> > (or executing it in interpretation state)?
>
>Right-bracket is supposed to be executed in interpretation state, to
>return STATE to compilation. The standard does not say anything about
>use of right-bracket in compilation mode.

It does. ] has no "Compilation:" section, so 3.4.3.3 applies:

|Unless otherwise specified in a "Compilation:" section of the glossary
|entry, the compilation semantics of a Forth definition shall be to
|append its execution semantics to the execution semantics of the
|current definition.

[Ruvim]

On 2020-02-06 05:53, Krishna Myneni wrote:
> On 05-02-20 6:22 PM, Ruvim wrote:
>> : foo [ [ 123 ]  [ . 456 ] literal . ;
> > 1. Could you please proof it by the standard?
>
> See 6.1.2500 in the Forth-2012 standard.
> Interpretation semantics for [ are "undefined".

It does not matter for my corrected example.

> Unfortunately, the standard does not say what "undefined" means.

I don't think that it is unclear. "Undefined" means "not defined".
It is just a kind of a label.
In the standard, "undefined semantics" means that these semantics are
not defined by the standard. A standard Forth system may arbitrary
define these semantics (i.e., they are system dependent), and a standard
program shall not rely on these semantics.

> I read it to mean a condition worse than "ambiguous condition",
> calling for a compiler error.

https://forth-standard.org/standard/doc#subsection.4.1.2
4.1.2 Ambiguous conditions
...
- interpreting a word with undefined interpretation semantics;

https://forth-standard.org/standard/usage#usage:ambiguous
3.4.4 Possible actions on an ambiguous condition
...
- ignore and continue;
...
- take implementation-dependent actions.

https://forth-standard.org/standard/exception#table:throw
9.3.4 Possible actions on an ambiguous condition

- execute THROW

> However, someone from the committee should clarify its meaning.
> At the least, it suggests that when you use "[" in interpretation mode,
> you cannot expect the code to be portable. Indeed this is the case. For
> example, in Gforth, one obtains:
> ------
> : [ [compile] [ ; immediate

After that, you don't use standard "[" word in interpretation state any
more, you use another your own word.

> *terminal*:1:17: warning: redefined [
> *terminal*:1:3: warning: original location ok
> : foo [ [ 123 ]  [ . 456 ] literal . ; foo 123
> *terminal*:2:38: warning: redefined foo
> *terminal*:2:4: warning: original location456  ok
> -----
> The messages indicate FOO is redefined.

Since you defined FOO twice.

> > 2. What about execution of right-brackets two times one after
> > another (or executing it in interpretation state)?

It's a typo. Of course, I wanted to say "in compilation mode".

> Right-bracket is supposed to be executed in interpretation state, to
> return STATE to compilation. The standard does not say anything about
> use of right-bracket in compilation mode.


> > A standard program may do anything that is not prohibited by
> > the standard. And I don't see any even implicit ambiguous
> > conditions that are connected with executing of "[" and "]"
> > words.
>
> It's possible that it is not explicitly prohibited by the standard.
> However, your code cannot be considered portable per the standard.
> Furthermore, the standard does not explicitly prohibit [ from pushing a
> compilation frame (onto the return stack, for example) and ] from
> popping a compilation frame. Pushing and popping need not involve the
> data stack at all.

System is not allowed to do it, since changing of the return stack is
detectable by a standard program.


For a standard program, everything which is not forbidden is allowed.

For a standard system, everything which is not allowed (and detectable
by a standard program) is forbidden.


We already discussed this point:

An important premise is that on performing a standard code
a Forth system is not allowed to produce an unspecified side
effect that can be detected by a standard code.

See also:
news:COadnXWMgYRwKenA...@supernews.com
https://groups.google.com/d/msg/comp.lang.forth/YorBW05PS0A/CMDd7XsrAwAJ

> By the way, FOO's behavior would be considered undefined on the first
> execution of [ since the state of the system is intrepretation at that
> point.

No. FOO's behavior is just to print 456, it does not perform "[".

During compilation of FOO, the second "[" is performed in interpretation
state, but it is a user-defined immediate word that has well defined
interpretation semantics.


--
Ruvim

[none albert]

In article <r1gmak$inr$1...@dont-email.me>, Ruvim <ruvim...@gmail.com> wrote:
>On 2020-02-06 05:53, Krishna Myneni wrote:
>> On 05-02-20 6:22 PM, Ruvim wrote:
>>> : foo [ [ 123 ]  [ . 456 ] literal . ;
>> > 1. Could you please proof it by the standard?
>>
>> See 6.1.2500 in the Forth-2012 standard.
>> Interpretation semantics for [ are "undefined".
>
>It does not matter for my corrected example.
>
>
>> Unfortunately, the standard does not say what "undefined" means.
>
>I don't think that it is unclear. "Undefined" means "not defined".
>It is just a kind of a label.
>In the standard, "undefined semantics" means that these semantics are
>not defined by the standard. A standard Forth system may arbitrary
>define these semantics (i.e., they are system dependent), and a standard
>program shall not rely on these semantics.

An example may clarify this.
It is occasionally useful to perform something a couple of time
in compilation mode, for example a small table of primes :

CREATE PRIMES 1000 2 DO I PRIME? IF I , THEN LOOP
HERE PRIMES - CELL/ CONSTANT #PRIMES

A standard system may provide this facility and is still standard.
A program may use this facility, but is no longer standard.
The latter should be obvious, it is not portable to standard systems
that do not provide this facility.

[Krishna Myneni]

On 06-02-20 3:29 AM, Ruvim wrote:
> On 2020-02-06 05:53, Krishna Myneni wrote:
>> On 05-02-20 6:22 PM, Ruvim wrote:
>>> : foo [ [ 123 ]  [ . 456 ] literal . ;
>>  > 1. Could you please proof it by the standard?
>>
>> See 6.1.2500 in the Forth-2012 standard.
>> Interpretation semantics for [ are "undefined".
>
> It does not matter for my corrected example.
>

Yes, it does. You are still executing the original left-bracket [ in
interpretation mode. See below.

>
>> Unfortunately, the standard does not say what "undefined" means.
>
> I don't think that it is unclear. "Undefined" means "not defined".
> It is just a kind of a label.
> In the standard, "undefined semantics" means that these semantics are
> not defined by the standard. A standard Forth system may arbitrary
> define these semantics (i.e., they are system dependent), and a standard
> program shall not rely on these semantics.
>

....

>
> https://forth-standard.org/standard/doc#subsection.4.1.2
> 4.1.2 Ambiguous conditions
>   ...
>   - interpreting a word with undefined interpretation semantics;
>
> https://forth-standard.org/standard/usage#usage:ambiguous
> 3.4.4 Possible actions on an ambiguous condition
>   ...
>   - ignore and continue;
>   ...
>   - take implementation-dependent actions.
>
> https://forth-standard.org/standard/exception#table:throw
> 9.3.4 Possible actions on an ambiguous condition
>
>   - execute THROW
>

From Anton's reply concerning the meaning of "undefined" with respect
to the interpretation semantics of a word:

"It means that the standard does not define what a standard Forth system

should do. Consequently, a standard program cannot rely on any
particular behaviour."

This interpretation suggests your code cannot be considered to be a
standard program since it contains behavior specific to an ambiguous
condition. Are you in agreement with this?

>
>
>> However, someone from the committee should clarify its meaning. At the
>> least, it suggests that when you use "[" in interpretation mode, you
>> cannot expect the code to be portable. Indeed this is the case. For
>> example, in Gforth, one obtains:
>> ------
>> : [ [compile] [ ; immediate
>


> After that, you don't use standard "[" word in interpretation state any
> more, you use another your own word.
>
>> *terminal*:1:17: warning: redefined [
>> *terminal*:1:3: warning: original location ok
>> : foo [ [ 123 ]  [ . 456 ] literal . ; foo 123
>> *terminal*:2:38: warning: redefined foo
>> *terminal*:2:4: warning: original location456  ok
>> -----
>> The messages indicate FOO is redefined.
>
> Since you defined FOO twice.
>

I copied your code verbatim. Where is FOO being defined twice?

>>  > A standard program may do anything that is not prohibited by

>>  > the standard. ...

Per the statement above: "... a standard program cannot rely on any
particular behavior."

>> It's possible that it is not explicitly prohibited by the standard.
>> However, your code cannot be considered portable per the standard.
>> Furthermore, the standard does not explicitly prohibit [ from pushing
>> a compilation frame (onto the return stack, for example) and ] from
>> popping a compilation frame. Pushing and popping need not involve the
>> data stack at all.
>
> System is not allowed to do it, since changing of the return stack is
> detectable by a standard program.
>

Yes, the standard for [ and ] would probably have to be changed to allow
the behavior I am describing. In practice, however, it would be unusual
to switch to interpretation mode from within a definition and assume the
return stack to be in a certain configuration. I think that would result
in a not easily understandable program.

>> By the way, FOO's behavior would be considered undefined on the first
>> execution of [ since the state of the system is intrepretation at that
>> point.
>
> No. FOO's behavior is just to print 456, it does not perform "[".

Yes, I mistakenly thought it was compiling [ into the definition of FOO
. That is not the case.

> During compilation of FOO, the second "[" is performed in interpretation
> state, but it is a user-defined immediate word that has well defined
> interpretation semantics.

The effect is still to execute the *original* left-bracket [ in
interpretation state which is an ambiguous condition. It does not make
your code a standard program, even if you redefine [.

KM

[Krishna Myneni]

On 06-02-20 2:30 AM, Anton Ertl wrote:
...

>> Right-bracket is supposed to be executed in interpretation state, to
>> return STATE to compilation. The standard does not say anything about
>> use of right-bracket in compilation mode.
> It does. ] has no "Compilation:" section, so 3.4.3.3 applies:
>
> |Unless otherwise specified in a "Compilation:" section of the glossary
> |entry, the compilation semantics of a Forth definition shall be to
> |append its execution semantics to the execution semantics of the
> |current definition.

Does this mean, per the standard, that one may use ] in sequence several
times within a definition? E.g. is the following a standard program?

: foo [ 256 ] ] literal ;

Krishna

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>Does this mean, per the standard, that one may use ] in sequence several
>times within a definition? E.g. is the following a standard program?
>
>: foo [ 256 ] ] literal ;

Yes.

[Ruvim]

On 2020-02-06 13:55, Krishna Myneni wrote:
> On 06-02-20 2:30 AM, Anton Ertl wrote:

> ....

Yes, it is a standard code [1], that may be a part of a standard program.

NB: the second "]" is compiled, not interpreted.
So, the execution semantics for FOO is to set compilation state and
place 256 to the data stack.


[1] I prefer to say "standard code" in place of "standard program"
regarding to *code fragments*, since formally a standard program should
be also properly documented, see 5.2.1 and 4.2.


--
Ruvim

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>On 06-02-20 3:29 AM, Ruvim wrote:
>> On 2020-02-06 05:53, Krishna Myneni wrote:

>>> : [ [compile] [ ; immediate

and

: foo [ [ 123 ] [ . 456 ] literal . ;

>> During compilation of FOO, the second "[" is performed in interpretation
>> state, but it is a user-defined immediate word that has well defined
>> interpretation semantics.
>
>The effect is still to execute the *original* left-bracket [ in
>interpretation state which is an ambiguous condition.

That's what you get from fuzzy thinking. "execute the *original*
left-bracket [" is not precise enough. What happens is that [COMPILE]
[ appends the compilation semantics of the original [ into the new [,
so the new [ has defined interpretation semantics. It is not relevant
for [ what STATE the text interpreter is in when performing the
interpretation semantics of the new [ and thus the compilation
semantics of the original [.

[Krishna Myneni]

On 06-02-20 5:15 AM, Anton Ertl wrote:
> Krishna Myneni <krishna...@ccreweb.org> writes:
>> On 06-02-20 3:29 AM, Ruvim wrote:
>>> On 2020-02-06 05:53, Krishna Myneni wrote:
>>>> : [ [compile] [ ; immediate
>
> and
>
> : foo [ [ 123 ] [ . 456 ] literal . ;
>
>>> During compilation of FOO, the second "[" is performed in interpretation
>>> state, but it is a user-defined immediate word that has well defined
>>> interpretation semantics.
>>
>> The effect is still to execute the *original* left-bracket [ in
>> interpretation state which is an ambiguous condition.
>
> That's what you get from fuzzy thinking. "execute the *original*
> left-bracket [" is not precise enough. What happens is that [COMPILE]
> [ appends the compilation semantics of the original [ into the new [,
> so the new [ has defined interpretation semantics. It is not relevant
> for [ what STATE the text interpreter is in when performing the
> interpretation semantics of the new [ and thus the compilation
> semantics of the original [.
>

Are you stating that there is no ambiguous condition for the following
code, and that it may be considered to be a standard program/code?

: [ [compile] [ ; immediate
: foo [ [ 123 ] [ . 456 ] literal . ; foo


Then, why is Gforth behaving differently than Ruvim's output for the 2nd
statement,

: foo [ [ 123 ] [ . 456 ] literal . ; foo

In Gforth there is an attempt to redefine FOO. In Ruvim's listed output,
the second statement simply printed 123 and 456 in sequence.

KM

[Krishna Myneni]

Ok. I see what happened. The code was tried twice, with COLD executed in
between. The meaning of COLD may be different in Gforth than in kForth.
Apparently the previous definition of FOO was not forgotten by COLD. So,
yes, the behavior under Gforth is the same as for Ruvim's output.

KM

[Ruvim]

On 2020-02-06 13:49, Krishna Myneni wrote:
> On 06-02-20 3:29 AM, Ruvim wrote:
>> On 2020-02-06 05:53, Krishna Myneni wrote:
>>> On 05-02-20 6:22 PM, Ruvim wrote:
>>>> : foo [ [ 123 ]  [ . 456 ] literal . ;

[...]

>> https://forth-standard.org/standard/doc#subsection.4.1.2
>> 4.1.2 Ambiguous conditions
>>    ...
>>    - interpreting a word with undefined interpretation semantics;

>

> From Anton's reply concerning the meaning of "undefined" with respect
> to the interpretation semantics of a word:
> "It means that the standard does not define what a standard Forth system
> should do.  Consequently, a standard program cannot rely on any
> particular behaviour."

>
> This interpretation suggests your code cannot be considered to be a
> standard program since it contains behavior specific to an ambiguous
> condition. Are you in agreement with this?

No.

A program cannot rely on the interpretation semantics of the standard
"[" word. And my code does not contain interpretation semantics of this
word, so it doesn't rely on it.

>>> *terminal*:1:17: warning: redefined [
>>> *terminal*:1:3: warning: original location ok
>>> : foo [ [ 123 ]  [ . 456 ] literal . ; foo 123
>>> *terminal*:2:38: warning: redefined foo
>>> *terminal*:2:4: warning: original location456  ok
>>> -----
>>> The messages indicate FOO is redefined.
>>
>> Since you defined FOO twice.
>
> I copied your code verbatim. Where is FOO being defined twice?

I can't reproduce it in gforth 0.7.2




[...]

>> During compilation of FOO, the second "[" is performed in
>> interpretation state, but it is a user-defined immediate word that has
>> well defined interpretation semantics.

A more accurate formulation:

During compilation of FOO, for the first occurrence of "[" word a Forth
system performs compilation semantics of this word, for the second
occurrence it performs interpretation semantics for this word, that is
well defined since it is a user-defined word.

> The effect is still to execute the *original* left-bracket [ in
> interpretation state which is an ambiguous condition.

Oh. We had so many discussions wrt this issue in the past year that I
thought the question is already closed.

In the general case, the effect is not equal to interpret the original "[".

When the original "[" word is interpreted, a system performs its
*interpretation* semantics. And it is disallowed for a standard program,
since this semantics is undefined in the standard.

When the redefined "[" word is interpreted, a system eventually performs
the *compilation semantics* of the original "[" word.

The standard nowhere says that performing compilation semantics (for
some or any word) in interpretation state is an ambiguous condition.

> It does not make your code a standard program, even if you redefine [.

You have an incorrect idea that my code performs some interpretation
semantics that are undefined in the standard.


A similar case:

: compile, compile, ;
: bar [ ' foo compile, ] ;

— it is a standard code too.


--
Ruvim

[Krishna Myneni]

On 06-02-20 6:56 AM, Ruvim wrote:

>
>>>> *terminal*:1:17: warning: redefined [
>>>> *terminal*:1:3: warning: original location ok
>>>> : foo [ [ 123 ]  [ . 456 ] literal . ; foo 123
>>>> *terminal*:2:38: warning: redefined foo
>>>> *terminal*:2:4: warning: original location456  ok
>>>> -----
>>>> The messages indicate FOO is redefined.
>>>
>>> Since you defined FOO twice.
>>
>> I copied your code verbatim. Where is FOO being defined twice?
>
> I can't reproduce it in gforth 0.7.2

The problem is understood now. I assumed that COLD restarted the system
in Gforth, without memory of past definitions.

...
>>> During compilation of FOO, the second "[" is performed in
>>> interpretation state, but it is a user-defined immediate word that
>>> has well defined interpretation semantics.
>
> A more accurate formulation:
>
> During compilation of FOO, for the first occurrence of "[" word a Forth
> system performs compilation semantics of this word, for the second
> occurrence it performs interpretation semantics for this word, that is
> well defined since it is a user-defined word.
>
>
>> The effect is still to execute the *original* left-bracket [ in
>> interpretation state which is an ambiguous condition.
>
> Oh. We had so many discussions wrt this issue in the past year that I
> thought the question is already closed.
>

Sorry, I apparently missed those discussions.

> In the general case, the effect is not equal to interpret the original "[".
>
> When the original "[" word is interpreted, a system performs its
> *interpretation* semantics. And it is disallowed for a standard program,
> since this semantics is undefined in the standard.
>
> When the redefined "[" word is interpreted, a system eventually performs
> the *compilation semantics* of the original "[" word.
>
> The standard nowhere says that performing compilation semantics (for
> some or any word) in interpretation state is an ambiguous condition.
>

...

> You have an incorrect idea that my code performs some interpretation
> semantics that are undefined in the standard.
>

Ok. I think I see your point now.

KM

[Coos Haak]

Op Thu, 6 Feb 2020 14:15:18 +0300 schreef Ruvim:

> On 2020-02-06 13:55, Krishna Myneni wrote:
>> On 06-02-20 2:30 AM, Anton Ertl wrote:
>> ....
>>>> Right-bracket is supposed to be executed in interpretation state, to
>>>> return STATE to compilation. The standard does not say anything about
>>>> use of right-bracket in compilation mode.
>>> It does.  ] has no "Compilation:" section, so 3.4.3.3 applies:
>>>
>>> |Unless otherwise specified in a "Compilation:" section of the glossary
>>> |entry, the compilation semantics of a Forth definition shall be to
>>> |append its execution semantics to the execution semantics of the
>>> |current definition.
>>
>> Does this mean, per the standard, that one may use ] in sequence several
>> times within a definition? E.g. is the following a standard program?
>>
>>: foo [ 256 ] ] literal ;
>
> Yes, it is a standard code [1], that may be a part of a standard program.
>
> NB: the second "]" is compiled, not interpreted.
> So, the execution semantics for FOO is to set compilation state and
> place 256 to the data stack.
>

Yes, that's the behavior of gforth_0.7.0._20200130 undeder Linux, 32 and 64
bits.

The windows version crashes:
$ gforth
Gforth 0.7.9_20200130
Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type
`authors'
Copyright © 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
: foo [ 256 ] ] literal ; ok
\ safe until I do this:
see foo
: foo
]
coos@southernman ~

groet Coos

[dxforth]

On Thursday, February 6, 2020 at 10:37:05 PM UTC+11, Anton Ertl wrote:
> Krishna Myneni <krishna...@ccreweb.org> writes:
> >On 06-02-20 3:29 AM, Ruvim wrote:
> >> On 2020-02-06 05:53, Krishna Myneni wrote:
> >>> : [ [compile] [ ; immediate
>
> and
>
> : foo [ [ 123 ] [ . 456 ] literal . ;
>
> >> During compilation of FOO, the second "[" is performed in interpretation
> >> state, but it is a user-defined immediate word that has well defined
> >> interpretation semantics.
> >
> >The effect is still to execute the *original* left-bracket [ in
> >interpretation state which is an ambiguous condition.
>
> That's what you get from fuzzy thinking. "execute the *original*
> left-bracket [" is not precise enough. What happens is that [COMPILE]
> [ appends the compilation semantics of the original [ into the new [,
> so the new [ has defined interpretation semantics. It is not relevant
> for [ what STATE the text interpreter is in when performing the
> interpretation semantics of the new [ and thus the compilation
> semantics of the original [.

Fuzzy thinking is believing one can summon the spirit of ANS to
adjudicate on matters posthumously things it was never asked to
consider when alive.

[Krishna Myneni]

On 06-02-20 5:06 AM, Anton Ertl wrote:
> Krishna Myneni <krishna...@ccreweb.org> writes:
>> Does this mean, per the standard, that one may use ] in sequence several
>> times within a definition? E.g. is the following a standard program?
>>
>> : foo [ 256 ] ] literal ;
>
> Yes.

These discussions were useful. Ruvim had pointed out earlier (a few
months ago) that "]" was non-standard in kForth, in that it had
immediate precedence. I have fixed that problem now, both in the
kForth-32 master branch and in kForth-64. Both of the examples we
discussed here now give the same output in kForth, as with Ruvim's Forth
and with Gforth. kForth-32 (v. 2.1.5), the transitional version
towards Forth-2012 and kForth-64 (v. 0.1.5) now snap more closely to the
standard, even while preserving several unique features of kForth. I
plan to back-port these changes to version 1.6, the Forth-94-aligned,
32-bit version.

Despite the aggravation of having to go through these examples in
explicit detail, the discussion does benefit the standard.

Krishna Myneni

Examples from this thread under kForth-32/64
------
\ ** Example 1 **
: foo [ 256 ] ] literal ;
ok
.s
<empty>
ok
foo \ stays in compilation mode due to the 2nd "]"
test

TEST
Line 4: VM Error(-13): Undefined word
\ ...
cold
ok
\ ** Example 2 **
: [ postpone [ ; immediate
[ is redefined
ok
: foo [ [ 123 ] [ . 456 ] literal . ; foo
123 456 ok
.s
<empty>
--------

[Anton Ertl]

Coos Haak <htr...@gmail.com> writes:
>The windows version crashes:
>$ gforth
>Gforth 0.7.9_20200130
>Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type
>`authors'

>Copyright Š 2019 Free Software Foundation, Inc.

>License GPLv3+: GNU GPL version 3 or later
><https://gnu.org/licenses/gpl.html>
>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>Type `help' for basic help
>: foo [ 256 ] ] literal ; ok
>\ safe until I do this:
>see foo
>: foo
> ]
>coos@southernman ~

Looks like a bug in SEE. It decompiles the ] all right (this is the
second ] in the source code), and leaves the process when decompiling
lit 256. Strange. You can check if SIMPLE-SEE works better.

[Coos Haak]

Op Fri, 07 Feb 2020 06:22:16 GMT schreef Anton Ertl:

> Coos Haak <htr...@gmail.com> writes:
>>The windows version crashes:
>>$ gforth
>>Gforth 0.7.9_20200130
>>Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type
>>`authors'
>>Copyright Š 2019 Free Software Foundation, Inc.
>>License GPLv3+: GNU GPL version 3 or later
>><https://gnu.org/licenses/gpl.html>
>>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>>Type `help' for basic help
>>: foo [ 256 ] ] literal ; ok
>>\ safe until I do this:
>>see foo
>>: foo
>> ]
>>coos@southernman ~
>
> Looks like a bug in SEE. It decompiles the ] all right (this is the
> second ] in the source code), and leaves the process when decompiling
> lit 256. Strange. You can check if SIMPLE-SEE works better.
>
> - anton

simple-see gives an omission of ;s in the windows version

: foo [ 123 ] ] literal ; ok
simple-see foo
$6FFFFF875D50 call
$6FFFFF875D58 <]>
$6FFFFF875D60 lit
$6FFFFF875D68
coos@southernman ~ <- what now?

the linux version compiles a terminating ;s as exepected

: foo [ 123 ] ] literal ; ok
simple-see foo
$7FD04CE30D48 call
$7FD04CE30D50 <]>
$7FD04CE30D58 lit
$7FD04CE30D60 123
$7FD04CE30D68 ;s ok

groet Coos

[Anton Ertl]

Coos Haak <htr...@gmail.com> writes:
>> Coos Haak <htr...@gmail.com> writes:
>>>The windows version crashes:
>>>$ gforth
>>>Gforth 0.7.9_20200130

...

>: foo [ 123 ] ] literal ; ok
>simple-see foo
>$6FFFFF875D50 call
>$6FFFFF875D58 <]>
>$6FFFFF875D60 lit
>$6FFFFF875D68
>coos@southernman ~ <- what now?

It seems that the decompilation of 123 is the problem. The decompiler
now tests whether a cell is an accessible address by performing a
fetch. Apparently the signal handler does not work properly in the
Windows port and leaves the process.

[Bernd Paysan]

Am Donnerstag, 6. Februar 2020 17:08:49 UTC+1 schrieb Coos Haak:
> Yes, that's the behavior of gforth_0.7.0._20200130 undeder Linux, 32 and 64
> bits.
>
> The windows version crashes:
> $ gforth
> Gforth 0.7.9_20200130
> Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type
> `authors'
> Copyright © 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <https://gnu.org/licenses/gpl.html>
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `help' for basic help
> : foo [ 256 ] ] literal ; ok
> \ safe until I do this:
> see foo
> : foo
> ]
> coos@southernman ~

Looks like a bug in Cygwin64 (or Windows) — if you start gforth with --no-dynamic, it works as it should, the exception is caught, but it you use dynamic superinstructions, they don't generate an exception, and instead terminate the program.

The Cygwin32 bit version works fine.

[Krishna Myneni]

On 06-02-20 6:56 AM, Ruvim wrote:

...

> A more accurate formulation:
>
> During compilation of FOO, for the first occurrence of "[" word a Forth
> system performs compilation semantics of this word, for the second
> occurrence it performs interpretation semantics for this word, that is
> well defined since it is a user-defined word.

> ...

: [ [compile] [ ; immediate

Just to be clear, what are the interpretation semantics of the redefined
"[" ? Does the standard say anything specifically about the
interpretation semantics of IMMEDIATE words ? What is the expected
behavior of the redefined "[" in interpretation mode since [COMPILE]
does not have interpretation semantics?

Krishna

[Krishna Myneni]

I just realized the last question concerning [COMPILE] does not apply.
Let me rephrase the entire comment:

Just to be clear, what are the interpretation semantics of the redefined
"[" ? Does the standard say anything specifically about the
interpretation semantics of IMMEDIATE words ? What is the expected

behavior of the redefined "["?

KM

[Ruvim]

User-defined immediate words have the default interpretation semantics:
i.e., when the text interpreter encounters an immediate word in
interpretation state, it performs the execution semantics of this word
(and it does it in interpretation state).

Regarding the standard immediate words, for some of them the standard
specify "Interpretation" section to declare undefined interpretation
semantics for them. So, a Forth system is free to do anything on
interpreting these words.


So, the interpretation semantics for the user-defined "[" word is to
perform its execution semantics. The execution semantics of this word is
to set interpretation state.

Nothing wrong if interpretation state was already set before executing
this word.


--
Ruvim

[Krishna Myneni]

Ok. Thanks for the clarification. I'm not saying it is wrong for your
redefined "[" to set interpretation state in STATE 0.

KM

[hughag...@gmail.com]

You are trying to implement a disambiguifier:

: [
state @ 0= abort" *** no interpretation semantics for: [ ***"
postpone [ ;
immediate

You are screwing everything up!

For one thing, you can't use [COMPILE] because there is no guarantee
in ANS-Forth that [ is non-immediate. ANS-Forth weirdly fails to define words
as being non-immediate or immediate (that is Elizabeth Rather's stupidity).

For another thing, you are making the same weird mistake that
Anton Ertl, Alex McDonald and Gerry Jackson were making:
https://groups.google.com/forum/#!topic/comp.lang.forth/y96tQf_iOSk%5B1-25%5D
You seem to think that disambiguifiers magically allow words without
interpretation semantics to be used inside of [ ] brackets.
They don't. This may or may not work from one ANS-Forth implementation
to another. This usually works for IF etc. (they compile code).
This may or may not work for R@ and [ etc.. This is non-standard.

I said this above:

On Wednesday, February 5, 2020 at 9:53:54 PM UTC-7, hughag...@gmail.com wrote:
> Krishna Myneni is making a fool out of himself!

> ...

> The ANS-Forth and Forth-200x cult never learns anything!
> They just continue to spout the same idiotic blather, year after year.
> They just continue to fail in the same way, decade after decade.
> This embarrassing behavior never ceases, but it just goes on and on...

With more creativity, you could be stupid in a new way, rather than just
be stupid in the same way that Anton Ertl, Alex McDonald and Gerry Jackson
were stupid previously. I don't expect the ANS-Forth cult to ever
be intelligent, but it is boring when you fail to even be stupid in
new ways but just make the same idiotic mistakes over and over again.