Couldn't this be seen as an interpreted language? (Or rather an instance of a modified BF interpreter?). If you think about it, this is exactly what Easy is doing (except for the inverted operations). I see it as no different from running python commands (or even perl commands?) from its command line interpreter. Similarly, it could be conceivable to run Easy and pipe in a modifified BF program through standard in, and achieve the same results as running the same BF program in its compilation state. Does this make sense or am I missing something? --Stux 01:11, 21 Oct 2005 (GMT)
- I think you're right, but there's the problem that an instruction can't be input unless it needs to be executed or used for a bracket matching. --Ihope127 19:11, 21 Oct 2005 (GMT)
- Ohh! I see what you mean! So the program replaces the normal input and so we don't have any way of sending normal input into the program's own standard input stream, right!? Then, doesn't that mean that Easy has that same deficiency? --Stux 18:52, 23 Oct 2005 (GMT)
- Um, user input is divided between program and "normal" input as is needed. --Ihope127 14:29, 24 Oct 2005 (GMT)
- Oh, I'm sorry I completely misunderstood what you meant then. Are you referring to a problem with the Easy specification, or a problem with piping commands to BF? --Stux 04:22, 25 Oct 2005 (GMT)
- It's the problem with giving the commands to BF: there's no way as far as I know to completely write a program before it's run. --Ihope127 15:35, 25 Oct 2005 (GMT)
- Ok I think I (finally) see what you mean, no wait I take that back. Grrr! Why am I not seeing this the right way!? Ok so currently if I pipe in a BF program it will try to execute it the moment the first character of the program comes in, but when it encounters a "[" it must find the next "]" and cannot since it hasn't been presented as input. Likewise (this is me expanding a little) if it finds a "]" it must either go back in the input quite a bit (something not necessarily available on all streams) or store the entire program in memory already as the input comes in. Is that um... better? (If so... wouldn't that mean that implementing Easy would probably run into the same problem?) --Stux 14:12, 31 Oct 2005 (GMT)
- Hmm. I think I'll write a little bit of Easy "code" right here:
- First, the interpreter tries to execute the first character, but it doesn't exist, so it accepts some input, which is "+". Then it executes this +, then goes on to the next instruction, which still doesn't exist, therefore it is taken from input again. However, this is a left bracket, therefore the interpreter keeps accepting input until a right bracket is reached, therefore "[.,]" is taken as one big block. Then it is executed, and this piece of code takes ",+++." as input: it is treated as input, not as code. Then EOF is input and output again, and therefore this loop exits. It transfers to the next piece of "code", which must be taken from input, however EOF is recieved as input again, thus ending the program.
- Input: +[.,],+++.
- Special input: +[.,]
- Program input: ,+++.
- Output: ,+++.
- --Ihope127 16:45, 31 Oct 2005 (GMT)
- Added this to the article page, but changed it to Hello, world! instead. --MizardX 03:48, 16 November 2008 (UTC)
Where do implementations go?
I've dumped into it's own section, but this seems like a bit wrong because it'll only work for tiny implementations. Putting it here (the talk page) seems worse because it's not chatter or questions. If you have a better idea ON THIS SITE please move it there leaving behind a link Rdebath (talk) 09:06, 25 September 2013 (UTC)
- Own section is fine for small implementations. (For a particularly extreme example, look at what happened on Deadfish.) For large implementations, using a subpage is the best idea; for example, see Aubergine and its interpreter Aubergine/aubergine.hs. --ais523 21:00, 25 September 2013 (UTC)