6.1.0895 CHAR char CORE

I don't see this defined in the standard at all (not even as ambiguous condition). I guess we should fix this in the standard.

I think a system should react to this condition by reporting an error.

There's not even a suitable standard throw code available.

Gforth's current behavior is to return whatever character is found after the end of the input buffer, which is a classical read outside boundary problem.

I have just fixed this in Gforth, which now produces an error. I have used -16 "Attempt to use zero-length string as a name" as throw code, but it does not quite fit.

Yes, seems like an error to me, too. Thanks.

My Forth does REFILL until it finds a char... does that make sense, or is it better to simply ABORT?

The section 3.4.1 Parsing says: "Parsing may change the contents of >IN, but shall not affect the contents of the input buffer". It means, CHAR, doing parsing, shall not refill the input buffer.

On the other hand, 4.1.2 Ambiguous conditions says that an ambiguous condition can occur due to "unexpected end of input buffer, resulting in an attempt to use a zero-length string as a name". NB: "name" is not necessary a word name. It's a special parsed text abbreviation, which means "a token delimited by space" (actually a lexeme).

Due to this ambiguous condition, CHAR may do anything if name is empty string, including refilling the input buffer. Probably a good choice is just to throw an exception.

CHAR has default compilation semantics, and that may be confusing. Forth-94 supports [CHAR] for compiling a literal character into a definition. In Forth-2012 there is also the option to use the syntax 'A', which pushes the ASCII code of A at interpretation/run-time.