From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl writes:

In article <2024Mar10.193700@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

minforth@gmx.net (minforth) writes:
However,

: foo 123 >r :noname r> postpone literal postpone ; ;
foo execute . \ prints 123
is guaranteed to work in Forth-94 (ISO Forth) and Forth-2012.

I thought that
"
123 >r : noname r> postpone literal postpone ;
noname . \ prints 123
"
is not guaranteed to work in Forth-94 (ISO Forth).
Why is this different?

The latter is non-standard because interpretation semantics for >R are undefined. Also, the definition of NONAME is not finished, and if it
was finished, then calling NONAME results in NONAME taking a value
from the return stack that it did not put there.

Why are you asking that question? You should know that.

- 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 2023: https://euro.theforth.net/2023
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <2024Mar10.193700@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

minforth@gmx.net (minforth) writes:

Although I find it obvious and not worth the hassle, the specification >>should be amended so that "a program shall not use the return stack to
pass data between outer and inner functions, i.e. from an enclosing word
to its inner quotation(s) of any nesting depth, or from a quotation to
its outer enclosing word regardless of its nesting depth".

If you think so, make a proposal. In the rest of the standard, the >compilation semantics of control-flow words communicate through the >control-flow stack, which usually is the data stack. I see no reason
to make an exception for [: ... ;].

This is the most expected way because analogously

123 >r :noname r> lit, ;

is also not guaranteed to work in ISO Forth.

However,

: foo 123 >r :noname r> postpone literal postpone ; ;
foo execute . \ prints 123

is guaranteed to work in Forth-94 (ISO Forth) and Forth-2012.

I thought that
"
123 >r : noname r> postpone literal ;
noname . \ prints 123
"
is not guaranteed to work in Forth-94 (ISO Forth).
Why is this different?
This is assuming >R works in interpret mode, such as gforth.

Ignore the previous answer, I forget to delete a postpone.

- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 2024-03-07 20:53, Ruvim wrote:

On 2024-03-07 20:18, minforth wrote:

Ruvim wrote:

The accepted proposal for quotations [1] specifies only compilation
semantics for the words "[:" and ";]".

The expected interpretation semantics for "[: ... ;]" are ...

Expected by whom?

By me and many other people.

Some Forth systems are actually implement these interpretation semantics (some of them for the case when the current definition is absent only).

I'd rather prefer some error message on a stray [: or ;] (principle of
least surprise)

According to the principle of least surprising, interpreting a
definition name should be equivalent to interpreting of the definition
body.

And if they are not equivalent — it should be for some clear and convincing reason.  For example, `exit` can be used only in a definition body.

Let's take the definition:
  : foo [: 123 . ;] execute ;

There is no a convincing reason why the following lines should not be observationally equivalent:
  foo
  [: 123 . ;] execute

BTW, a fundamental property of a pure concatenative language is that in
the same lexical environment, *any* call to a definition can always be replaced by the definition's body.

In Forth, it's not always possible, especially when a definition is used interpretively (e.g., if it's name is encountered by the Forth text interpreter in interpretation state) — due to some special words like control-flow words, r-stack operations, parsing words, local variables,
etc, which impose corresponding restrictions on their use.

If it is not too difficult to implement a word or construct without such restrictions, then it is worth implementing. Because it makes learning
and testing code much easier.

So, it's worth implementing interpretation semantics for such words as
`[']`, `[char]`, `c"`, `."`, `abort"`, `postpone`, "[: ... ;]", "if ...
else ... then", `>r`, `r>`, etc.

NB: R-stack operations shall affect a separate stack in their
interpretation semantics to avoid problems in edge cases in a
user-defined text interpreter [1].


[1] https://forth-standard.org/standard/tools/SYNONYM#reply-703

--
Ruvim
--- Synchronet 3.20a-Linux NewsLink 1.114