|laziness, impatience, and hubris|
59 /e explainedby BooK (Curate)
|on Jun 18, 2001 at 10:47 UTC||Need Help??|
It's not exactly the same here. The program is loosely inspired from my little PostScript experience. It has a stack, and spents most of its time working with it.
@_ (aliased to @ARGV, so that pop() works the way I want) is my stack. I store the data on the bottom of the stack, and the code on top of it. Each line of code is followed by a pop() that put the next line of code in the program counter (sort of). This is not the same as assigning to $_. In fact, $_ is only assigned the value of the result of the last instruction (a pop() on an empty @_: nothing).
To understand the program you have to read the stack (er, @_) backwards.
The first commands put a pop() command at the end of each element (including the data, oops), to ensure that the program will run smoothly.
Next, the hexadecimal data (except the ;pop at the end of it, thanks to substr()) is converted into characters. (OK, this part of the program uses $_ instead of the stack.)
The data is then split, converted into numbers (and negative ones, too, because these are considered signed characters) and shifted back in the bottom of the stack.
Now, the loop is constructed by repeating the two commands on top of the stack 24 times (and the print() goes first). The first piece of data is converted and printed (chr 74 is a J). The next command takes the first two bits of data, add them and put the result twice on the stack. And we loop. print(), keep the result, and add it to the next data.
By now, you found out that the hexadecimal data is the list of offset between the characters of the infamous JAPH line.
Maybe not as easy as you first thought ($s remains the same during the whole program, and $_ is changed several times, without having its content evaluated).