#1

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
ADD X Y

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

> teletype : code exchange
#2

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.

#3

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

#4

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.

#5

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

#6

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 †

#7

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
#8

That is an amazing article that should be required reading.