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?

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

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

Ruvim wrote:

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

Then this should also be equivalent?

: BLA ." 1 " ;

BLA
" 1 "

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

Ruvim wrote:

On 2024-03-07 21:58, minforth wrote:

Ruvim wrote:

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

Then this should also be equivalent?

: BLA ." 1 " ;

BLA
" 1 "

Yes, `BLA` and `." 1 "`.

Yes,
BLA
and
." 1 "

They are not, they do different things: BLA does not parse the input stream.

Simmilarly: [: replacing :noname is not a quotation, it is just some kind
of alias.

Anyhow IMO quotations are crippled as long as they can't access upvalues.
E.g.
: TTT { a } [: a . ;] dup execute 2 to a execute ;
1 TTT -> 1 2

But then interpreting
[: a . ;]
makes no sense.

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

Ruvim wrote:

Anyhow IMO quotations are crippled as long as they can't access upvalues.
E.g.
: TTT  { a } [: a . ;] dup execute 2 to a execute ;
1 TTT -> 1 2

If they could access local variables of a containing definition — they should be called "closures", not "quotations".

Closures are a completely different matter. Closures own their own individual copy/reference of their lexical environment at the time of their creation.
TTT does not have this copy.

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

My quotation "model" with access to upvalues works here.
Useful now and then, but they cannot pass the man-or-boy test.

As I said, pure closures are a different thing altogether.
Read it up, if you are interested.

IIRC a while ago Anton Ertl and/or Bernd Paysan have implemented
closures for gforth:

: A {: w^ k x1 x2 x3 xt: x4 xt: x5 | w^ B :} recursive
k @ 0<= IF x4 x5 f+ ELSE
B k x1 x2 x3 action-of x4 [{: B k x1 x2 x3 x4 :}L
-1 k +!
k @ B @ x1 x2 x3 x4 A ;] dup B !
execute THEN ;

10 [: 1e ;] [: -1e ;] 2dup swap [: 0e ;] A f.

They introduced a special closure syntax, so quotations with
access to locals of the enclosing function must not be confused
with closures.

Additionally for your pleasure they also introduced interpreted [: ;] ;-)

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

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

On 2024-03-07 16:29, Ruvim wrote:

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

The expected interpretation semantics for "[: ... ;]" are that this
construct behaves like ":noname ... ;" (at least for the resulting stack
effect), but the system should correctly work regardless whether the
current definition exists (i.e., a definition that is being compiled).
It means, if a definition is being compiled, its compilation shall be
correctly suspended by "[:", and resumed after ";]" under the hood.

Bellow are the test cases for the standardized compilation semantics,
and for the expected interpretation semantics.

Interestingly, some Forth systems fail the t12 and t13 tests for the
standardized compilation semantics.

[...]

===== start of "quotation.test.fth"

\ Test cases for quotations "[: ... ;]"



\ Testing the compilation semantics

\ t11
t{ :noname [: 123 ;] ; execute execute -> 123 }t

: lit, postpone literal ;
: ([:) postpone [: ;
: (;]) postpone ;] ;

\ t12
t{ :noname [ ([:) (;]) ] ; 0<> -> -1 }t > \ t13
t{ :noname 1 [ ([:) 2 lit, (;]) ] 3 ; execute swap execute -> 1 3 2 }t

t12 roughly tests that the compilation semantics for the words "[:" and
";]" can be correctly performed programmatically.

This test fails in Gforth, VfxForth, minForth.

Is there any Forth system where this test succeeds? I.e., is this
supposed failure actually common practice?

The problem is that the system enters compilation state after executing >"([:)". But it shall not. This action cannot be a part of compilation >semantics at all (it's not possible to correctly specify this action,
and it is not actually specified for the "[:" compilation semantics).

Let's see. <http://www.forth200x.org/documents/forth19-1.pdf> says:

|Suspends compiling to the current definition, starts a new nested
|definition with execution token xt, and compilation continues with
|this nested definition.

The CfV on which it is based <http://www.forth200x.org/quotations.txt>
uses the same wording.

One could argue that "compilation continues" allows switching to
compilation state, so it's not clear that this test should succeed.
But anyway, it is better to improve the wording to make this switch
explicit.

And probably similarly for ";]". We would have to check whether all
systems switch to compilation state after the compilation semantics of
;], or whether some restore the state before "[:".

- 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

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

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

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

On 2024-03-07 16:29, Ruvim wrote:

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

The expected interpretation semantics for "[: ... ;]" are that this
construct behaves like ":noname ... ;" (at least for the resulting stack >>> effect), but the system should correctly work regardless whether the
current definition exists (i.e., a definition that is being compiled).
It means, if a definition is being compiled, its compilation shall be
correctly suspended by "[:", and resumed after ";]" under the hood.

Bellow are the test cases for the standardized compilation semantics,
and for the expected interpretation semantics.

Interestingly, some Forth systems fail the t12 and t13 tests for the
standardized compilation semantics.

[...]

===== start of "quotation.test.fth"

\ Test cases for quotations "[: ... ;]"



\ Testing the compilation semantics

\ t11
t{ :noname [: 123 ;] ; execute execute -> 123 }t

: lit, postpone literal ;
: ([:) postpone [: ;
: (;]) postpone ;] ;

\ t12
t{ :noname [ ([:) (;]) ] ; 0<> -> -1 }t > \ t13
t{ :noname 1 [ ([:) 2 lit, (;]) ] 3 ; execute swap execute -> 1 3 2 }t

t12 roughly tests that the compilation semantics for the words "[:" and >>";]" can be correctly performed programmatically.

This test fails in Gforth, VfxForth, minForth.

Is there any Forth system where this test succeeds? I.e., is this
supposed failure actually common practice?

The problem is that the system enters compilation state after executing >>"([:)". But it shall not. This action cannot be a part of compilation >>semantics at all (it's not possible to correctly specify this action,
and it is not actually specified for the "[:" compilation semantics).

Let's see. <http://www.forth200x.org/documents/forth19-1.pdf> says:

|Suspends compiling to the current definition, starts a new nested >|definition with execution token xt, and compilation continues with
|this nested definition.

The CfV on which it is based <http://www.forth200x.org/quotations.txt>
uses the same wording.

One could argue that "compilation continues" allows switching to
compilation state, so it's not clear that this test should succeed.
But anyway, it is better to improve the wording to make this switch
explicit.

And probably similarly for ";]". We would have to check whether all
systems switch to compilation state after the compilation semantics of
;], or whether some restore the state before "[:".

- anton

I replace both [: ;] and :NONAME ; with { } that leaves an xt, but
} restores the STATE that was present with {.
Note that ;] and ; do the same, as it happens that ;] restores the
compilation state present with [: .
Also ; restore the interpretation state present with :NONAME
Now [ ] and { } can be nested width impunity.

: double [ VARIABLE A ] A ! A @ { DUP + } EXECUTE ;
2 double .
4 OK
I avoid the pathological cases in the above test by restricting
words that parse ahead.

I have reworked shani's lisp using these { } constructs, and
use it also for mal (Make Another Lisp) github project.
So count me a fan of simple quotations.

Groetjes Albert


{ } and [ ] can be constructed with the four nestings.

Let's assume our Forth has the following mechanism available:

({) (}) brackets a piece of code and leaves an execution token, not dea.
Can be used outside a definition instead of :NONAME
As lightweight as possible.
Inside: compilation mode.

(( )) make sure dictionary space can be used between them by compiling an
AHEAD, or equivalent.

([) (]) New context for definitions, maybe in the middle of a word.
- tucks away onto the return stack, any data that could be spoiled by
compiling something, then recovers it again
In particular w.r.t. current wordlist, remove the information
what word is being compiled, then restore it again.
Inside: interpretation mode.

(s s) save and restore STATE.
--
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 -

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

Ruvim wrote:

In minForth, "[:" leaves some data on the return stack, and ";]"
consumes this data from the return stack (contrary to the
specification). So, it fails in the following test case:

t{ : [t14] ( -- ) 123 >r ([:) r> lit, (;]) ; immediate -> }t
t{ :noname [t14] ; execute execute -> 123 }t

What specification are you talking about? Your own?

I can't find [t14] in the standard compliance tests.

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

Thanks for pointing out this bug in the standard specification for quotations.

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".

This is the most expected way because analogously

123 >r :noname r> lit, ;

is also not guaranteed to work in ISO Forth.

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

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.

- 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

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

Anton Ertl 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 [: ... ;].

Some systems might use the return stack for local frames. But well, then follows probably 'implementation-defined' or 'ambiguity' ...

But if it is better for clarification and portability, Ruvim is right and
some more test cases should be added to the reference tests.

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.

There is no control flow here.

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

minforth@gmx.net (minforth) writes:

Anton Ertl 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 [: ... ;].

Some systems might use the return stack for local frames. But well, then >follows probably 'implementation-defined' or 'ambiguity' ...

How locals are stored is indeed implementation-defined, but there are
limits. E.g., a standard system must not store them on the data
stack, while the return stack is explicitly mentioned ("he storage
resource may be the return stack"), and other restrictions on standard
programs that use locals also make it easy for standard systems to use
the return stack for locals.

In any case, note that this is about where the locals reside at
run-time. When a standard system compiles locals, it must leave the
locals stack alone. Look at <https://forth-standard.org/standard/usage#subsection.3.1.5>: There
are system-compilation types on the control-flow stack (which may be
the data stack), and system-execution types on the return stack.

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.

There is no control flow here.

I consider calling and returning to be control-flow. In any case,
:NONAME has the stack effect ( C: -- colon-sys ) ( S: -- xt ), i.e.,
it pushes a colon-sys on the control-flow stack.

- 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

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

Anton Ertl wrote:

Look at
<https://forth-standard.org/standard/usage#subsection.3.1.5>: There
are system-compilation types on the control-flow stack (which may be
the data stack), and system-execution types on the return stack.

There in 3.2.3.3 Return Stack the standard stipulates that
"A system may use the return stack in an implementation-dependent manner ..
for storing run-time nesting information."

This is exactly the case in MinForth's definitions for nestable [: ;]
and why Ruvim's [T14] failed.

BTW many CATCH/THROW implementations use the return stack in a similar way, i.e. they don't use an exception stack.

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

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 postpone ;
noname . \ prints 123
"
is not guaranteed to work in Forth-94 (ISO Forth).
Why is this different?

M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html

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 -

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

Ruvim wrote:

BTW many CATCH/THROW implementations use the return stack in a similar way, >> i.e. they don't use an exception stack.

CATCH ( i*x xt -- j*x 0 | i*x n )

The state of the return stack after performing CATCH is the same as
before performing.

Performing CATCH ends with its inner EXECUTE. The part after EXECUTE is performed
by some THROW. Before that, nesting information is pushed onto the return stack:

VARIABLE HANDLER 0 HANDLER ! \ last exception handler

: CATCH ( xt -- exception# | 0 \ return addr on stack
SP@ >R ( xt ) \ save data stack pointer
HANDLER @ >R ( xt ) \ and previous handler
RP@ HANDLER ! ( xt ) \ set current handler
EXECUTE ( ) \ execute returns if no THROW
R> HANDLER ! ( ) \ restore previous handler
R> DROP ( ) \ discard saved stack ptr
0 ( 0 ) \ normal completion
;

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

On 7 Mar 2024 at 13:29:13 CET, "Ruvim" <ruvim.pinka@gmail.com> wrote:

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

The expected interpretation semantics for "[: ... ;]" are that this
construct behaves like ":noname ... ;"

...

Interestingly, some Forth systems fail the t12 and t13 tests for the standardized compilation semantics.

VFX implements [: and friends as NDCS words - words that have
Non-Default Compilation Semantics. Where the words behave correctly
and assumptions are then made about POSTPONE for non NDCS words,
MPE is not going assign priority to a fix.

In the time since we introduced NDCS words, there have been *no*
technical support issues about NDCS from application programmers.

\ t11
t{ :noname [: 123 ;] ; execute execute -> 123 }t

: lit, postpone literal ;
: ([:) postpone [: ;
: (;]) postpone ;] ;

\ t12
t{ :noname [ ([:) (;]) ] ; 0<-> -1 }t
\ t13
t{ :noname 1 [ ([:) 2 lit, (;]) ] 3 ; execute swap execute -> 1 3 2 }t

\ Testing the interpretation semantics
\ (the expected behavior)

\ t21
t{ depth [: ;] depth 1- = ?dup nip -> 0 }t
\ t22
t{ [: 123 ;] execute -> 123 }t
\ t23
t{ [: 1 [: 2 ;] 3 ;] execute swap execute -> 1 3 2 }t

\ Testing the interpretation semantics
\ doing compilation of another definition
\ (the expected behavior)

\ t31
t{ [: [ depth [: ;] depth 1- = ?dup nip ] literal ;] execute -> 0 }t
\ t32
t{ [: 1 [ [: 2 ;] ] literal 3 ;] execute swap execute -> 1 3 2 }t

===== end of "quotation.test.fth"

[1] http://www.forth200x.org/quotations-v4.txt

--
Ruvim

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com
MPE website
http://www.vfxforth.com/downloads/VfxCommunity/
downloads

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

This is my last reply to this fruitless language lawywering:

The function to be executed within CATCH receives nesting information
via the return stack. CATCH passes control over to that function, which
does with that information on the return stack what has to be done:
use it in an exception case or jump back for cleanup.

The point is, the standard is rather fuzzy in such points. The IMO
overzealous interpretation that return stack usage is forbidden unless
it is explicitly allowed, thereby ignoring 3.2.3.3 first paragraph, and building test cases on top of this overzealous interpretation, is moot.

--
Now back to my new 3-wheeler motorscooter for a happy sunny ride! :-)

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

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

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

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 -

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