The beloved fish who swims through the code of ><> (an esoteric programming language) has been taken out of its natural environment. This change has rendered it incapable of moving around in the way it's used to: what used to be toroidal movement has been restricted to simple left-to-right movement. But ><> programs are still written as if the fish were capable of moving through them. It is your task, dear programmer, to write a program to linearize a ><> program. And do it in as few bytes as possible; fish don't have very large memories.
Movement in ><>
In ><>, movement is toroidal and one character at a time. This means that the fish (the pointer) can "wrap" around from the end of a line back to the beginning. In ><>, the fish also is capable of moving top-to-bottom, bottom-to-top, and right-to-left, in contrast to the way most pointers move. So this movement pattern would be valid:
>>>^ >>>v
>>>^ v
and it would end on an infinite loop (looping back to the top line once it gets past the bottom infinitely).
The fish moves in a grid of length equal to max(row length) and height equal to the number of rows.
How do you figure out which way the fish moves? These commands change the direction vector of movement (e.g. (-1,0) means right-to-left):
Command | Direction Change
---------------------------
> | (1,0) (default)
< | (-1,0)
^ | (0,1)
v | (0,-1)
/ | (x,y) -> (y,x)
\ | (x,y) -> (-y,-x)
| | (x,y) -> (-x,y)
_ | (x,y) -> (x,-y)
# | (x,y) -> (-x,-y)
; | (0,0)
As noted, the fish starts moving left-to-right, i.e. with direction vector (1,0). The fish starts parsing commands starting with the first command it sees and changes its direction if a command matches one of the aforementioned direction changers.
The fish stops moving when it sees a ; and terminates the program.
Input
Input will be a valid (e.g. not infinitely looping) program given through STDIN. You may also read a file if you wish. The lines of each program will not necessarily be of the same length.
Input is given as a string, with newlines separating each line in the program.
Programs will not loop, which also means they will always terminate with a ;.
Output
Output will be the program linearized. That is, you should return all of the characters (including direction changers) that the fish would see if it ran the program "normally." This is all of the characters in its path to the ;.
If the input is has lines of unequal length and the fish ends up moving along a line shorter than the length of the longest line, you should treat that as if the fish were moving over a space (see test cases).
Those familiar with ><> will know that direction changers are not the only way to do movement in it, but for simplicity's sake treat the input as if they are the only way to affect movement.
Rules
- Standard loopholes apply
- You may write either a full program or function
- Input is supplied through STDIN or a file as a string containing the program lines separated by newlines (
\n)- You may take the input differently, within reason (feel free to ask me if you have a specific kind of input in mind). You may not pad the input with spaces so the line lengths match.
- Refer to this meta post regarding flexible input. As it stands of posting, general consensus is to be as flexible as possible within reason.
- Output is a single string through STDOUT or returned by the function (depending on what you choose to do, see Rule 2)
Test Cases
v >v
>abcv//;
gfed<^ih
v>abcv<defghi^//>v;
v >v
>abcv//;
gfed<^
v>abcv<defg ^//>v;
abcdef;
abcdef;
abcd|;
abcd|dcba;
abcd#;
abcd#dcba;
abcd\;
_
abcd\_\dcba;
^;
>abcde/
^jihg<
^ >abcde/ <ghij^a;
;
;
