Re: single-xt approach in the standard

On 2024-09-23 12:36, albert@spenarnc.xs4all.nl wrote:

In article <vcq1e5$25spg$7@dont-email.me>,
Ruvim  <ruvim.pinka@gmail.com> wrote:

On 2024-09-22 13:53, albert@spenarnc.xs4all.nl wrote:

In article <vcbuog$3etuk$3@dont-email.me>,
Ruvim  <ruvim.pinka@gmail.com> wrote:

On 2024-09-17 16:15, mhx wrote:

On Tue, 17 Sep 2024 10:54:37 +0000, Ruvim wrote:
>

Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
>
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.

>

[...]

>
The single-xt approach was used in Forth systems long before Forth-94.
Should this approach be possible for a standard system?
>
There is a point of view (which I don't share) that it is impossible to
implement the standard word `s"` (from the File word set) in a standard
*program*. I.e., that the following definition for `s"` is not standard
compliant:

The double negation makes it hard to understand.

Yes. Sometimes it's hard to express yourself clearly right away ))

You are of the opinion that it is possible to implement s" in a standard program.
You mean that the following code is standard compliant.

Yes. And my opinion is even stronger: this definition for `s"` both standard compliant and implements `s"` specified in the section 11.6.1.2165 of Forth-2012.
I also wanted to say that there is an opinion that this definition does not implement `s"` specified in 11.6.1.2165. An interesting question for those who share this opinion: how can 11.6.1.2165 be changed (if at all) to allow this implementation?  Maybe I have asked this before, but I can't find any answers at the moment.

You throw in the heap (ALLOCATE), that requires a powerful system, okay.
If you require SLITERAL ALLOCATE TUCK (that are not present e.g. in the
ciforth kernel) what is the probability that S" still has to be defined?

This does not matter. For example, if a program needs more than two buffers for `s"` interpretation, it might test and redefine `s"`.

(In ciforth it is already defined).

>
    : s" ( "ccc" -- sd | )
      [char] " parse
      state @ if postpone sliteral exit then
      dup >r allocate throw tuck r@ move r>
    ; immediate

>
/*****************************************************************************/
/*  This is not true.                                                        */
/*****************************************************************************/
>
I have demonstrated that it is possible to make numbers state smart
(the excursion to S" serves only to muddy the waters) where
the definition of number or S" doesn't contain a reference to STATE.

>
>
It seems, you have misunderstood what I said. I have said "in a standard
*program*", not "in a standard system".

 I misunderstood it. In fact the longer I look, the less I understand.
Of course a number of standard words cannot be portably implemented.
That is a remark I have made myself.

Agreed.

In this case you say that in
a Forth where an arbitrary set of difficult words are implemented
it is possible to define S" portably in terms of standard words.
So true.

Yes.

 If I add the condition that STATE is only used in INTERPRET,
that is cheating, and largely irrelevant.
 

>
This is important for standard libraries that may need to define or
redefine some standard words. Here by standard library I mean a standard
program that, when loaded, does not make the standard system non-standard.

 Agreed. However standard libraries are not useful in the context of
gforth where every imaginable word in the standard is present,
unless for the purpose of exactly defining meaning.

I mean, a possibility to define and redefine standard words is important for standard programs for which a Standard System must exist after the program is loaded.

>
See also "4.2.2 Other program documentation", that says:
| A program shall also document:
|  - whether a Standard System exists after the program is loaded.

I remember Algol68 went that route. Most features are explained
in Algol68 itself, with the remark that the implementer should
think of more clever ways to do it. Is this similar?

Maybe, but not quite :)

Even in some classic single-xt systems, one xt can be associated with
many nt. (of course, what is now "nt" was known as "NFA").

>
I cringe on this formulation.

>
This is what the standard says. Namely, the section "3.1.3.5 Execution
tokens" says: "Different definitions may have the same execution token
if the definitions are equivalent".
>
For example:
>
   1 constant a
   1 constant b
   ' a ' b = .
>
It is possible for a standard system to print "-1" when interpreting
this program.

 I have a hard time with this. I can't argue with the standard however.
"I cringe that this is in the standard."

Why?   This only adds some freedom to systems and imposes some light restrictions on programs (when xt-s of user-defined words are used as identifiers for some other things).
--
Ruvim