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


,------------------------------------------
| 2023-02-24 14:39:44  JimPeterson  wrote:
| referenceImplementation - Possible Reference Implementation
| see: https://forth-standard.org/standard/double/DZeroEqual#contribution-290
`------------------------------------------
For two's complement representations:
```
: D0= 0= SWAP 0= AND ;
```


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


,------------------------------------------
| 2023-02-24 16:33:46  ruv  replies:
| requestClarification - "... the remainder of the current line."?
| see: https://forth-standard.org/standard/block/bs#reply-988
`------------------------------------------
> what "... the remainder of the current line." actually means.
> Does it mean to imply that `\` will skip `>IN` to the next multiple of 64, or would CR characters terminate a line?

According to the section [7.4.1.1 Implementation-defined options](https://forth-standard.org/standard/block#subsubsection.7.4.1.1), it's an _implementation-defined_ option:
- > the length of a line affected by 7.6.2.2535 `\` (if implemented).

It means that if a program has source code in blocks, an it employs the system's implementation for the word `\` (line comments), then this program has an _environmental dependency_ concerning the length of a block line.



,------------------------------------------
| 2023-02-24 19:10:52  ruv  replies:
| referenceImplementation - Maybe `REFILL`?
| see: https://forth-standard.org/standard/core/bs#reply-989
`------------------------------------------
> Is this, effectively:
> ```
> : \ REFILL DROP ; IMMEDIATE
> ```

It isn't acceptable, since `REFILL` **may** change the input buffer, but "`\`" must not change the input buffer.

See [3.3.3.5 Input buffers](https://forth-standard.org/standard/usage#usage:inbuf):
"The address and length returned by `SOURCE`, the string returned by `PARSE`, and directly computed input-buffer addresses are valid only until the text interpreter does I/O to refill the input buffer or the input source is changed".


> wouldn't simply "... discard..." suffice?

"_To parse_" is a formal term, which also refers "[3.4.1 Parsing](https://forth-standard.org/standard/usage#usage:parsing)" that describes the behavior in details (i.e, how `>IN` is changed). "Discard" means that the parsed string is not used.  Without "parse" the specified behavior would be less clear.


>  `REFILL` strongly implies that it operates one line at a time. 

In the **general** case, it depends on the input source kind. If you want to be independent on that kind, you cannot assume that `REFILL` operates on text lines. See my post [Portable line-oriented parsing](https://github.com/ForthHub/discussion/discussions/126) on this regard.



,------------------------------------------
| 2023-02-24 19:42:45  JohanKotlinski  replies:
| comment - Tail call elimination
| see: https://forth-standard.org/standard/core/RECURSE#reply-990
`------------------------------------------
Hi, sorry for being unclear! I certainly did not mean that there should be a general guarantee of tail-call elimination.

What I meant, `RECURSE ;` and `RECURSE EXIT` could guarantee tail-call elimination.

I realize that it is a bold proposal. But it would make `RECURSE` way more useful, to allow recursive code without stack-overflow.



,------------------------------------------
| 2023-02-24 21:36:11  ruv  replies:
| comment - Input source after THROW
| see: https://forth-standard.org/standard/exception/THROW#reply-991
`------------------------------------------
As I can see, "nesting of input sources (i.e., with `LOAD`, `EVALUATE`, or `INCLUDE-FILE`)" is mentioned, and un-nesting input source specifications is **required** by the section [9.3.5 Exception handling](https://forth-standard.org/standard/exception#subsection.9.3.5).

And [A.13](https://forth-standard.org/standard/rationale#rat:exception) also says that the standard "does require `INCLUDE-FILE` to unnest the input source specification if an exception is `THROW`n".

I used to think that it's an omission that `THROW` restores the input source specification, while `CATCH` does not save it. But actually it's **by intention**.
The Idea is that `THROW` restores what `INCLUDE-FILE` (or `EVALUATE`, etc) saves. If nothing was saved (between an instance of `THROW` and the nearest instance of `CATCH`), then the input source specification is already the same as before `CATCH`, and no need to restore it.

---

> In the long run we should probably specify a (logical) input stack 

It's a possible way to describe this behavior more clear/ thoroughly.
Another possible way is to formally use the exception stack (and exception frames) for that, taking into account that the Exception word set is mandatory.

Although, it seems this formalism is not worth introducing, since there is no questions on this regard. The questions were only about the state of the input source (whether this state shall be restored or not). So it's enough to clarify only this.