On 8 Jan 2022 at 11:21:41 CET, "Anton Ertl" <Anton Ertl> wrote:
>
> Yes: Checking iForth, lxf, SwiftForth, and VFX, none of them has
> picked up EXCEPTION. This is probably because need for defining throw
> codes in libraries is rare, and I guess the low importance of
> libraries in Forth also plays a role. Anyway, if you want to write a
> library for Gforth, Gforth has had EXCEPTION since at least 1998.

The reason why we ignored EXCEPTION was that it did not do what we
wanted. VFX provides ERRDEF and friends.

ERRDEF <name> "<text>" \ -- n

At compile time this generates a CONSTANT called <name> associated
with the text for THROW number n. The constant n is incremented for the
next use of ERRDEF. There are variants of ERRDEF that take a value and
SYSERRDEF generates a number in the range -1..-4095.

These have been in VFX since v3.6.

Stephen

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

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2022-01-08 13:55, Anton Ertl wrote:
>> I don't know what dxforth means, but there is such a difference: A
>> library that is provided independent of systems cannot know what throw
>> codes are used by the system, and so has to define throw codes outside
>> the -4095..0 range. OTOH, a library that is provided by the system
>> implementor for a specific system can know which throw codes the
>> system uses and in that case the lowest collision risk is if the
>> library uses throw codes in the -4095..-1 range that are not used by
>> anything else in the system (nor any other system library).
>
>
>Does it mean that if some vendor includes some portable library into its
>system, it should also change the throw codes in this library to the
>-4095..-256 range?

That would be ideal for eliminating collision risks, but the fact that
we are considering such measures points to a lack in the Forth
standard.

>> As an example, the version of EXCEPTION in the compat library uses
>> numbers outside the -4095..-1 range, while the version of EXCEPTION
>> built into Gforth uses numbers inside that range.
>
>So a third-party library should not use the built-in EXCEPTION word when
>it runs in Gforth to avoid -4095..-1 range, should it?

No, using the built-in exception is a good idea? In your scenario the
third-party library gets the throw code from a system word instead of
defining it itself, and of course using that throw code is perfectly
safe. It knows how to avoid collisions with Gforth's built-in throw
codes, and avoids collisions with user-defined throw codes by using
numbers in the -4095..-1 range.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Stephen Pelc <stephen@vfxforth.com> writes:
>On 8 Jan 2022 at 11:21:41 CET, "Anton Ertl" <Anton Ertl> wrote:
>>
>> Yes: Checking iForth, lxf, SwiftForth, and VFX, none of them has
>> picked up EXCEPTION. This is probably because need for defining throw
>> codes in libraries is rare, and I guess the low importance of
>> libraries in Forth also plays a role. Anyway, if you want to write a
>> library for Gforth, Gforth has had EXCEPTION since at least 1998.
>
>The reason why we ignored EXCEPTION was that it did not do what we
>wanted. VFX provides ERRDEF and friends.
>
>ERRDEF <name> "<text>" \ -- n
>
>At compile time this generates a CONSTANT called <name> associated
>with the text for THROW number n.

So instead of writing

s" my error message" exception constant mythrowcode

you write

errdef mythrowcode "my error message"

I don't see why you do not add EXCEPTION as factor of ERRDEF. NIH?

>The constant n is incremented for the
>next use of ERRDEF. There are variants of ERRDEF that take a value and
>SYSERRDEF generates a number in the range -1..-4095.

ERRDEF starts at 509 in VFX Forth 64 5.11 RC2, which has the risk of
colliding with user-defined throw codes. So better ignore ERRDEF and
use SYSERRDEF.

>These have been in VFX since v3.6.

Looking at VFX release notes, that was in 2003.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 10/01/2022 05:01, Anton Ertl wrote:
> Stephen Pelc <stephen@vfxforth.com> writes:
>>On 8 Jan 2022 at 11:21:41 CET, "Anton Ertl" <Anton Ertl> wrote:
>>>
>>> Yes: Checking iForth, lxf, SwiftForth, and VFX, none of them has
>>> picked up EXCEPTION. This is probably because need for defining throw
>>> codes in libraries is rare, and I guess the low importance of
>>> libraries in Forth also plays a role. Anyway, if you want to write a
>>> library for Gforth, Gforth has had EXCEPTION since at least 1998.
>>
>>The reason why we ignored EXCEPTION was that it did not do what we
>>wanted. VFX provides ERRDEF and friends.
>>
>>ERRDEF <name> "<text>" \ -- n
>>
>>At compile time this generates a CONSTANT called <name> associated
>>with the text for THROW number n.
>
> So instead of writing
>
> s" my error message" exception constant mythrowcode
>
> you write
>
> errdef mythrowcode "my error message"
>
> I don't see why you do not add EXCEPTION as factor of ERRDEF. NIH?
>
>>The constant n is incremented for the
>>next use of ERRDEF. There are variants of ERRDEF that take a value and
>>SYSERRDEF generates a number in the range -1..-4095.
>
> ERRDEF starts at 509 in VFX Forth 64 5.11 RC2, which has the risk of
> colliding with user-defined throw codes. So better ignore ERRDEF and
> use SYSERRDEF.
>
>>These have been in VFX since v3.6.
>
> Looking at VFX release notes, that was in 2003.

It's saying Standard Forth is no closer to being a computing language
than it was in 2003. Indeed, I'm increasingly loathe to call Forth a
'computing language' at all because it doesn't meet the criteria most
people expect of one. The term Moore used to describe Forth was "toolkit"
- which is at least honest. That's not to say an individual Forth
implementation couldn't become a well-designed 'language'. What's for
sure is Standard Forth will never be one - not least because members are
determined to keep their own. If Standard Forth has achieved it has
been in the language of compromise and appeasement - not computing.

On 2022-01-09 20:39, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2022-01-08 13:55, Anton Ertl wrote:
>>> I don't know what dxforth means, but there is such a difference: A
>>> library that is provided independent of systems cannot know what throw
>>> codes are used by the system, and so has to define throw codes outside
>>> the -4095..0 range. OTOH, a library that is provided by the system
>>> implementor for a specific system can know which throw codes the
>>> system uses and in that case the lowest collision risk is if the
>>> library uses throw codes in the -4095..-1 range that are not used by
>>> anything else in the system (nor any other system library).
>>
>>
>> Does it mean that if some vendor includes some portable library into its
>> system, it should also change the throw codes in this library to the
>> -4095..-256 range?
>
> That would be ideal for eliminating collision risks, but the fact that
> we are considering such measures points to a lack in the Forth
> standard.

Yes, this lack exists, of course. It is just not too critical at the moment.

>>> As an example, the version of EXCEPTION in the compat library uses
>>> numbers outside the -4095..-1 range, while the version of EXCEPTION
>>> built into Gforth uses numbers inside that range.
>>
>> So a third-party library should not use the built-in EXCEPTION word when
>> it runs in Gforth to avoid -4095..-1 range, should it?
>
> No, using the built-in exception is a good idea? In your scenario the
> third-party library gets the throw code from a system word instead of
> defining it itself, and of course using that throw code is perfectly
> safe. It knows how to avoid collisions with Gforth's built-in throw
> codes, and avoids collisions with user-defined throw codes by using
> numbers in the -4095..-1 range.

Then it's as if this third-party library becomes a part of the system.

And what about a program? May it use the built-in "EXCEPTION"? If yes,
then it formally violates the restriction on programs (albeit it's
totally safe).

Concerning the "EXCEPTION" word as an API. This word has two functions:
reserve a throw code, and associate a textual message with this code.

Probably in a basic API these functions should be disjointed. And a
general method to retrieve a message by a throw code should be a part of
this API too.

Also, an interesting thing is a method to retrieve a throw number by a
message. Having such a method, something similar to my "sthrow" can be
defined. The key idea is that you don't need to declare exceptions
beforehand, but just use them on the fly.

\ message-by-code? ( n -- sd.message true | n false )
\ code-by-message? ( sd.message -- n true | sd.message false )

: obtain-code-by-message ( sd.name -- n )
\ it reuses the same code for the same message
dup 0= if nip exit then
code-by-message? if exit then exception
;
: throw-message ( sd.name -- ) obtain-code-by-message throw ;

\ testing

t{ [: "#error-test" throw-message ;] catch
message-by-code? -rot "#error-test" compare -> -1 0 }t

"#error-test" throw-message
\ the system should print "#error-test" as an error message.

By the definition of "exception" in Gforth I see that it isn't allowed
to be performed during compilation. But it can be corrected.

--
Ruvim

On 2022-01-10 13:31, Ruvim wrote:
> On 2022-01-09 20:39, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2022-01-08 13:55, Anton Ertl wrote:
>>>> I don't know what dxforth means, but there is such a difference: A
>>>> library that is provided independent of systems cannot know what throw
>>>> codes are used by the system, and so has to define throw codes outside
>>>> the -4095..0 range.  OTOH, a library that is provided by the system
>>>> implementor for a specific system can know which throw codes the
>>>> system uses and in that case the lowest collision risk is if the
>>>> library uses throw codes in the -4095..-1 range that are not used by
>>>> anything else in the system (nor any other system library).
>>>
>>>
>>> Does it mean that if some vendor includes some portable library into its
>>> system, it should also change the throw codes in this library to the
>>> -4095..-256 range?
>>
>> That would be ideal for eliminating collision risks, but the fact that
>> we are considering such measures points to a lack in the Forth
>> standard.
>
>
> Yes, this lack exists, of course. It is just not too critical at the
> moment.
>
>
>
>
>>>> As an example, the version of EXCEPTION in the compat library uses
>>>> numbers outside the -4095..-1 range, while the version of EXCEPTION
>>>> built into Gforth uses numbers inside that range.
>>>
>>> So a third-party library should not use the built-in EXCEPTION word when
>>> it runs in Gforth to avoid -4095..-1 range, should it?
>>
>> No, using the built-in exception is a good idea?  In your scenario the
>> third-party library gets the throw code from a system word instead of
>> defining it itself, and of course using that throw code is perfectly
>> safe.  It knows how to avoid collisions with Gforth's built-in throw
>> codes, and avoids collisions with user-defined throw codes by using
>> numbers in the -4095..-1 range.
>
>
> Then it's as if this third-party library becomes a part of the system.
>
> And what about a program? May it use the built-in "EXCEPTION"? If yes,
> then it formally violates the restriction on programs (albeit it's
> totally safe).
>
>
>
> Concerning the "EXCEPTION" word as an API. This word has two functions:
> reserve a throw code, and associate a textual message with this code.
>
> Probably in a basic API these functions should be disjointed. And a
> general method to retrieve a message by a throw code should be a part of
> this API too.
>
> Also, an interesting thing is a method to retrieve a throw number by a
> message. Having such a method, something similar to my "sthrow" can be
> defined.  The key idea is that you don't need to declare exceptions
> beforehand, but just use them on the fly.
>
>   \ message-by-code?  ( n -- sd.message true | n false )
>   \ code-by-message?  ( sd.message -- n true | sd.message false )
>
>   : obtain-code-by-message ( sd.name -- n )
>     \ it reuses the same code for the same message
>     dup 0= if nip exit then
>     code-by-message? if exit then exception
>   ;
>   : throw-message ( sd.name -- ) obtain-code-by-message throw ;
>
>   \ testing
>
>   t{ [: "#error-test" throw-message ;] catch
>     message-by-code? -rot "#error-test" compare -> -1 0 }t
>
>   "#error-test" throw-message
>   \ the system should print "#error-test" as an error message.
>
>
> By the definition of "exception" in Gforth I see that it isn't allowed
> to be performed during compilation. But it can be corrected.

This doesn't occur in the example above, but it can occur in general.

E.g., for performance, it could be better to resolve the message in
compile time. And it can be done via a recognizer:

throw-message:error-test

or

throw-message( #error-test )

Yes, it is similar to 'ABORT"'. But it doesn't accept a flag, and it
produces a unique throw code for each unique message.

--
Ruvim

On 2022-01-08 13:21, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2022-01-08 03:33, dxforth wrote:
>>> The idea of ANS and systems reserving negative numbers is that programs
>>> could use positive numbers without risk - no?
>>
>> Maybe it was intended, but:
>>
>> 1. The corresponding restriction on systems is not declared.
[...]
>> 2. This risk is very low (did anybody face its occurrence in practice?).
>
> I tend to avoid defining new throw codes, partly because standard
> Forth does not have a good way to do it. I Gforth I have such a way,
> but I have also defined few new throw codes in Gforth-specific programs. Maybe we don't need that that often
>
>> 3. If a program uses libraries, such a risk exists anyway.
> ...
>> As an option to solve the problem of conflicting error codes, a method
>> to reserve error codes for programs can be developed and standardized.
>
> Many years ago (in 1999 or earlier) I have proposed
>
> http://www.forth200x.org/exception.html
>
> This is a pre-Forth-200x proposal that I never bothered to propose for
> Forth200x.
>
>> Probably, since we don't have such a method yet, then the problem is not
>> so critical in practice too.
>
> Yes: Checking iForth, lxf, SwiftForth, and VFX, none of them has
> picked up EXCEPTION. This is probably because need for defining throw
> codes in libraries is rare, and I guess the low importance of
> libraries in Forth also plays a role. Anyway, if you want to write a
> library for Gforth, Gforth has had EXCEPTION since at least 1998.

A word like "EXCEPTION" solves the problem of collision only partially.

The throw codes that EXCEPTION provides can change from run to run and
from one system to another system. So these codes cannot play a role of
fixed error codes.

But sometimes a program/library have to define fixed error codes. Some
possible reasons for that as follows:

1. Fixed codes should be a part of an API (for example, they are passed
to a different process).

2. Fixed codes should be referred in an external resource (e.g. an
external file with error messages in different languages).

So, fixed codes are really needed sometimes. How this problem can be
solved? As it is well known, by introducing extra level of indirection
(https://w.wiki/4aD).

Every new unique throw code shall be obtained from the system only. No
other way can guarantee uniqueness (a global directory for all libraries
is not an option, I guess).

Also, a system should provide a convenient API to identify a set of
throw codes and a way to create a bijection between this set and a set
of user-defined error codes.

Conceptually, a program/library should be able to define the following
words for its internal use in a portable way:

my-throw ( x.err|0 -- )
my-err? ( n -- x.err true | n false )

\ testing:

0 value ior1
0 value ior2

t{ [: 123 my-throw ;] catch dup to ior1 my-err? -> 123 -1 }t

t{ [: 456 my-throw ;] catch dup to ior2 my-err? -> 456 -1 }t

t{ [: 123 throw ;] catch my-err? -> 123 0 }t

t{ [: 123 my-throw ;] catch -> ior1 }t

t{ [: ior1 throw ;] catch my-err? -> 123 -1 }t
t{ [: ior2 throw ;] catch my-err? -> 456 -1 }t

t{ [: c" #err-03" my-throw ;] catch
my-err? swap count s" #err-03" compare -> -1 0 }t

t{ ior1 my-err? -> 123 -1 }t

The API should guarantee that the actual throw codes (like in ior1 and
ior2) are unique in the running process, among all loaded libraries or
modules.

Also, this API should provide a way to bijectively associate an error
message and a throw code.

When such an API is provided, the programs/libraries may be softly
restricted to encourage them to always obtain/reserve throw codes form
the system.

--
Ruvim

On 10/01/2022 21:31, Ruvim wrote:
> On 2022-01-09 20:39, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2022-01-08 13:55, Anton Ertl wrote:
>>>> I don't know what dxforth means, but there is such a difference: A
>>>> library that is provided independent of systems cannot know what throw
>>>> codes are used by the system, and so has to define throw codes outside
>>>> the -4095..0 range. OTOH, a library that is provided by the system
>>>> implementor for a specific system can know which throw codes the
>>>> system uses and in that case the lowest collision risk is if the
>>>> library uses throw codes in the -4095..-1 range that are not used by
>>>> anything else in the system (nor any other system library).
>>>
>>>
>>> Does it mean that if some vendor includes some portable library into its
>>> system, it should also change the throw codes in this library to the
>>> -4095..-256 range?
>>
>> That would be ideal for eliminating collision risks, but the fact that
>> we are considering such measures points to a lack in the Forth
>> standard.

The application is in charge. Let it assign the codes.

\ library
0 value throw1
0 value throw2

\ throw strings if requ'd
s" throw 1" 2constant $throw1
s" throw 2" 2constant $throw2

\ application
1000 to throw1
1001 to throw2

.... catch case
throw1 of $throw1 endof
throw2 of $throw2 endof
?dup if throw then exit
endcase cr type abort

\ alternatively SwiftForth's ?ABORT
.... catch
throw1 over = $throw1 ?abort
throw2 over = $throw2 ?abort
throw

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2022-01-09 20:39, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2022-01-08 13:55, Anton Ertl wrote:
>>>> As an example, the version of EXCEPTION in the compat library uses
>>>> numbers outside the -4095..-1 range, while the version of EXCEPTION
>>>> built into Gforth uses numbers inside that range.
>>>
>>> So a third-party library should not use the built-in EXCEPTION word when
>>> it runs in Gforth to avoid -4095..-1 range, should it?
>>
>> No, using the built-in exception is a good idea? In your scenario the
>> third-party library gets the throw code from a system word instead of
>> defining it itself, and of course using that throw code is perfectly
>> safe. It knows how to avoid collisions with Gforth's built-in throw
>> codes, and avoids collisions with user-defined throw codes by using
>> numbers in the -4095..-1 range.
>
>
>Then it's as if this third-party library becomes a part of the system.

No, Gforth's EXCEPTION is part of the system. It passes out throw
codes (from the system range) that programs (including libraries,
including non-system libraries) can THROW and CATCH, just like they
can THROW and CATCH the throw codes defined in the standard.

>And what about a program? May it use the built-in "EXCEPTION"?

Certainly.

>If yes,
>then it formally violates the restriction on programs (albeit it's
>totally safe).

What makes you think so?

>Concerning the "EXCEPTION" word as an API. This word has two functions:
>reserve a throw code, and associate a textual message with this code.
>
>Probably in a basic API these functions should be disjointed.

Why? I see no reason why a program should create a throw code without
associated text message, and also no reason why a program should
associate a text with an arbitrary number.

>And a
>general method to retrieve a message by a throw code should be a part of
>this API too.

The system certainly has this functionality somewhere if it outputs
the text message in the system catch handler. I have not needed this
functionality in a program yet, though.

>Also, an interesting thing is a method to retrieve a throw number by a
>message. Having such a method, something similar to my "sthrow" can be
>defined. The key idea is that you don't need to declare exceptions
>beforehand, but just use them on the fly.

But then you cannot check for that throw code in a CATCH, or (if using
the same message produces the same throw code) you have to repeat the
whole message. In the first case, you can just as well use abort".
The second case is cumbersome to use, and complicates implementation.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Ruvim <ruvim.pinka@gmail.com> writes:
>A word like "EXCEPTION" solves the problem of collision only partially.
>
>The throw codes that EXCEPTION provides can change from run to run and
>from one system to another system.

Sure. The same is true of, e.g., xts. Not a problem.

>But sometimes a program/library have to define fixed error codes. Some
>possible reasons for that as follows:
>
>1. Fixed codes should be a part of an API (for example, they are passed
>to a different process).

But what does this have to do with THROW codes?

>2. Fixed codes should be referred in an external resource (e.g. an
>external file with error messages in different languages).

I find error messages in different languages of dubious value
(basically it means that the user then has trouble googling for his
problem), but in any case, if we want to go there, we would probably
use a gettext-like interface, and use that to deal with not just error
messages, but all other messages as well. An error-message-only
mechanism is probably not a good idea.

>Every new unique throw code shall be obtained from the system only.

That's the idea behind EXCEPTION.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 2022-01-10 17:43, dxforth wrote:
> On 10/01/2022 21:31, Ruvim wrote:
>> On 2022-01-09 20:39, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>>
>>>> Does it mean that if some vendor includes some portable library into
>>>> its
>>>> system, it should also change the throw codes in this library to the
>>>> -4095..-256 range?
>>>
>>> That would be ideal for eliminating collision risks, but the fact that
>>> we are considering such measures points to a lack in the Forth
>>> standard.
>
> The application is in charge.  Let it assign the codes.
>
> \ library
> 0 value throw1
> 0 value throw2
>
> \ throw strings if requ'd
> s" throw 1" 2constant $throw1
> s" throw 2" 2constant $throw2
>
> \ application
> 1000 to throw1
> 1001 to throw2

Why is it better than if the library allocates throw codes in the
system? (I mean, if such a method is standardized). E.g.:

s" throw 1" exception constant throw1
s" throw 2" exception constant throw2

An advantage of this method is that an application don't need to bear
the burden of assigning throw codes for all the libraries that it uses.

> ... catch case
>   throw1 of $throw1 endof
>   throw2 of $throw2 endof
>   ?dup if throw then  exit
> endcase  cr type abort
>
> \ alternatively SwiftForth's ?ABORT
> ... catch
> throw1 over = $throw1 ?abort
> throw2 over = $throw2 ?abort
> throw

It's possible, of course. But is it an API that you really want to use?

How do you see an ideal solution for this problem?

--
Ruvim

On 12/01/2022 17:59, Ruvim wrote:
>
> Why is it better than if the library allocates throw codes in the
> system? (I mean, if such a method is standardized). E.g.:
>
> s" throw 1" exception constant throw1
> s" throw 2" exception constant throw2
>
> An advantage of this method is that an application don't need to bear
> the burden of assigning throw codes for all the libraries that it uses.
> ...
>
> It's possible, of course. But is it an API that you really want to use?
>
> How do you see an ideal solution for this problem?

I'm not sure it represents enough of a problem to the programmer to warrant
burdening the system. Besides which EXCEPTION takes from the system's pool
of codes. Doesn't that make the codes ANS assigned to applications redundant?
At the very least it's taking things in a different direction.
OTOH I think ?ABORT is neat and it's a factor of ABORT". It existed as a
headerless word in DX-Forth because I couldn't see additional use for it -
until now. Who would have guessed.

On 2022-01-12 10:41, dxforth wrote:
> On 12/01/2022 17:59, Ruvim wrote:
>>
>> Why is it better than if the library allocates throw codes in the
>> system? (I mean, if such a method is standardized). E.g.:
>>
>>     s" throw 1" exception constant throw1
>>     s" throw 2" exception constant throw2
>>
>> An advantage of this method is that an application don't need to bear
>> the burden of assigning throw codes for all the libraries that it uses.
>> ...
>>
>> It's possible, of course. But is it an API that you really want to use?
>>
>> How do you see an ideal solution for this problem?
>
> I'm not sure it represents enough of a problem to the programmer to warrant
> burdening the system.  Besides which EXCEPTION takes from the system's pool
> of codes.

What namely burdening to the system do you mean?

Usually a system already has some mechanism to associate error messages
with throw codes, that EXCEPTION probably can utilize (well, an opposite
example is SP-Forth, where this mechanism is based on external files
with error messages, so it cannot be used by the EXCEPTION word).

> Doesn't that make the codes ANS assigned to applications redundant?

If a program will be restricted to obtain new throw codes from the
system only, and if ANS ever assigned any range of throw codes to
applications only, then yes, this assignment would become redundant.

But ANS didn't. As I shown, Forth-94 doesn't restrict a system to the
range -4095..0 (it only recommends to use this range, see 9.3.1).
Consequently, it was impossible to assign the complementary range to
applications _exclusively_.

In any way, a standardized EXCEPTION (or something alike) shall provide
throw codes outside of the range {-255...0}, and without any other
restrictions (for example, it should not be restricted by the range
{-4095...-256}). Probably, it would be even better to provide new throw
codes only outside of the range {-4095...0}.

> At the very least it's taking things in a different direction.

And what a problem?

> OTOH I think ?ABORT is neat and it's a factor of ABORT".  It existed as a
> headerless word in DX-Forth because I couldn't see additional use for it -
> until now.  Who would have guessed.

?ABORT ( flag c-addr u -- )

Yes, it's a useful factor. Probably, an unconditional variant is
slightly more efficient (but more verbose in use).

To provide a way to rethrow or handle such an exception, a system should
also provide something like ABORTION-REASON ( -- c-addr u )
A complement word could be SET-ABORTION-REASON ( c-addr u -- )

And then "?ABORT" can be defined as follows

: ?abort ( flag c-addr u -- )
rot if set-abortion-reason -2 throw then 2drop
;

--
Ruvim

On 2022-01-11 21:36, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2022-01-09 20:39, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>> On 2022-01-08 13:55, Anton Ertl wrote:
>>>>> As an example, the version of EXCEPTION in the compat library uses
>>>>> numbers outside the -4095..-1 range, while the version of EXCEPTION
>>>>> built into Gforth uses numbers inside that range.
>>>>
>>>> So a third-party library should not use the built-in EXCEPTION word when
>>>> it runs in Gforth to avoid -4095..-1 range, should it?
>>>
>>> No, using the built-in exception is a good idea? In your scenario the
>>> third-party library gets the throw code from a system word instead of
>>> defining it itself, and of course using that throw code is perfectly
>>> safe. It knows how to avoid collisions with Gforth's built-in throw
>>> codes, and avoids collisions with user-defined throw codes by using
>>> numbers in the -4095..-1 range.
>>
>>
>> Then it's as if this third-party library becomes a part of the system.
>
> No, Gforth's EXCEPTION is part of the system. It passes out throw
> codes (from the system range) that programs (including libraries,
> including non-system libraries) can THROW and CATCH, just like they
> can THROW and CATCH the throw codes defined in the standard.

Yes, it's clear.

The initial point was that according to the standard (the current
version), any library should be considered as either a part of a system,
or a part of a program.

And if a library defines a throw code in the range -4095..-1, this
library should be considered as a part of the system, even if it's a
third party library. Since otherwise it's a part of the program, and it
makes the program formally not compliant.

>> And what about a program? May it use the built-in "EXCEPTION"?
>
> Certainly.
>
>> If yes,
>> then it formally violates the restriction on programs (albeit it's
>> totally safe).
>
> What makes you think so?

"Programs shall not define values for use with THROW in the range
{-4095...-1}" (in the section 9.3.1, Forth-2012).

But via your "EXCEPTION", a program defines for use a throw code in this
range. Hence the program formally violates this restriction.

>> Concerning the "EXCEPTION" word as an API. This word has two functions:
>> reserve a throw code, and associate a textual message with this code.
>>
>> Probably in a basic API these functions should be disjointed.
>
> Why? I see no reason why a program should create a throw code without
> associated text message,

(Disclaimer: I don't insist, it's just an idea for discussion)

The catch-throw mechanism is a general control flow mechanism. And it
can be used not only for error handling.

If a user can always bypass creating such a message, e.g.:

: next-exc ( -- n ) 0. exception ;

then why do you need to force him to always provide a message?

> and also no reason why a program should
> associate a text with an arbitrary number.

Not with arbitrary numbers, but with defined (in some sense) throw codes
only.

>>
>> And a general method to retrieve a message by a throw code
>> should be a part of this API too.
>
> The system certainly has this functionality somewhere if it outputs
> the text message in the system catch handler. I have not needed this
> functionality in a program yet, though.

Such a method can be required by a user-defined text interpreter (as
well as a method to recovery internal states after an error, as it was
discussed in 2021).

>> Also, an interesting thing is a method to retrieve a throw number by a
>> message. Having such a method, something similar to my "sthrow" can be
>> defined. The key idea is that you don't need to declare exceptions
>> beforehand, but just use them on the fly.
>
> But then you cannot check for that throw code in a CATCH, or (if using
> the same message produces the same throw code) you have to repeat the
> whole message.

I use such a lazy method to generate exceptions when I don't need to
check throw codes, and they are not a part of an API (actually, it's
majority). Sometimes I need to check an actual message (or its
_pattern_), since in such cases the message also brings some semantics
information for internal use (i.e. it is not only a message for logs).

> In the first case, you can just as well use abort".

I do: my "sthrow" is a factor of 'abort"'

One problem with that is the same as with "errno" — the information can
be lost when you clean up the objects before rethrow the exception.

> The second case is cumbersome to use, and complicates implementation.

To avoid complication of an implementation, a lower level API to solve
the problem can be only provided.

For example, if you can iterate over all the defined pairs of a throw
code and its message, the operations to find a message by a code, and
find a code by a message have almost the same complexity.

--
Ruvim

On 2022-01-12 01:21, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> A word like "EXCEPTION" solves the problem of collision only partially.
>>
>> The throw codes that EXCEPTION provides can change from run to run and
>>from one system to another system.
>
> Sure. The same is true of, e.g., xts. Not a problem.
>
>> But sometimes a program/library have to define fixed error codes. Some
>> possible reasons for that as follows:
>>
>> 1. Fixed codes should be a part of an API (for example, they are passed
>> to a different process).
>
> But what does this have to do with THROW codes?

Ideally, — nothing. But such use is allowed by the current standard. So
we should support a migration, I think.

>> 2. Fixed codes should be referred in an external resource (e.g. an
>> external file with error messages in different languages).
>
> I find error messages in different languages of dubious value
> (basically it means that the user then has trouble googling for his
> problem), but in any case, if we want to go there, we would probably
> use a gettext-like interface, and use that to deal with not just error
> messages, but all other messages as well. An error-message-only
> mechanism is probably not a good idea.

Agreed.

But if somebody already use throw numbers for that, it should have a
clear way how to migrate on "random" throw numbers.

>> Every new unique throw code shall be obtained from the system only.
>
> That's the idea behind EXCEPTION.

Yes, and I support the idea of EXCEPTION

I only want to have a way:

1. to get new throw code without explicit declaration beforehand. I
mean, to get the throw code right inside the definition, on the fly,
immediately before throw.

2. to associate bijectively any number with new throw code.

Actually, the latter point can be implemented by a library in a portable
way.

--
Ruvim

On 2022-01-12 19:47, Ruvim wrote:

>>> 2. Fixed codes should be referred in an external resource (e.g. an
>>> external file with error messages in different languages).
>>
>> I find error messages in different languages of dubious value
>> (basically it means that the user then has trouble googling for his
>> problem), but in any case, if we want to go there, we would probably
>> use a gettext-like interface, and use that to deal with not just error
>> messages, but all other messages as well.  An error-message-only
>> mechanism is probably not a good idea.
>
> Agreed.

As it appears, gettext is not a good choice.
See: https://github.com/projectfluent/fluent/wiki/Fluent-vs-gettext

> But if somebody already use throw numbers for that, it should have a
> clear way how to migrate on "random" throw numbers.

Fixed identifiers are essential. Probably, textual hierarchical
identifiers is a better choice in many cases.

--
Ruvim

On 13/01/2022 02:03, Ruvim wrote:
> On 2022-01-12 10:41, dxforth wrote:
>> On 12/01/2022 17:59, Ruvim wrote:
>>> ...
>>> How do you see an ideal solution for this problem?
>>
>> I'm not sure it represents enough of a problem to the programmer to warrant
>> burdening the system.  Besides which EXCEPTION takes from the system's pool
>> of codes.
>
> What namely burdening to the system do you mean?
>
> Usually a system already has some mechanism to associate error messages
> with throw codes, that EXCEPTION probably can utilize (well, an opposite
> example is SP-Forth, where this mechanism is based on external files
> with error messages, so it cannot be used by the EXCEPTION word).

Small systems may well find it a burden. Mine uses exactly two ANS
exceptions (codes -1 and -2) which I find sufficient. Implementing
EXCEPTION would likely require a linked list (or two as I have a split
dictionary). MARKER/FORGET would need to be involved to trim the lists
along with the dictionary. That's a lot of effort/resources to expend
for the privilege of having the system hand out codes.

> ...
>
>> OTOH I think ?ABORT is neat and it's a factor of ABORT".  It existed as a
>> headerless word in DX-Forth because I couldn't see additional use for it -
>> until now.  Who would have guessed.
>
> ?ABORT ( flag c-addr u -- )
>
> Yes, it's a useful factor. Probably, an unconditional variant is
> slightly more efficient (but more verbose in use).
>
> To provide a way to rethrow or handle such an exception, a system should
> also provide something like ABORTION-REASON ( -- c-addr u )
> A complement word could be SET-ABORTION-REASON ( c-addr u -- )
>
> And then "?ABORT" can be defined as follows
>
> : ?abort ( flag c-addr u -- )
> rot if set-abortion-reason -2 throw then 2drop
> ;

Yes. It's near identical to how I implemented it.

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

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

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

On 2022-01-13 03:38, dxforth wrote:
> On 13/01/2022 02:03, Ruvim wrote:
>> On 2022-01-12 10:41, dxforth wrote:
>>> On 12/01/2022 17:59, Ruvim wrote:
>>>> ...
>>>> How do you see an ideal solution for this problem?
>>>
>>> I'm not sure it represents enough of a problem to the programmer to
>>> warrant
>>> burdening the system.  Besides which EXCEPTION takes from the
>>> system's pool
>>> of codes.
>>
>> What namely burdening to the system do you mean?
>>
>> Usually a system already has some mechanism to associate error messages
>> with throw codes, that EXCEPTION probably can utilize (well, an opposite
>> example is SP-Forth, where this mechanism is based on external files
>> with error messages, so it cannot be used by the EXCEPTION word).
>
> Small systems may well find it a burden.  Mine uses exactly two ANS
> exceptions (codes -1 and -2) which I find sufficient.  Implementing
> EXCEPTION would likely require a linked list (or two as I have a split
> dictionary).  MARKER/FORGET would need to be involved to trim the lists
> along with the dictionary.  That's a lot of effort/resources to expend
> for the privilege of having the system hand out codes.

A dedicated linked list is only one of possible implementations.
For example, a word list is a built in linked list that can be also
used. But it can implemented even without any linked list!

here constant magic-exception

: exception ( sd.message -- n )
align magic-exception , here >r ," r>
;
: message-by-throwcode? ( n -- c-addr u true | n false )
dup magic-exception here within 0= if false exit then
dup cell- @ magic-exception <> if false exit then
count true
;

In this simple variant we don't provide a method to find the throw code
by a message, and the "exception" word shall not be performed when the
current definition exists. But these limitations are not too difficult
to mitigate.

>> ...
>>
>>> OTOH I think ?ABORT is neat and it's a factor of ABORT".  It existed
>>> as a headerless word in DX-Forth because I couldn't see additional
>>> use for it - until now. Who would have guessed.
>>>
>>
>>     ?ABORT ( flag c-addr u -- )
>>
>> Yes, it's a useful factor. Probably, an unconditional variant is
>> slightly more efficient (but more verbose in use).
>>
>> To provide a way to rethrow or handle such an exception, a system should
>> also provide something like ABORTION-REASON ( -- c-addr u )
>> A complement word could be SET-ABORTION-REASON ( c-addr u -- )
>>
>> And then "?ABORT" can be defined as follows
>>
>>     : ?abort ( flag c-addr u -- )
>>       rot if set-abortion-reason -2 throw then 2drop
>>     ;
>
> Yes.  It's near identical to how I implemented it.
>
> : ?ABORT ( n c-addr u -- )  rot if  errmsg 2! -2 throw  then 2drop ;
>
> : (abort") ( n -- )  r> count 2dup + >r  ?abort ;
>
> : ABORT"  state @ if  postpone (abort")  ,"  exit  then
>   postpone s"  ?abort ; immediate

It shows a rare case when "postpone" is used in system-specific way to
later perform some interpretation semantics.

A less confusing way is to explicitly append execution semantics:
[ ' s" compile, ]
or perform it:
['] s" execute

These ways also works when the system provides a full compliant
"postpone" (i.e. without relying on RFI 99-027).

Also, the word '(abort")' is needless. Have a look:

: abort" ( flag "ccc" -- )
[ ' s" compile, ]
['] ?abort state @ if compile, else execute then
; immediate

Compilation or executing an xt depending on STATE I call "translation of
xt". It's a very useful factor:

: tt-xt ( i*x xt -- j*x )
state @ if compile, else execute then ;

Using this factor, definition for 'abort"' becomes even more compact:

: abort" ( flag "ccc" -- )
[ ' s" compile, ] ['] ?abort tt-xt ; immediate

(of course, it's still a system-dependent definition, since it relies on
specific implementation for 's"' ).

--
Ruvim

As a note I output error messages as well as prompt via errout. Clean data,
exclusive of messages and prompt, is output via stdout which can be directed
to a file or another display if so desired.
--
me

Another note. In my exception handlers which end in an abort I use user abort, UABORT ,
a deferred word which is assigned a hard abort on startup. Hard abort resets the
vocabulary to Forth but many times I don't want that and I switch in a soft abort that
only resets data stack and quits. On some occasions I switch in behaviors that may
reset stack only and not quit, or noop and not do anything, or print stack and then quit,
etc.
--
me

FigForth gets error text form block file when WARNING is set to one, otherwise it just
prints the error number. A system could just as easily get the text from a sequence
file.
I mark my block file with magic XYZZY which informs how the block file is configured
and if it has error text and where they are located. If the block file does not contain
error text, I set WARNING to zero.
--
me

On 13/01/2022 22:37, Ruvim wrote:
>
> A dedicated linked list is only one of possible implementations.
> For example, a word list is a built in linked list that can be also
> used. But it can implemented even without any linked list!
>
> here constant magic-exception
>
> : exception ( sd.message -- n )
> align magic-exception , here >r ," r>
> ;
> : message-by-throwcode? ( n -- c-addr u true | n false )
> dup magic-exception here within 0= if false exit then
> dup cell- @ magic-exception <> if false exit then
> count true
> ;
>
> In this simple variant we don't provide a method to find the throw code
> by a message, and the "exception" word shall not be performed when the
> current definition exists. But these limitations are not too difficult
> to mitigate.

Interesting technique. Since n is an exception I would just throw it (e.g.
via ?ABORT). Personally I would have a hard time justifying EXCEPTION.
YMMV

>>
>> : ?ABORT ( n c-addr u -- )  rot if  errmsg 2! -2 throw  then 2drop ;
>>
>> : (abort") ( n -- )  r> count 2dup + >r  ?abort ;
>>
>> : ABORT"  state @ if  postpone (abort")  ,"  exit  then
>>   postpone s"  ?abort ; immediate
>
> It shows a rare case when "postpone" is used in system-specific way to
> later perform some interpretation semantics.
>
> A less confusing way is to explicitly append execution semantics:
> [ ' s" compile, ]
> or perform it:
> ['] s" execute
>
> These ways also works when the system provides a full compliant
> "postpone" (i.e. without relying on RFI 99-027).
>
>
> Also, the word '(abort")' is needless. Have a look:
>
> : abort" ( flag "ccc" -- )
> [ ' s" compile, ]
> ['] ?abort state @ if compile, else execute then
> ; immediate
>
>
> Compilation or executing an xt depending on STATE I call "translation of
> xt". It's a very useful factor:
>
> : tt-xt ( i*x xt -- j*x )
> state @ if compile, else execute then ;
>
> Using this factor, definition for 'abort"' becomes even more compact:
>
> : abort" ( flag "ccc" -- )
> [ ' s" compile, ] ['] ?abort tt-xt ; immediate
>
> (of course, it's still a system-dependent definition, since it relies on
> specific implementation for 's"' ).

For my DTC system, it was cheaper to compile (abort") than (s") ?abort.

On 2022-01-14 03:06, dxforth wrote:
> On 13/01/2022 22:37, Ruvim wrote:
>>
>> A dedicated linked list is only one of possible implementations.
>> For example, a word list is a built in linked list that can be also
>> used. But it can implemented even without any linked list!
>>
>>     here constant magic-exception
>>
>>     : exception ( sd.message -- n )
>>       align magic-exception , here >r ," r>
>>     ;
>>     : message-by-throwcode? ( n -- c-addr u true | n false )
>>       dup magic-exception here within 0= if false exit then
>>       dup cell- @ magic-exception <> if false exit then
>>       count true
>>     ;
>>
>> In this simple variant we don't provide a method to find the throw code
>> by a message, and the "exception" word shall not be performed when the
>> current definition exists. But these limitations are not too difficult
>> to mitigate.
>
> Interesting technique.  Since n is an exception I would just throw it (e.g.
> via ?ABORT).

Formally n is a throw code.

"?ABORT" doesn't accept a throw code, it accepts a flag and always uses
-2 as a throw code.

An arbitrary throw code can be used as the argument of THROW

s" test error message" exception constant my-ior
:noname my-ior throw ; catch message-by-throwcode? 0= abort" Err" type
\ it should print "test error message"

The system can use "message-by-throwcode?" to show an error message when
an exception was not caught by the user.

> Personally I would have a hard time justifying EXCEPTION. YMMV

I don't sure that namely this variant is worth standardizing. But I like
it's key idea, since it provides an easy way to avoid the possibility of
throw codes collision.

[...]
>> Using this factor, definition for 'abort"' becomes even more compact:
>>
>>     : abort" ( flag "ccc" -- )
>>       [ ' s" compile, ]  ['] ?abort tt-xt ; immediate
>>
>> (of course, it's still a system-dependent definition, since it relies on
>> specific implementation for 's"' ).
>
> For my DTC system, it was cheaper to compile (abort") than (s") ?abort.

Ah, I see. You save one cell per each use of 'abort"' in a definition.

--
Ruvim

On 14/01/2022 17:29, Ruvim wrote:
> On 2022-01-14 03:06, dxforth wrote:
>> On 13/01/2022 22:37, Ruvim wrote:
>>>
>>> A dedicated linked list is only one of possible implementations.
>>> For example, a word list is a built in linked list that can be also
>>> used. But it can implemented even without any linked list!
>>>
>>>     here constant magic-exception
>>>
>>>     : exception ( sd.message -- n )
>>>       align magic-exception , here >r ," r>
>>>     ;
>>>     : message-by-throwcode? ( n -- c-addr u true | n false )
>>>       dup magic-exception here within 0= if false exit then
>>>       dup cell- @ magic-exception <> if false exit then
>>>       count true
>>>     ;
>>>
>>> In this simple variant we don't provide a method to find the throw code
>>> by a message, and the "exception" word shall not be performed when the
>>> current definition exists. But these limitations are not too difficult
>>> to mitigate.
>>
>> Interesting technique.  Since n is an exception I would just throw it (e.g.
>> via ?ABORT).
>
> Formally n is a throw code.
>
> "?ABORT" doesn't accept a throw code, it accepts a flag and always uses
> -2 as a throw code.
>
> An arbitrary throw code can be used as the argument of THROW
>
> s" test error message" exception constant my-ior
> :noname my-ior throw ; catch message-by-throwcode? 0= abort" Err" type
> \ it should print "test error message"
>
> The system can use "message-by-throwcode?" to show an error message when
> an exception was not caught by the user.
>
>
>> Personally I would have a hard time justifying EXCEPTION. YMMV
>
> I don't sure that namely this variant is worth standardizing. But I like
> it's key idea, since it provides an easy way to avoid the possibility of
> throw codes collision.

It's not worth standardizing message-by-throwcode? because most users will
say the system should be the error handler of last resort i.e. if I THROW
a code generated by EXCEPTION and don't CATCH it, the system should display
the message and abort.

On 2022-01-14 17:35, dxforth wrote:
> On 14/01/2022 17:29, Ruvim wrote:
>> On 2022-01-14 03:06, dxforth wrote:
>>> On 13/01/2022 22:37, Ruvim wrote:
>>>>
>>>> A dedicated linked list is only one of possible implementations.
>>>> For example, a word list is a built in linked list that can be also
>>>> used. But it can implemented even without any linked list!
>>>>
>>>>     here constant magic-exception
>>>>
>>>>     : exception ( sd.message -- n )
>>>>       align magic-exception , here >r ," r>
>>>>     ;
>>>>     : message-by-throwcode? ( n -- c-addr u true | n false )
>>>>       dup magic-exception here within 0= if false exit then
>>>>       dup cell- @ magic-exception <> if false exit then
>>>>       count true
>>>>     ;
>>>>
>>>> In this simple variant we don't provide a method to find the throw code
>>>> by a message, and the "exception" word shall not be performed when the
>>>> current definition exists. But these limitations are not too difficult
>>>> to mitigate.
>>>
>>> Interesting technique.  Since n is an exception I would just throw it
>>> (e.g.
>>> via ?ABORT).
>>
>> Formally n is a throw code.
>>
>> "?ABORT" doesn't accept a throw code, it accepts a flag and always uses
>> -2 as a throw code.
>>
>> An arbitrary throw code can be used as the argument of THROW
>>
>>     s" test error message" exception constant my-ior
>>     :noname my-ior throw ; catch message-by-throwcode? 0= abort" Err"
>> type
>>     \ it should print "test error message"
>>
>> The system can use "message-by-throwcode?" to show an error message when
>> an exception was not caught by the user.
>>
>>
>>> Personally I would have a hard time justifying EXCEPTION. YMMV
>>
>> I don't sure that namely this variant is worth standardizing. But I like
>> it's key idea, since it provides an easy way to avoid the possibility of
>> throw codes collision.
>
> It's not worth standardizing message-by-throwcode? because most users will
> say the system should be the error handler of last resort i.e. if I THROW
> a code generated by EXCEPTION and don't CATCH it, the system should display
> the message and abort.

Yes, you are right, but it's unrelated to standardizing
"message-by-throwcode?". If no exception frame on the exception stack,
the system should display the message regardless of this word. And by
the section 9.6.1.2275 a system is already allowed to do it:

| Otherwise, the system may display an implementation-dependent
| message giving information about the condition associated
| with the THROW code n.

Also, I said nothing concerning standardizing the word
"message-by-throwcode?". But I believe such a word should be
standardized. It's useful to a user-defined text interpreter, to some
libraries for logging, etc. And such a function is usually implemented
by systems in any case.

--
Ruvim