State smart dot quote

[John A Peters]

." tripped me up as a beginner in Forth and again, just now. Why not make ." an immediate word in addition to a compiled word. Instead we have to use .( when in immediate context.

I am not a programer, just a user so I may be out of my league but it seams like good if non standard icea.

Thoughts?

[dxforth]

Forth-79's ." was state-smart. Forth-83 considered it evil and removed it
for the sake of beginners. 'dual-xt' was the next generation of state-smart
words. It added a level of separation in the hope nobody would encounter
code that broke it.

[Bruce McFarling]

On Wednesday, September 16, 2020 at 10:27:04 AM UTC+8, John A Peters wrote:
> ." tripped me up as a beginner in Forth and again, just now. Why not make ." an immediate word in addition to a compiled word. Instead we have to use .( when in immediate context.

> I am not a programer, just a user so I may be out of my league but it seams like good if non standard icea.

In my eForth port, ." IS immediate ... it is also compile-only, because what it DOES immediately is compile the runtime that prints and then skips past a string, and then embeds the string in the definition. Doing that in interpret mode wouldn't be very useful. The operation it calls that parses and embeds a string in a definition is not COMPILE-ONLY however, as it can be useful with a CREATEd word.

If you mean, why not make a different interpret mode word that has a similar effect and access both under the same name, like S" ... well, as you can see from the fact that the two rather ad hoc Forth79 and Forth83 "standards" took opposite sides on the debate, that's a debatable thing. Having S" do it that way was certainly hotly debated.

If it really annoys you, the standard specification of the word leaves the interpretation semantics undefined, so it was the implementer of your Forth who decided to not make it state smart. I presume if you avoid the sharp corners where state smartedness causes issues, you might try:

: ." ( "ccc<quote>" -- ) STATE @ IF POSTPONE ." ELSE POSTPONE .( THEN ; IMMEDIATE

As far as where the sharp corners where state smartedness runs into issues, there are much smarter people than me who can elaborate on that at length.

Virtually,
Bruce McFarling, Beijing

[none albert]

In article <21f88ca5-fe3b-48ec...@googlegroups.com>,

I took a different stand. Allowing numbers to be state smart, we extend that
notion to all sort of constants. So we want to have
"AAAP"
that generates a string in interpret mode and compiles a string in compile
mode.
We also want
{ saklsaksl akslsakl }
that generates an anonymous function in interpret mode, and compiles
that xt in compile mode. (No more :NONAME and no different notation
in compilation mode for anonumous functions "lambda's" . )

The bottom line is that both .( and ." are superfluous and that you want
to do
"we gaan naar Rome" TYPE
in both interpret and compilation mode, and get over it.

>
>Virtually,
>Bruce McFarling, Beijing

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

[Anton Ertl]

Bruce McFarling <bruce.m...@gmail.com> writes:
>On Wednesday, September 16, 2020 at 10:27:04 AM UTC+8, John A Peters wrote:

>> ." tripped me up as a beginner in Forth and again, just now. Why not make=
> ." an immediate word in addition to a compiled word. Instead we have to us=
>e .( when in immediate context.=20
>=20
>> I am not a programer, just a user so I may be out of my league but it sea=
>ms like good if non standard icea.=20

The STATE-smartness discussion has been going on since before
Forth-83, and Forth-83 answered it by standardizing ." and .(.
Forth-94 kept this. If you want to know why, you can find the long
answer in

<http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz>

There you also find how to implement a dual (not STATE-smar) ."

>If it really annoys you, the standard specification of the word leaves the =
>interpretation semantics undefined, so it was the implementer of your Forth=
> who decided to not make it state smart. I presume if you avoid the sharp c=

>orners where state smartedness causes issues, you might try:
>

>: ." ( "ccc<quote>" -- ) STATE @ IF POSTPONE ." ELSE POSTPONE .( THEN ; IMM=
>EDIATE
>
>As far as where the sharp corners where state smartedness runs into issues,=

> there are much smarter people than me who can elaborate on that at length.

This is not a correct implementation of .", because this definition
has STATE-smart compilation semantics. E.g.:

: my-." postpone ." ; immediate
: foo [ my-." hi" ] ; \ must not print anything
foo \ prints "hi"

Let's see how various systems perform:

[~:116820] gforth
Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
: my-." postpone ." ; immediate ok
: foo [ my-." hi" ] ; \ must not print anything ok
foo \ prints "hi" hi ok

[~:116821] sf
SwiftForth i386-Linux 3.6.3 29-Jun-2016
: my-." postpone ." ; immediate ok
: foo [ my-." hi" ] ; \ must not print anything ok
foo \ prints "hi" hi ok

[~:116822] iforth

FORTH> : my-." postpone ." ; immediate ok
FORTH> : foo [ my-." hi" ] ; \ must not print anything ok
FORTH> foo \ prints "hi" hi ok
FORTH> bye
[~:116823] vfxlin
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
: my-." postpone ." ; immediate ok
: foo [ my-." hi" ] ; \ must not print anything ok
foo \ prints "hi" hi ok

They all work correctly. Let's see how your ." performs:

Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit : ." ( "ccc<quote>" -- ) STATE @ IF POSTPONE ." ELSE POSTPONE .( THEN ; IMMEDIATE redefined ." ok
: my-." postpone ." ; immediate ok
: foo [ my-." hi" ] ; \ must not print anything hi" ] ; \ must not print anything ok
foo \ prints "hi"
:4: Undefined word
>>>foo<<< \ prints "hi"

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

albert@cherry.(none) (albert) writes:
>I took a different stand. Allowing numbers to be state smart, we extend that
>notion to all sort of constants. So we want to have
> "AAAP"
>that generates a string in interpret mode and compiles a string in compile
>mode.

Speak for yourself. I do not want a STATE-smart "AAAP". Instead, it
should be equivalent to

: "AAAP" S" AAAP" ;

(while a STATE-smart "AAAP" would look as follows:

: "AAAP" s" AAAP" state @ if postpone sliteral then ; immediate
)

The difference shows up in

: comp-"AAAP" POSTPONE "AAAP" ;
: foo [ comp-"AAAP" ] type ;
foo \ should print "AAAP"

Let's see what the different versions do:

Plain colon definition:

Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit

: "AAAP" S" AAAP" ; ok
: comp-"AAAP" POSTPONE "AAAP" ; ok
: foo [ comp-"AAAP" ] type ; ok
foo \ should print "AAAP" AAAP ok

STATE-smart colon definition:

: "AAAP" s" AAAP" state @ if postpone sliteral then ; immediate ok
: comp-"AAAP" POSTPONE "AAAP" ; ok
: foo [ comp-"AAAP" ] type ;
:3: unstructured
: foo [ comp-"AAAP" ] type >>>;<<<

Using Gforths string recognizer:

Gforth 0.7.9_20200827
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
: comp-"AAAP" POSTPONE "AAAP" ; ok
: foo [ comp-"AAAP" ] type ; ok
foo \ should print "AAAP" AAAP ok

So the string recognizer behaves like the plain colon definition, as
it should.

[none albert]

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

Part of my master plan is to get rid of POSTPONE.
Even if that is tedious at times, it is less error prone and less
opaque. POSTPONE may make some actions portable but for me the
price is too high.

I don't agree that literal denotations should behave like plain
colon definitions.

>
>- anton

[Brian Fox]

If you have no aversion to state-smart words I did this in my kernel.

: ." ( ccc" -- )
POSTPONE S"
STATE @
IF POSTPONE TYPE
ELSE TYPE
THEN ; IMMEDIATE

[dxforth]

Provided it's not VFX or GForth as POSTPONE S" won't work on those systems.
So much for 'idiot-proof' dual-xt words.

[Anton Ertl]

POSTPONE S" works in Gforth as specified in FORTH-94/2012. Brian
Fox's code apparently expects a non-standard S".

[Bruce McFarling]

On Wednesday, September 16, 2020 at 6:05:45 PM UTC+8, Bruce McFarling wrote:
> On Wednesday, September 16, 2020 at 10:27:04 AM UTC+8, John A Peters wrote:
> > ." tripped me up as a beginner in Forth and again, just now. Why not make ." an immediate word in addition to a compiled word. Instead we have to use .( when in immediate context.

> > I am not a programer, just a user so I may be out of my league but it seams like good if non standard idea.

> In my eForth port, ." IS immediate ... it is also compile-only, because what it DOES immediately is compile the runtime that prints and then skips past a string, and then embeds the string in the definition. Doing that in interpret mode wouldn't be very useful. The operation it calls that parses and embeds a string in a definition is not COMPILE-ONLY however, as it can be useful with a CREATEd word.

> If you mean, why not make a different interpret mode word that has a similar effect and access both under the same name, like S" ... well, as you can see from the fact that the two rather ad hoc Forth79 and Forth83 "standards" took opposite sides on the debate, that's a debatable thing. Having S" do it that way was certainly hotly debated.

> If it really annoys you, the standard specification of the word leaves the interpretation semantics undefined, so it was the implementer of your Forth who decided to not make it state smart. I presume if you avoid the sharp corners where state smartedness causes issues, you might try:

> : ." ( "ccc<quote>" -- ) STATE @ IF POSTPONE ." ELSE POSTPONE .( THEN ; IMMEDIATE

Don't post in a hurry before going to class, obviously the delimiter there is wrong, it's more like:
: int-." ( "ccc<quote>" -- ) [CHAR] " PARSE TYPE ;
: ." ( "ccc<quote>" -- ) STATE @ IF POSTPONE ." ELSE int-." THEN ; IMMEDIATE

> As far as where the sharp corners where state smartedness runs into issues, there are much smarter people than me who can elaborate on that at length.

Fortunately not only "can" but "did".

If you used to other interpreted languages, where if they are compiled, they try to do it "behind your back" and if they succeed call that "transparent" compilation, don't forget that you are explicitly calling the compiler into action when you ":". It is more ACTUALLY transparent, in that the program is not blind to the compilation process, but is explicitly stating what is going

So it might "feel like" interpret mode and compile mode ." that type the string are doing the same thing, but they really ARE NOT: one is parsing a string and then typing it at the same time, the other is compiling a string handler and parsing a string and embedding it in the compiled word so that the string is typed later.

Doing those tasks with separate words is more natural in Forth, because they ACTUALLY do different things. One makes your scripts talk when you load them. The other makes your words talk when you execute them.

Virtually,

[dxforth]

On 17/09/2020 01:52, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>> On 17/09/2020 00:16, Brian Fox wrote:
>>> If you have no aversion to state-smart words I did this in my kernel.
>>>
>>> : ." ( ccc" -- )
>>> POSTPONE S"
>>> STATE @
>>> IF POSTPONE TYPE
>>> ELSE TYPE
>>> THEN ; IMMEDIATE
>>
>> Provided it's not VFX or GForth as POSTPONE S" won't work on those systems.
>
> POSTPONE S" works in Gforth as specified in FORTH-94/2012. Brian
> Fox's code apparently expects a non-standard S".

Since when is start-smart S" non-standard?

Unfortunate is the Standard that must support two incompatible systems of
state-smartness; expecting users to be sufficiently aware of the pecadillos
of each so as to avoid writing code that will break. So how did Forth-94
get here? As with integer division, nowhere near enough forthers found
Forth-83's state-smart schtick sufficiently compelling to do something
about it.

[Brian Fox]

On 2020-09-16 11:52 AM, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>> On 17/09/2020 00:16, Brian Fox wrote:
>>> If you have no aversion to state-smart words I did this in my kernel.
>>>
>>> : ." ( ccc" -- )
>>> POSTPONE S"
>>> STATE @
>>> IF POSTPONE TYPE
>>> ELSE TYPE
>>> THEN ; IMMEDIATE
>>
>> Provided it's not VFX or GForth as POSTPONE S" won't work on those systems.
>
> POSTPONE S" works in Gforth as specified in FORTH-94/2012. Brian
> Fox's code apparently expects a non-standard S".
>
> - anton
>

Mea culpa. I forgot to mention that.
I went all in on state smartness with S" and ."
It is much easier to use for the casual user that I was trying to
get to try Forth. Sadly it didn't make any difference to the target
audience.
:-)
BASIC is just too easy to grasp.

[Bruce McFarling]

An implementation standard like Forth83 only has to worry about how state smart words work if defined as defined and executed in a Forth complying with the implementation. No 32bit Forth and no native subroutine threaded Forth could comply with the Forth83 standard, so that benefit was immaterial to them.

Specifying word behavior so the same source could be run on different implementations was itself a new practice, intrinsically, because any given implementation only has to specify how a word behaves when it executes on it's own behavior. In retrospect, if the "file string" buffered interpreted string had been FS" and S" had only ever been given a compiler behavior, that seems like it would have avoided issues that we can recall being pointed out and discussed in the late 90s in this newsgroup.

These kinds of things are unsurprising in a consensus driven industrial standardization process ... it's why we went from Mini-USB to Micro-USB following analysis of the issue of repeated insertions leading to connection failures.

Virtually,
Bruce McFarling, Beijing

[dxforth]

On 17/09/2020 14:47, Bruce McFarling wrote:
> On Thursday, September 17, 2020 at 10:33:57 AM UTC+8, dxforth wrote:
>> On 17/09/2020 01:52, Anton Ertl wrote:
>>> dxforth <dxf...@gmail.com> writes:
>>>> On 17/09/2020 00:16, Brian Fox wrote:
>>>>> If you have no aversion to state-smart words I did this in my kernel.
>>>>>
>>>>> : ." ( ccc" -- )
>>>>> POSTPONE S"
>>>>> STATE @
>>>>> IF POSTPONE TYPE
>>>>> ELSE TYPE
>>>>> THEN ; IMMEDIATE
>>>>
>>>> Provided it's not VFX or GForth as POSTPONE S" won't work on those systems.
>>>
>>> POSTPONE S" works in Gforth as specified in FORTH-94/2012. Brian
>>> Fox's code apparently expects a non-standard S".
>> Since when is start-smart S" non-standard?
>
>> Unfortunate is the Standard that must support two incompatible systems of
>> state-smartness; expecting users to be sufficiently aware of the pecadillos
>> of each so as to avoid writing code that will break. So how did Forth-94
>> get here? As with integer division, nowhere near enough forthers found
>> Forth-83's state-smart schtick sufficiently compelling to do something
>> about it.
>
> An implementation standard like Forth83 only has to worry about how state smart words work if defined as defined and executed in a Forth complying with the implementation. No 32bit Forth and no native subroutine threaded Forth could comply with the Forth83 standard, so that benefit was immaterial to them.
>

If you're saying Forth-94 found itself in a position of needing to please
everybody and failed, then I agree. It's why there's a 200x and lobbyists
distributing 'state-smart is evil' pamphlets. What Forth has is politics -
not a Standard. Moore refused to vote. His principles weren't up for sale.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>Since when is start-smart S" non-standard?

STATE-smart S" has never been standard.

[Anton Ertl]

Brian Fox <bria...@rogers.com> writes:
>I went all in on state smartness with S" and ."
>It is much easier to use for the casual user that I was trying to
>get to try Forth.

I doubt it. Look at this:

[~:116853] gforth

Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit

cr ." bla"
bla ok
: foo ." bla" ; cr foo
bla ok

Note that this ." is not STATE-smart. Do you think it is harder to
use than your STATE-smart ." ? Here's the current definition:

:noname '"' parse type ;
:noname '"' parse postpone SLiteral postpone type ;
interpret/compile: ." ( compilation 'ccc"' -- ; run-time -- ) \ core dot-quote

[Anton Ertl]

Bruce McFarling <bruce.m...@gmail.com> writes:
>An implementation standard like Forth83 only has to worry about how state s=
>mart words work if defined as defined and executed in a Forth complying wit=
>h the implementation. No 32bit Forth and no native subroutine threaded For=
>th could comply with the Forth83 standard, so that benefit was immaterial t=
>o them.

Forth-83 is an interface standard, like Forth-94. Are you confusing
it with F83 (Laxen&Perry's implementation of Forth-83)?

Forth-83 standardizes 16-bit addresses, so yes, a 32-bit system is not
Forth-83 compliant. Despite repeated claims to the contrary, Forth-83
does not standardize the execution mechanism. Native code and
subroutine-threaded code are Forth-83 compliant AFAICS.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>If you're saying Forth-94 found itself in a position of needing to please
>everybody and failed, then I agree. It's why there's a 200x

Forth-200x is there because Forth-2012 is not the be-all and end-all
of Forth. Forth-2012 is there because Forth-94 is not the be-all and
end-all of Forth. Like Forth-94 and Forth-2012, the Forth-200x work
since Forth-2012 is backwards compatible.

>and lobbyists
>distributing 'state-smart is evil' pamphlets.

Wow, some big political interest group has paid me big bucks for
writing that paper. I wish:-)

> Moore refused to vote. His principles weren't up for sale.

Chuck Moore does not need a Forth standard. He writes his own Forth
system and his own Forth programs to run on these systems, and does
not care much what other people do.

Concerning STATE-smartness, that was eliminated in polyForth while
Chuck Moore was at Forth, Inc., he then had no STATE in cmForth, and
AFAIK he did not reintroduce STATE in any of his later Forth systems.

[dxforth]

On 17/09/2020 17:57, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>> Since when is start-smart S" non-standard?
>
> STATE-smart S" has never been standard.

Meaning what - that it's illegal to implement a state-smart S"
under Forth-94?

[Anton Ertl]

A user can implement a STATE-smart S" on top of a Forth-94 system,
just like he can implement

: + * ;

In both cases the result will be a non-standard system.

A system that implements S" as STATE-smart word is non-standard.

[A. K.]

Am Donnerstag, 17. September 2020 12:53:20 UTC+2 schrieb Anton Ertl:
> dxforth <dxf...@gmail.com> writes:
> >On 17/09/2020 17:57, Anton Ertl wrote:
> >> dxforth <dxf...@gmail.com> writes:
> >>> Since when is start-smart S" non-standard?
> >>
> >> STATE-smart S" has never been standard.
> >
> >Meaning what - that it's illegal to implement a state-smart S"
> >under Forth-94?
>
> A user can implement a STATE-smart S" on top of a Forth-94 system,
> just like he can implement
>
> : + * ;
>
> In both cases the result will be a non-standard system.
>
> A system that implements S" as STATE-smart word is non-standard.
>

Your own zealous over-interpretation. It is UB.

6.1.2165 S" “s-quote” CORE
Interpretation: Interpretation semantics for this word are undefined.

[Anton Ertl]

"A. K." <minf...@arcor.de> writes:
>Am Donnerstag, 17. September 2020 12:53:20 UTC+2 schrieb Anton Ertl:
>> A system that implements S" as STATE-smart word is non-standard.

>>=20

>
>Your own zealous over-interpretation. It is UB.
>

>6.1.2165 S" =E2=80=9Cs-quote=E2=80=9D CORE

>Interpretation: Interpretation semantics for this word are undefined.

This does not make a STATE-smart S" standard.

And actually the point of STATE-smart S" is to approximate
11.6.1.2165, which defines interpretation semantics for S".

[dxforth]

On 17/09/2020 18:12, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>> If you're saying Forth-94 found itself in a position of needing to please
>> everybody and failed, then I agree. It's why there's a 200x
>
> Forth-200x is there because Forth-2012 is not the be-all and end-all
> of Forth. Forth-2012 is there because Forth-94 is not the be-all and
> end-all of Forth. Like Forth-94 and Forth-2012, the Forth-200x work
> since Forth-2012 is backwards compatible.
>
>> and lobbyists
>> distributing 'state-smart is evil' pamphlets.
>
> Wow, some big political interest group has paid me big bucks for
> writing that paper. I wish:-)

Had it been useful code that everyone could use, the result might
have been different :)

>
>> Moore refused to vote. His principles weren't up for sale.
>
> Chuck Moore does not need a Forth standard.

To anyone who asks, he appears to tell them they don't need a Standard
either.

> He writes his own Forth
> system and his own Forth programs to run on these systems, and does
> not care much what other people do.
>
> Concerning STATE-smartness, that was eliminated in polyForth while
> Chuck Moore was at Forth, Inc., he then had no STATE in cmForth, and
> AFAIK he did not reintroduce STATE in any of his later Forth systems.

I'm sure there are many things Moore hasn't done, nor imagine him doing.
Such as setting up a Fig-style bureaucracy with himself as head waiting
for petitioners to come forward cap in hand to beg an audience, only to
be told: 'We've discussed this with other TC members and don't feel
there's much possibility of it passing'. Moore wouldn't play this game
and I don't see why anyone else should.

[none albert]

In article <2020Sep1...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

>dxforth <dxf...@gmail.com> writes:
>>On 17/09/2020 17:57, Anton Ertl wrote:
>>> dxforth <dxf...@gmail.com> writes:
>>>> Since when is start-smart S" non-standard?
>>>
>>> STATE-smart S" has never been standard.
>>
>>Meaning what - that it's illegal to implement a state-smart S"
>>under Forth-94?
>
>A user can implement a STATE-smart S" on top of a Forth-94 system,
>just like he can implement
>
>: + * ;
>
>In both cases the result will be a non-standard system.

I don't think that where IF has undefined interpretation behaviour,
that if I add that I get a non-standard system. This behaviour cannot
be used in a standard program, but standard programs run as before.

For example in the following an interpreted DO LOOP is used
to create a table at compile time.
Of course the following code is not standard,
but it must be considered as part of the Forth implementation,
and the resulting system is still standard.
----------------------
( CRC-MORE CRC ) CF: \ AvdH
1 CELLS 4 < ?LEAVE-BLOCK
"BOUNDS" WANTED "NEW-IF" WANTED HEX
\ Well the polynomial
EDB8,8320 CONSTANT CRC32_POLYNOMIAL
\ Auxiliary table with values for single bytes.
CREATE CRCTable
100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC32_POLYNOMIAL XOR THEN
LOOP , LOOP
\ For initial CRC and BUFFER COUNT pair, leave the updated CRC
: CRC-MORE BOUNDS DO DUP I C@ XOR 0FF AND CELLS CRCTable + @
SWAP 8 RSHIFT XOR LOOP ;
\ For BUFFER COUNT pair, leave the CRC .
: CRC -1 ROT ROT CRC-MORE INVERT ;
----------------------

>
>A system that implements S" as STATE-smart word is non-standard.

No need to have S" in a kernel. So I guess a good solution is to
supply S" as a loadable extension and require the user to sign
an eula if it happens to be STATE-smart.

[dxforth]

On 17/09/2020 20:45, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>> On 17/09/2020 17:57, Anton Ertl wrote:
>>> dxforth <dxf...@gmail.com> writes:
>>>> Since when is start-smart S" non-standard?
>>>
>>> STATE-smart S" has never been standard.
>>
>> Meaning what - that it's illegal to implement a state-smart S"
>> under Forth-94?
>
> A user can implement a STATE-smart S" on top of a Forth-94 system,
> just like he can implement
>
> : + * ;
>
> In both cases the result will be a non-standard system.
>
> A system that implements S" as STATE-smart word is non-standard.

You're challenging Forth Inc? That'll be an interesting fight.

[Brian Fox]

On 2020-09-17 3:59 AM, Anton Ertl wrote:
> Brian Fox <bria...@rogers.com> writes:
>> I went all in on state smartness with S" and ."
>> It is much easier to use for the casual user that I was trying to
>> get to try Forth.
>
> I doubt it. Look at this:
>
> [~:116853] gforth
> Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> cr ." bla"
> bla ok
> : foo ." bla" ; cr foo
> bla ok
>
> Note that this ." is not STATE-smart. Do you think it is harder to
> use than your STATE-smart ." ? Here's the current definition:
>
> :noname '"' parse type ;
> :noname '"' parse postpone SLiteral postpone type ;
> interpret/compile: ." ( compilation 'ccc"' -- ; run-time -- ) \ core dot-quote
>
> - anton
>

That looks nice.

From the perspective of BASIC hobbyists, that I and others have to
tried to convince, Forth is just too hard.

So it is probably moot which version is simpler for my original
"evangelistic" goal. I gave that up.

What is the definition of INTERPET/COMPILE:
Looks like a way to determine the "state" of the system. ?

[Brian Fox]

On 2020-09-17 3:59 AM, Anton Ertl wrote:

> Brian Fox <bria...@rogers.com> writes:
>> I went all in on state smartness with S" and ."
>> It is much easier to use for the casual user that I was trying to
>> get to try Forth.
>
> I doubt it. Look at this:
>
> [~:116853] gforth
> Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> cr ." bla"
> bla ok
> : foo ." bla" ; cr foo
> bla ok
>
> Note that this ." is not STATE-smart. Do you think it is harder to
> use than your STATE-smart ." ? Here's the current definition:
>
> :noname '"' parse type ;
> :noname '"' parse postpone SLiteral postpone type ;
> interpret/compile: ." ( compilation 'ccc"' -- ; run-time -- ) \ core dot-quote
>
> - anton
>

That looks nice.

From the perspective of BASIC hobbyists, that I and others have to
tried to convince, Forth is just too hard.

So it is probably moot which version is simpler for my original
"evangelistic" goal. I gave that up.

What is the definition of INTERPET/COMPILE:

Looks like a way to determine the "state" of the system when the word is
executed. ?

[Anton Ertl]

Brian Fox <bria...@rogers.com> writes:
>> Note that this ." is not STATE-smart. Do you think it is harder to
>> use than your STATE-smart ." ? Here's the current definition:
>>
>> :noname '"' parse type ;
>> :noname '"' parse postpone SLiteral postpone type ;
>> interpret/compile: ." ( compilation 'ccc"' -- ; run-time -- ) \ core dot-quote

...

>What is the definition of INTERPET/COMPILE:

: i/c>comp ( nt -- xt1 xt2 )
>body cell+ @ ['] execute ;

: interpret/compile: ( interp-xt comp-xt "name" -- ) \ gforth
swap alias ,
['] i/c>comp set->comp
['] no-to set-to
['] no-defer@ set-defer@ ;

If you want to understand how it works, read (or watch or both)

@InProceedings{paysan19,
author = {Bernd Paysan and M. Anton Ertl},
title = {The new {Gforth} Header},
crossref = {euroforth19},
pages = {5--20},
url = {http://www.euroforth.org/ef19/papers/paysan.pdf},
url-slides = {http://www.euroforth.org/ef19/papers/paysan-slides.pdf},
video = {https://wiki.forth-ev.de/doku.php/events:ef2019:header},
OPTnote = {refereed},
abstract = {The new Gforth header is designed to directly
implement the requirements of Forth-94 and
Forth-2012. Every header is an object with a fixed
set of fields (code, parameter, count, name, link)
and methods (\texttt{execute}, \texttt{compile,},
\texttt{(to)}, \texttt{defer@}, \texttt{does},
\texttt{name>interpret}, \texttt{name>compile},
\texttt{name>string}, \texttt{name>link}). The
implementation of each method can be changed
per-word (prototype-based object-oriented
programming). We demonstrate how to use these
features to implement optimization of constants,
\texttt{fvalue}, \texttt{defer}, \texttt{immediate},
\texttt{to} and other dual-semantics words, and
\texttt{synonym}.}
}
@Proceedings{euroforth19,
title = {35th EuroForth Conference},
booktitle = {35th EuroForth Conference},
year = {2019},
key = {EuroForth'19},
url = {http://www.euroforth.org/ef19/papers/proceedings.pdf}

}

>Looks like a way to determine the "state" of the system. ?

It does not determine the state at run-time (unlike STATE-smart
words). Instead, the text interpreter asks the word at text
interpretation time for its interpretation semantics (when
interpreting), or for its compilation semantics (when compiling).

[none albert]

If you want BASIC users to be at ease, just use "NORMAL STRINGS".
They are compatible with upcoming standards, and you can use them
wide and far, before you have to explain anything about parsing the
input stream.

[Anton Ertl]

My impression is that as long as their customers don't complain, they
don't care. When a customer complains, they'll fix it, like MPE has
done. I outlined an alternative approach in
<2017Dec1...@mips.complang.tuwien.ac.at>, but they have not taken
this approach.

[Anton Ertl]

Bruce McFarling <bruce.m...@gmail.com> writes:
>If you used to other interpreted languages, where if they are compiled, the=
>y try to do it "behind your back" and if they succeed call that "transparen=
>t" compilation, don't forget that you are explicitly calling the compiler i=
>nto action when you ":". It is more ACTUALLY transparent, in that the progr=
>am is not blind to the compilation process, but is explicitly stating what =
>is going=20
>
>So it might "feel like" interpret mode and compile mode ." that type the st=
>ring are doing the same thing, but they really ARE NOT: one is parsing a st=
>ring and then typing it at the same time, the other is compiling a string h=
>andler and parsing a string and embedding it in the compiled word so that t=

>he string is typed later.
>

>Doing those tasks with separate words is more natural in Forth, because the=
>y ACTUALLY do different things. One makes your scripts talk when you load t=

>hem. The other makes your words talk when you execute them.

In Forth we have literals and "normal" words like + and . that you can
cut and paste between interpreted and compiled code:

: foo 2 2 + . ;
foo
2 2 + .

Forth has a little complexity in the text interpreter to make this
possible; the text interpreter could be made simpler if it did not
support literals and if even the code above could look different
between compiled and interpreted mode. E.g., the code above could
look like:

: foo cl 2 cl 2 [compile] + [compile] . ;
foo
il 2 il 2 + .

In this example IL is "interpret literal", CL is "compile literal",
[COMPILE] compiles the following word.

Coming back to classical Forth, you have words like IF that just work
in compiled code, and there have been attempts to do something about
that, too, but I won't go into that now.

And there are parsing words like ." and .(. These work like CL and IL
above, and therefore we cannot copy and paste them between interpreted
and compiled code. However, being able to copy-and-paste is a
desirable property, so some systems support interpreted ." . For S"
this has actually been standardized in the file wordset. However,
these words cannot be implemented in the classical
single-xt+immediate-flag systems, so if you want such words, you have
to go beyond this approach; there are many different ways that work
correctly.

An alternative is to treat strings like numbers, and have a string
recognizer (which supports cutting and pasting between interpreted and
compiled code). With that, you don't need S", and you can replace ."
with "<string>" TYPE.

[dxforth]

Wrong version but your first point applies. The rationale for S"
clearly states it was modelled after then existing implementations
of " many of which were state-smart (e.g. LMI). The only question
that concerned '94 was whether S" should return addr/len or counted
string as the practice had been evenly divided. Before indulging
in 'Von Daniken' interpretations, one should examine the whole
picture - which was that Forth-94 bent over backwards to accommodate
existing practice. One may debate the wisdom of it, but not the
intent for which there is overwhelming evidence. It shouldn't
require Carl Sagan to dismiss fanciful 'Chariots of the Gods'
speculations that have flourished on c.l.f. in the last decade.
Is it Forth that's being promoting, or 'Book of Revelations'.

[Bruce McFarling]

On Thursday, September 17, 2020 at 4:11:49 PM UTC+8, Anton Ertl wrote:
> Bruce McFarling <bruce.m...@gmail.com> writes:
> >An implementation standard like Forth83 only has to worry about how state s=
> >mart words work if defined as defined and executed in a Forth complying wit=
> >h the implementation. No 32bit Forth and no native subroutine threaded For=
> >th could comply with the Forth83 standard, so that benefit was immaterial t=
> >o them.
>
> Forth-83 is an interface standard, like Forth-94. Are you confusing
> it with F83 (Laxen&Perry's implementation of Forth-83)?

More likely to be conflating it with Forth-79, which specified the contents of return stack as the address of the word being executed, so a 6502 subroutine threaded Forth was non-compliant,

> Forth-83 standardizes 16-bit addresses, so yes, a 32-bit system is not
> Forth-83 compliant.

Which does render the distinction in many 90s use cases moot, as requiring 16 bit addressing hamstrings a subroutine threaded Forth on a 32 bit processor.

Virtually,
Bruce McFartling, Beijing

[Bruce McFarling]

On Thursday, September 17, 2020 at 3:44:48 PM UTC+8, dxforth wrote:
> If you're saying Forth-94 found itself in a position of needing to please
> everybody and failed, then I agree.

I am saying it failed to be perfect, because it was a real world process, and real world processes cannot deliver perfection.

> It's why there's a 200x and lobbyists
> distributing 'state-smart is evil' pamphlets.

wevs

> What Forth has is politics - not a Standard.

The standards process without politics can deliver imagined perfection, but fantasies don't export to the real world, so they don't deliver real world industrial standards.

> Moore refused to vote. His principles weren't up for sale.

Nobodies' principles were for sale in the process, there was no money changing hands for the vote.

You could more accurately say he refused to compromise his principles. Of cpurse, that was not a hard stand to take, since as the user of Forth's he wrote himself for his own needs, he wasn't going to benefit from compromising.

[Brian Fox]

On 2020-09-17 11:44 AM, Anton Ertl wrote:
> Brian Fox <bria...@rogers.com> writes:
>>> Note that this ." is not STATE-smart. Do you think it is harder to
>>> use than your STATE-smart ." ? Here's the current definition:
>>>
>>> :noname '"' parse type ;
>>> :noname '"' parse postpone SLiteral postpone type ;
>>> interpret/compile: ." ( compilation 'ccc"' -- ; run-time -- ) \ core dot-quote
> ...
>> What is the definition of INTERPET/COMPILE:
>
> : i/c>comp ( nt -- xt1 xt2 )
> >body cell+ @ ['] execute ;
>
> : interpret/compile: ( interp-xt comp-xt "name" -- ) \ gforth
> swap alias ,
> ['] i/c>comp set->comp
> ['] no-to set-to
> ['] no-defer@ set-defer@ ;
>

> It does not determine the state at run-time (unlike STATE-smart
> words). Instead, the text interpreter asks the word at text
> interpretation time for its interpretation semantics (when
> interpreting), or for its compilation semantics (when compiling).
>
> - anton
>

Thanks.
It looks like a good solution.
I can't do it in an 8K byte kernel so I will use the cheap way
"warts and all" as we say in English.

[Bruce McFarling]

On Friday, September 18, 2020 at 8:30:26 PM UTC+8, Brian Fox wrote:
> Thanks.
> It looks like a good solution.
> I can't do it in an 8K byte kernel so I will use the cheap way
> "warts and all" as we say in English.

Yeah, in my current port originally based on eForth v1.0, I begrudge the cell in the dictionary entry for the XT, even if it is necessary to be able to migrate the dictionary to one (or more) of the High RAM segments to clear room in the much more limited Low RAM.

So for this port, I'm going to have a state smart S" and if it passes the rest of the ANS compliance tests I will refer to it as "aligned" with the ANS Forth standard.

However, one approach which doesn't spend an extra cell per word ... though it DOES require an entire additional vocabulary entry for each multiple-xt word ... is to place the COMPILE-ONLY lexicon bit at bit5, with a compiler mask for the lexicon_length byte of %11100000 and an interpreter mask of %11000000 so that compiler-only words simply are not "seen" in interpret mode. Then if interpret-mode-S" is threaded into the dictionary before compiler-mode-S" the interpret semantics are delivered in interpret state and the compiler semantics are delivered in compile state.

Another approach which is even more parsimonious in an implementation that doesn't use a SMUDGE bit is to have three lexicon bits as IMMEDIATE, EXTENSION, COMPILE-ONLY and the EXTENSION returns a byte of flag bits that specify the nature of the vocabulary extension. If the EXTENSION bit is clear, #0 is returned, and the stored byte returned if EXTENSION is set ... so "special compiler semantics" would be allocated one extended status bit and it would indicate a compiler semantics XT is stored in the dictionary entry. Rather than the name, LEXICON+length byte, link and, for separated header, XT, so 7 additional bytes for a separate interpret and compile mode S", while with the extension status byte, it would just be three additional bytes.

If special compilation semantics were the only thing you were going to handle, you could just use the third lexicon bit for special compilation semantics, but I'm already reserving two extra status bits to indicate the presence and significance of the High RAM segment byte for the dictionary entry that links to a different High RAM segment and for words executing from High RAM segments, to store the High RAM segment that contains them.

Virtually,
Bruce McFarling, Beijing

[A. K.]

My POV: as long as any Forth passes the test suite, it is okay. No need for
jumping through hoops to make things complicated, just for the sake of
some programmer might shoot his own foot after too much careless POSTPONE'ing.

F.ex. some MinForth compiler words and S" et al are state smart, but MinForth
passes the complete test suite. What else does one need?

It also has a COMPILE-ONLY header flag to throw a -14 standard exception.

[Ruvim]

On 2020-09-17 06:40, Brian Fox wrote:
> On 2020-09-16 11:52 AM, Anton Ertl wrote:
[...]

>> Brian Fox's code apparently expects a non-standard S".
>>

> Mea culpa. I forgot to mention that.

> I went all in on state smartness with S" and ."

These words may be implemented as immediate and STATE dependent words,
but POSTPONE should be implemented accordingly to be standard-compliant.

: POSTPONE ( "ccc" -- )
BL WORD FIND DUP 0= IF -13 THROW THEN
SWAP LIT,
1 = IF ['] EXECUTE-COMPILING ELSE ['] COMPILE, THEN COMPILE,
; IMMEDIATE

See an implementation over a standard system at https://git.io/JUE8L
And a short PoC (proof of concept) at https://git.io/JvctZ

> It is much easier to use for the casual user that I was trying to

> get to try Forth. Sadly it didn't make any difference to the target
>  audience.
> :-)


--
Ruvim

[Ruvim]

On 2020-09-17 20:07, Anton Ertl wrote:
[...]

> However, being able to copy-and-paste is a desirable property,
> so some systems support interpreted ." .

> For S" this has actually been standardized in the file wordset.
> However, these words cannot be implemented in the classical
> single-xt+immediate-flag systems,

These words *can* be implemented in the classic single-xt+immediate-flag
systems!

I shown a possible approach: you just need the corresponding
implementation of POSTPONE -- https://git.io/JvctZ

Anton, IIRC, you didn't have objections concerning standard-compliance
of this approach. Could you please clarify your point?


--
Ruvim

[Anton Ertl]

Ruvim <ruvim...@gmail.com> writes:
>These words may be implemented as immediate and STATE dependent words,
>but POSTPONE should be implemented accordingly to be standard-compliant.
>
> : POSTPONE ( "ccc" -- )
> BL WORD FIND DUP 0= IF -13 THROW THEN
> SWAP LIT,
> 1 = IF ['] EXECUTE-COMPILING ELSE ['] COMPILE, THEN COMPILE,
> ; IMMEDIATE

This POSTPONE does not know if a word is intended as a dual word like
S" or as a STATE-smart word. It either does not POSTPONE the dual
word correctly, or it does not POSTPONE the STATE-smart word
correctly.

E.g., consider

: [state?] state ? ; immediate
: state? postpone [state?] ;
state? \ should print 0

Works on Gforth, SwiftForth, VFX, iForth. Does it work with the
POSTPONE above?

[dxforth]

On 19/09/2020 21:25, A. K. wrote:
>
> My POV: as long as any Forth passes the test suite, it is okay. No need for
> jumping through hoops to make things complicated, just for the sake of
> some programmer might shoot his own foot after too much careless POSTPONE'ing.
>
> F.ex. some MinForth compiler words and S" et al are state smart, but MinForth
> passes the complete test suite. What else does one need?

> ...

What would you change in your system for the better were it not ruled from
above? That's the question Forth poses.

[A. K.]

The only one ruling here is myself.
The only one posing silly questions is you.

[dxforth]

By your own admission a test suite rules you when you are in a position
to make your own rules. Moore might consider that silly.

[Ruvim]

On 2020-09-19 19:58, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:
>> These words may be implemented as immediate and STATE dependent words,
>> but POSTPONE should be implemented accordingly to be standard-compliant.
>>
>> : POSTPONE ( "ccc" -- )
>> BL WORD FIND DUP 0= IF -13 THROW THEN
>> SWAP LIT,
>> 1 = IF ['] EXECUTE-COMPILING ELSE ['] COMPILE, THEN COMPILE,
>> ; IMMEDIATE
>
> This POSTPONE does not know if a word is intended as a dual word like
> S" or as a STATE-smart word. It either does not POSTPONE the dual
> word correctly, or it does not POSTPONE the STATE-smart word
> correctly.

By your past description [1], they are the same, i.e. a "STATE-smart
word" is just a dual word that is implemented in some specific way:

| A STATE-smart word is an immediate word with
| STATE-dependent execution semantics used to approximate
| dual-semantics.



But concerning the Standard, — it doesn't specify what is a STATE-smart
word, and what is a correct way to postpone it.

> E.g., consider
>
> : [state?] state ? ; immediate
> : state? postpone [state?] ;
> state? \ should print 0

It's wrong that it "should".
Actually, it *may* print a nonzero number.

You know [2], according to the TC reply on RFI by Philip Preston [3],
"it is an ambiguous condition for a program to perform compilation
semantics in the interpretation state".

POSTPONE appends the compilation semantics for a given word to the
current definition. Hence, it's ambiguous to later perform this
definition in interpretation state.

Hence, performing of your "state?" in interpretation state is ambiguous.
Therefore, your program *may* print nonzero.



Moreover, if the compilation semantics for "[state?]" are equal to the
execution semantics of "[state?]" then "state?" should print 0.
But if "state?" may print nonzero, then for this word the compilation
semantics are not equal to the execution semantics!

It's one more argument against your interpretation, that for any
immediate word the compilation semantics are equal to the execution
semantics, that are equal to the interpretation semantics (see "POSTPONE
POSTPONE and interpretation state" and "Semantics rethinking" threads in
2019).


Also, if "state?" may print zero, then POSTPONE is allowed to append
execution semantics for this word (instead of the compilation
semantics), but due to an ambiguous condition, a standard program cannot
depend on this deviation (and cannot rely on how "state?" works in
interpretation state). Actually, it's look like just a concession to
inaccurate implementation of POSTPONE in some Forth systems.






Indeed we want to be able to perform compilation semantics even in
interpretation state. But a standard way in this case is to enter
compilation state, perform the compilation semantics, and leave back to
interpretation state if changing state wasn't a part of this performing,
otherwise do nothing more.

Fortunately, POSTPONE can and may be implemented, and even redefined in
such a way to guarantee this behavior in run-time.

So this solution satisfies both sides [4]: a) that compilation semantics
may be performed only in compilation state, b) that POSTPONE allows to
use the compilation semantics in interpretation state. — Bingo!






[1] Semantics rethinking (was: WL-TOOLS and ?IMMEDIATE)
Anton Ertl, 2019-10-01
news:2019Oct...@mips.complang.tuwien.ac.at
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/wYqHc5hqVjQ/rs6__03hAwAJ

[2] Poll: compiling an immediate word
Anton Ertl, 1999-04-19
news:7fg1ir$nj4$1...@news.tuwien.ac.at
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/nNTw9VjlSGU/ULNN9TncU6EJ

[3] Q99-027, regarding compilation while in Interpretation state.
RFI by Philip Preston, 1998
http://forth.sourceforge.net/standard/dpans/a99-027.txt

[4] RFI 009, regarding executing words with compilation semantics from
POSTPONE in interpretation state
RFI by Bernd Paysan, 1996
http://forth.sourceforge.net/standard/dpans/q0009.txt


--
Ruvim

[Bruce McFarling]

On Sunday, September 20, 2020 at 10:45:48 AM UTC+8, dxforth wrote:
> What would you change in your system for the better were it not ruled from
> above? That's the question Forth poses.

Oh, that one's easy. If my system does not pass the test suite, and I am not ruled from above to prevent me from modifying it to pass the test suite, I would change it so that it passes the test suite.

Fortunately I am not ruled from above, and therefore am free to change my system in whatever way I can work out to ensure that is passes the test suite.

Virtually,
BruceMcF, Beijing

[dxforth]

This would be in support of the virtual forth for the virtual CX16 for
purposes of communicating with virtually anyone that uses the ISO 15145
protocol? Unbelievable.

[Cecil - k5nwa]

El 20/9/20 a las 01:54, dxforth escribió:

Most people here consider Moore silly, yes sometimes they praise him but
they totally ignore his definition of Forth which is not ANS Forth.

His goal has always been to make things simpler not more complicated as
some here are bent on doing.

I rather go the simpler way but few here cares which is fine with me as
many here have lost their way so I will not follow them.

--
Cecil - k5nwa

[Bruce McFarling]

On Sunday, September 20, 2020 at 11:26:57 PM UTC+8, dxforth wrote:
> This would be in support of the virtual forth for the virtual CX16 for
> purposes of communicating with virtually anyone that uses the ISO 15145
> protocol?

Indeed, one does have to work on an emulator in order to have software ready when hardware ships, though with various design changes along the way most of the work was on an emulator of a SCPU equipped Commodore 64.

But yes, when the CX16 does come to market, being able to direct people to existing tutorials and to bundle existing libraries will be quite handy.

> Unbelievable.

I'm wondering why people should listen to your sweeping claims about what all Forth programmers are or are not doing if you are unable to grasp the appeal of having an ANS Forth in the context of that kind of real world project.

Virtually,
BruceMcF, Beijing

[dxforth]

On 20/09/2020 19:37, Ruvim wrote:
> ...

> [4] RFI 009, regarding executing words with compilation semantics from POSTPONE in interpretation state
> RFI by Bernd Paysan, 1996
> http://forth.sourceforge.net/standard/dpans/q0009.txt

So this silly debate has been going on since 1996 because the ANS TC had
offered to draft a response but didn't get round to completing it. And
in the 16 years of its existence the 200x TC had either been unable, or
unwilling, to answer it. That ought to be an answer in itself.

[Gerry Jackson]

Well said.

--
Gerry

[Gerry Jackson]

On 20/09/2020 20:29, Cecil - k5nwa wrote:
> El 20/9/20 a las 01:54, dxforth escribió:
>> On 20/09/2020 15:27, A. K. wrote:
>>> Am Sonntag, 20. September 2020 04:45:48 UTC+2 schrieb dxforth:
>>>> On 19/09/2020 21:25, A. K. wrote:
>>>>>
>>>>> My POV: as long as any Forth passes the test suite, it is okay. No
>>>>> need for
>>>>> jumping through hoops to make things complicated, just for the sake of
>>>>> some programmer might shoot his own foot after too much careless
>>>>> POSTPONE'ing.
>>>>>
>>>>> F.ex. some MinForth compiler words and S" et al are state smart,
>>>>> but MinForth
>>>>> passes the complete test suite. What else does one need?
>>>>> ...
>>>>
>>>> What would you change in your system for the better were it not
>>>> ruled from
>>>> above?  That's the question Forth poses.
>>>
>>> The only one ruling here is myself.
>>> The only one posing silly questions is you.
>>>
>>
>> By your own admission a test suite rules you when you are in a position
>> to make your own rules.  Moore might consider that silly.
>

It's silly to regard a test suite as ruling what you do let alone the
view that a standard like ANS Forth is imposed on you. The choice of
whether to follow the standard is the individuals (unless, of course, if
your employer insists on it, but then it's your choice to work for that
employer).

A rational way to regard a standard such as ANS Forth is that it
provides the basis for program portability between different Forth
systems. The test suite is merely a tool that indicates where your
software may not be portable. If you're just programming for yourself
and don't want portability - fine, ignore the standard and its test suite.

>
> Most people here consider Moore silly,

I doubt that is true

> yes sometimes they praise him but
> they totally ignore his definition of Forth which is not ANS Forth.
>
> His goal has always been to make things simpler not more complicated as
> some here are bent on doing.
>
> I rather go the simpler way but few here cares which is fine with me as
> many here have lost their way so I will not follow them.
>

As exemplified by Cecil who is going his own way - do you see anybody
criticising him for that?

--
Gerry

[Gerry Jackson]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sorry I meant "Forth system may not execute a standard program correctly"

[A. K.]

IMO "merely a tool for portability" does not give enough credit to its value.
A lot of clever thoughts went into the suite. When building a new Forth core
(or more) I find it extremely helpful for spotting design mistakes.

It is particularly useful for testing a CATCH/THROW/ABORT mechanism. I use just
- tester.fr
- prelimtest.fth
- coretest.fth
- coreplustest.fth
- exceptiontest.fth
From there on it is application domain, and practically never I have to revert
back to core bugs.

BTW I use a little helper routine to EVALUATE those test files line by line
by piping through stdin. Block or File wordsets are not needed.

[Ruvim]

You are wrong.

The TC Reply to Q99-027 (RFI by Philip Preston) actually answers to Q009
(RFI by Bernd Paysan) as well.
http://forth.sourceforge.net/standard/dpans/a99-027.txt

According to the TC reply, the intention was that the compilation
semantics that POSTPONE appends is allowed to be performed in
compilation state only.


But I shown (see https://git.io/JUE8L) that even a program can redefine
POSTPONE in such a way that the generated code may be performed in any
state, since it sets compilation state by itself if it's required.

Also, such behavior of POSTPONE for immediate words can be concluded
even from the wording of the standard.


A fix to make POSTPONE be more convenient:

: postpone ( "ccc" -- )
postpone [: postpone postpone postpone ;]
postpone execute-compiling
; immediate



--
Ruvim

[dxforth]

On 21/09/2020 17:47, Gerry Jackson wrote:
> On 20/09/2020 20:29, Cecil - k5nwa wrote:
>> El 20/9/20 a las 01:54, dxforth escribió:
>>> On 20/09/2020 15:27, A. K. wrote:
>>>> Am Sonntag, 20. September 2020 04:45:48 UTC+2 schrieb dxforth:
>>>>> On 19/09/2020 21:25, A. K. wrote:
>>>>>>
>>>>>> My POV: as long as any Forth passes the test suite, it is okay. No need for
>>>>>> jumping through hoops to make things complicated, just for the sake of
>>>>>> some programmer might shoot his own foot after too much careless POSTPONE'ing.
>>>>>>
>>>>>> F.ex. some MinForth compiler words and S" et al are state smart, but MinForth
>>>>>> passes the complete test suite. What else does one need?
>>>>>> ...
>>>>>
>>>>> What would you change in your system for the better were it not ruled from
>>>>> above?  That's the question Forth poses.
>>>>
>>>> The only one ruling here is myself.
>>>> The only one posing silly questions is you.
>>>>
>>>
>>> By your own admission a test suite rules you when you are in a position
>>> to make your own rules.  Moore might consider that silly.
>>
>
> It's silly to regard a test suite as ruling what you do let alone the view that a standard like ANS Forth is imposed on you. The choice of whether to follow the standard is the individuals (unless, of course, if your employer insists on it, but then it's your choice to work for that employer).
>
> A rational way to regard a standard such as ANS Forth is that it provides the basis for program portability between different Forth systems. The test suite is merely a tool that indicates where your software may not be portable. If you're just programming for yourself and don't want portability - fine, ignore the standard and its test suite.

Except there's no demand for portable forth programmers. There may have
once been a demand for good forth programmers. A rational way to regard
a Forth Standard is that it is happy to have supporters whether they
program or not. Not unlike FIG. Better still if they paid :)

[dxforth]

On 21/09/2020 19:09, Ruvim wrote:
> On 2020-09-21 03:26, dxforth wrote:
>> On 20/09/2020 19:37, Ruvim wrote:
>>> ... [4] RFI 009, regarding executing words with compilation semantics from POSTPONE in interpretation state
>>> RFI by Bernd Paysan, 1996
>>> http://forth.sourceforge.net/standard/dpans/q0009.txt
>>
>> So this silly debate has been going on since 1996 because the ANS TC had
>> offered to draft a response but didn't get round to completing it.  And
>> in the 16 years of its existence the 200x TC had either been unable, or
>> unwilling, to answer it.  That ought to be an answer in itself.
>
> You are wrong.
>
> The TC Reply to Q99-027 (RFI by Philip Preston) actually answers to Q009 (RFI by Bernd Paysan) as well.
> http://forth.sourceforge.net/standard/dpans/a99-027.txt

That's your opinion - not a TC ruling on the question. The matter
is resolved by having the current TC rule on it.

[A. K.]

You seem to be incited by your own bogeyman you call TC. :-)
There is no TC anymore.

Inform yourself about the actual Forth200x working group and its open attitude
for individual and community proposals:
http://www.forth200x.org/
https://forth-standard.org/

Don't be a Hugh, be constructive and participate to change things for the better.

[Gerry Jackson]

Thanks, that's good to hear. It's the first report I've had that someone
has used the prelim test that I devised to help bring up a new Forth system.

>
> BTW I use a little helper routine to EVALUATE those test files line by line
> by piping through stdin. Block or File wordsets are not needed.
>

Is that a general solution that could be usefully shared with the test
suite or specific to your system?

--
Gerry

[A. K.]

'Slurping' OS pipes eg before entering the outer QUIT interpreter loop requires
non-standard OS access eg by POSIX commands, of course.

I don't think it can be generalized, given the enormous variety of Forth
systems and implementation techniques.

[Anton Ertl]

Ruvim <ruvim...@gmail.com> writes:
>On 2020-09-19 19:58, Anton Ertl wrote:
>> Ruvim <ruvim...@gmail.com> writes:
>>> These words may be implemented as immediate and STATE dependent words,
>>> but POSTPONE should be implemented accordingly to be standard-compliant.
>>>
>>> : POSTPONE ( "ccc" -- )
>>> BL WORD FIND DUP 0= IF -13 THROW THEN
>>> SWAP LIT,
>>> 1 = IF ['] EXECUTE-COMPILING ELSE ['] COMPILE, THEN COMPILE,
>>> ; IMMEDIATE
>>
>> This POSTPONE does not know if a word is intended as a dual word like
>> S" or as a STATE-smart word. It either does not POSTPONE the dual
>> word correctly, or it does not POSTPONE the STATE-smart word
>> correctly.
>
>By your past description [1], they are the same, i.e. a "STATE-smart
>word" is just a dual word that is implemented in some specific way:
>
>| A STATE-smart word is an immediate word with
>| STATE-dependent execution semantics used to approximate
>| dual-semantics.

That's certainly the usual intention. Nevertheless, there exist cases
where users actually expect STATE-smart rather than dual behaviour,
typically when building other STATE-smart words. E.g., Brian Fox
recently posted this STATE-smart .", which expects a STATE-smart S"
and does not work as intended with a dual S".

: ." ( ccc" -- )
POSTPONE S"
STATE @
IF POSTPONE TYPE
ELSE TYPE
THEN ; IMMEDIATE

I have also seen cases where users write POSTPONE LITERAL, expecting
LITERAL to be STATE-smart.

>But concerning the Standard, — it doesn't specify what is a STATE-smart
>word, and what is a correct way to postpone it.

It specifies the execution semantics of all user-defined words, and
specifies that the interpretation semantics are the same, and, for
immediate words (STATE-smart words are immediate), that the
compilation semantics is also the same. And it specifies that
POSTPONE appends the compilation semantics (=execution semantics for
STATE-smart words) to the current definition.

>> E.g., consider
>>
>> : [state?] state ? ; immediate
>> : state? postpone [state?] ;
>> state? \ should print 0
>
>It's wrong that it "should".
>Actually, it *may* print a nonzero number.
>
>You know [2], according to the TC reply on RFI by Philip Preston [3],
>"it is an ambiguous condition for a program to perform compilation
>semantics in the interpretation state".

Whoever wrote that obviously knew that they could not argue that from
the standard's text, so they announced to rewrite the text. That
rewrite never materialized.

My conclusion is that even if the Forth-94 TC's intention really was
to answer yes to the two questions by Philip Preston, they did not
follow up on that. Maybe they later had second thoughts about their
answer. Their answer is taking a shot-gun approach at allowing
STATE-smart implementations of standard words, with lots of colateral
damage. E.g., it would de-standardize common practice like

: (S POSTPONE ( ; IMMEDIATE
(S ...)

Forth200x has been working since 2004, and released Forth-2012,
without changing the Forth-94 text defining compilation semantics
etc., and without anybody even proposing a rewrite, or proposing to
add these ambiguous conditions, so it seems that people are mostly
happy with that part of the standard as it stands. So this RFI answer
is no longer relevant.

A more surgical approach to allowing STATE-smart S" would be to make
ticking and POSTPONEing S" ambiguous, like TO. But none of the fans
of STATE-smart S" has made such a proposal, either.

>It's one more argument against your interpretation, that for any
>immediate word the compilation semantics are equal to the execution
>semantics, that are equal to the interpretation semantics

It's one more argument that the answer to this RFI is irrelevant.

>Also, if "state?" may print zero, then POSTPONE is allowed to append
>execution semantics for this word (instead of the compilation
>semantics), but due to an ambiguous condition, a standard program cannot
>depend on this deviation (and cannot rely on how "state?" works in
>interpretation state). Actually, it's look like just a concession to
>inaccurate implementation of POSTPONE in some Forth systems.

I am not sure I follow you here. Do you want to say that the common
practice of implementing POSTPONE is wrong, and that the only accurate
implementation of POSTPONE is yours? In that case that standard would
have failed to standardize common practice. It makes more sense to
adopt an interpretation of the standard that aligns more with common
practice. You can now point to SwiftForth (STATE-smart S") for a
deviation of my interpretation from some existing practice, but if you
look at the number of systems and programs that would have to be
changed, the my interpretation is much closer to common practice than
yours.

>[3] Q99-027, regarding compilation while in Interpretation state.
>RFI by Philip Preston, 1998
>http://forth.sourceforge.net/standard/dpans/a99-027.txt

[Gerry Jackson]

On 21/09/2020 15:11, A. K. wrote:
>>> BTW I use a little helper routine to EVALUATE those test files line by line
>>> by piping through stdin. Block or File wordsets are not needed.
>>>
>> Is that a general solution that could be usefully shared with the test
>> suite or specific to your system?
>>
> 'Slurping' OS pipes eg before entering the outer QUIT interpreter loop requires
> non-standard OS access eg by POSIX commands, of course.
>
> I don't think it can be generalized, given the enormous variety of Forth
> systems and implementation techniques.

Thanks, I thought it that was probably the case.

--
Gerry

[dxforth]

On 21/09/2020 23:05, A. K. wrote:
> ...

> You seem to be incited by your own bogeyman you call TC. :-)
> There is no TC anymore.

You are quibbling over the word 'Technical' ?

>
> Inform yourself about the actual Forth200x working group and its open attitude
> for individual and community proposals:
> http://www.forth200x.org/
> https://forth-standard.org/

You are suggesting ANS didn't have 'working groups' and wasn't open
to 'individual and community proposals'?

Without a defined list of voting members (refer to any 200x document
for their names) there would be nobody responsible for what's in the
document and nobody to rule on technical questions. Is that what
you want?

>
> Don't be a Hugh, be constructive and participate to change things for the better.
>

Participate in what exactly - endless debate the current leadership
shows no interest in resolving? Go back 30 years to a state of naivety?
If anyone has done that they should step forward and explain how out
of curiosity.

[Bruce McFarling]

On Tuesday, September 22, 2020 at 2:23:49 AM UTC+8, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:
> >You know [2], according to the TC reply on RFI by Philip Preston [3],
> >"it is an ambiguous condition for a program to perform compilation
> >semantics in the interpretation state".

> Whoever wrote that obviously knew that they could not argue that from
> the standard's text, so they announced to rewrite the text. That
> rewrite never materialized.

Now we are getting into Hugh territory of ignoring the direct statement
to dismiss an answer that is not liked based on inferred motivation.

The direct statement is that:
(1.) It is an ambiguous condition for a program to perform compilation

semantics in the interpretation state.

(2.) It is an ambiguous condition for a program to append semantics to the
current definition in the interpretation state.

> My conclusion is that even if the Forth-94 TC's intention really was
> to answer yes to the two questions by Philip Preston, they did not
> follow up on that.

(I) They stated that they intended to rewrite some language where it turned out that that the original language did not correctly convey the TC's intent. That intention was never carried through before the TC disbanded.

(2) They also actually answered the question. They actually answered yes to both. So that established that under Forth94, both of those are ambiguous conditions.

> Maybe they later had second thoughts about their answer.

A speculative hypothetical change of heart on a TC decision where that speculative hypothetical change
of heart has nil weight.

> Their answer is taking a shot-gun approach at allowing STATE-smart implementations of standard words, with lots of collateral damage.

> E.g., it would de-standardize common practice like ...

De-standardizing one set of common practice because not doing so de-standardizes another set of common practices is indeed the kind of decision the TC had to make. In the RFI, they stated that they had intended intended to do that in one direction, and the RFI rules that the standard should be interpreted in that light.

> Forth200x has been working since 2004, and released Forth-2012,
> without changing the Forth-94 text defining compilation semantics
> etc., and without anybody even proposing a rewrite, or proposing to
> add these ambiguous conditions, so it seems that people are mostly
> happy with that part of the standard as it stands. So this RFI answer
> is no longer relevant.

The standard as it stands includes the content of RFI's. Perhaps the people who are content with the actual standard as it stands simply use it, and those who are not content with the elements of the standard that you prefer to set aside are using Forth20xx in its place.

So, per Chuck Moore, everybody gets a standard.

After all, much of a standard is simply resolving coordination games, such as whether to drive on the right or the left, or whether "red" means stop and "green" means go or the reverse, or which pin gets GND, +3.3VCC, +5VCC, MOSI, MISO, CLK, /SEL in an SPI block header. As long as the standard helps one coordinates effectively with those one wishes to coordinate with, another group coordinating on a different, partially overlapping standard isn't the kind of thing that it's necessary to worry about.

> A more surgical approach to allowing STATE-smart S" would be to make
> ticking and POSTPONEing S" ambiguous, like TO.

Indeed, an alternate plausible hypothesis as to why the TC never completed the mooted rewrite before ceasing work is that some members were in favor of this solution to allow restricting the scope of those ambiguous conditions and the TC did not reach consensus before it ceased working.

A third, also plausible, interpretation is that the Forth-94 gave those who saw a need for a formal industrial standard enough of the required benefit that there was not enough incentive to start another standardization round, and while the mooted rewrite on that point was was essentially finished there was no place for the WIP to land.

> But none of the fans
> of STATE-smart S" has made such a proposal, either.

It may well be because they are satisfied with the actual Forth-94 solution that performing compilation semantics in interpret state and appending semantics to a definition in interpretation state are ambiguous conditions.

Virtually,
BruceMcF, Beijing

[dxforth]

On 21/09/2020 23:05, A. K. wrote:

> Am Montag, 21. September 2020 13:29:14 UTC+2 schrieb dxforth:

> > [snipped]

> Don't be a Hugh, be constructive and participate to change things for the better.
>

Ok. A contribution to historians.

A Brief History of Forth - the Standard Years

The Forthers doubting their ability, demanded the Priests make "gods"
to go before them. The Priests gathered up the Forthers' golden
earrings and ornaments, constructed a "molten calf" and declared:
"These be thy gods, O Forthers". Moore went down from the mountain,
but upon seeing the calf, became angry that the Forthers had turned
aside quickly out of the way which Simplicity commanded.

with help from Wikipedia

[A. K.]

grow up

[dxforth]

It's not me you have to worry about. I'm not promising you anything.

[a...@littlepinkcloud.invalid]

It is a TC ruling, as it clearly says.

Andrew.

[Ruvim]

On 2020-09-21 20:21, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:
>> On 2020-09-19 19:58, Anton Ertl wrote:
>>> Ruvim <ruvim...@gmail.com> writes:
>>>> These words may be implemented as immediate and STATE dependent words,
>>>> but POSTPONE should be implemented accordingly to be standard-compliant.
>>>>
>>>> : POSTPONE ( "ccc" -- )
>>>> BL WORD FIND DUP 0= IF -13 THROW THEN
>>>> SWAP LIT,
>>>> 1 = IF ['] EXECUTE-COMPILING ELSE ['] COMPILE, THEN COMPILE,
>>>> ; IMMEDIATE

(1)

>>>
>>> This POSTPONE does not know if a word is intended as a dual word like
>>> S" or as a STATE-smart word. It either does not POSTPONE the dual
>>> word correctly, or it does not POSTPONE the STATE-smart word
>>> correctly.
>>
>> By your past description [1], they are the same, i.e. a "STATE-smart
>> word" is just a dual word that is implemented in some specific way:
>>
>> | A STATE-smart word is an immediate word with
>> | STATE-dependent execution semantics used to approximate
>> | dual-semantics.
>
> That's certainly the usual intention.

A consequence of this definition is that if a word is not used to
approximate dual-semantics, then it isn't a STATE-smart word.

Also, you rejected the guess that by STATE-smart word you mean *any*
immediate word with STATE-dependent execution semantics.

So "STATE-smart" is still a too vague term.

> Nevertheless, there exist cases
> where users actually expect STATE-smart rather than dual behaviour,
> typically when building other STATE-smart words. E.g., Brian Fox
> recently posted this STATE-smart .", which expects a STATE-smart S"
> and does not work as intended with a dual S".
>
> : ." ( ccc" -- )
> POSTPONE S"
> STATE @
> IF POSTPONE TYPE
> ELSE TYPE
> THEN ; IMMEDIATE
>

This definition relies on that POSTPONE appends execution semantics for
immediate words and S" is an immediate STATE-dependent word.

So, this code is non-standard. But it doesn't matter, if it's an
internal part of a system.

> I have also seen cases where users write POSTPONE LITERAL, expecting
> LITERAL to be STATE-smart.
>

Such code is non-standard too.



My conclusion is that a standard system *may* have POSTPONE implemented
as (1) above.


Many systems that implement dual semantics words as immediate words, are
non-compliant since POSTPONE incorrectly works for them.

These systems can be easily made compliant by changing POSTPONE similar
to (1), and fixing several places where POSTPONE is used to append
execution semantics of a word, i.e. replace these cases of POSTPONE X by
['] X EXECUTE
or
[ ' X COMPILE, ]

(system's internal details that may be non-compliant).




[...]
I will address other questions in another message.


--
Ruvim

[Bruce McFarling]

On Tuesday, September 22, 2020 at 6:15:09 PM UTC+8, Ruvim wrote:
> Many systems that implement dual semantics words as immediate words, are
> non-compliant since POSTPONE incorrectly works for them.

> These systems can be easily made compliant by changing POSTPONE similar
> to (1), and fixing several places where POSTPONE is used to append
> execution semantics of a word, i.e. replace these cases of POSTPONE X by
> ['] X EXECUTE
> or
> [ ' X COMPILE, ]

In other words, by having to know whether or not the compilation semantics is to execute or to compile the word, the exact knowledge requirement which POSTPONE is intended eliminate, to simplify porting code when that may vary ... as in a subroutine threaded system that has a macro to compile the effect of DROP rather than compiling a call to the routine called by the interpreter.

That seems to be taking the functionality of POSTPONE backwards.

Virtually,
BruceMcF, Beijing

[Ruvim]

On 2020-09-22 15:09, Bruce McFarling wrote:
> On Tuesday, September 22, 2020 at 6:15:09 PM UTC+8, Ruvim wrote:
>> Many systems that implement dual semantics words as immediate words, are
>> non-compliant since POSTPONE incorrectly works for them.
>
>> These systems can be easily made compliant by changing POSTPONE similar
>> to (1), and fixing several places where POSTPONE is used to append
>> execution semantics of a word, i.e. replace these cases of POSTPONE X by
>> ['] X EXECUTE
>> or
>> [ ' X COMPILE, ]

(2)

>
> In other words, by having to know whether or not the compilation semantics
> is to execute or to compile the word, the exact knowledge requirement which
> POSTPONE is intended eliminate, to simplify porting code when that may vary
> ... as in a subroutine threaded system that has a macro to compile the
> effect of DROP rather than compiling a call to the routine called by
> the interpreter.

"DROP" that is implemented as a macro (i.e. an immediate word) that
compiles the effect of DROP is non-standard.

Nevertheless, POSTPONE implemented as (1) works correctly for such macro.

While the popular implementation of POSTPONE works incorrectly for such
macro.


But if you want to create an alias (or a wrapper) for such macro,
you have to compile its execution semantics. And the recipe (2) above is
only of such cases.

> That seems to be taking the functionality of POSTPONE backwards.

It false impression.

POSTPONE solves problem of old COMPILE for compilation semantics, and
never solved this problem for interpretation semantics or execution
semantics.

I.e., if you need to append compilation semantics — you don't need to
know how a word is implemented. And the implementation (1) makes this
property stronger.

But if you need to append execution semantics, or interpretation
semantics, POSTPONE cannot help.


Accidentally, in some implementations POSTPONE appends execution
semantics of an immediate word. But using the resulting word during
interpretation is ambiguous. Therefore, if you want to execute the
resulting word in interpretation state, you have to know whether the
argument of POSTPONE is an immediate word and what it's interpretation
semantics.
With implementation (1) you don't need to know this.


--
Ruvim

[Bruce McFarling]

On Tuesday, September 22, 2020 at 9:04:16 PM UTC+8, Ruvim wrote:
> Accidentally, in some implementations POSTPONE appends execution
> semantics of an immediate word. But using the resulting word during
> interpretation is ambiguous.

Why is that an issue? The purpose of POSTPONE is for writing compiling words.

> Therefore, if you want to execute the resulting word in interpretation
> state, you have to know whether the argument of POSTPONE is an
> immediate word and what it's interpretation semantics.
> With implementation (1) you don't need to know this.

So there are tricks that you can play with POSTPONE in interpret state
if you play standard-lawyer games with the under-specified term
"compiler semantics' to interpret "append the compilation semantics"
to do something that is NOT ambiguous if the word should happen to
be executed in interpret state?

It seems that in the RFI, the counter-argument prevailed, that it doesn't
matter what standards-lawyer arguments you might present, the
use of the term in the ANS Forth standard refers to what a word does
IN compile state, and doesn't constrain what might happen if the
resulting word might be executed in interpret state.

As in any ambiguous condition, any given ANS Forth implementation
would be free to have anything happen in that circumstance. It might
perform the interpret semantics of a state smart word, it might
doggedly persist in performing the compilation semantics, or, albeit
unlikely, it may stand up and sing the national anthem of the country
in which it resides. (Arise, ye who refuse to be slaves! ...)

If Forth2012 assumes the dogged persistance of the compilation
semantics, I hope it is explicitly specified, and not brought in via
dogged insistence on an interpretation of ANS Forth which was
unambiguously ruled to be a misinterpretation.

Virtually,
BruceMcF, Beijing

[Ruvim]

On 2020-09-21 20:21, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:

[...]

>> But concerning the Standard, — it doesn't specify what is a STATE-smart
>> word, and what is a correct way to postpone it.
>
> It specifies the execution semantics of all user-defined words, and
> specifies that the interpretation semantics are the same, and, for
> immediate words (STATE-smart words are immediate), that the
> compilation semantics is also the same. And it specifies that
> POSTPONE appends the compilation semantics (=execution semantics for
> STATE-smart words) to the current definition.
>

Well, after removing the vague "STATE-smart" term and parenthesis, you say:

| It specifies the execution semantics of all user-defined
| words, and specifies that the interpretation semantics

| are the same, and, for immediate words, that the

| compilation semantics is also the same.
| And it specifies that POSTPONE appends the compilation

| semantics to the current definition.

I.e., that for *any* immediate word IS = ES and CS = ES,
that means IS = CS.

Let's refer to the original wording and definitions.

As I already wrote [5], if we substitute definitions of "interpretation
semantics" and "compilation semantics" in place the terms themselves, we
get:

in 2.1:
| immediate word:
| A Forth word whose { behavior when its name is encountered
| by the text interpreter *in compilation state* } is to perform its
| execution semantics.

in 3.4.3.2:
| Unless otherwise specified in an "Interpretation:" section of the
| glossary entry, { the behavior of a Forth definition when its name
| is encountered by the text interpreter *in interpretation state* }
| is its execution semantics.


In the first case it means that execution semantics are performed in
compilation state.

In the seconds case it means that execution semantics are performed in
interpretation state.

And it's obvious that the behavior that these execution semantics show
in interpretation state may be *unequal* to the behavior in compilation
state (when everything else arguments being equal).

So, how to compose the specification for such an immediate word (that
have the different behavior in the different state)?

One approach is:
if interpreting do this, if compiling do that.

(i.e., to specify only execution semantics).

Another approach is to call one behavior "interpretation semantics" and
another behavior "compilation semantics" and specify them separately and
more simply (without conditional ifs):

Interpretation: do this.
Compilation: do that.

An additional feature of this approach is that now the word can be
implemented in the different way. If we don't say that it's an immediate
word, and don't specify execution semantics, then the word is not
obligated to be immediate and even to have execution semantics.
But if we allow another implementations, we cannot get execution
semantics (xt) in a portable way anymore. So we should disallow taking
execution token for such words.


Good. But can we describe via the different interpretation semantics
and compilation semantics a word that should be namely an immediate
word? Yes, we can: we should just add a note that it's an immediate
word. Does it mean that for this word IS = CS ? — No. They are different.

NB: the standard specifies a word to be an immediate word only in the
cases when IS = CS. But a user may define an immediate word for which IS
<> CS, i.e. that has STATE-dependent execution semantics.

For the words having CS <> IS and CS <> default, the standard doesn't
required to be immediate words, but it *allows* them to be immediate words.




It seems, the only reason to say that CS = ES = IS for any immediate
word is to prove that a better implementation of POSTPONE (when argument
is an immediate word) is non-compliant. It doesn't have other consequences.

But, taking into account Q99-027 [3], and some other grounds, both
implementations are compliant: the better implementation, as well as the
simple implementation (aka common practice).




[...]

> Do you want to say that the common practice of implementing POSTPONE
> is wrong, and that the only accurate implementation of POSTPONE is yours?

No. I want to say that both are allowed by the standard at the moment.

> In that case that standard would have failed to standardize common
> practice.

POSTPONE is a new word that was introduced in Forth-94. Common practice
concerning POSTPONE was absent before Forth-94. So it's incorrect to say
that it have failed in this regard.

> It makes more sense to
> adopt an interpretation of the standard that aligns more with common
> practice. You can now point to SwiftForth (STATE-smart S") for a
> deviation of my interpretation from some existing practice, but if you
> look at the number of systems and programs that would have to be
> changed, the my interpretation is much closer to common practice than
> yours.

I would not suggest to make non-standard the popular implementation of
POSTPONE. So no need to change systems.

Also, no programs would have to be changed. If a program performs, in
interpretation state, the compilation semantics appended by POSTPONE,
then it has an environmental dependency.


If a program relies on STATE-dependent immediate words, my
implementation of POSTPONE just more convenient in use. Since the code
like the following:

: foo ]] if user-defined-macro then [[ ;
: bar [ ... foo ] ;

does not depend on STATE, and works as expected.

>> [3] Q99-027, regarding compilation while in Interpretation state.
>> RFI by Philip Preston, 1998
>> http://forth.sourceforge.net/standard/dpans/a99-027.txt

[5] Semantics rethinking, 2019-08-04
news:qi6con$1bdk$1...@gioia.aioe.org
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/vrq2f2XXy1Q/tiuq7hJTFgAJ


--
Ruvim

[dxforth]

Not according to Anton. So why doesn't your committee resolve it once and
for all?

>
> Andrew.
>

[Ruvim]

On 2020-09-23 03:05, Bruce McFarling wrote:
> On Tuesday, September 22, 2020 at 9:04:16 PM UTC+8, Ruvim wrote:
>> Accidentally, in some implementations POSTPONE appends execution
>> semantics of an immediate word. But using the resulting word during
>> interpretation is ambiguous.
>
> Why is that an issue? The purpose of POSTPONE is for writing compiling words.

Yes, but such compiling words are occasionally tested in interpretation
state (when compilation is "suspended"). Or they just used
interpretively in a user-defined DSL. And the expectation of an average
user is that the run-time semantics of the code that POSTPONE generates
are STATE-independent. Some people also conclude from the standard that
this is obligated.

Well, what picture we have in this regard?

1. All systems satisfy this expectation for ordinary words and for
STATE-independent immediate words.

2. The dual-xt systems satisfy this expectation when POSTPONE is applied
to any standard dual semantics word.

3. Many classic single-xt+immediate systems satisfy this expectation for
dual semantics words that are allowed to be argument of POSTPONE,
perhaps with exception for the S" word.

4. Many other classic single-xt+immediate systems don't satisfy this
expectation for dual semantics words at all.

5. The most systems don't satisfy this expectation for user-defined
STATE-dependent immediate words. Despite of majority, it doesn't mean
that they behavior should be standardized. Since it means that in some
cases user will need to know whether the argument of POSTPONE is an
immediate word and what its interpretation semantics. But the intention
was that user never need to know how an argument of POSTPONE is implemented.

So, a better ways for a Forth system to satisfy the mentioned
expectation without any exceptions.

And the proposed implementation of POSTPONE makes *any* system to
satisfy this expectation for *all* words.

Although, it doesn't make the programs that rely on this expectation
compliant. But when this practice will be wide enough, it can be
standardized.

>
>> Therefore, if you want to execute the resulting word in interpretation
>> state, you have to know whether the argument of POSTPONE is an
>> immediate word and what it's interpretation semantics.
>> With implementation (1) you don't need to know this.
>
> So there are tricks that you can play with POSTPONE in interpret state
> if you play standard-lawyer games with the under-specified term
> "compiler semantics' to interpret "append the compilation semantics"
> to do something that is NOT ambiguous if the word should happen to
> be executed in interpret state?
>
> It seems that in the RFI, the counter-argument prevailed, that it doesn't
> matter what standards-lawyer arguments you might present, the
> use of the term in the ANS Forth standard refers to what a word does
> IN compile state, and doesn't constrain what might happen if the
> resulting word might be executed in interpret state.

Yes. But if we find consensus what should happen in interpretation
state, and implement the same behavior in enough amount of systems, it
can be later standardized.



--
Ruvim

[none albert]

In article <dcd7612a-1096-4ec3...@googlegroups.com>,

Bruce McFarling <bruce.m...@gmail.com> wrote:
>On Tuesday, September 22, 2020 at 9:04:16 PM UTC+8, Ruvim wrote:
>> Accidentally, in some implementations POSTPONE appends execution
>> semantics of an immediate word. But using the resulting word during
>> interpretation is ambiguous.
>
>Why is that an issue? The purpose of POSTPONE is for writing compiling words.

Would you say that if we just add in the standard that using POSTPONE
in a non-immediate word is an ambiguous condition, we're out of the
woods?
A quick survey learns me that I never use POSTPONE except in immediate
words, so fine by me.

Or would we have to add "any word that contains a
usage of POSTPONE has undefined interpretation semantics"?
(Still fine by me.)

>Virtually,
>BruceMcF, Beijing

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

[Bruce McFarling]

On Wednesday, September 23, 2020 at 8:03:14 PM UTC+8, none albert wrote:
> In article <dcd7612a-1096-4ec3...@googlegroups.com>,
> Bruce McFarling <bruce.m...@gmail.com> wrote:
> >On Tuesday, September 22, 2020 at 9:04:16 PM UTC+8, Ruvim wrote:
> >> Accidentally, in some implementations POSTPONE appends execution
> >> semantics of an immediate word. But using the resulting word during
> >> interpretation is ambiguous.

> >Why is that an issue? The purpose of POSTPONE is for writing compiling words.

> Would you say that if we just add in the standard that using POSTPONE
> in a non-immediate word is an ambiguous condition, we're out of the
> woods?
> A quick survey learns me that I never use POSTPONE except in immediate
> words, so fine by me.

That's a little broad, since someone might have a non-immediate word that is a common factor used in immediate compiling words, and under Forth94, that complies with the definition of POSTPONE.

> Or would we have to add "any word that contains a
> usage of POSTPONE has undefined interpretation semantics"?
> (Still fine by me.)

The second was already explained by the Technical Committee in the response to the RFI to be what is meant when the definition of POSTPONE says that it appends compilation semantics. Using a word in interpretation state when it has been specified to have compilation semantics appended is an ambiguous condition under the Forth94 standard.

Virtually,
BruceMcF, Beijing

[none albert]

In article <84921cf0-b6d1-4459...@googlegroups.com>,

Bruce McFarling <bruce.m...@gmail.com> wrote:
>On Wednesday, September 23, 2020 at 8:03:14 PM UTC+8, none albert wrote:
>> In article <dcd7612a-1096-4ec3...@googlegroups.com>,
>> Bruce McFarling <bruce.m...@gmail.com> wrote:
>> >On Tuesday, September 22, 2020 at 9:04:16 PM UTC+8, Ruvim wrote:
>> >> Accidentally, in some implementations POSTPONE appends execution
>> >> semantics of an immediate word. But using the resulting word during
>> >> interpretation is ambiguous.
>
>> >Why is that an issue? The purpose of POSTPONE is for writing compiling words.
>
>> Would you say that if we just add in the standard that using POSTPONE
>> in a non-immediate word is an ambiguous condition, we're out of the
>> woods?
>> A quick survey learns me that I never use POSTPONE except in immediate
>> words, so fine by me.
>
>That's a little broad, since someone might have a non-immediate word that is a
>common factor used in immediate compiling words, and under Forth94, that
>complies with the definition of POSTPONE.

The above stipulation doesn't preclude postponing those words
in immediate words. Whether or not the words postponed are immediate
or not is immaterial. Then, as long as it is postponed, and only used
to compile, the word could be made immediate with no consequences
other than make it very clear that it belongs to the compiler realm.

<SNIP>

[Bruce McFarling]

On Thursday, September 24, 2020 at 5:40:03 PM UTC+8, none albert wrote:
> In article <84921cf0-b6d1-4459...@googlegroups.com>,
> Bruce McFarling <bruce.m...@gmail.com> wrote:
> >On Wednesday, September 23, 2020 at 8:03:14 PM UTC+8, none albert wrote:

> >> Would you say that if we just add in the standard that using POSTPONE
> >> in a non-immediate word is an ambiguous condition, we're out of the
> >> woods?

> >> A quick survey learns me that I never use POSTPONE except in immediate
> >> words, so fine by me.

> >That's a little broad, since someone might have a non-immediate word that is a
> >common factor used in immediate compiling words, and under Forth94, that
> >complies with the definition of POSTPONE.

> The above stipulation doesn't preclude postponing those words
> in immediate words. Whether or not the words postponed are immediate
> or not is immaterial. Then, as long as it is postponed, and only used
> to compile, the word could be made immediate with no consequences
> other than make it very clear that it belongs to the compiler realm.

But it require an otherwise unnecessary POSTPONE in order to compile rather than execute a word non-immediate which was only made immediate to comply with the rule.

The current status quo is that use of a word containing a POSTPONEd behavior outside of compilation state is an ambiguous behavior & so the implementation can do whatever it wants to in that circumstance.

All that would really need to be added to the text of the standard to forestall the extant misinterpretation from those unaware of the response to the RFI or who misrepresent its relevance would be, in 3.4.3.2 Interpretation Semantics:

"Unless [compilation semantics have been appended by POSTPONE, or if] otherwise specified in an Interpretation: section of the glossary entry, the interpretation semantics of a Forth definition are its execution semantics."

That's the lacunea in the text, which has been used as part of the extant argument ...
... which the TC explicitly ruled to be a misinterpretation of what the TC intended when it specified the definition of POSTPONE.

However, it is not strictly speaking required, because the response to the RFI clarifies the issue. After all, the ANSI has been around for a century now ... the ANS Forth Standard was far from the first standard where an unintended implication was argued to follow from an interaction of different sections, and it certainly won't have been the last. That's why they have the RFI process.

Virtually,

BruceMcF, Beijing

[Anton Ertl]

Bruce McFarling <bruce.m...@gmail.com> writes:
>However, one approach which doesn't spend an extra cell per word ... though=
> it DOES require an entire additional vocabulary entry for each multiple-xt=
> word ... is to place the COMPILE-ONLY lexicon bit at bit5, with a compiler=
> mask for the lexicon_length byte of %11100000 and an interpreter mask of %=
>11000000 so that compiler-only words simply are not "seen" in interpret mod=
>e. Then if interpret-mode-S" is threaded into the dictionary before compile=
>r-mode-S" the interpret semantics are delivered in interpret state and the =
>compiler semantics are delivered in compile state.
>
>Another approach which is even more parsimonious in an implementation that =
>doesn't use a SMUDGE bit is to have three lexicon bits as IMMEDIATE, EXTENS=
>ION, COMPILE-ONLY and the EXTENSION returns a byte of flag bits that specif=
>y the nature of the vocabulary extension. If the EXTENSION bit is clear, #0=
> is returned, and the stored byte returned if EXTENSION is set ... so "spec=
>ial compiler semantics" would be allocated one extended status bit and it w=
>ould indicate a compiler semantics XT is stored in the dictionary entry.

There are many implementation approaches for dual-semantics words,
with different benefits and different costs.

If you only want to support system-defined words in the FORTH wordlist
as dual words (i.e., no user-defined dual words), and use a
linked-list dictionary implementation, a cmForth-like approach looks
particularly cheap:

In the dictionary, first define the implementations of the
interpretation semantics, e.g.:

: s" '"' parse copy-to-buffer ;

Then have a block of definitions that contains only implementations of
the compilation semantics of dual and compile-only words, e.g.:

: s" '"' parse postpone sliteral ; immediate

Now assume X is the last word defined before this block, Y is the last
word in this block, and Z is the first word after this block. Then
this block can be made invisible by redirecting the link field of Z to
X, and made visible again by redirecting this link field to Y:

: comp-invisible [ ' X >NFA ] literal [ ' Z >LFA ] literal ! ;
: comp-visible [ ' Y >NFA ] literal [ ' Z >LFA ] literal ! ;

[ can call COMP-INVISIBLE, ] can call COMP-VISIBLE. ' and ['] can
save the visibility, call COMP-INVISIBLE, search for the word, then
restore the visibility. POSTPONE can work similarly, but call
COMP-VISIBLE.

A drawback of this approach is that you cannot implement nts and
words using them (at least I don't see a good way to do it).

[Bruce McFarling]

On Friday, September 25, 2020 at 12:58:24 AM UTC+8, Anton Ertl wrote:
> A drawback of this approach is that you cannot implement nts and
> words using them (at least I don't see a good way to do it).

Yes, in addition to the namespace saving, an additional advantage of an extended lexicon status bit to indicate the presence of a compilation-xt is that it remains compatible with nt's. Compile-only as the lowest lexicon bit which is masked when finding in compile state and unmasked when finding in interpret state shares with the cmForth approach that it requires some additional machinery if you want to support NTs ... and if, for example, that machinery is a status bit to indicate that there is another compilation-mode dictionary entry of the same name and a pointer to it, you may as well have a status bit to indicate there is another compilation-mode XT and store that XT.

Virtually,
BruceMcF, Beijing

[A. K.]

It becomes simple and namespace-saving with different-sized headers for
normal and dual-xt words.

[Bruce McFarling]

It is particularly straightforward with the separated wordlist model in the eForth that I am porting, since it builds the wordlist down ... it first stashes the name below the previous wordlist entry, including length/lexicons, then the link to the previous entry, then the xt for the definition. A "extended status" lexicon bit can then refer to a byte below that and below that would be whatever data is implied to be present by the bits set in that extended status byte.

So it would be straightforward to have a:

: <name> ... interpretation semantics ... ;
:COMPILES ... compiler semantics ... COMPILES;

... kind of system.

Virtually,
BruceMcF, Beijing

[Anton Ertl]

Bruce McFarling <bruce.m...@gmail.com> writes:
>Yes, in addition to the namespace saving, an additional advantage of an ext=
>ended lexicon status bit to indicate the presence of a compilation-xt is th=

>at it remains compatible with nt's.

Another relatively cheap-to-implement approach that is compatible with
nts and with hashed dictionary lookup is to have a separate lookup
table nt->xt that gives you the other semantics of the nt. E.g., the
regular xt of the dictionary entry might represent the compilation
semantics, while the xt represents the interpretation semantics. You
can check the lookup table for every NAME>INTERPRET (even a linear
search in the small table is relatively cheap), or only if the
immediate bit is set; or only if the compile-only bit is set if the
header has that.

Advantages: You don't need an extra header bit, and avoid
complications for allowing an optional extra cell in the header. This
approach can be easily added to an existing implementation.

Disadvantages: you need an extra cell for the nt key in the lookup
table; the lookup table is either fixed-size, or needs extra
complications and memory for making it extensible (e.g., a linked
list).

The first implementation of dual words in Gforth was along these lines
(section 5.1, subsections "First implementation" and "Experiences" of
<https://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf>):
When the pre-existing compile-only bit is set, the NT/NFA is looked up
in a table, giving the xt for the corresponding interpretation
semantics xt if successful (the word is really compile-only
otherwise). The lookup table was implemented as case-insensitive
wordlist in the dictionary, but for a small implementation I would go
for an array.