Brainf*ck Language EOF Design Problem
in brainfuck language, there's the issue of EOF.
what should EOF be?
and this really means, whether the system should have the capability of knowing there's no more input.
if so, then EOF should return a value. Else, it can do nothing.
if we want this capability, then we need a value for EOF. What value should it be?
then, the issue touches on user interface. That is, should we allow user to input a value of 0?
because, if we allow user to input 0, then, EOF can't take that value. So, the natural choice of EOF would be -1. (which is, not a possible value of a byte normally. This complicates brainf*ck spec.)
if we do not allow user to input 0, then, EOF can take that value of 0.
In the end, it's a design issue. There isn't a best answer. The issues are:
- should the system know when there's no more input. From a engineering point of view, as building a machine, yes is better. From pure abstract brainf*ck “math model” point of view, no is better.
- should the UI allow user to input 0? From pure UI design point of view, yes, because that way is simple, consistent, allowing user to input any value in a byte. (and byte here we assume a integer of 0 to 255.) But then the problem with this is, for implementation, we can't use 0 as EOF anymore, and complicate things as there's no -1 in a byte normally. (unless we don't want the machine to be able to know there's no more input.)
|◇||allow UI 0||no UI 0|
|allow EOF detection||EOF = -1||EOF = 0|
|no EOF detection||N/A||N/A|