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


,------------------------------------------
| 2020-01-09 21:15:01  Blackice  wrote:
| requestClarification - Why RECURSE is needed?
| see: https://forth-standard.org/standard/core/RECURSE#contribution-125
`------------------------------------------
: FACTORIAL ( +n1 -- +n2 ) DUP 2 < IF DROP 1 EXIT THEN DUP 1- FACTORIAL * ;
After the execution of the ":" the word FACTORIAL is defined in the vocabulary and available for FIND. Even as incomplete definition, nothing prevents to compile the call to itself. Why special word is needed?


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


,------------------------------------------
| 2019-10-30 11:17:45  ruv  replies:
| requestClarification - license
| see: https://forth-standard.org/standard/implement#reply-340
`------------------------------------------
As I can see, a license is not mentioned anywhere in the standard. 

Usually, reference implementations are licensed under some [permissive license](https://en.wikipedia.org/wiki/Permissive_software_license) or even dedicated to the public domain. Particularly, the reference implementations that are the result of standardization processes are often dedicated to the public domain (see [Wikipedia](https://en.wikipedia.org/wiki/Reference_implementation)).

In any case, we may assume there is no any licensing fees.



,------------------------------------------
| 2019-11-07 00:11:50  ruv  replies:
| comment - Ambiguous condition could be removed
| see: https://forth-standard.org/standard/core/POSTPONE#reply-341
`------------------------------------------
> @ruv: Your implementation sketch is not complete enough to be sure what the plan is. 

I published a proof of concept, a working example that can be tested on a standard Forth system, see at [GitHub](https://gist.github.com/ruv/21e7b4d0693dce587adeecb824e9c5aa).

>  Looking at the behaviour of S" in SwiftForth (it behaves as a STATE-smart rather than dual word), I don't expect SwiftForth to change even if you remove the ambiguous condition; unless a customer complains, but they apparently have not about S".

My proposal does not affect `S"` word. Applying `POSTPONE` to `S"` was never ambiguous. So, behavior of `POSTPONE S"` is already non standard in SwiftForth. I just show a simple way how to fix this issue, and also make `POSTPONE` proper working for other words with minimal effort.

I agree that it is reasonable to wait until the proper implementation will be sufficiently common. OTOH, there is a sense to take into account only those Forth systems in which `POSTPONE` correctly works for all words except `TO`, `IS` and `ACTION-OF` (that are only affected by my proposal). Since if `POSTPONE` incorrectly works for some other words in a Forth system, changing the ambiguous condition regarding these three words does not change the compliance status of this Forth system. Don't sure that we know even a few such Forth systems.




,------------------------------------------
| 2020-01-10 09:49:12  AntonErtl  replies:
| requestClarification - Why RECURSE is needed?
| see: https://forth-standard.org/standard/core/RECURSE#reply-342
`------------------------------------------
See the specification of [:](http://forth-standard.org/standard/core/Colon) :

> The current definition shall not be findable in the dictionary until it is ended

So your FACTORIAL does not work in standard Forth.  That's why Forth has RECURSE.

Why are colon definitions only visible later?  1) If you make an error, resulting in an incomplete definition, this protects you from calling it.  2) You can define words with the same name, and extended behaviour that calls a previous word with the same name.