In Thinking Forth (also here), Leo Brodie writes:

LaFarr Stuart...didn't like the input buffer, so he implemented Forth without it, and discovered that he didn't really need an input buffer.

How is the Forth input buffer used, and how did Stuart's alternative implementation without it work?

  • 1
    Forth Inc (forth.com) have a free, downloadable pdf of "Thinking Forth". The link in the question might give missing pages.
    – UncleBod
    Sep 16, 2022 at 13:41
  • 1
    @UncleBod Thanks for the clue. I like the Google Books link because it highlights the start of the relevant text on the page, but I've added another link to that page (without highlighting) in a copy that makes the full text available.
    – cjs
    Sep 16, 2022 at 14:57

2 Answers 2


Typically, a Forth interpreter will read an entire line of text into a buffer called "the input buffer" and will then scan that buffer, breaking it down into words which it either executes or compiles. Because Forth machines are often quite low level and lack fully dynamically allocated memory, it's hard for an implementation to read a line of arbitrary length so the input buffer is usually a fixed size and that represents the maximum line length (ignoring such modernisms as UTF-8 for now).

It seems that LaForth, instead of waiting for a new-line, merely waits for a space and so executes/compiles each word as it is typed in and does not wait for the end of the line. There's still a buffer, but it is quite a small buffer. Word size is constrained but line length is not.¹

It seems like a nice approach and probably leads to a simplified parser. but there are some issues. Ansi Forth more or less assumes that the input buffer exists and so includes words that can be used to manipulate it in various ways. I don't see how these words (which are considered standard) could be implemented in LaForth.

¹ This is described in section 1.3.1 of the LaForth book.

  • @cjs No I don't mind. I should have cited it myself but I forgot to add it.
    – JeremyP
    Sep 17, 2022 at 9:01

It depends on your interpretation of input buffer.

The answer is in section 1.3.1 of LaForth. There is an input buffer but not as most systems would interpret the meaning of the term. It only gathers one word and then interprets it immediately. It does not wait for the user to type in an entire line into a buffer before starting the interpretation process.

The question is whether the buffer used to gather the word is an input buffer. I would say it is - the terminator is a space. Some would argue that it isn't an input buffer because there is no line terminator (CR/LF). The main difference is the ability to edit the buffer. If it is interpreted immediately, the user has no chance of editing. If it waits until a CR/LF is input, the user can still edit the buffer.

  • 5
    The simple phrase "input buffer" does not imply "line" in any sense, so I agree with you. It's a buffer and it contains input. QED.
    – dave
    Sep 16, 2022 at 15:56
  • @another-dave Of course the degenerate case of this is using the A register as a one character "input buffer." :-P
    – cjs
    Sep 17, 2022 at 22:47
  • 1
    @cjs A firmware project of mine for a CPU with 16 bytes of RAM has a one bit input buffer for a button I need to know the previous and current state of. I still think of it as an input buffer, so why not? :)
    – pipe
    Sep 18, 2022 at 9:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .