On 2022-10-05 17:12, minf...@arcor.de wrote:

Ruvim schrieb am Mittwoch, 5. Oktober 2022 um 14:45:20 UTC+2:

On 2022-10-05 16:17, Gerry Jackson wrote:

On 04/10/2022 22:53, Ruvim wrote:

On 2022-10-04 01:10, Gerry Jackson wrote:

On 29/09/2022 11:20, Krishna Myneni wrote:

On 9/29/22 02:24, minf...@arcor.de wrote:

I was only wondering if your idea could be extended to +TO.

Yes, it can; however, if you need to use +TO my advice would be to >>>>>> not use a VALUE (or FVALUE or other extended VALUE) but go back to >>>>>> VARIABLEs. One can use of +! , F+! (not currently standard, but
necessary), etc. with corresponding variables. A drawback of TO and >>>>>> extensions such as +TO is that various Forth operations such as '
(tick), ['], POSTPONE, etc. on them results in an ambiguous
condition in standard Forth.

If I define +TO as (using standard Forth):

: +to ( n "name" -- )
parse-name 2>r ( -- n ) ( R: -- ca u )
2r@ s" + to " 2r@
<# holds holds holds 2r> #> evaluate
; immediate

which given
+to x
on a value x evaluates
x + to x

' ['] and POSTPONE can be applied to +TO. It may need special
compilation semantics for some cases but that's beside the point.

Having an opaque implementation for "+to", Tick should not be applied
to "+to" in a standard program while execution semantics are not
specified for "+to" in the documentation.

Sorry, I thought the semantics of +TO was well understood so
documentation was unnecessary in a c.l.f discussion

What are well understood are the interpretation semantics and
compilation semantics for "+to", but not execution semantics.

If the phrase:
' +to
returns an xt, this xt identifies some execution semantics. And these
execution semantics may vary, if you don't specify it in a
documentation/standard/etc. (NB: I consider a case of opaque
implementations).

"postpone" may be applied to "+to" in any case. But the behavior of
the containing definition in interpretation state is ambiguous if the
system provides not fully compliant "postpone".

A test case:

: compiling(+to) postpone +to ;
0 value x
: test-x 10 [ compiling(+to) x ] x ;
x . test-x . \ should print "0 10"

If this test fails, the system /effectively/ imposes an environmental
restriction: a program should not start performing compilation
semantics in interpretation state.

Yes my system and others failed test-x. To make this work something like >>> a compile only word [+TO] needs to be defined

To make this work something like a fully compliant "postpone" should be
defined.

See: https://github.com/ForthHub/discussion/discussions/105

As long as the Forth-2012 Test Suite is passed successfully,
a system's POSTPONE implementation is good enough.

The Test Suit doesn't cover all the cases.

I created a new test case. At the moment, no one pointed out a mistake
in my reasoning, or shown that this test is incorrect.

https://github.com/ForthHub/discussion/discussions/103


Anyway, it's OK to stick with the mentioned environmental restriction,
if it's good enough for you.

If not, a reference implementation should be added here: https://forth-standard.org/standard/implement

Reference implementations are not normative and optional:

https://forth-standard.org/proposals/reference-implementations-are-not-normative#reply-772


--
Ruvim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ruvim schrieb am Mittwoch, 5. Oktober 2022 um 16:22:20 UTC+2:

On 2022-10-05 17:12, minf...@arcor.de wrote:

Ruvim schrieb am Mittwoch, 5. Oktober 2022 um 14:45:20 UTC+2:

On 2022-10-05 16:17, Gerry Jackson wrote:

On 04/10/2022 22:53, Ruvim wrote:

On 2022-10-04 01:10, Gerry Jackson wrote:

On 29/09/2022 11:20, Krishna Myneni wrote:

On 9/29/22 02:24, minf...@arcor.de wrote:

I was only wondering if your idea could be extended to +TO.

Yes, it can; however, if you need to use +TO my advice would be to >>>>>> not use a VALUE (or FVALUE or other extended VALUE) but go back to >>>>>> VARIABLEs. One can use of +! , F+! (not currently standard, but
necessary), etc. with corresponding variables. A drawback of TO and >>>>>> extensions such as +TO is that various Forth operations such as ' >>>>>> (tick), ['], POSTPONE, etc. on them results in an ambiguous
condition in standard Forth.

If I define +TO as (using standard Forth):

: +to ( n "name" -- )
parse-name 2>r ( -- n ) ( R: -- ca u )
2r@ s" + to " 2r@
<# holds holds holds 2r> #> evaluate
; immediate

which given
+to x
on a value x evaluates
x + to x

' ['] and POSTPONE can be applied to +TO. It may need special
compilation semantics for some cases but that's beside the point.

Having an opaque implementation for "+to", Tick should not be applied >>>> to "+to" in a standard program while execution semantics are not
specified for "+to" in the documentation.

Sorry, I thought the semantics of +TO was well understood so
documentation was unnecessary in a c.l.f discussion

What are well understood are the interpretation semantics and
compilation semantics for "+to", but not execution semantics.

If the phrase:
' +to
returns an xt, this xt identifies some execution semantics. And these
execution semantics may vary, if you don't specify it in a
documentation/standard/etc. (NB: I consider a case of opaque
implementations).

"postpone" may be applied to "+to" in any case. But the behavior of
the containing definition in interpretation state is ambiguous if the >>>> system provides not fully compliant "postpone".

A test case:

: compiling(+to) postpone +to ;
0 value x
: test-x 10 [ compiling(+to) x ] x ;
x . test-x . \ should print "0 10"

If this test fails, the system /effectively/ imposes an environmental >>>> restriction: a program should not start performing compilation
semantics in interpretation state.

Yes my system and others failed test-x. To make this work something like >>> a compile only word [+TO] needs to be defined

To make this work something like a fully compliant "postpone" should be
defined.

See: https://github.com/ForthHub/discussion/discussions/105

As long as the Forth-2012 Test Suite is passed successfully,
a system's POSTPONE implementation is good enough.

The Test Suit doesn't cover all the cases.

I created a new test case. At the moment, no one pointed out a mistake
in my reasoning, or shown that this test is incorrect.

https://github.com/ForthHub/discussion/discussions/103

Anyway, it's OK to stick with the mentioned environmental restriction,
if it's good enough for you.

You're right. I any case, hair splitting has become too precious with my
few remaining hairs. :o)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-08 15:39, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2022-09-29 21:43, Anton Ertl wrote:

Zbig <zbigniew2011@gmail.com> writes:

So state-smart words are bad

They are evil! [ertl98]

In this regard the paper shows that it's incorrect to implement an
ordinary word as an immediate word. So, it's not just evil, it's a mistake.

There are several aspects why state-smart words are worse than many
other mistakes:

1) They work as intended much of the time, and only behave wrongly in
corner cases.

It's a common case for bugs/mistakes in programs — a program behaves
wrongly due to some mistake in some corner cases only.

2) This seduces some people to try to argue (by language lawyering or
by declaring the standar to be buggy) that not the state-smart words,
but the corner case is a mistake; i.e., indemnify the implementation
by blaming the programmer.

Concerning "postpone" — I blame implementations ;)

3) In your case it's even worse, because AFAICS you try to declare not
just the corner case usage, but also all widely used systems as buggy
through language-lawyering.

I expressed my position many times concerning "postpone" (and probably
never called widely used systems as buggy in this regard).

For example, on 2020-09-23 [1], in answer to your message:
|| 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.

[1] Re: Semantics of POSTPONE and immediate words news://rke4a2$i5i$1@dont-email.me https://groups.google.com/g/comp.lang.forth/c/ildjR6oy6hg/m/caArstkVBgAJ

Now I talk more precisely.

The well known popular implementation for "postpone" effectively imposes
an environmental restriction on programs — namely, a program is not
allowed to perform compilation semantics in interpretation state (in
general case). Actually, this restriction was explicitly stated in
Forth-79 and Forth-84, but it is absent in Forth-94 (IIRC, some Forth94
TC members said that this restriction was always implied, so its absent
is just an omission).

Anyway, a standard system may impose environmental restrictions.
Moreover, this particular restriction was supported by Forth-94 TC,
according to their RFI Q99-027/A99-027.

But a better way, of course, to implement "postpone" without this
restriction.

But concerning 's"' (and other combined words) the paper only says (in
the section 3, on page 3):

| This definition behaves correctly as long as it
| is only processed by the text interpreter,
| but it fails with ', postpone, etc.,
| as discussed in Section 2.

This reasoning is wrong:
1. actually, it does not fail with ' (Tick);
2. if it fails with "postpone", then a problem is in "postpone", and
the problem should be corrected in "postpone".

I explained [1] why it doesn't fail with Tick:

It's obvious that in the general case, performing execution semantics in
compilation state may be inequivalent to performing these execution
semantics in interpretation state.

Apart from the difference in the contents of STATE, there must not be
a difference between the behaviour.

I don't quite understand what do you mean by this.

S" is not specified as a STATE-dependent word,
so for it there should be no difference.

This argument is not quite clear and seems to be wrong.

">r", "to", "evaluate", "[", "]" are not specified as STATE-dependent
words too, — does it mean that there should be no difference? No.

And we don't have any ground to say
that they should be equivalent in the case of the s" word, since the
execution semantics for s" are not specified by the standard.

(¹)

Possibly, but ' arguably should produce an execution token for the interpretation semantics of a word.

"... for the interpretation semantics" — it's too loose wording. It
isn't a verifiable proposition.

Probably you want to say that executing in interpretation state the
execution token that Tick returns for a word shall perform the
interpretation semantics for this word. (²)

Where "to execute an execution token" means to perform the execution
semantics identified by this execution token.

I can agree with this more precise wording.

Arguments for that position:

1) 6.1.0070 ' says:

|When interpreting, ' xyz EXECUTE is equivalent to xyz.

So when interpreting,

' S" execute bla"

is equivalent to

S" bla" >
2) "4.1.2 Ambiguous conditions" explicitly disallows

|attempting to obtain the execution token, (e.g., with 6.1.0070 ',
|6.1.1550 FIND, etc. of a definition with undefined interpretation |semantics;

but not of words without execution semantics.

These arguments say for the precise wording (²), but they still say
nothing against (¹).


So, nothing in the Standard precludes an implementation from providing STATE-dependent execution semantics for 's"'.



If you think, Forth-94 TC meant STATE-independent execution semantics
for 's"', then they failed to specify it that way.

To specify it that way, it would be enough to rename "Interpretation:"
to "Execution:" in the glossary entry for 's"'.

BTW, I already provided you with this argument in my message on
2019-10-01Z [2], didn't see your answer on that.

[2] Re: Semantics rethinking, 2019-10-01Z
news://qn0hfp$25u$1@dont-email.me https://groups.google.com/g/comp.lang.forth/c/wYqHc5hqVjQ/m/V3vdluLuAwAJ


Concerning ambiguous conditions — in Forth-2012 an ambiguous condition
exists if Tick is applied to any word without specified execution
semantics, but 's"' and 's\"'. Probably, it's just an omission.



--
Ruvim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ruvim <ruvim.pinka@gmail.com> writes:

On 2022-10-08 15:39, Anton Ertl wrote:

3) In your case it's even worse, because AFAICS you try to declare not
just the corner case usage, but also all widely used systems as buggy
through language-lawyering.

I expressed my position many times concerning "postpone" (and probably
never called widely used systems as buggy in this regard).

You made statements about how you think a standard system must behave
that no system complies with, in particular with respect to test cases
like:

: [.state] state @ . ; immediate
: .state postpone [.state] ;
.state \ prints 0

AFAIK your position is that this must print -1. No system I have
tested behaves that way.

The well known popular implementation for "postpone" effectively imposes
an environmental restriction on programs — namely, a program is not
allowed to perform compilation semantics in interpretation state (in
general case).

That's just weasel-wording for claiming that it's non-standard. And
given that the systems do not document such an environmental
restriction, they would just not be standard-compliant, if your claim
was true.

But concerning 's"' (and other combined words) the paper only says (in
the section 3, on page 3):

| This definition behaves correctly as long as it
| is only processed by the text interpreter,
| but it fails with ', postpone, etc.,
| as discussed in Section 2.

This reasoning is wrong:
1. actually, it does not fail with ' (Tick);
2. if it fails with "postpone", then a problem is in "postpone", and
the problem should be corrected in "postpone".

I explained [1] why it doesn't fail with Tick:

It's obvious that in the general case, performing execution semantics in >>> compilation state may be inequivalent to performing these execution
semantics in interpretation state.

Apart from the difference in the contents of STATE, there must not be
a difference between the behaviour.

I don't quite understand what do you mean by this.

Consider:

: .state state @ . ;
: ]execute[ ] execute postpone [ ;
' .state ]execute[ \ print -1
' .state execute \ print 0

So code that reads STATE often behaves somewhat differently depending
on the contents of STATE, as shown above. That's like any other
global state, e.g.:

: .base-1 base @ 1- . ;
: hex-execute base @ >r hex execute r> base ! ;
: dec-execute base @ >r decimal execute r> base ! ;
' .base-1 hex-execute \ prints f
' .base-1 dec-execute \ prints 9

S" is not specified as a STATE-dependent word,
so for it there should be no difference.

This argument is not quite clear and seems to be wrong.

">r", "to", "evaluate", "[", "]" are not specified as STATE-dependent
words too, — does it mean that there should be no difference? No.

Apart from EVALUATE, yes. EVALUATE text-interprets the string, and
text interpretation is STATE-dependent. If

1 >r : foo [ r> ] literal ;

does not work on some systems, that's because of the text
interpreter's usage of the return stack, not because of anything to do
with STATE.

And we don't have any ground to say
that they should be equivalent in the case of the s" word, since the
execution semantics for s" are not specified by the standard.

(¹)

Possibly, but ' arguably should produce an execution token for the
interpretation semantics of a word.

"... for the interpretation semantics" — it's too loose wording. It
isn't a verifiable proposition.

' s" execute bla" type \ prints "bla"

and

: ]execute[ ] execute postpone [ ;
' s" ]execute[ bla" type \ prints "bla"

works as intended on Gforth, iForth, VFX64, but not on SwiftForth.

Probably you want to say that executing in interpretation state the
execution token that Tick returns for a word shall perform the
interpretation semantics for this word. (²)

No. I want to say that EXECUTEing the xt returned by tick performs
the interpretation semantics of the word.

Arguments for that position:

1) 6.1.0070 ' says:

|When interpreting, ' xyz EXECUTE is equivalent to xyz.

So when interpreting,

' S" execute bla"

is equivalent to

S" bla"

BTW, what's not verifiable here?

If you think, Forth-94 TC meant STATE-independent execution semantics
for 's"', then they failed to specify it that way.

I actually think that they wanted to allow STATE-smart implementation
of S", but they failed to specify it that way. If anybody wants to
have their state-smart S" blessed by the standard, they should make a
proposal for that. That has not happened yet.

Concerning ambiguous conditions — in Forth-2012 an ambiguous condition >exists if Tick is applied to any word without specified execution
semantics, but 's"' and 's\"'. Probably, it's just an omission.

Yes. But, as mentioned above, if you want to have your STATE-smart S"
and S\" become standard, make a proposal that allows such an
implementation.

- 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: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-24 16:15, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2022-10-08 15:39, Anton Ertl wrote:

3) In your case it's even worse, because AFAICS you try to declare not
just the corner case usage, but also all widely used systems as buggy
through language-lawyering.

I expressed my position many times concerning "postpone" (and probably
never called widely used systems as buggy in this regard).

You made statements about how you think a standard system must behave
that no system complies with, in particular with respect to test cases
like:

: [.state] state @ . ; immediate
: .state postpone [.state] ;
.state \ prints 0

AFAIK your position is that this must print -1. No system I have
tested behaves that way.

I have many systems that behave that way.

And for many of them, if a system does not behave that way initially, I
include a small polyfill [1], and the system magically become fully standard-compliant in this regard ;-)


[1] A standard compliant polyfill for "postpone" https://github.com/ForthHub/discussion/discussions/103#solution

--
Ruvim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-24 16:15, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2022-10-08 15:39, Anton Ertl wrote:

3) In your case it's even worse, because AFAICS you try to declare not
just the corner case usage, but also all widely used systems as buggy
through language-lawyering.

I expressed my position many times concerning "postpone" (and probably
never called widely used systems as buggy in this regard).

[...]

The well known popular implementation for "postpone" effectively imposes
an environmental restriction on programs — namely, a program is not
allowed to perform compilation semantics in interpretation state (in
general case).

That's just weasel-wording for claiming that it's non-standard. And
given that the systems do not document such an environmental
restriction, they would just not be standard-compliant, if your claim
was true.

Well, it seems you are agree that many systems *effectively* impose this restriction on programs (correct me if I'm wrong). And the only question
is whether they should document this restriction, or this restriction
follows from the standard (normative parts of).

My conclusion is that it does not follow from the standard.


As I showed in my other message [1], a limited implementation for
"postpone" along with the corresponding environmental restriction was
actually considered by the Forth-94 TC as a possible option for a
standard system.

By the limited "postpone" I mean one that when it's applied to an
immediate word, appends the execution semantics of the word (instead of
the compilation semantics) to the current definition. Consequently, the
code appended by the limited "postpone" should not be executed in interpretation state in the general case (although, in some particular
cases it may).

But the section A.6.1.0190, which presumes this option, is not
normative. And there is no a normative section that implies the
mentioned restriction. So, a strongly standard system shall document
this environmental restriction (if any).

OTOH, a system that can be made strongly standard by merely changing its documentation can be considered as almost standard system.

And I never checked whether some system fulfills all the documentation requirements. This criterion will be at the end of the list if I would
evaluate degree of standard-compliance for a system.

Since, a practical question is what environmental restrictions a system *effectively* imposes on programs (regardless what its documentation
says), and how far is the system from a fully standard system (i.e. a
system without environmental restrictions).




[1] Re: POSTPONE and semantics of immediate words, 2022-10-25, 15:43Z news://tj906s$1trj2$2@dont-email.me https://groups.google.com/g/comp.lang.forth/c/rjbRkJPLMpY/m/K_fW332AAQAJ


[...]

--
Ruvim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-11-02 18:16, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2022-10-09 08:19, Anton Ertl wrote:

Gerry Jackson <do-not-use@swldwa.uk> writes:

On 04/10/2022 22:53, Ruvim wrote:

On 2022-10-04 01:10, Gerry Jackson wrote:

: +to  ( n "name" -- )
    parse-name 2>r          ( -- n ) ( R: -- ca u )
    2r@ s"  + to " 2r@
    <# holds holds holds 2r> #> evaluate
; immediate

...

' ['] and POSTPONE can be applied to +TO. It may need special
compilation semantics for some cases but that's beside the point.

Forgot to comment on this earlier, but this posting shows why you may
want to document POSTPONE +TO as ambiguous (and also all the other cases). >>>

  : compiling(+to) postpone +to ;
  0 value x
  : test-x 10 [ compiling(+to) x ] x ;
  x . test-x . \ should print "0 10"

...

Yes my system and others failed test-x.

That's because +TO is state-smart (with the state dependence coming
from EVALUATE).

NB: if the system provides a full-compliant implementation for
"postpone" then this "+to" is not state-smart [1]

(1)

[1] Anton Ertl, Re: WL-TOOLS and ?IMMEDIATE, 2019-09-21Z
news://2019Sep21.164152@mips.complang.tuwien.ac.at
https://groups.google.com/g/comp.lang.forth/c/wYqHc5hqVjQ/m/CSVN_agwBAAJ

| So if POSTPONE eliminates this STATE-dependence,
| the word is not STATE-smart.

Note the context of this statement: A POSTPONE that special-cases a
word where the implementation looks state-smart and actually appends a state-dumb behaviour to the current definition.

I don't see a contradiction with my statement (1).

Probably, a more accurate/formal definition for your term "STATE-smart"
could help.

I.e., a POSTPONE that does something like

: postpone
parse-name find-name dup [ s" +to" find-name ] literal = if
... \ append some state-dumb behaviour to the current definition
then
\ deal with other words
name>compile swap postpone literal compile, ;

What matters in this question is the specification, not the
implementation internal details.




[...]

When you throw some user-defined STATE-smart word at it, POSTPONE will produce a STATE-smart result, as every system I have tested does, and
which is standard behaviour IMO.

Here you give again two propositions, which I have already commented in
this thread:

1. In the systems that you tested, "postpone" appends execution
semantics of the word when it's applied to an immediate word.

2. This behavior of "postpone" is standard compliant.


If you try to proof the second proposition via the first one, you get
into the logical fallacy "Appeal to authority". So the first proposition neither proofs nor disproves the second one.


Also, these propositions don't mean that other behavior of "postpone" is
not standard compliant (e.g., how it behaves in my implementation). So
they are not connected to my statement (1) at all. Please, let me know
if you actually wanted to say that the mentioned behavior is the *only* standard behavior.



Concerning the second proposition by itself.

This behavior was standard for "[compile]" in Forth-79 and Forth-83.

In the frame of Forth-94, the conclusion that this behavior for
"postpone" is fully standard compliant (i.e., without environmental restrictions) only follows from your peculiar understanding of the
"compilation semantics" notion, which I already challenged.


By the way, what *practical* benefits follows from this understanding?
(apart from easier implementations, due to absent of motivation to make
it better, of course)

I asked this question in different forms several times already (for
example [1]), nobody has provided even one example.




[1] Compilation semantics and name>compile (was: Demonstration of Dual Semantics Forth), 2022-10-29, 20:33Z
news://tjk2ml$3lbli$1@dont-email.me https://groups.google.com/g/comp.lang.forth/c/O3ysyEOropM/m/79zxbaVqAQAJ


--
Ruvim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-24 16:15, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2022-10-08 15:39, Anton Ertl wrote:

On 2022-10-01 17:27Z, Ruvim wrote:

But concerning 's"' (and other combined words) the paper only says (in >>>> the section 3, on page 3):

| This definition behaves correctly as long as it
| is only processed by the text interpreter,
| but it fails with ', postpone, etc.,
| as discussed in Section 2.

This reasoning is wrong:
1. actually, it does not fail with ' (Tick);
2. if it fails with "postpone", then a problem is in "postpone", and >>>> the problem should be corrected in "postpone".

I explained [1] why it doesn't fail with Tick:

It's obvious that in the general case, performing execution semantics in >>>> compilation state may be inequivalent to performing these execution
semantics in interpretation state.

Apart from the difference in the contents of STATE, there must not be
a difference between the behaviour.

I don't quite understand what do you mean by this.

Consider:

: .state state @ . ;
: ]execute[ ] execute postpone [ ;
' .state ]execute[ \ print -1
' .state execute \ print 0

So code that reads STATE often behaves somewhat differently depending
on the contents of STATE, as shown above.

And what?

Tick returns an execution token that identifies some *execution*
semantics. In the general case it can be STATE-dependent execution
semantics.

And for the word ".state" you define STATE-dependent execution
semantics. And so they demonstrate the different effects in the
different STATE.

That's like any other global state, e.g.:

: .base-1 base @ 1- . ;
: hex-execute base @ >r hex execute r> base ! ;
: dec-execute base @ >r decimal execute r> base ! ;
' .base-1 hex-execute \ prints f
' .base-1 dec-execute \ prints 9

Yes.

Similar, we could introduce hex-semantics — a behavior in hex-base (i.e.
the effects that can be observed when execution was started in
hex-base), and dec-semantics — a behavior in dec-base. NB: we always
talk about *observable* behaviors only.

What are the hex-semantics for the word "decimal"?
— they are to put #10 into "base".

What are the hex-semantics for the word "hex"?
— they are to do nothing.

What are the dec-semantics of the word "decimal"?
— they are to do nothing.

Also we can see that your "hex-execute" performs the hex-semantics for a
word in most cases, but sometimes it interferes and fails. An example of
fail:

hex decimal .base-1 \ prints "9"
hex ' decimal hex-execute .base-1 \ prints "f"

In this case the hex-semantics for "decimal" are not performed by "hex-execute".

S" is not specified as a STATE-dependent word,
so for it there should be no difference.

It's impossible to specify both *observable* and STATE-dependent
interpretation semantics (ditto for compilation semantics). See also my examples about "base" above.

Hence, you probably talk about execution semantics (the same as in your examples above). But the execution semantics for 's"' are not specified
at all. They are specified as neither STATE-dependent nor STATE-independent.


Then, you have got into a logical fallacy, since your reasoning leads to contrary conclusions. Take a look:

- It is not specified as STATE-*dependent*, so there should be *no* difference.
- It is not specified as STATE-*independent*, so there should *be* difference.






[...]

--
Ruvim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-24 16:15, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2022-10-08 15:39, Anton Ertl wrote:

On 2022-10-01 17:27Z, Ruvim wrote:

But concerning 's"' (and other combined words) the paper only says (in >>>> the section 3, on page 3):

| This definition behaves correctly as long as it
| is only processed by the text interpreter,
| but it fails with ', postpone, etc.,
| as discussed in Section 2.

This reasoning is wrong:
1. actually, it does not fail with ' (Tick);
2. if it fails with "postpone", then a problem is in "postpone", and >>>> the problem should be corrected in "postpone".

I explained [1] why it doesn't fail with Tick:

It's obvious that in the general case, performing execution semantics in >>>> compilation state may be inequivalent to performing these execution
semantics in interpretation state.

[...]

And we don't have any ground to say
that they should be equivalent in the case of the s" word, since the
execution semantics for s" are not specified by the standard.

(¹)

Possibly, but ' arguably should produce an execution token for the
interpretation semantics of a word.

"... for the interpretation semantics" — it's too loose wording. It
isn't a verifiable proposition.

' s" execute bla" type \ prints "bla"

and

: ]execute[ ] execute postpone [ ;
' s" ]execute[ bla" type \ prints "bla"

works as intended on Gforth, iForth, VFX64, but not on SwiftForth.

By my view, and according to the classic single-xt approach (which was
an initial basis for Forth-94), it works as intended on SwiftForth,
Wina, minForth, cforth, pforth, SP-Forth, and many-many other, namely as:

' s" execute bla" type \ prints "bla"

: foo [ ' s" ]execute[ bla" ] type ; \ prints nothing
foo \ prints "bla"

But not on Gforth, iForth and VFX64.


Anyway, neither my nor your expectation concerning applying "]execute["
to the execution token of 's"' is based on the standard. Obviously,
Forth-94 allows both variants for systems, and hence the programs are restricted accordingly.

Probably you want to say that executing in interpretation state the
execution token that Tick returns for a word shall perform the
interpretation semantics for this word. (²)

No. I want to say that EXECUTEing the xt returned by tick performs
the interpretation semantics of the word.

Then you are wrong in the general case.

It works in this way in your system.

But in the straightforward single-xt systems it performs the
interpretation semantics of this word only if the system in
interpretation state, and it performs the compilation semantics
otherwise. And this behavior violates no standard requirements on Forth systems.

Arguments for that position:

1) 6.1.0070 ' says:

|When interpreting, ' xyz EXECUTE is equivalent to xyz.

So when interpreting,

' S" execute bla"

is equivalent to

S" bla"

BTW, what's not verifiable here?

This is verifiable in interpretation state only.

When you apply the general rule from 6.1.0070, you may only conclude
that the execution semantics of 's"' in interpretation state should be identical to the interpretation semantics for 's"'.

But there is no any normative fragment that allows you to conclude what
should these execution semantics in compilation state be.



[...]


--
Ruvim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <2022Oct24.181504@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>

Yes. But, as mentioned above, if you want to have your STATE-smart S"
and S\" become standard, make a proposal that allows such an
implementation.

I hope nobody does. Let's move to recognizing thingies that looks
like normal strings e.g. "we gaan naar Rome"

- anton

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-24 16:15, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2022-10-08 15:39, Anton Ertl wrote:

On 2022-10-01 17:27Z, Ruvim wrote:

But concerning 's"' (and other combined words) the paper only says (in >>>> the section 3, on page 3):

| This definition behaves correctly as long as it
| is only processed by the text interpreter,
| but it fails with ', postpone, etc.,
| as discussed in Section 2.

This reasoning is wrong:
1. actually, it does not fail with ' (Tick);
2. if it fails with "postpone", then a problem is in "postpone", and >>>> the problem should be corrected in "postpone".

I explained [1] why it doesn't fail with Tick:

It's obvious that in the general case, performing execution semantics in >>>> compilation state may be inequivalent to performing these execution
semantics in interpretation state.

[...]

And we don't have any ground to say
that they should be equivalent in the case of the s" word, since the
execution semantics for s" are not specified by the standard.

(¹)

Possibly, but ' arguably should produce an execution token for the
interpretation semantics of a word.

"... for the interpretation semantics" — it's too loose wording. It
isn't a verifiable proposition.

' s" execute bla" type \ prints "bla"

and

: ]execute[ ] execute postpone [ ;
' s" ]execute[ bla" type \ prints "bla"

[...]

If you think, Forth-94 TC meant STATE-independent execution semantics
for 's"', then they failed to specify it that way.

I actually think that they wanted to allow STATE-smart implementation
of S", but they failed to specify it that way.

My statement:
Forth-94 did not specify anything to disallow STATE-dependent
execution semantics for 's"', so it's allowed.

Your statement:
Forth-94 did not specify anything to allow STATE-smart implementation
of 's"', so it's disallowed.



1. Due to your vague term "STATE-smart" (which you still have not
accurately defined), it's unclear whether you object to me or not.

If you do, then, according to your view, what can be normatively
specified for 's"' that *allows* the phrases (a) and (b) to produce
different results?

(a) ' s" execute
(b) ' s" ]execute[

For example, which allows "foo2" (but not "foo1") to print "bla" by the following definitions:

: ]execute[ ] execute postpone [ ;
: ?t ( 0 | 0 sd -- ) dup if type then drop ;
: foo1 0 [ 0 ' s" execute bla" ?t ] ?t ;
: foo2 0 [ 0 ' s" ]execute[ bla" ?t ] ?t ;



2. Your statement means that there is some general normative ground by
which a particular implementation is not allowed for 's"', and it can be
only allowed by some explicit exception. But you cannot provide such a
ground.

Your only assertion: «'S"' is not specified as a STATE-dependent word»
And this assertion does not stand up to scrutiny [1].




[1] Re: POSTPONE and semantics of immediate words (was: Extended VALUEs
in Forth 200x)
2022-11-08, 00:48Z
news:tkc91q$3l73k$1@dont-email.me https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/vo1jtxeRDwAJ



--
Ruvim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)