,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2022-08-19 18:00:05  AntonErtl  wrote:
| proposal - Pronounciations
| see: https://forth-standard.org/proposals/pronounciations#contribution-261
`------------------------------------------
## Author:

Anton Ertl

## Change Log:

## Problem:

Some pronounciations are misleading or inconsistent.  This proposal covers all the pronounciations I commented on recently.

## Solution:

Change the pronounciations.

## Proposal:

Change the pronounciations as follows:

Word | current pronounciation | proposed pronounciation | rationale
-------- | ------------------------------ | --------------------------------- | -----------
`+x/string` |  plus-x-string | plus-x-slash-string | audio-to-writing correspondence
`-trailing-garbage` | minus-trailing-garbage | dash-trailing-garbage | consistency with `-trailing`
`f>s`    | F to S | f-to-s | consistency with `d>s`
`s>f`    | S to F | s-to-f | consistency with `s>d`
`x\string-` | x-string-minus | x-backslash-string-minus | audio-to-writing correspondence

### "than"

For many words containing ">" or "<" we have inconsistent pronounciations, some with "than" and some without.  Depending on which way we want to go, one of the following subsections should be accepted, and the other rejected:

#### Have "than"

Change the "less" into "less-than" in the pronounciations of `0< <# d0< du< f0< f<`

Change the "greater" into "greather-than" in the pronounciations of `#> 0>`

#### Do without "than"

Change the "less-than" into "less" in the pronounciations of `< d< u<`

Change the "greater-than" into "greater" in the pronounciations of `> u>` 



,---------.
| Replies |
`---------´


,------------------------------------------
| 2022-08-19 14:47:25  AntonErtl  replies:
| comment - Exception word set is not optional any more
| see: https://forth-standard.org/standard/exception#reply-851
`------------------------------------------
I was tasked with drafting the change, but apparently did not make a proposal for it.  But the editor has implemented the intention of the committee: In forth17-1 it says "The optional Exception word set", while in 18-1 it says "The Exception word set".

The rationale was that we wanted to get rid of ambiguous conditions, and in many cases this would have meant specifying one behaviour for a Forth system without exception wordset, and specifying a different behaviour for a Forth system with exception wordset, which would complicate the standard, and would make it harder to use (a standard program would have to consider both behaviours).  The cost is that even small systems now have to implement CATCH and THROW, but given that these words are cheap to implement, we decided that the benefit is worth this cost.

The alternatives you suggest would run counter to the intention of reducing the ambiguous conditions, and they are an example of the complications we avoid by making the exception wordset mandatory.


,------------------------------------------
| 2022-08-19 15:09:45  AntonErtl  replies:
| requestClarification - Should QUIT propagate exceptions?
| see: https://forth-standard.org/standard/core/QUIT#reply-852
`------------------------------------------
Of course in Forth-94 and Forth-2012 QUIT does not empty the exception stack because there is no exception stack in CORE.  Now, with the exception wordset being mandatory, emptying the exception stack can be specified.

I tried your example (but with "3 throw" instead of "abort" to make it easier to see what happens) on Gforth, iForth, SwiftForth, and VFX64, and none of the printed "test-passed"; all of them behaved just like when you do "3 throw" on the command line without going through your code; i.e., in all of them QUIT empties the exception stack.  So we should specify that in the standard.