Re: Semantics as observable behavior (was: single-xt approach in the standard)

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

On 2024-09-22 21:13, Anton Ertl wrote:

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

- All standard programs are single-xt programs (in the part of
user-defined words). Why we should remove the way to document this
programs/words in the standard terms of interpretation semantics,
compilation semantics and execution semantics?

 
Who proposes removing that?  I often write about the interpretatation
and compilation semantics of various words with default compilation
semantics or with immediate compilation semantics, and I see nobody
who wants to remove that possibility.
 
Examples:
 
: foo 1 ;
 
The execution semantics of FOO are to push 1 on the data stack.
The interpretation semantics of FOO are to push 1 on the data stack.
The compilation semantics of FOO are append the execution semantics of
FOO to the current definition.
 
: bar state @ ; immediate
 
The execution semantics of BAR are to push the contents of STATE on
the data stack.

>
Do you agree that this describes an observable behavior, not an
implementation?  And all the implementations for execution semantics
that show this behavior are observationally equivalent to each other?
>
For example, this definition:
>
: bar2  state @ if  state @  else  0  then ; immediate
>
is observationally equivalent to your `bar`.

Yes.  So what?

The interpretation semantics of BAR are to push the contents of STATE
on the data stack.

>
I think, we should use the black box model — specify what can be
observed. And according to what can be observed, the interpretation
semantics of this word are to push zero on the data stack.

No.

: [execute] execute ; immediate
s" bar" find-name name>interpret ] [execute] [ . \ prints -1

Use FIND-NAME or FIND-NAME-IN based on TRAVERSE-WORDLIST if the system
at hand does not implement FIND-NAME yet.

The compilation semantics of BAR are to push the contents of STATE on
the data stack.

>
>
>
Anton, forgive me for being blunt, but I think your understanding of
"interpretation semantics" and "compilation semantics" for words whose
execution semantics depend on STATE is useless both in practice and in
theory.

It's very useful, in particular for predicting how a system behaves.
I leave it up to you whether you consider this theory or practice.

Take a look at my next rationale.
>
When I'm interested in the interpretation semantics of a word, I'm
interested in precisely the behavior that can be *observed* when the
Forth text interpreter encounters the name of this word in
interpretation state.  And if I specify the interpretation semantics for
a word, I specify namely this behavior.

Now coming back from wishful thinking to reality, that's not how
systems behave.

If we say that the term "interpretation semantics" means something else
in some cases, we should introduce another term to denote the behavior
that can be observed when the Forth text interpreter encounters the name
of a word in interpretation state.

It's the other way 'round: The standard specifies the interpretation
semantics and compilation semantics of words (either explicitly, or
through default mechanisms), and the text interpreter then performs
the interpretation semantics when it encounters the word in interpret
state, and it performs the compilation semantics when it encounters
the word in compilation state.

In the example above, the standard specifies unambiguously how the
execution semantics of BAR derives from STATE and @, and how the
interpretation semantics and compilation semantics of BAR are derived
from the execution semantics of BAR.

With that we can then determine what code like
 
: bla postpone bar ; immediate
bla .     \ prints 0
] bla [ . \ prints -1
 
should do; I show the output in comments.  I just tested gforth,
iforth, SwiftForth, and VFX Forth, and unsurprisingly they all produce
the output shown in the comments.
 

>
[1] Well, I can see only one reason for using another meaning for the
"interpretation semantics" and "compilation semantics" terms than given
above: to represent the classic implementation of `postpone` as
conforming to what is formally specified in Forth-94, without accepting
into the standard the proposed ambiguous condition (see [2]).  But it is
better to honestly say that "postpone" appends execution semantics of
the word if this word is an immediate word. There is no need to blur the
meaning of terms.

The meaning of the compilation semantics of BAR is crystal-clear, and
likewise the interpretation semantics of BLA and the compilation
semantics of BLA.  There is nothing blurred here.

As to the definition of POSTPONE, it is very straightforward, and
every system implements it correctly.  No need for a redefinition.

They may not be what you wish for, but they are clearly defined.

- 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 2024: https://euro.theforth.net