[290] 2023-02-24 14:39:44 JimPeterson wrote:

referenceImplementation - Possible Reference Implementation

For two's complement representations:

: D0= 0= SWAP 0= AND ;

[r988] 2023-02-24 16:33:46 ruv replies:

requestClarification - "... the remainder of the current line."?

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, 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.

[r989] 2023-02-24 19:10:52 ruv replies:

referenceImplementation - Maybe `REFILL`?

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: "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" 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 on this regard.

[r990] 2023-02-24 19:42:45 JohanKotlinski replies:

comment - Tail call elimination

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.

[r991] 2023-02-24 21:36:11 ruv replies:

comment - Input source after THROW

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.

And A.13 also says that the standard "does require INCLUDE-FILE to unnest the input source specification if an exception is THROWn".

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.