Use a single RESUME for all INTERCAL-72-style if consructs
If you need to write the equivalent of an "if" statement, the normal method using INTERCAL-72 code is to NEXT
twice and then do a computed RESUME
. (In modern code, often a computed COME FROM
will be better, but this tip assumes your code prefers NEXT
.) You almost certainly have to pay the bytes for the first NEXT
, as it jumps from one branch of the "if" to the other. Sharing the second NEXT
is also nontrivial, unless you have a lot of "if" statements that go to the same place upon seeing a #1
. However, the RESUME
can be anywhere in the program (because control is going to leave it instantly anywhere).
There are two ways to handle this. If you have a lot of "if" statements, then the RESUME
probably warrants a single-digit line number, so that your second NEXT
statement can be as short as possible. If possible, try to make it a computed RESUME
that would naturally occur in your code (admittedly, this is difficult, as it's rare for those to appear in the "normal flow" of code rather than being NEXT
ed to); then, the only cost is the line number. You'll have to use a single boolean variable for all these NEXT
s; the universal consensus here is to use .5
, mostly because it's the variable that the standard library uses for boolean return values.
Alternatively, it's possible to make use of an undocumented (technically underdocumented, because I slipped a hint into the INTERCAL documentation when I noticed) feature of the standard library. Because a central location for a RESUME
is so useful, the standard library uses one internally. Line numbers in INTERCAL are global (with namespacing conventions, but which can be broken if you know what you're doing), so you can NEXT
right into the standard library internals if you want to, and in particular, can NEXT
to its central RESUME location. This is sufficiently popular in existing INTERCAL code that standard library replacements tend to have to implement it to avoid breaking existing programs.
The line in question is (either literally or effectively, depending on the implementation):
(1001) DO RESUME .5
The main reason not to use this is its long line number; if you need to do a lot of INTERCAL-72-style if constructs, it'll be better to use your own to give it a shorter number.
Of course, you can combine the techniques, writing something like
(9)DO(1001)NEXT
which is only marginally longer than
(9)DORESUME.5
and has the benefit that the booleans become #2
and #3
(which is harder to read, but normally easier to generate). Actually, it might even be worth putting in the extra code to handle #0
and #1
if you're going to be iffing a lot (but computed COME FROM
will probably work better in this case unless your requirements are very weird).
Despite the language's intentionally obtuse and wordy syntax,
\$\endgroup\$