A problem of compass directions

The context is this famous paper from 1968.


Even GO TO pales beside the mighty and mind-boggling COME FROM statement.
(Fun fact: COME FROM was implemented in one version of the INTERCAL programming language, and one of INTERCAL’s authors is Don Woods of Adventure fame.)


And then you realize that

Several recent languages have adopted an Intercal-like, asynchronous computed COME-FROM concept. Only they refer to it with funny terms like “exception handling”.
— Hans Mulder

This tangent is not entirely off topic. Compass directions provide a sort of immediate structural clarity, to help the reader visualize the map of the game, just like loops and if-statements in source code help the reader grasp the flow of the program. Named exits are like gotos (or pointers), wildly leading from one point of the map to another.

And yet, a good writer can provide the same kind of clarity in the prose itself, without resorting to compass directions, just like a careful programmer can produce perfectly readable assembly code. And conversely, a badly designed game map with compass directions can be hard to visualize, just like a badly written program in a high-level language can be horrendously difficult to follow, even if there is no goto in sight.


I was waiting for an opportunity to mention Donald Knuth’s “Structured programming with go to statements” from 1974.

A while ago I was toying with the notion of implementing a dystopian language. One keyword was GOWHERE, which takes a 16-letter string (as part of an interpreted language) jumps to the first literal match in the source code (GOBACKWHERE would provide a backtrack, for symmetry).

OMG, I’m sooooo out of that state of mind to remember those kind of jokes XDDD so long time. Funny joke!

I can imagine a time travelling IF:


A land downunder?