dxf <dxforth@gmail.com> writes:

Checking the doc it says:

9.3.5 Possible actions on an ambiguous condition

A system choosing to execute THROW when detecting one of the ambiguous
conditions listed in table 9.3.6 shall use the throw code listed there.

Calling ABORT or QUIT is not an ambiguous condition, so that section
plays no role there.

So while CATCH and THROW are compulsory (EXCEPTION wordset), there is no >requirement to implement any of the codes listed in the table. Only if
the EXCEPTION EXT wordset is implemented must the codes for ABORT and
ABORT" be used. Thus a system may implement the following if it wishes:

: QUIT -56 THROW ;

That would not be a standard system, because in a standard system QUIT
must do what 6.1.2050 QUIT says, and "-56 THROW" is not a correct implementation of 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 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

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

dxf <dxforth@gmail.com> writes:

On 4/05/2025 2:02 am, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:

Checking the doc it says:

9.3.5 Possible actions on an ambiguous condition

A system choosing to execute THROW when detecting one of the ambiguous
conditions listed in table 9.3.6 shall use the throw code listed there.

Calling ABORT or QUIT is not an ambiguous condition, so that section
plays no role there.

Yet ABORT ABORT" and QUIT are present in the table and assigned codes.

For ABORT the section 9.6.2.0670 specifies that it performs a -1
THROW. While -1 happens to be the value shown in table 9.1 as being
reserved for ABORT, there is no ambiguous condition involved here.
Likewise for -2, ABORT" and section 9.6.2.0680.

So table 9.1 is useful beyond the purpose of assigning throw codes to
ambiguous conditions. However, for QUIT there is no redefinition in
chapter 9.

It is clear to me all three are candidates for CATCHing and that this
was the intent.

It may have been the intent of adding the -56 throw code to also have
a corresponding redefinition of QUIT in Chapter 9, but they did not
follow through on it. Maybe because -56 THROW changes the data stack
depth while QUIT does not.

This is confirmed by the EXCEPTION EXT wordset in which
ABORT and ABORT" are required to be CATCHable irrespective of their
category.

Category?

A system that implements 9.6.2.0670 makes ABORT catchable, and a
system that implements 9.6.2.0680 makes ABORT" catchable. I find it
perverse that these words are in Exception ext, so you could have a
system that has CATCH, but an uncatchable ABORT and/or an uncatchable
ABORT". And for QUIT, the standard as it is does not have a catchable
variant at all.

: QUIT -56 THROW ;

That would not be a standard system, because in a standard system QUIT
must do what 6.1.2050 QUIT says, and "-56 THROW" is not a correct
implementation of that.

No for the fact QUIT is CATCHable by virtue of its inclusion in the table
of codes in Section 9.

There is nothing in the standard that makes such a connection (unlike
for ABORT and ABORT"). I don't know for what purpose -56 was added to
the table, but I know (and we have the proposal text) for what purpose
-59 (ALLOCATE) was added to the table, and it was not with the intent
of redefining ALLOCATE as

: ALLOCATE -59 THROW ;

So obviously it's just your interpretation of the table that if the
description of a throw code C contains a word name W, systems
implementing the exception wordset are free to redefine W as throwing
C.

If OTOH you believe the inclusion of ABORT ABORT"
and QUIT was made in error then you have the option of testing that by
making a proposal to have them removed.

The throw codes -1 and -2 were obviously added due to 9.6.2.0670 and 9.6.2.0680, not at all in error. I do not know why -56 was added, but
it does not hurt, and existing programs might use it, so there is no
good reason to remove it from the table.

Admittedly, the presence in the table results in no guarantees from
the standard, so removing the entry for -56 would not really hurt,
either. In any case, such a proposal would only poll the opinion of
the current committee, so it's not a way to find out whether the
Forth-94 committee consider the addition of -56 to the table as a
mistake.

If someone made a proposal to the committee, existing practice would
probably be considered more important than whatever we can still
determine about the intent of the Forth-94 committee. I don't know a
way to determine how many programs there are around that expect QUIT
to be catchable, or that expect it not to be catchable, but for
systems we can check relatively easily what they do:

Here's the code I give to the Forth systems:

1 .( a ) cr -56 throw .( b )
.s
2 .( a ) cr quit .( b )
.s
: foo 3 -56 throw ; ' foo catch 5
.s
: bar 4 quit ; ' bar catch 6
.s

Let's see what different Forth systems do:

Gforth 0.7.9_20250409
1 .( a ) cr -56 throw .( b ) a

*the terminal*:1:17: error: QUIT
1 .( a ) cr -56 >>>throw<<< .( b )
.s <0> ok
2 .( a ) cr quit .( b ) a

.s <1> 2 ok 1
: foo 3 -56 throw ; ' foo catch 5 ok 3
.s <3> 2 -56 5 ok 3
: bar 4 quit ; ' bar catch 6
.s <4> 2 -56 5 4 ok 4


iForth 5.1-mini
FORTH> 1 .( a ) cr -56 throw .( b ) a

FORTH> .s
Data: ---
System: ---
Float: --- ok
FORTH> 2 .( a ) cr quit .( b ) a

[1]FORTH> .s
Data: 2 ---
System: ---
Float: --- ok
[1]FORTH> : foo 3 -56 throw ; ' foo catch 5
[1]FORTH> .s
Data: 2 ---
System: ---
Float: --- ok
[1]FORTH> : bar 4 quit ; ' bar catch 6
[2]FORTH> .s
Data: 2 4 ---
System: ---
Float: --- ok

SwiftForth x64-Linux 4.0.0-RC89 15-Jul-2024
1 .( a ) cr -56 throw .( b ) a
QUIT
.s
<-Top ok
2 .( a ) cr quit .( b ) a
.s
2 <-Top ok
: foo 3 -56 throw ; ' foo catch 5 ok
.s
2 -56 5 <-Top ok
: bar 4 quit ; ' bar catch 6 .s
2 -56 5 4 <-Top ok

VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64

1 .( a ) cr -56 throw .( b ) a

No text available for THROW code -56(10)

1 .( a ) cr -56 throw .( b )

^
.s
DATA STACK
empty stack
ok
2 .( a ) cr quit .( b ) a

.s
DATA STACK
top
2 0000:0000:0000:0002
ok-1
: foo 3 -56 throw ; ' foo catch 5 ok-3
.s
DATA STACK
top
5 0000:0000:0000:0005
-56 FFFF:FFFF:FFFF:FFC8
2 0000:0000:0000:0002
ok-3
: bar 4 quit ; ' bar catch 6
.s
DATA STACK
top
4 0000:0000:0000:0004
5 0000:0000:0000:0005
-56 FFFF:FFFF:FFFF:FFC8
2 0000:0000:0000:0002

So Gforth, SwiftForth, and VFX behave the same way: QUIT is not
catchable, while -56 THROW is; QUIT does not produce output, while an
uncaught -56 THROW results in output from the system.

In iForth 5.1-mini QUIT preserves the stack while an uncaught -56
THROW resets it to empty (as it should); the uncaught -56 THROW does
not produce a message. For the cases with CATCH, the FOO variant does
not put the -56 on the stack and does not text-interpret the 5
afterwards, but it does preserve the 2 that was pushed earlier.
Strange. The BAR variant behaves as expected. If I try

2 : foo 3 1 throw ; ' foo catch 5
.s

iForth 5.1-mini behaves as follows:

FORTH> 2 : foo 3 1 throw ; ' foo catch 5 ok
[3]FORTH> .s
Data: 2 1 5 ---
System: ---
Float: --- ok

This is expected, so it seems to do something special for -56 THROW.

- 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 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

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

On Sun, 4 May 2025 13:33:31 +0000, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:

On 4/05/2025 2:02 am, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:

[..]

In iForth 5.1-mini QUIT preserves the stack while an uncaught -56
THROW resets it to empty (as it should); the uncaught -56 THROW does
not produce a message. For the cases with CATCH, the FOO variant does
not put the -56 on the stack and does not text-interpret the 5
afterwards, but it does preserve the 2 that was pushed earlier.
Strange. The BAR variant behaves as expected. If I try

2 : foo 3 1 throw ; ' foo catch 5
..s

iForth 5.1-mini behaves as follows:

FORTH> 2 : foo 3 1 throw ; ' foo catch 5 ok
[3]FORTH> .s
Data: 2 1 5 ---
System: ---
Float: --- ok

This is expected, so it seems to do something special for -56 THROW.

Searching for: -56 THROW
D:\dfwforth\examples\misc\risky-program.frt(3): \ A heated debate is
possible over the exact action -56 THROW should have. Should it QUIT ? D:\dfwforth\examples\misc\risky-program.frt(57): 2: 1999 12 [ -56 throw
-56 THROW executed
Found 3 occurrence(s) in 1 file(s), 39514 ms

There must have been a convincing reason.

-marcel

---
\ Het Vijgeblaadje #17, december 1999
\ CATCH en THROW (II) De Schoolmeester (Albert Nijhof)
\ A heated debate is possible over the exact action -56 THROW should
have.
\ Should it QUIT ?

ANEW -risky-program

: .DEPTH ( -- )
DEPTH 0 .R ." : "
DEPTH 0>= IF exit ENDIF
BEGIN 0 DEPTH 0= UNTIL \ Repair stack if necessary
." Stack underflow " ;

: .TOP2 ( -- )
DEPTH 1 > IF OVER . ENDIF
DEPTH IF DUP . ENDIF ;

: .TOP4 ( -- )
DEPTH 4 > IF ." ~ " ENDIF
DEPTH 2 > IF 2>R .TOP2 2R> ENDIF
.TOP2 ;

: STATE-SIGN ( -- )
STATE @ IF [CHAR] ]
ELSE [CHAR] [
ENDIF ;

: .SITUATION ( -- )
CR .DEPTH .TOP4 STATE-SIGN EMIT SPACE ;

CREATE inputbuffer #80 ALLOT

: INPUT ( -- addr len )
inputbuffer DUP #80 ACCEPT SPACE ;

: RISKY-PROGRAM ( --)
.SITUATION INPUT EVALUATE ;

: VB ( -- )
BEGIN
['] RISKY-PROGRAM CATCH
?DUP IF . ." THROW executed " ENDIF
AGAIN ;

DOC
(*
FORTH> vb
0: [ drop -4 THROW executed
0: [ 12
1: 12 [ 19

dxf <dxforth@gmail.com> writes:

On 6/05/2025 3:29 am, Ruvim wrote:

On 2025-05-05 08:11, dxf wrote:

: bar 4 quit ; ' bar catch 6

   stack is: -56 6

This violates `quit` 6.1.2050, because:
  - `quit` is not allowed to remove anything from the data stack (in this case, remove 4 from the stack);
  - `quit` is not allowed to place anything on the data stack (in this case, place `-56`);
  - `quit` is not allowed to interpret the remaining part of the input buffer  (in this case, interpret "6" and place 6 on the stack).

A caught ABORT does the same:

SwiftForth i386-Win32 3.11.9-RC1 01-Sep-2022

: bar 4 abort ; ' bar catch 6 .s
-1 6 <-Top ok

That's the correct behaviour of 9.6.2.0670 ABORT, not of 6.1.0670
ABORT [*]. So apparently your system implements 9.6.2.0670 ABORT, which
is compliant with the standard. For QUIT, there is only 6.1.2050
QUIT, and the behaviour your system exhibits does not comply with the requirements the standard specifies in section 6.1.2050.

[*] I think the standard makes little sense here: It does not give
much of a guarantee what behaviour a program can expect when it ABORTs
(or ABORT"s) while a CATCH is active. OTOH, a program that uses CATCH
can rely on the existence of THROW and therefore avoid the use of
ABORT or ABORT". The only issue is that someone might want to write a
library without relying on the presence of THROW, and instead use
ABORT or ABORT", and then that library is used by a program that uses
CATCH. For ABORT, the program can deal with this problem by defining

: ABORT -1 THROW ;

For ABORT", one can do a similar thing, but that typically loses some capability.

- 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 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

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

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

Yes, -1 and -2 are special cases in 9.6.1.2275 (when there is no user >exception frame). But for those cases it *only* specifies what message
shall be displayed, and *nothing more*.

BTW, for several decades Gforth did not comply with the standard
requirement not to print anything on ABORTing:

Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
abort
:1: Aborted

abort<<<

Backtrace:
$7F49ED85DA78 throw

Only after these decades somebody complained about that, and Gforth
was fixed to be standard-compliant in that respect, too. But it seems
that hardly anybody cares about that deviation.

- 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 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

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

dxf <dxforth@gmail.com> writes:

Except THROW special-cased codes -1 and -2 effectively reserving their behaviour.
One can speculate why ANS didn't do so for -56 but to my mind QUIT when implemented
should function as expected i.e. -56 THROW uncaught should perform QUIT.

Currently the standard document does not agree with your mind, and
therefore standard-compliant systems don't work the way you would
like. You could try to write a proposal for what you have in mind.

- 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 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

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

In article <eb7292e0cd166c6a9c5ce7bd766179d4@www.novabbs.com>,
mhx <mhx@iae.nl> wrote:

On Sun, 4 May 2025 13:33:31 +0000, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:

On 4/05/2025 2:02 am, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:

[..]

In iForth 5.1-mini QUIT preserves the stack while an uncaught -56
THROW resets it to empty (as it should); the uncaught -56 THROW does
not produce a message. For the cases with CATCH, the FOO variant does
not put the -56 on the stack and does not text-interpret the 5
afterwards, but it does preserve the 2 that was pushed earlier.
Strange. The BAR variant behaves as expected. If I try

2 : foo 3 1 throw ; ' foo catch 5
..s

iForth 5.1-mini behaves as follows:

FORTH> 2 : foo 3 1 throw ; ' foo catch 5 ok
[3]FORTH> .s
Data: 2 1 5 ---
System: ---
Float: --- ok

This is expected, so it seems to do something special for -56 THROW.

Searching for: -56 THROW
D:\dfwforth\examples\misc\risky-program.frt(3): \ A heated debate is
possible over the exact action -56 THROW should have. Should it QUIT ? >D:\dfwforth\examples\misc\risky-program.frt(57): 2: 1999 12 [ -56 throw
-56 THROW executed
Found 3 occurrence(s) in 1 file(s), 39514 ms

There must have been a convincing reason.

The example shows that it only serves to give work to
standard lawyers.

-marcel

Example snipped.
<SNIP>

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

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

This whole thread is like a sleeping pill...

--

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

In article <vvg6l5$12kee$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:

On 2025-05-06 14:12, dxf wrote:

Irrespective of the merits such a change to the spec for THROW would
be not be practical given most systems appear to use ANS' QUIT-based
exception handler. But for new implementers or the curious here is
how I organised mine and which is readily changeable.


\ return to OS with exit code
: RETURN ( code -- ) ... ;

\ perform ANS QUIT
: (quit) ( -- ) r0 @ rp! reset normal /interpret
begin cr (refill) drop interpret state? 0= if (vstat)
@execute then again ;

\ exit to OS or back to forth
: ?return ( code -- ) turnkey? if return then drop (quit) ;

Returning to OS can be useful not only for a turnkey program, but also
for batch mode, in which the Forth system must return to the OS on any >uncaught error.

A possible use-case in Linux shell:

./generate-forth-program params | forth --batch-mode

since you probably prefer not to interpret the following lines if there
an error occurs when defining a word in some line.

\ clear data stacks
: (abort) ( i*x -- ) s0 @ sp! fs0 @ fsp ! 1 ?return ;

\ part of THROW
: error ( n -- )
-1 of (abort) then
-2 of boot cell+ @ 0= if .error then
space errmsg 2@ type (abort) then
." THROW #" @base decimal swap . !base (abort) ;

: QUIT ( -- ) 0 ?return ; \ QUIT not trapped

\ QUIT is not trapped in DX-Forth but may be made so by
\ adding -56 of 1 ?return then to 'error' and defining
\ : QUIT -56 throw ;

I use `quit` only for testing and debugging. And I expect to get into
the Forth text interpreter (Forth shell) exactly in the current program
state (as far as possible).

If `quit` simply calls `-56 throw`, the program state will probably
change (due to actions after `catch` in the program, including restoring
the data stack depth in `throw`) when you get into the Forth shell.
Also, there is a chance that you will not get into the Forth shell at
all if the program does not re-throw the error in some places.

So I would not recommend the suggested deviation in the `quit` behavior
even for new implementers, since this brakes the well-known expectation
from `quit`. A better way is to introduce another word with desired
behavior deviation.

I introduced `break that does deviate from `QUIT only in not cleaning
the return stack. So you can debug from such a nested "shell" with
impunity. A soon as you type ^D into this shell, you can continue
as if nothing happened. Or you can amend the stack, maybe even the
return stack, is you know what you're doing.

Of course `break must save and restore the current input stream.
I have words for that. It is straightforward. Others have
proposed INTERPRET-WHILE-READING or some such words.
Maybe these words could define a `break, but not as easily.

: break
SAVE
BEGIN '(ACCEPT) CATCH DUP E_BROKEN_PIPE <> WHILE
?ERRUR SET-SRC INTERPRET REPEAT
DROP RESTORE
;

: QUIT
POSTPONE [
BEGIN
R0 @ RSP! \ this part is missing from break.
'(ACCEPT) CATCH DUP E_BROKEN_PIPE = IF
BYE THEN
?ERRUR 1+ SET-SRC INTERPRET OK AGAIN
;

'(ACCEPT) CATCH
is approximately
REFILL

: ?ABORT ( flag c-addr u -- )
rot if errmsg 2! -2 throw then 2drop ;

: (abort") ( flag -- ) r> count 2dup + >r ?abort ;

: ABORT" state @ if postpone (abort") ," end
postpone s" ?abort ; immediate

: ABORT -1 throw ;

I have banned ABORT" c.s to the source library.

--
Ruvim

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

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

In article <5069a2ba51509e4f92ffa680982a4e353ec45ab8@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 9/05/2025 4:20 pm, Ruvim wrote:

On 2025-05-09 04:54, dxf wrote:

On 8/05/2025 10:50 pm, Ruvim wrote:

On 2025-05-08 06:52, dxf wrote:

On 8/05/2025 3:52 am, Ruvim wrote:

...
I use `quit` only for testing and debugging. And I expect to get

into the Forth text interpreter (Forth shell) exactly in the current
program state (as far as possible).

If `quit` simply calls `-56 throw`, the program state will

probably change (due to actions after `catch` in the program, including >restoring the data stack depth in `throw`) when you get into the Forth
shell. Also, there is a chance that you will not get into the Forth
shell at all if the program does not re-throw the error in some places.

So I would not recommend the suggested deviation in the `quit`

behavior even for new implementers, since this brakes the well-known >expectation from `quit`. A better way is to introduce another word with >desired behavior deviation.

ANS never gave a rationale for ABORT ABORT" QUIT - only
options that we're now exploring.

For the reasons you've stated I'm reluctant to define:

: QUIT -56 THROW ;

But are there reasons an application might were THROW able
to handle it?

I don't see such a reason. The application can simply do
`abort` or `-56 throw` (and no special cases are needed).

Yes but those would be workarounds.  It's making the argument
QUIT can't or shouldn't be caught whereas I'm talking about
entitlement.

`BYE` and `EXIT` cannot be caught too.

QUIT is in the table; those are not. Besides BYE is an optional tool
and I've no idea what use is a catchable EXIT .

`QUIT` can be considered by the Forth program as a kind of `BYE` that >immediately returns control to the Forth shell (when `BYE` returns

control to the host OS).

Speaking of entitlement, ANS made EXCEPTION EXT a one-way street.
There's no rolling back from the changes.

If you mean that EXCEPTION EXT is not actually optional in itself, but

must be provided if EXCEPTION is provided — yes, I agree.

Not what I said but if you're going to enforce a catchable ABORT and
ABORT" then why omit QUIT - and if you do - why is it in table?

We can keep going round in circles but ISTM what's needed is a rationale. >Because I'm not seeing one in ANS. Folks have implemented what it said
but can't explain it. Hence the Bible allusion.

The whole discussion is pointless. The starting point should be what
is the central interpretation loop. I find QUIT a suitable candidate,
but if one is of a different opinion, one should say so.
This is a requirement for a sensible discussion what ABORT THROW and
whatnot are supposed to do with regards to the central interpretation
loop.
The first thing one should do separate the two cases:
1. there is a CATCH/THROW handler
2. there is no CATCH/THROW handler

Another question that arises: are there multiple interpretation loops?
If there are, you cannot ignore this in the discussion.

Abstract discussion like this could occur in discussing algol68, pascal
or haskell, not so much in discussing Forth.

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

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

dxf <dxforth@gmail.com> writes:

ANS made provision for a catchable QUIT.

No such provision is specified in 6.1.2050 QUIT, the only
specification of QUIT in ANS 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 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

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