On 24/05/2021 19:00, Alexander Wegel wrote:
> dxforth <dxforth@gmail.com> wrote:
>
>> On 23/05/2021 21:59, Ruvim wrote:
>
>> > But the current definition can exist in interpretation state too, e.g.:
>> >
>> > : bar [: ." (ABC)" ;] compile, ." (ABC compiled)" ; immediate
>> > : foo [ ' bar compile, ] ;
>> >
>> > And in these conditions their ES (and then the default IS) make sense.
>>
>> Make sense to whom?
>
> To people thinking a step further.
>

Then they should think further. ANS was never about creating a new forth
paradigm - it was accommodating existing implementations, predominantly
the vendors. Just as 200x had to modify its expectations over locals and
accommodate Forth Inc, so it will be with MPE should it not back down.
The standard is a set of rules - rules that can and have changed by TC's
when in their interest to do so.

On Tue, 25 May 2021 11:32:45 +1000, dxforth <dxforth@gmail.com> wrote:

>Then they should think further. ANS was never about creating a new forth
>paradigm - it was accommodating existing implementations, predominantly
>the vendors.

The TC discusses and votes. It mostly accommodates the views of those
people who turn up.

>Just as 200x had to modify its expectations over locals and
>accommodate Forth Inc, so it will be with MPE should it not back down.

What position of MPE are you talking about?

>The standard is a set of rules - rules that can and have changed by TC's
>when in their interest to do so.

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 25/05/2021 19:04, Stephen Pelc wrote:
> On Tue, 25 May 2021 11:32:45 +1000, dxforth <dxforth@gmail.com> wrote:
>
>>Then they should think further. ANS was never about creating a new forth
>>paradigm - it was accommodating existing implementations, predominantly
>>the vendors.
>
> The TC discusses and votes. It mostly accommodates the views of those
> people who turn up.

Those views have consistently been that a 'standard program' should be
able to run on vendors' systems. Just as it was with ANS.

>
>>Just as 200x had to modify its expectations over locals and
>>accommodate Forth Inc, so it will be with MPE should it not back down.
>
> What position of MPE are you talking about?

>> > : bar [: ." (ABC)" ;] compile, ." (ABC compiled)" ; immediate
>> > : foo [ ' bar compile, ] ;

On 24/05/2021 20:10, albert wrote:
> In article <2021May23.170041@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> <SNIP>
>>And thinking more about it, it's probably an ill-thought-out way to
>>protect programmers from using these words wrongly. Similar in spirit
>>(though not in semantics) to how dxforth pollutes his system with
>>?COMP, while SwiftForth demonstrates that this kind of paternalism is
>>unnecessary.
>
> : test [ IF ] "TRUE" TYPE ELSE "FALSE" TYPE THEN ;
> : test [ IF ? ciforth ERROR # 17 : COMPILATION ONLY, USE IN DEFINITION
> WANT -plain-control-
> -plain-control- : (WARNING) NOT PRESENT, THOUGH WANTED
> OK
> : test [ IF ] "TRUE" TYPE ELSE "FALSE" TYPE THEN ;
> OK
> 0 test
> FALSE OK
> 1 test
> TRUE OK
>
> I don't think this is paternalism, as long as you can switch it off,
> but the benefits are slim.
> I think more of them as training wheels for novices.
> The only word where `?COMP would have helped me is in `; .
> As in editing errors like
> : double
> 2 * ;
> ;
> but fig-Forth did not have a `?COMP in `; and neither do I.
> ...

Fig-forth had ?COMP in COMPILE which was executed by ';'

I use ?COMP a total of fives times which covers all the usual suspects.

On Thursday, May 13, 2021 at 11:58:53 AM UTC+1, Stephen Pelc wrote:

> COMPILE, may not parse source text or have additional stack effects.

I take your point about stack effects (so I have reverted to not using COMPILE, for
this purpose), but I don't see why COMPILE, may not parse. Sure, it doesn't show up
in the definition of COMPILE, but then neither does it in EXECUTE - and I don't see
anyone argue that you can't EXECUTE a parsing word. And in the rationale, COMPILE,
is supposed to be the compilation equivalent of EXECUTE.

(although, as usual, I may be completely wrong!)

Paul

On Thursday, May 13, 2021 at 11:48:41 AM UTC+1, Ruvim wrote:

> This issue is addressed by the Recognizer API
>
> The most recently discussed variant can be found at:
> https://forth-standard.org/proposals/minimalistic-core-api-for-recognizers?hideDiff#reply-515

Ah, thank you for that. I will probably find it useful.

> "compilation semantics of xt" is a nonsense.
>
> Compilation semantics make sense for only named definitions (words).
> Ditto interpretation semantics.
>
> Please refer to 2.1 Definitions of terms
> https://forth-standard.org/standard/notation#notation:terms

I'm not sure that it is a nonsense at all. With the usual disclaimer that I may
be completely wrong, surely any implementation of NDCS/dual words will
allow at least *some* words, as identified by their xts, to have separately identifiable
compilation semantics. So far as I can tell, this would be true of words
defined with INTERPRET/COMPILE in Gforth or with :NDCS in VFX.

In article <s8kjta$1l4b$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
>On 24/05/2021 20:10, albert wrote:
>> In article <2021May23.170041@mips.complang.tuwien.ac.at>,
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> <SNIP>
>>>And thinking more about it, it's probably an ill-thought-out way to
>>>protect programmers from using these words wrongly. Similar in spirit
>>>(though not in semantics) to how dxforth pollutes his system with
>>>?COMP, while SwiftForth demonstrates that this kind of paternalism is
>>>unnecessary.
>>
>> : test [ IF ] "TRUE" TYPE ELSE "FALSE" TYPE THEN ;
>> : test [ IF ? ciforth ERROR # 17 : COMPILATION ONLY, USE IN DEFINITION
>> WANT -plain-control-
>> -plain-control- : (WARNING) NOT PRESENT, THOUGH WANTED
>> OK
>> : test [ IF ] "TRUE" TYPE ELSE "FALSE" TYPE THEN ;
>> OK
>> 0 test
>> FALSE OK
>> 1 test
>> TRUE OK
>>
>> I don't think this is paternalism, as long as you can switch it off,
>> but the benefits are slim.
>> I think more of them as training wheels for novices.
>> The only word where `?COMP would have helped me is in `; .
>> As in editing errors like
>> : double
>> 2 * ;
>> ;
>> but fig-Forth did not have a `?COMP in `; and neither do I.
>> ...
>
>Fig-forth had ?COMP in COMPILE which was executed by ';'
>
>I use ?COMP a total of fives times which covers all the usual suspects.

You're right. I got rid of COMPILE and ?COMP disappeared with it.

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

On Wed, 26 May 2021 00:50:16 -0700 (PDT), Paul Liles
<pauldliles@btopenworld.com> wrote:

>On Thursday, May 13, 2021 at 11:58:53 AM UTC+1, Stephen Pelc wrote:
>
>> COMPILE, may not parse source text or have additional stack effects.
>
>I take your point about stack effects (so I have reverted to not using COMPILE, for
>this purpose), but I don't see why COMPILE, may not parse. Sure, it doesn't show up
>in the definition of COMPILE, but then neither does it in EXECUTE - and I don't see
>anyone argue that you can't EXECUTE a parsing word. And in the rationale, COMPILE,
>is supposed to be the compilation equivalent of EXECUTE.

It can't parse because
a) Anton says so and
b) the standard only indicates parsing for words that parse.
Hence, there's an assumption in the standard that only words that
parse explicitly are allowed to do so.

Most parsing words such as S" and friends are laid down by
actions performed at compile time. In ye olden days, such words
were immediate and were executed in compile state. If you want to
avoid COMPILE, problems, your compiling words such as S" and IF
have to be immediate.

In modern times, people have realised the impact of the magic
phrase "non-default compilation semantics" (NDCS for short).
A few systems, such as VFX and gForth have tools to build
words that are not immediate, but are NDCS words.

To implement and use NDCS words, a few words need to be added to
the standard. My most recent paper on these words is recommended
and is available at:

https://www.dropbox.com/s/sgposml3558oram/SpecialWords4.pdf?dl=0

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

Paul Liles <pauldliles@btopenworld.com> writes:
>With the usual disclaimer that I may
>be completely wrong, surely any implementation of NDCS/dual words will
>allow at least *some* words, as identified by their xts, to have separately identifiable
>compilation semantics. So far as I can tell, this would be true of words
>defined with INTERPRET/COMPILE in Gforth

In Gforth, a named word (such as the words defined with
INTERPRET/COMPILE:) is identified by the nt, and a word defined with
interpret/compile: has interpretation semantics identified by an xt,
and compilation semantics identified by (normally) a pair of xts.

Example:

: int-sem ." interpretation semantics" ;
: comp-sem ." compilation semantics" ;
' int-sem ' comp-sem interpret/compile: dual-word
dual-word \ output: interpretation semantics
] dual-word [ \ output: compilation semantics
``dual-word \ get the nt of DUAL-WORD
dup name>interpret smart. \ output: `int-sem (the xt of int-sem)
name>compile ... \ output: <2> `comp-sem `execute
' dual-word smart. \ output: `int-sem

A note on syntax and some relatively unknown words:

``<word> produces the nt of <word> (using a recognizer)
`<word> produces the xt for the interpretation semantics of <word>
smart. prints a cell in a smart way (e.g. an xt using `<word> syntax)
.... smart variant of .S

So you see that ticking DUAL-WORD produces the same xt as ticking
INT-SEM, so this xt does not identify DUAL-WORD. You also see that
the compilation semantics of DUAL-WORD is represented by two xts, none
of which is the xt that you get by ticking DUAL-WORD. And you see
that you can get from the nt of DUAL-WORD to both the interpretation
and compilation semantics.

- 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

Paul Liles <pauldliles@btopenworld.com> writes:
>I take your point about stack effects (so I have reverted to not
>using COMPILE, for this purpose), but I don't see why COMPILE, may
>not parse. Sure, it doesn't show up in the definition of COMPILE, but
>then neither does it in EXECUTE - and I don't see anyone argue that
>you can't EXECUTE a parsing word. And in the rationale, COMPILE, is
>supposed to be the compilation equivalent of EXECUTE.

Yes, you can EXECUTE an xt that represents semantics that parses, and
it will perform the semantics identified by the xt, which is to parse.
By contrast, when you COMPILE, an xt that represents semantics that
parses, COMPILE, will append the semantics represented by the xt to
the execution semantics of the current definition (let's call that
definition C). Any parsing that happens does not happen when COMPILE,
runs, but when C runs.

The compilation equivalent of EXECUTE means that

: compile, ( xt -- ) postpone literal postpone execute ;

is a correct (but not particularly fast) implementation of COMPILE,.
And there is quite a bit of code relying on this equivalence (actually
most uses of COMPILE,)

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

Anton Ertl schrieb am Mittwoch, 26. Mai 2021 um 19:26:31 UTC+2:
> Paul Liles <pauld...@btopenworld.com> writes:
> >With the usual disclaimer that I may
> >be completely wrong, surely any implementation of NDCS/dual words will
> >allow at least *some* words, as identified by their xts, to have separately identifiable
> >compilation semantics. So far as I can tell, this would be true of words
> >defined with INTERPRET/COMPILE in Gforth
> In Gforth, a named word (such as the words defined with
> INTERPRET/COMPILE:) is identified by the nt, and a word defined with
> interpret/compile: has interpretation semantics identified by an xt,
> and compilation semantics identified by (normally) a pair of xts.
>
> Example:
>
> : int-sem ." interpretation semantics" ;
> : comp-sem ." compilation semantics" ;
> ' int-sem ' comp-sem interpret/compile: dual-word
> dual-word \ output: interpretation semantics
> ] dual-word [ \ output: compilation semantics
> ``dual-word \ get the nt of DUAL-WORD
> dup name>interpret smart. \ output: `int-sem (the xt of int-sem)
> name>compile ... \ output: <2> `comp-sem `execute
> ' dual-word smart. \ output: `int-sem
>
> A note on syntax and some relatively unknown words:
>
> ``<word> produces the nt of <word> (using a recognizer)
> `<word> produces the xt for the interpretation semantics of <word>
> smart. prints a cell in a smart way (e.g. an xt using `<word> syntax)
> ... smart variant of .S
>
> So you see that ticking DUAL-WORD produces the same xt as ticking
> INT-SEM, so this xt does not identify DUAL-WORD. You also see that
> the compilation semantics of DUAL-WORD is represented by two xts, none
> of which is the xt that you get by ticking DUAL-WORD. And you see
> that you can get from the nt of DUAL-WORD to both the interpretation
> and compilation semantics.

OMG .. convoluted constructs require convoluted introspection and complex
header & search structures.

That has led me back to 'good ole state smartness'. VERY rare are
situations where this is a problem. On the contrary, my code became
simpler and shorter and easier to maintain.

Perhaps because I am writing real-world applications, and don't try to create
a 'theoretically clean and Lispy' Forth.

Thank you both, Stephen and Anton, I've reversed out my changes to COMPILE, (and
I've read both your various papers on NDCS, which have been nagging at me for the
last six months).

Perhaps if I share my implementation you can tell me what, if anything I have done
wrong:

1) Extend DEFERed words by one cell to hold, optionally, a compilation xt

The compilation xt defaults to zero (meaning default compilation semantics),
so the actual specification of DEFER needs no change.

2) Four new words to manipulate the compilation semantics, based on DEFER@,
DEFER!, IS and ACTION-OF

COMPILE@ ( xt1 – xt2|false ) \ retrieve the compilation semantics if any.
COMPILE! ( xt2|false xt1 – ) \ set compilation semantics, or revert to default.
COMPILES ( xt|false “<spaces>name” -- ) \ Set or reset the compilation semantics of <name>
COMPILE-OF ( “<spaces>name” – xt|false ) \ retrieve the compilation semantics of <name>

3) Compiling, Postponing etc.

There is one extra word I need, which should really be called
"EXECUTE-THE-COMPILATION-SEMANTICS-OF-XT" but I call it (EXCOMP) for short.

It is purely an internal word, equivalent to Stephen's NDCS, and shows up as a factor
of POSTPONE and as a returned value from NAME>COMPILE.

Since my implementation has a single token per word (no separate nt) from which
all flags are accessible, I have not found a need to modify FIND.

I find this a neat and flexible implementation, though I guess it might be more
troublesome for optimising compilers because of the extreme late binding of
everything.

So far as I can tell, so long as the four new words are not exposed to the user
there are no implications for the standard. However, I have at least two concerns
that have sprung to mind:

a) this leaves some DEFERed words having two sets of execution semantics.
In practice it is always clear which is needed, but there may be hidden nuances
that I have not thought of.

b) if there is any use case for a DEFERed word being assigned the xt of another
DEFERed word, the whole thing will fall to pieces!
In use it looks like this (using Anton's usual example):

defer 2DUP
:noname over over ; is 2DUP
:noname postpone over postpone over ; compiles 2DUP

and, for example,

: NDCS, ( xt -- ) compile@ execute ;

Much thanks,

Paul

On 5/26/21 2:02 PM, minf...@arcor.de wrote:
> Anton Ertl schrieb am Mittwoch, 26. Mai 2021 um 19:26:31 UTC+2:
>> Paul Liles <pauld...@btopenworld.com> writes:
>>> With the usual disclaimer that I may
>>> be completely wrong, surely any implementation of NDCS/dual words will
>>> allow at least *some* words, as identified by their xts, to have separately identifiable
>>> compilation semantics. So far as I can tell, this would be true of words
>>> defined with INTERPRET/COMPILE in Gforth
>> In Gforth, a named word (such as the words defined with
>> INTERPRET/COMPILE:) is identified by the nt, and a word defined with
>> interpret/compile: has interpretation semantics identified by an xt,
>> and compilation semantics identified by (normally) a pair of xts.
>>
>> Example:
>>
>> : int-sem ." interpretation semantics" ;
>> : comp-sem ." compilation semantics" ;
>> ' int-sem ' comp-sem interpret/compile: dual-word
>> dual-word \ output: interpretation semantics
>> ] dual-word [ \ output: compilation semantics
>> ``dual-word \ get the nt of DUAL-WORD
>> dup name>interpret smart. \ output: `int-sem (the xt of int-sem)
>> name>compile ... \ output: <2> `comp-sem `execute
>> ' dual-word smart. \ output: `int-sem
>>
>> A note on syntax and some relatively unknown words:
>>
>> ``<word> produces the nt of <word> (using a recognizer)
>> `<word> produces the xt for the interpretation semantics of <word>
>> smart. prints a cell in a smart way (e.g. an xt using `<word> syntax)
>> ... smart variant of .S
>>
>> So you see that ticking DUAL-WORD produces the same xt as ticking
>> INT-SEM, so this xt does not identify DUAL-WORD. You also see that
>> the compilation semantics of DUAL-WORD is represented by two xts, none
>> of which is the xt that you get by ticking DUAL-WORD. And you see
>> that you can get from the nt of DUAL-WORD to both the interpretation
>> and compilation semantics.
>
> OMG .. convoluted constructs require convoluted introspection and complex
> header & search structures.
>
> That has led me back to 'good ole state smartness'. VERY rare are
> situations where this is a problem. On the contrary, my code became
> simpler and shorter and easier to maintain.
>
> Perhaps because I am writing real-world applications, and don't try to create
> a 'theoretically clean and Lispy' Forth.
>

"Theoretically clean" and "convoluted" are mostly antonyms. On the
whole, a theoretically clean approach has the potential to avoid an
immense amount of confusion about what code is supposed to do, once the
design is understood. Admittedly, I don't like all of the notation used
above, but it does not seem to me to be particularly hard to comprehend.
I certainly don't see it as being "convoluted" -- far from it. Indeed
the single-xt + immediate flag strikes me as being arbitrarily restricted.

It should be easy to mimic single-xt + immediate flag behavior within a
dual word framework and one can keep programming within that model. The
dual word approach expands the possible behavior of words while also
allowing for precision in determining the expected behavior. The
trade-off in implementing the dual word approach is a bit more
complexity, as you have noted. Just because there is complexity under
the hood does not mean you have to use it.

Krishna

On 27/05/2021 05:02, minf...@arcor.de wrote:
> ...
> That has led me back to 'good ole state smartness'. VERY rare are
> situations where this is a problem. On the contrary, my code became
> simpler and shorter and easier to maintain.
>
> Perhaps because I am writing real-world applications, and don't try to create
> a 'theoretically clean and Lispy' Forth.
>

Some things are better left on the drawing board:

https://en.wikipedia.org/wiki/The_Tower_of_Babel_(Bruegel)

Krishna Myneni schrieb am Donnerstag, 27. Mai 2021 um 04:07:25 UTC+2:
> On 5/26/21 2:02 PM, minf...@arcor.de wrote:
> > Anton Ertl schrieb am Mittwoch, 26. Mai 2021 um 19:26:31 UTC+2:
> >> Paul Liles <pauld...@btopenworld.com> writes:
> >>> With the usual disclaimer that I may
> >>> be completely wrong, surely any implementation of NDCS/dual words will
> >>> allow at least *some* words, as identified by their xts, to have separately identifiable
> >>> compilation semantics. So far as I can tell, this would be true of words
> >>> defined with INTERPRET/COMPILE in Gforth
> >> In Gforth, a named word (such as the words defined with
> >> INTERPRET/COMPILE:) is identified by the nt, and a word defined with
> >> interpret/compile: has interpretation semantics identified by an xt,
> >> and compilation semantics identified by (normally) a pair of xts.
> >>
> >> Example:
> >>
> >> : int-sem ." interpretation semantics" ;
> >> : comp-sem ." compilation semantics" ;
> >> ' int-sem ' comp-sem interpret/compile: dual-word
> >> dual-word \ output: interpretation semantics
> >> ] dual-word [ \ output: compilation semantics
> >> ``dual-word \ get the nt of DUAL-WORD
> >> dup name>interpret smart. \ output: `int-sem (the xt of int-sem)
> >> name>compile ... \ output: <2> `comp-sem `execute
> >> ' dual-word smart. \ output: `int-sem
> >>
> >> A note on syntax and some relatively unknown words:
> >>
> >> ``<word> produces the nt of <word> (using a recognizer)
> >> `<word> produces the xt for the interpretation semantics of <word>
> >> smart. prints a cell in a smart way (e.g. an xt using `<word> syntax)
> >> ... smart variant of .S
> >>
> >> So you see that ticking DUAL-WORD produces the same xt as ticking
> >> INT-SEM, so this xt does not identify DUAL-WORD. You also see that
> >> the compilation semantics of DUAL-WORD is represented by two xts, none
> >> of which is the xt that you get by ticking DUAL-WORD. And you see
> >> that you can get from the nt of DUAL-WORD to both the interpretation
> >> and compilation semantics.
> >
> > OMG .. convoluted constructs require convoluted introspection and complex
> > header & search structures.
> >
> > That has led me back to 'good ole state smartness'. VERY rare are
> > situations where this is a problem. On the contrary, my code became
> > simpler and shorter and easier to maintain.
> >
> > Perhaps because I am writing real-world applications, and don't try to create
> > a 'theoretically clean and Lispy' Forth.
> >
>
> It should be easy to mimic single-xt + immediate flag behavior within a
> dual word framework and one can keep programming within that model. The
> dual word approach expands the possible behavior of words while also
> allowing for precision in determining the expected behavior. The
> trade-off in implementing the dual word approach is a bit more
> complexity, as you have noted. Just because there is complexity under
> the hood does not mean you have to use it.

Why that hassle? Just avoid making state-changing words.
Or make it two words, like CHAR and [CHAR] or ' and ['].

"minf...@arcor.de" <minforth@arcor.de> writes:
>Or make it two words, like CHAR and [CHAR] or ' and ['].

Yes, that's certainly a good way to avoid the pitfalls of
STATE-smartness (and while you may have avoided them, I fell into
them).

Or, for the cases like the above, another alternative is recognizing
'c' and `<word>.

But there is the lure of cutting and pasting code from compiled to
interpreted code. The two-word approach does not allow that; the
recognizer approach allows it, but does not cover stuff like IF
.... THEN or [: ... ;]. And that's where people who complain about
theoretical cleanliness venture into the practical dirtyness of
STATE-smartness or broken COMPILE,.

IMO Forth implementors should make a decision between

1) Single-xt-with-immediate-flag system with IF and [IF], [: and
:NONAME, and (without the corresponding recognizer) with ' and ['].

2) A system that implements independent interpretation and compilation
semantics.

- 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

Anton Ertl schrieb am Donnerstag, 27. Mai 2021 um 10:48:59 UTC+2:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >Or make it two words, like CHAR and [CHAR] or ' and ['].
> Yes, that's certainly a good way to avoid the pitfalls of
> STATE-smartness (and while you may have avoided them, I fell into
> them).
>
> Or, for the cases like the above, another alternative is recognizing
> 'c' and `<word>.
>
> But there is the lure of cutting and pasting code from compiled to
> interpreted code. The two-word approach does not allow that; the
> recognizer approach allows it, but does not cover stuff like IF
> ... THEN or [: ... ;]. And that's where people who complain about
> theoretical cleanliness venture into the practical dirtyness of
> STATE-smartness or broken COMPILE,.
>
> IMO Forth implementors should make a decision between
>
> 1) Single-xt-with-immediate-flag system with IF and [IF], [: and
> :NONAME, and (without the corresponding recognizer) with ' and ['].
>
> 2) A system that implements independent interpretation and compilation
> semantics.
>
> - 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

Anton Ertl schrieb am Donnerstag, 27. Mai 2021 um 10:48:59 UTC+2:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >Or make it two words, like CHAR and [CHAR] or ' and ['].
> Yes, that's certainly a good way to avoid the pitfalls of
> STATE-smartness (and while you may have avoided them, I fell into
> them).
>
> Or, for the cases like the above, another alternative is recognizing
> 'c' and `<word>.
>
> But there is the lure of cutting and pasting code from compiled to
> interpreted code. The two-word approach does not allow that; the
> recognizer approach allows it, but does not cover stuff like IF
> ... THEN or [: ... ;].

Just don't do such crazy things.

> And that's where people who complain about
> theoretical cleanliness venture into the practical dirtyness of
> STATE-smartness or broken COMPILE,.
>
> IMO Forth implementors should make a decision between
>
> 1) Single-xt-with-immediate-flag system with IF and [IF], [: and
> :NONAME, and (without the corresponding recognizer) with ' and ['].
>
> 2) A system that implements independent interpretation and compilation
> semantics.

Add to this the different requirements for fat interactive desktop Forths
and small eg embedded Forths.

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

Implementers of 200x will follow whatever the two vendors and professor
on the TC can agree constitutes a Standard Forth implementation.

On 2021-05-23 18:00, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-05-17 18:36, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> writes:
>> [...]
>>
>>
>> Interpretation semantics (IS) for the words:
>> "COMPILE,", "CS-PICK", "CS-ROLL", "(LOCAL)"
>> are undefined by the standard, execution semantics (ES) are defined.
>>
>> It's obvious that their execution semantics make sense only when the
>> current definition exists (i.e. some definition is being defined/compiled).
>>
>> But the current definition can exist in interpretation state too, e.g.:
>>
>> : bar [: ." (ABC)" ;] compile, ." (ABC compiled)" ; immediate
>> : foo [ ' bar compile, ] ;
>>
>> And in these conditions their ES (and then the default IS) make sense.
>
> Yes.
>
>> Furthermore, the current definition can be absent in compilation state:
>>
>> ] bar [
>>
>> And in these conditions their ES don't make sense.
>
> Yes.
>
>> So, if the default IS for them make sense in some cases, and without
A typo is corrected: "ES" is replaced by "IS" in the line above.

>> additional efforts in implementation, what is the rationale to declare
>> IS for them undefined? (see (1) bellow)
>
> I don't think they gave a rationale.
>
> My guess is that they undefined the interpretation semantics for they
> kinds of words that would have gotten the C attribute in Forth-83;

It's very reasonable and convincing!

I dimly remember that I even read some similar rationale somewhere, but
I cannot find the source now. Perhaps it was in some of your past messages.

In Forth-83 the following words (from the normative parts) have "C" flag
but don't have "I" flag:

1.
<MARK
<RESOLVE
>MARK
>RESOLVE
?BRANCH
BRANCH
2.
COMPILE
3.
EXIT
I
J
K
>R
R>
R@

I broke them up into tree groups.

Any word X from the group 1 can be simply redefined as : X X ;
The words from other groups cannot be redefined in this way.

When the execution semantics (ES) of a word from the groups 1 or 2 are
performed, the current definition should exist. But it doesn't matter
for the words from the group 3.

The ES for a word from the groups 2 or 3 should not be performed
directly (via "EXECUTE" or interpretively), but they may be only
performed in the frame of the ES of another definition (to which they
were appended).

So any word that appends some semantics (or controls code generation),
or should not be directly performed, — is marked with "C" attribute in
Forth-83.

Obviously, the words "COMPILE,", "CS-PICK", "CS-ROLL", "(LOCAL)" belong
to the group 1.

> but that attribute is not clearly defined (or maybe I have to learn a lot
> more about Forth-83 to know what it means).

Some excerpts from Forth-79 are following.

Attributes
Capitalized symbols indicate attributes of the defined words:

C The word may only be used during compilation of a colon
definition.

I Indicates that the word is IMMEDIATE and will execute
during compilation, unless special action is taken.

General error conditions:
5. interpretation of words restricted to compilation.

Some excerpts from Forth-83 are following.

11.4 Attributes
Capitalized symbols indicate attributes of the defined words:

C The word may only be used during compilation of a colon
definition.

I Indicates that the word is IMMEDIATE and will execute during
compilation, unless special action is taken.

10.2 General Error Conditions
5. execution of words restricted to compilation only, when not
in the compile state and while not compiling a colon
definition;

The wording in these parts is not enough precise to be unambiguously
understood easily. But the most consistent interpretation is as follows:

- "use of a word" means that the word is encountered by the Forth text
interpreter;
- "execution of a word" means performing of the execution semantics
for this word.

It means that both examples above (the definition of "foo" and the use
of "bar") are explicitly not compliant with Forth-83.

Also, it means that Forth-83 implies a general rule similar to A99-027
as a consequence of the normative parts.

One problem is that the error condition 5 should not be applicable to
the words in the group 3. It looks like a flaw in the terminology and/or
wording in Forth-83.

> And thinking more about it, it's probably an ill-thought-out way to
> protect programmers from using these words wrongly.

If it's true, then I don't think this way of protection was invented by
Forth-83. More probably that it was in practice before Forth-83, and
Forth-83 had introduced the corresponding restrictions on programs to
achieve better portability only.

[...]
>>> I don't see it. Which concessions to which existing implementations
>>> do you mean? These four words were new in Forth-94.
>>
>> By a concession I mean relaxing of an implementation. I.e., undefined
>> interpretation semantics for these words is a concession to the
>> implementers (I just don't sure that it's demanded).
>
> By "concession to existing implementations" I understand that there
> existed (at the time) at least one implementation that either
>
> 1) implemented one of these words (maybe under a different name) and
> had such a limitation.
>
> 2) Would have had difficulty implementing these words unless the
> limitation was in place.
>
> And my question was whether you can name a system for which the
> standard made these consessions for one of these reasons. If you
> cannot, then I think we should lay the "concession" speculation to
> rest.

I agree.

It could look like a concession, but I don't know such a system, and so
I asked, whether somebody knows.

So, if it isn't a concession, then it should be a consequence of a
general rule (to have some sense).

And it seems, we have found this rule: the attribute "C" and the error
condition 5 in Forth-83.

By this rule "COMPILE," cannot "be executed during interpretation" (as
A.6.2.0945 says).

[...]

--
Ruvim

On Wed, 26 May 2021 11:10:48 +1000, dxforth <dxforth@gmail.com> wrote:

>> What position of MPE are you talking about?
>
>>> > : bar [: ." (ABC)" ;] compile, ." (ABC compiled)" ; immediate
>>> > : foo [ ' bar compile, ] ;

I suspect that there are two issues you are complaining about
1) Quotations required Examples/quotations.fth to be loaded
2) Compilation of FOO above barfed.

Item 1) is fixed in the now-released VFX Forth 5.2 which contains
quotations using [: ... ;] in the kernel and in the manual.

Item 2) is fixed by making COMPILE, handle NDCS words which
(according to Anton) it should not have to do.

As with many things in VFX, the practice of making users happy
or happier predominated over theory.

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

Stephen

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

In article <s8qc4o$3k4$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
<SNIP>
>Some excerpts from Forth-79 are following.
>
> Attributes
> Capitalized symbols indicate attributes of the defined words:
>
> C The word may only be used during compilation of a colon
> definition.

Note how that is better then demanding that STATE is set to compiling.
Interpreting a compiling word while a colon definition is being built
is explicitly okay making
[ 'IF EXECUTE ]
equivalent to
IF

Or
[ POSTPONE IF ]
if you believe that compiling words cannot be executed.

>
> I Indicates that the word is IMMEDIATE and will execute
> during compilation, unless special action is taken.
>
<SNIP>
>--
>Ruvim

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

On Friday, May 28, 2021 at 10:54:38 AM UTC+1, Stephen Pelc wrote:

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

I would certainly support that approach. I have spent way too
much time over the last few weeks shuffling NDCS logic between
COMPILE, NAME>COMPILE and the text interpreter, depending
whose post I last read and paid attention to. It works fine
wherever I put it, but on balance COMPILE, feels like its natural
home and is the easier to document and explain.

On 2021-05-28 13:25, albert wrote:
> In article <s8qc4o$3k4$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
> <SNIP>
>> Some excerpts from Forth-79 are following.
>>
>> Attributes
>> Capitalized symbols indicate attributes of the defined words:
>>
>> C The word may only be used during compilation of a colon
>> definition.
>
> Note how that is better then demanding that STATE is set to compiling.

The terminology of Forth-94 is far better.

> Interpreting a compiling word while a colon definition is being built
> is explicitly okay making
> [ 'IF EXECUTE ]
> equivalent to
> IF

This is not backward compatible, and it's excludes the expected
interpretation semantics for "IF".

E.g.:

[ some-test IF 'X ELSE 'Y THEN COMPILE, ]

>
> Or
> [ POSTPONE IF ]

This is good. Since the most consistent (and so expected) interpretation
semantics for "POSTPONE" is to perform the compilation semantics for the
word in the argument.

> if you believe that compiling words cannot be executed.
>

--
Ruvim

On 2021-05-28 12:54, Stephen Pelc wrote:
[...]
> As with many things in VFX, the practice of making users happy
> or happier predominated over theory.
>
> Given the presence of systems that handle NDCS words, (VFX and
> gForth) it would appear that relaxing the constraints on COMPILE,
> (stack effects and parsing) would be a sensible approach.

Why don't propose just another word?

At the moment, "COMPILE," is equivalent to " LIT, POSTPONE EXECUTE ".

You suggest to break this very basic equivalence.

In opposite, I would suggest to make this equivalence stronger.

> For the vast majority of users, this is the minimal approach.
>

--
Ruvim