I guess you are talking about Careful Evaluation.
That one did set $_ within each eval().
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.
The last print() command gives
the \n, and the last two pop() clean
up the stack (@_) and $_.
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).
| [reply] |
I'm confused about one thing. A lot of it I follow without
your explanation, and your explanation makes most of the
rest clear, but... well, whatever is going on with the
print statement and the chr(shift) has me confounded.
Okay, first my own analysis up to the sticking point...
And here's where I get lost...
# 'unshift@_,(shift()+shift())x2;pop',
# 'print+chr(shift);pop'
# Apparently we construct an anonymous list out of those, repeat it 24
# times, and push it (flattened, presumably) onto the tail end of @_.
# This means that the next 48 instructions (err, 49) will be those two
# instructions alternating. Since the first is pushed first, the
# second will be popped first. Also last since It's repeated again
# just above the two instructions we popped off to repeat.
# WTF is that doing?
# Okay, break it down...
# print with no args prints $_ on STDOUT and returns... what?
# [consults Camel]
# print returns 1 if successful, 0 otherwise.
# So we're printing $_, removing the next char from the
# beginning of @_, taking its numeric value, adding one
# to it (or possibly 0, but I think 1), and... throwing
# that value away? What?
# Also, what's on $_? Isn't it still the messy unprocessed ASCII
# version of those hex data? I thought we were done with that after
# we converted it and threw the result on @_? But here we're throwing
# away the converted data from @_ and going back to (repeatedly)
# printing $_?
# HUH?
# [Consults camel]
# [Consults camel more]
# [Consults camel yet more]
# Losted am I.
| [reply]
[d/l]
[select] |
Err, I (jonadab) posted that. I swear I was logged in
when I hit "reply". I'd just voted on a node not twenty
minutes previous. So, err, if anyone replies, /msg me.
Thanks.
| [reply] |
