# Teletype operator precedence/parse order

I’ve just discovered a subtlety in teletype’s operator precedence or parse order. At the `>` prompt, do

``````P.PUSH 10
P.PUSH 13
``````

Now

``````P 0
``````

returns 10, and

``````P 1
``````

returns 13. However,

``````ADD P 0 P 1
``````

returns zero instead of 23, and

``````P 0
``````

now returns 13! What I think is happening here is that `P 0 P 1` is getting evaluated before the `ADD`, so `P 0` is getting set to the value of `P 1`; what surprises me is that `ADD` doesn’t insist on having two arguments and fails silently by returning zero. I know that data flows from right to left, but I would have thought the parser would vet the whole line before performing any evaluations.

(Although

``````X P 0
Y P 1
``````

is a fine workaround for this, both lines and variables are precious in teletype, so I was trying for concision.)

Ahoy! I’d call this a bug and not an operator / precedence behaviour… Will look into what’s going on here as you are indeed correct that the line should be vetted before being executed.

Cool, thanks. I’ll file it as a github issue.

I noticed a similar issue, although not specifically with ADD.
If I remember correctly (not in the studio at the moment) I was trying to do this:

IF EQ PN 0 X 1 : TR.PULSE 1

which ended up setting the pattern positions to 1s as opposed to evaluating the equation.

thanks for the heads up. there are some tricky issues in the code with this stuff, i will track them down. this is definitely an issue with `P` and `PN`

I’m curious about how a bug is possible. Guess I do not understand the nature of code. I mean, you punch a problem into a calculator, and it spits out the results. How does Teletype code ultimately differ from the code in a calculator? The calculator does not make a mistake, cause it does not know how to. At least, I have never come across a bug in a calculator, nor have I ever bought a calculator while it was in beta stage. “Please, send your calculator back to Target in about a week.” The calculator has it’s limits in memory and screen size and processing power, but the calculator “knows” that, so it will not let you exceed it’s limits. The idea of a code bug looks almost like a calculator which does not know its own boundaries. “Whoops, sorry! I told you I have 10 k of memory, when in fact i only have 5. If I had known that at the time, I would have prevented you from punching in those values. Or I would have miraculously expanded my own memory, resulting in me being the very first evidence of sentient artificial intelligence with a gym pass.” This question is either very philosophical or very fundamental, but I would like to understand this, and am slightly embarrassed that I do not.

Blessings,
Damon †

Here is an excellent article that covers exactly what you’re asking. I recommend everyone read it.

http://www.bloomberg.com/graphics/2015-paul-ford-what-is-code

3 Likes

That is an amazing article that should be required reading.