From Esolang
Jump to: navigation, search

Computational class

Since the playfield is (it would seem) fixed at a finite size throughout the lifetime of a program, but no limit is put on the size of a number that a Car can represent, probably implementing a Minsky machine in Maze is a better bet for proving it TC than "compiling a Funge to it". Chris Pressey (talk) 16:56, 15 September 2012 (UTC)

Well, thank you very much for this advice! I was in the middle of solving a wire crossing problem to translate crossing gotos from a Minsky machine, when Oerjan pointed out to me that 3-cell brainfuck only had properly nested loops, and so did not need gotos to cross. So here it goes, Maze is indeed Turing complete. --Koen (talk) 01:41, 16 September 2012 (UTC)


Anyone happen to know who designed this language? The article was created by a not-logged-in user, and the page doesn't name any credits. Chris Pressey (talk) 05:35, 16 September 2012 (UTC)


I'm wondering, is it possible to actually use -- in a program? Since cars are supposed to find their way through the maze, I was assuming that every tile in the maze was either:

  • a wall (cannot be driven over)
  • an instruction to tell the car what to do (such as %D, ())
  • a path, or other instruction that doesn't affect the car's driving

and that, in the third case, exactly two of the four adjacent tiles had to be walls. The car is coming from one of the other two adjacent tiles, and can understand that it has to go to the fourth adjacent tile. (And there's also the exception of the starting tile ^^, which by the same logic I assumed had to be surrounded by exactly 3 walls.)
But I see no way for -- ("a path that can become a wall) to be included in a maze without disturbing the "2 walls / 2 paths", since there are no "walls that can become paths" to balance them off. --Koen (talk) 14:50, 17 September 2012 (UTC)

As I see it, the specification is rather unfinished in some parts. (Afaict the original editor only made that one edit and one to the language list.) It says nothing about what to do when there is a possible choice, or a contradiction. For example, what if two cars are about to crash? I could imagine that if a car has no way to follow instructions or drive along, it might just stay put for that turn, or perhaps turn around in some cases, and that with multiple possible paths things get nondeterministic, perhaps using random selection. Some of the options might allow a -- to be usable, although naturally only once, which makes it a bit less interesting anyway. --Ørjan (talk) 15:46, 17 September 2012 (UTC)
I'm not sure cars can interact with each other - I see nothing wrong with two cars being on the same tile at the same moment, except maybe flavour (though you can imagine tiles to be large enough for several cars; after all, tiles are no less than TWO characters wide!!). Just staying put doesn't look good, since if it can't move this turn, chances are it'll never be able to move again (except maybe if it's stuck on a function like "IF ** THEN %D ELSE ..". or maybe that can be a use for --... imagine the following situation, where V is a car that just arrived from upside:
..,V ,--,##
Here the car is stuck because it can't decide whether to go left (to ..) or right (to --). But as soon as another car drives over --, it will become a wall, so our car will stop having a choice, and thus will go to the left.) But as you said it's one-use only; besides it only works if cars are "walls" to each other, otherwise the second car will be stuck on the --.
I guess if I were to implement Maze I would make it nondeterministic in case of multiple choices, and either have cars stop when they drive into a dead-end (dead-end because it has 3-walls next to it, or because it's like "%R,##"), or have them go back (as I said, if there are exactly two adjacent paths, the car arrives from one and exits to the other; if there is only one adjacent path, then I guess the car should arrive and leave by the only available path). I would allow car to "phase" through each other (that is, they wouldn't interact directly). An amelioration from the current -- may be to replace it with switches: for instance two new symbols "Gn" and "Sn", with n any one-digit number (or maybe even any character, or printable character), where the passage of cars over Sn toggles Gn from wall to path and path to wall. Another addition to the language may be a WAIT UNTIL <condition> statement in functions, that would force the car to stay put until the condition is met (for instance WAIT UNTIL ** could be used to synchronize cars).
--Koen (talk) 17:18, 17 September 2012 (UTC)

Getting Stuck

Does anybody know what this code would do?


The car would drive over the --, which would then turn into a wall, and make the car get stuck in a one tile area. What I’m really asking is what a car would do if it was stuck in a one tile area. IAM (talk) 20:10, 25 April 2016 (UTC)