Digest #216 2023-02-25
For two's complement representations:
: D0= 0= SWAP 0= AND ;
what "... the remainder of the current line." actually means. Does it mean to imply that
>INto the next multiple of 64, or would CR characters terminate a line?
According to the section 126.96.36.199 Implementation-defined options, it's an implementation-defined option:
the length of a line affected by 188.8.131.525
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.
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 184.108.40.206 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.
REFILLstrongly 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.
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.
As I can see, "nesting of input sources (i.e., with
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
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
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.