Parse this sic

From Esolang
Jump to navigation Jump to search

Parse this sic is an esoteric programming language by User:Digital Hunter. The name has a cute double meaning, and also serves to continue the pattern of languages I've created that end with "-ic".

If there's anything that needs clarification please bring it up on the talk page. If there are any glaring errors use your best judgement on how to clear them up.

Language overview

Parse this sic, or PTS, is a stack-based language with self-modifying code, built on the premise of the "word" datatype. Each word is essentially a string (but calling them strings is cursed and illegal) with an attached numeric value, and from this point forth words will be described with double quotes (as any string would). Anything that evaluates to a word can be passed to a parenthetical expression, and is known as a label. How exactly words' values are determined will be described in detail later. The null word is a special word that looks like an empty string, and is the shortest word with a value of zero.

Whitespace is never ignored, and words can and probably will contain interesting whitespace characters that an implementation must handle neatly. Additionally, whitespace contributes to the character count of a program which will matter to you in a few minutes if you're reading this for the first time.

Certain expressions will evaluate to a number, which is the natural result of performing arithmetic. The program itself will keep track of the correct value with a word that suffices, and the programmer can assume that any given number will always be mapped to the same representative word. A good implementation would store all numbers as the shortest word with the correct value. A list of the shortest words with specific values will eventually be provided. To either eliminate or espouse your confusion, this page will be written with normal base-10 numerals unless otherwise specified, and with the hope that you don't think too hard about the fact that every base is base-10.

Every character in your source code is given an index, with the first given index 1 and the last given index 0. Indices increase from left to right by one per character, and wrap around the edges. For example, in


, the = at the very end has indices 0, 9, -9, 18, -18, and I think you can see the pattern. Yes, it does get annoying to keep track of indices in long programs where the code that needs indices changes the length of all the code and you have a lot of things all depending on each other. No, nobody's doing anything about it.

Character indices wrap because code execution wraps around the edges. A program without a proper terminating case will thus repeat indefinitely.

Commands and keywords

Commands are commands, and keywords are special words that change the effects of a three-parameter parenthetical. This is a basic overview of their properties.

Command or keyword Description
+ Pops a word off the stack and jumps to the character in the program matching the index of the word's value. Technically evaluates to that word but this is nearly unusable. Is NOP if stack is empty.
- Flips the code reading direction between LTR (default) and RTL. Also flips the indices of every character. Technically evaluates to the null word but this is nearly unusable. Parentheses pair the same way regardless of code direction; a single parenthesis can act as either an open or a close.
* Pops a word off the stack and evaluates to it as a label if inside a parenthetical, outputs the word otherwise. Is NOP if stack is empty.
/ If the code direction is LTR and the value of the word on top of the stack is less than 1, skip to past the next / found.

If the code direction is RTL and the value of the word on top of the stack is greater than 0, skip to past the next / found.

Technically evaluates to the word peeked at but this is nearly unusable.

& Tells the program to stop reading a word. Creates a label to that word to which the whole bit (as in bunch) evaluates.
| Skips to past the next | in the code. Please don't ever make use of the fact that this evaluates to the null word. Do realise that this can be used as almost comments. However, the most effective way to write comments is to surround them with & on both sides.
= Kills program execution.
() Parenthetical expressions come in four flavours: zero-parameter, one-parameter, two-parameter, and three-parameter. They will be described more clearly later.
Anything else Activates program word-reading.
"ameliorate" When the first parameter in a three-param evaluates to "ameliorate" exactly, the parenthetical evaluates to a word with the value of the sum of the other two parameters.
"dominate" Same deal as above; evaluates to the third subtracted from the second.
"times" Same deal as above; evaluates to the product of the other two.
"spaces" Same deal as above; evaluates to the integer quotient where the second is the dividend and the third is the divisor. If the third has a value of zero, evaluates to the null word.
"walking" Same deal as above; the second parameter is interpreted as a PTS program operating on the same stack as the main program, but with independent indices. All zero-params immediately evaluate to the third parameter. The whole expression evaluates to the concatenation of everything output from the mini-program through * (null word if no output from miniprogram). However -- this is IMPORTANT -- the altered stack is the ONLY side effect of the miniprogram.
"succeed" Same deal as above; the first (determined by code direction) instance after the closing parenthesis of this expression of a substring of the code that matches the second parameter exactly will be replaced with the third parameter, with the search wrapping around the edges. If no replacement can be made, evaluate to the null word. If a replacement is made, evaluate to the word that was replaced (the second parameter).
"ditto" Same deal as above; evaluates to the second parameter if the second and third parameter match. Evaluates to the null word otherwise.

A neat 7-command 7-keyword situation.

More on words

Words are neat because they serve the function of both a string and a number. Note: I put number in italics when referring to numbers, those interesting technical words that result from an arithmetic three-param.

When the time comes to determine the value of a word, its equivalent string is searched through character-by-character from the beginning until a valid digit is encountred. A digit qualifies as any 0..9 or A..Z character (case-sensitive), and the first digit found will determine the base in which the rest of the word is read as a number -- 0 indicates unary, 1 indicates binary, Z indicates uhh base-36. Every nondigit will be ignored when calculating the value of the word from then on.

For example, the word "140f9ai392(324" has a value equal to 2 (with or without the quotes!), because the word is read as the binary number 10. A nice consequence of PTS's number system is that both "0" and "1" have the same value.

In code, words are generally first created with a word literal. When the program is run, if a non-command character is encountred it is treated as the first character in a word and word-reading mode is activated. Every character read from then on is added to the word, until & is found. This ends the word reading and creates a label to the word that was just read, which can then be passed to a parenthetical or just discarded (but why would you ever want to do that? So cruel). For example,


will act as a label to the word "140f9ai392(324" that is destined to do many great things. Do ignore the fact that this label is immediately discarded. Other than wasting memory, however, floating labels are helpful for word values that may be used later, or for placeholders with the "succeed" functionality. Additionally, marking comments and whitespace for readability with & will likely be used in larger programs so an implementation should be able to handle it effectively.

Parenthetical expressions

At long last.


First comes the zero-param. () is the sole example. When encountred in a program ordinarily, the user will be prompted for an input, which is automatically cast as a word. The zero-param will then evaluate to that word if passed to an outside parenthetical. However, in a "walking" mini-program, zero-params will not prompt for input but instead evaluate to the third parameter from the outside program as described earlier.


Next comes the one-param. (one-param&) is a valid one-param, with the word "one-param" as its one parameter. Anything that evaluates to a word can be passed to a one-param. A one-param's sole purpose is to push its parameter onto the stack, but it also evaluates to that word and can be used to do many things. It can even be passed to itself, like ((darkness&)), and push the same word twice!


Third comes the two-param. (1f1sh&2f0sh&) is a valid two-param, where "1f1sh" and "2f0sh" are its parameters. A two-param sees the entire program as one long (and technically infinite) word, and evaluates to the word that is the substring marked off with the indices determined by the values of its parameters, inclusive. This was incredibly wordy, so here's an example.


This code first creates a label to the word "uncopyrightable" which is immediately discarded. Sorry. Anyway, the first two-param looks at character 3 and character 6 to evaluate to "copy" and then also be immediately discarded. The next two-param evaluates to "bath". The final two both look from the very first (value 1) to the very last (value 0 (the second & labels the null word)) characters, and both evaluate to "uncopyrightable&(3&6&)(D&A&)(1&&)(0&&)=" which is the entire program. This makes it very easy to create pretty lame quines, because the source code can always be directly accessed by PTS programs, but interesting/traditional quines can still be written with other means.


At even longer last, the three-param. (perowanfe&word1&word2&) is a valid three-param. But wait, "perowanfe" isn't one of the keywords listed with the handy acronym Astute Dinosaur Thinks Stars Want Some Dinner! This is fine, because the three-param combines the functionality of functions with the equivalent of variable assignment and also word concatenation. Three uses for the three-param.

Above were described the effects of three-params if their first parameter evaluates to one of the keywords. In the example (perowanfe&word1&word2&), however, the second and third uses of the three-param are demostrated concurrently. From this point on in the program, anything that evaluates to "perowanfe" such as perowanfe& will instead evaluate to "word1word2" -- unless it is the first parameter of a three-param in which case the three-param will act to reassign its value -- hence the concatenative ability and pseudo-variable assignment. Some examples assuming these examples were already executed somewhere prior:

&(perowanfe&conch&shell&)         Anything that evaluates to "perowanfe" now evaluates to "conchshell" (instead of "word1word2") 
&(word1word2&conch&shell&)        Anything that evaluates to either "perowanfe" or "word1word2" now evaluates to "conchshell"
&(variable&New_Value&&)           Anything that evaluates to "variable" now points to "New_Value"

For convenience, if the second or third parameters in a redefinition-style three-param is the null word, then the first parameter will point to the exact value of the non-null-word parameter. This is to make working with numbers not a complete pain in the backside.

Parenthetical expressions can (and will) be nested, and are evaluated in the order of code direction, deepest first; if the code is LTR then the program will "enter" any parentheticals it sees from the left, and go as deep as possible. This matters for, say, the effects of stack manipulation. Parentheses pair the same way regardless of code direction -- any given ( could act as an open or a close.


It is specified that it is unspecified how any program will represent internally any given number that isn't 0 (by the null word) or 2..35 (by the digits 2..Z), and any programs written in PTS must assume that numbers other than those 35 cannot be trusted (for output purposes). Note: 1 is not included in those safe numbers because both "0" and "1" are valid words with value 1 as mentioned above somewhere.

To argue this reasoning, take for example the number -6 (negative six). A PTS snippet such as (dominate&3&9&) will evaluate to that number -6, but because there is no word with value -6 the number does not exist. It can still be pushed to the stack and interacted with (though outputting it or any other number other than the safe numbers is undefined behaviour), but in your mind it should appear as a black indecipherable fog. This is how all numbers should be treated in PTS (again, other than the safe ones).

However, because these numbers obey all the same mathematical rules as the numbers you're used to, "conversion" of them to a word that when read in decimal is that number corresponding to the value of the number is possible with a simple base-conversion algorithm. In PTS, this is most readily achieved with a snippet of code that may be executed via "walking". For example:


is a simple (bi-directional!) algorithm whose purpose is to leave the element currently on top of the stack untouched but push a new word that reads as a base-A (base ten) numeral and then terminate (and return control to the part of the program that executed it with "walking"). It is equivalent to the following (really bad) pseudocode:

duplicate the top of the stack
set a variable (newline) to the null word
if the top of the stack > 0
  push the number that is (current top of stack) mod (A)
  if this new top of stack is > 0
    if it is > 1 (checks by pushing the top of the stack - 1)
      set the newline variable to the concatenation of (this top of stack digit) and (its prior value)
      discard the two extraneous top values
      replace the top with it integer-divided by A
      jump back to the very first if-check
    otherwise (it is equal to 1)
      set the newline variable to the concatenation of (the word "1") and (its prior value)
      discard the two extraneous top values
      replace the top with it integer-divided by A
      jump back to the very first if-check
  otherwise (it is equal to 0)
    set the newline variable to the concatenation of (the word "0") and (its prior value)
    discard the single extraneous top value
    replace the top with it integer-divided by A
    jump back to the very first if-check
otherwise (it is zero and the process is done)
  discard the top of the stack (zero)
  push the newline pseudo-variable's value to the stack
  kill execution

where a % b is evaluated with a - (b * (a / b)) if / means integer division, because PTS does not have a built-in modulo operator.

A simple function-ish like this one is essential for any PTS program with meaningful numerical output, though it should be noted that this particular function is intended for use in a setting where negative numbers won't appear. Note that this little algorithm will work (as long as the bounds are correct) regardless of the code direction when it is run with "walking" (the side-effect of swapping code direction does not last).

A similar function with the reverse effect can be written as well, interpreting the word on top of the stack as a decimal number that is converted to a (unspecified) PTS-compatible form:


The most effective (and only) way to use some of PTS's commands is using numbers, however, so it is essential that you can come up with words with the right value on the fly. You can find a list here of numbers that you can use as a lookup table of sorts when writing PTS programs.

Example programs

These examples will eventually be followed up with explanations and prefaced with the knowledge required to understand them and hopefully debug them.

Hello, world!

The simplest one pushes the word "Hello, world!" to the stack to be outputted.

(Hello, world!&)*=

Quite a fun one:

((Saying&the following&))*=Hello, world!

The R-th character just so happens to be the =, so "Saying" points to the first character after that (the S-th character is H here) and "the following" points to the last character.

Cat program

This one will prompt the user for word (basically string) input indefinitely.


Input is taken, pushed to the stack, and outputted, and program execution wraps around to do it all again. Adding a = to the end will make it a simple terminating cat.

Reverse cat


Takes an input and reprints it reversed, demonstrating the basic principle behind .. a non-terminating example:


Note that the "succeed" is never called in the main program; the side effect of replacing the % with the input is therefore limited only to each instance of that code being called with "walking". Because I'm silly, I wrote this code with the intention of it being RTL without realising that it works just fine (and identically) LTR.

A slightly smarter program may be as follows:



Writing a quine in Parse this sic is almost trivial, thanks to the existence of two-params. So trivial, in fact, that the very first example of PTS code on this page is actually a quine program. One may hope to create, then, a more interesting quine, with the restriction that two-params may not be used. This task will prove to be incredibly difficult (though if anyone can write one, User:Digital Hunter would love to see it), so a line must be drawn somewhere. The following code was created with the restriction that no section of code is read with a two-param and outputted directly, basically the minimum requirement for non-cheating:


Take note of the fact that the program is all on a single line -- the wrapping effect is only for "readability" and the code contains no newlines.

ROT13 cipher


A ROT13 encoder/decoder that partially utilises the fact that capital letters have an associated numerical value. Works properly with all but two cases of inputs. Inputs containing the character "é" will have that "é" translated to a "Aa"-form of whichever lowercase letter happened to appear most recently in the message. The other case is if an input begins with a PTS instruction other than | or &, or has anywhere a non-|/& PTS instruction immediately following either an & or an even-numbered |.

Take note of the special treatment given to the word "0", as all other valued characters are simply mapped directly to an appropriate index in the code, but doing the same for 0s would incorrectly translate them into 1s.

The above program has a lot of repeated words, so the author took it upon themself to also create a more compact version:


The compact version borrows from techniques used to create the quine above, and essentially zips up the original ROT13 code into a word pushed to the stack with lengthy repeated sections replaced with short, valued words. The placeholder words need to have a value in order for the main loop of the subcode (succeed&%&*)((succeed&()(*)))/*(E&)+/**((303&&))=% to "know" when to terminate (as when there are no more successions to be made, "succeed" will by default evaluate as a null word; to interact meaningfully with /, the other side of the coin is a valued word).

Once all the substitutions are made and a fully-functional PTS program is sitting on top of the stack, it itself is run and fed a direct input. The ordinary output from the original program is regenerated by the "walking", pushed onto the stack, and outputted at last.

Infinite loop

While any PTS program without a = is trivially an infinite loop, here's one infinitely-executed program that neither reaches the end nor has any +.


A good implementation will crash upon trying to run it (the program length doubles with each iteration).

Here's a similar program that will lead to some kind of recursion error:


A program producing output as shown on the looping counter page may be constructed as follows.


Finite loop

Perhaps more computationally useful than a non-terminating loop in programs, a loop with start and end conditions.

The basic principle behind one in PTS is pushing an indicator onto the stack, whose interaction with / will flip. Here is a simple program showing how this works:

(start-min&&())(end-max&&())               get two variables to hold inputs                   |
&((start-min&(ameliorate&start-min&1&)&))  increment the looping variable.  Loop returns here ^
&((dominate&end-max&start-min&))           our indicator.  Will be positive until the end condition
&/(&*)*(, &)*|                             remove ^ from stack, output start-min which was pushed earlier, loop back
/=                                         in the case our indicator was nonpositive, end the program

The author would also like to showcase simpler loops outputting only the natural numbers less than an input. The first example will be a decrementing loop, as this is far simpler to do given the logic available in PTS.


Here the only storage method necessary is the stack. To create an incrementing loop such as the demonstrative program above, one may instead use three-param redefinition of a "variable", compared to the input stored on the stack:


Note this program may be modified quite easily for an intuitive Disan count, by switching the 1 for a 2 (or any other increment).

Alternatively, the prior decrementing loop can be modified so that instead of outputting directly, each step will instead modify a final term to be pushed onto the stack and outputted:



Prompts the user for input of something whose value will be evaluated in the normal PTS way (use unary or binary input to be safe), and outputs whatever the implementation decides is the best way to represent the number that is the input's factorial.


For example, inputting "5" could output:

  • "AA" -- best implementation!
  • "1111000" -- understandable
  • "000000.." (120 times) -- ☃

That example uses recursion which prevents it from involving a convert-to-base-A segment easily while still showcasing the use of PTS's builtins "intuitively", but it's still a neat little program that does the right job by basically assuming that it does the job of outputting the factorial and simply passing the torch to a "walking" call of itself to find the factorial of one less than its own job, with the base case of 0! = 1.

The following solution does output the base-2 represented factorial of the input, with a simple convert-to-base-2 operation built right into the code:

(Input a number to be factorialed below.
Note this needs a PTS number so use binary or unary to be safe!
Input: &)*(((
&&())))(Factorial of &)**( in binary is: &)*
  ^ This'll take an input, use newline as our "counter", and also pushes it to the stack
Now, we're going to push each number less than that input onto the stack until we reach 0
Something like [5] becomes [5 4 3 2 1 0]
&/((dominate&(*)1&))(J6&)+/(Then the top of the stack is cleared &*) and the goal now is
to perform a loop where the top two stack values are popped and their product is pushed.
By decrementing the value in our counter and checking that it stays above zero, this sort of
loop functionality is achieved! &((
&1&)))/(&*)((times&**))(845&)+ <-- this is just that multiplying step /( Now, we have
the completed factorial on top of the stack as intended.  The only problem here is that it's
in the form of a PTS "number"!  The next step is just to convert it to a consistent form,
and I've chosen to stick with using binary (I feel like unary would end the universe) &*)(
&)*= That bit of code there is the end condition, just output whatever's in our new use of newline
as our binary word placeholder.  We push to the stack our factorial modulo 2, which conveniently in
PTS logic falls on both ends of the slash command (technically we use ditto instead of dominate because
there are only two cases in binary and it's just slightly shorter)
&)| if they're the same, put a 0 in front of our placeholder concatenation thingy and then jump to
    the final step /(
&)  if they're not the same then put a 1 in front of our placeholder and continue to the final step
| <-- this is a "universal landing pad" sort of structure! -->
&(&*)((spaces&* divide by 2 for the next iteration ... &))(WD ... and jump back to repeat --> &)+
                                                              until the top of the stack is zero
                                                              and the base conversion is complete

Here's the same program, minimised:


Unary and binary are the only two bases that have a valid in-PTS representation for every number, and because this particular program is single-input single-output it can conveniently be plugged into any larger program to be run with "walking" to produce a meaningful value. If used in such a way, it may be more efficient to operate directly on the top of the stack, and this can be done by simply replacing the () at the start with a * and deleting the * in the middle by the =.

Fibonacci numbers

The following prompts the user for n (interpreted as a PTS number -- unary or binary to be safe) and outputs the nth Fibonacci number (in decimal!), if the 0th and 1st are 0 and 1, and each next term is the sum of the previous two.


If the user inputs "9" or "1001" or "000000000", the program will output "34".

Kolakoski sequence

The first three terms are hardcoded. This program has no end condition and will continue indefinitely.


Thue-Morse sequence

This program has no end condition and will continue indefinitely.


Look-and-say sequence

Uses the version also known as the "Say what you see sequence"; the rule starting with "1" and continuing indefinitely. No end condition.


The program can also be modified to support the general family of look-and-say sequences, where the user may input a starting seed of their own choosing, as follows:


Collatz sequence

Short program that outputs the chain of numbers associated with the function associated with the Collatz conjecture, in the usual base-ambiguous PTS way.


Expanding upon the logic to slot in base-conversion is possible and simple.



There is a shorter-by-one-character version that does the same job but is simply less interesting:


On account of the fact that it's "straightforward" to see what's going on.

Using a few tricks, the first snippet can be modified into what the author believes to be the most satisfying (and shortest) iteration:


All of these will output-indefinitely 1s if and only if the input exactly equals "1".

Roman numerals

Input PTS number (unary/binary to be easy) up to "F9F", outputs strict Roman numeral evaluation.


The upper bound is arbitrary-ish, because this program supports up to M and its author still does not quite understand the rules of Roman numerals.

Considerably golfed program with the exact same usage and output (actually outputs with a newline), though the non-golfed version uses different PTS techniques from the program above.


Either could conceivably be used inside of larger PTS programs.

Digital root

Contrary to what is said on the digital root calculator page, such a program in PTS is less than easy due to its lack of decimal bias.

The following program is really 3 "functions" and a master program in disguise: one to interpret a decimal input, one that converts valid PTS values to a decimal-readable form, and one that finds the sum of the digits of a supplied (assumed) decimal value.


It essentially works the brute-force way, repeatedly first converting the value on top of the stack to decimal and then summing the digits until it is less than 10.

Using the 1+(n-1)%9 trick makes a much shorter program:


Note that there are 3 and only 3 newline ('\n') characters in the above that are there for aesthetics; it will be left as an exercise to the reader to determine which three.

Square root calculator

Takes two integers, and finds the square root of the first to the precision of the second.

(Input below an integer you'd like to find the square root of,
and then approximately the number of digits of precision you want
Input both in decimal (base ten)

Square root of: &)*((()))(
Number of digits: &)*(d&&())(
Square root of &)**( is: &)*|

Prime number generator

Takes a PTS number input and lists out (in decimal) all the prime numbers up to and including that input using a sort of Sieve of Eratosthenes approach. Output is separated by " " characters.

&)(walking&(E3&&)&)*( &)*(10010011&)+/=(

The difficult part of implementing an eratosthesieve in PTS is that the stack cannot be looked through trivially; this hurdle is overcome by making use of PTS code's ability to edit itself. As the stack is read back in the main logic-dense part of this particular program, stack elements that survive the sieve are popped while some code that comes later is modified to have extra one-params that'll push everything back onto the stack (so deeper elements can be tested as well).

Pi calculator

Takes a PTS number input and outputs some decimal approximation to pi (3.14159265...) whose accuracy vaguely corresponds to the input.


For example, inputting "C" outputs "3141591620995" while "5" gives "313837". Execution takes about A times longer for each increment of whatever's input.

This particular program uses Leibniz's approximation of pi, a special case of the inverse tangent formula.

Phi calculator

Takes a PTS number input and outputs some decimal approximation to phi (1.6180339887...) whose accuracy vaguely corresponds to the input.


For example, inputting "Q" outputs "16180339887802" while "9" gives "161764". Unlike the pi calculator, this one handles inputs as large as "ZZ" easily.

This particular program determines phi as the ratio of consecutive (big) Fibonacci numbers.

Euler's number calculator

Takes a PTS number input and outputs some decimal approximation to e (2.718281828...) whose accuracy vaguely corresponds to the input.

/((spaces&(times&n&s&)d&))_|&/|/( &)(2.&)**=
/*( &0& &)|((dominate&(*)1&))/(&*)( &* &)_|&|/(**)( &1& &)_|&|

For example, inputting "Z" outputs "2718281828459045235360287471352662497757247093699959574966967627724076630353547594571382178525166427427466" while "5" gives "2718281828470583".

This particular program generates a truncated simple continued fraction representation of e on the stack which is simplified for an approximation.


Loops FizzBuzz from 1 to "410" which is 105 in decimal (so it can finish with a FizzBuzz).


Note the extra space (' ') at the start of the second line; some interpreters (such as the one this author is using) will incorrectly handle the side effect of redefining newline ('\n') that should be limited to only the "walking" call (which leads to a messy doubleprinting scenario) and the cleanest solution is just to alter the printed separator invisibly.

99 bottles of beer

This one prints all ten verses of 9 Bottles of Beer with the typo "1 bottles of beer" because I'm lazy. A full program will follow, but this shorter example demonstrates the basic logic of a 99 bottles program. Note the newlines and the double newline in the middle. Necessary for proper spacing of the verses and changing this aesthetically will also require label changes.

Go to the store, buy some more,

,dnuora ti ssap ,nwod eno ekaT
,llaw eht no reeb fo selttob )*((*))/+(&)/(&9)

This particular program could be edited quite easily to almost be a proper 99, but runs into the particular problem that numbers' representations are unspecified. Even if they were specified, by the rules of PTS a decimal-biased song wouldn't be possible anyway -- without a base conversion function. Despite its shortcomings, it's a good example of PTS's flow control, and most prominently the changing behaviour of / when reversed. If the bulk of the program was written for LTR, changing the decision portions isn't difficult but adds length to the program which isn't great.

With all that in mind, this is a full 99 Bottles of Beer, complete with base conversion and good grammar.

(L4&)+ 99 bottles of beer written in Parse-this-sic
=*(&.)*((&8F&3G))*(&99 ,erom emos yub ,erots eht ot oG

))*(&reeb fo elttob 1)*((&000000001&5G))*(&elttob 1)(*&)[h]+(&525)*(&

)&gniklaw)((&1*&etanimod))*(& ,dnuora ti ssap ,nwod eno ekaT
)&gniklaw)*(& ,llaw eht no reeb fo selttob )*(&(&7D&1

For readability, some of my two-params have a newline in one of their bound words that doesn't affect the value. Newlines and whitespace can always be interspersed in nonprinting words, though using spaces for character padding to make index counting easier is discouraged. Note the small [h] hidden in the author's code that is in direct violation of the discouragement expressed in the previous sentence.

Deadfish interpreter

Prompts the user for input of a one-line idso Deadfish program. Note: this one doesn't seem to like outputting "1".

&)(walking&(3&D1&)&)*( &)*(2&)+/(

Because this is the PTS wiki page, the author of this program will provide an explanation for it, with the convention that RTL code is shown with the wrong parenthesis types for readability.

Program execution hits the - at the start to read RTL from the very end. The relevant part of the program now is

&&&)((succeed&%&()))+[ et cetera ]

. % is not a command and so starts word-reading, ended by &. The first four three-params make it so that any word evaluating to one of idso will point to their capitalised variant, with the unfortunate side-effect that this interpreter accepts case-insensitive Deadfish, but this step is important because "ditto" cannot do anything useful if the words it compares have zero value (like lowercase letters). The next three-param establishes "p" as a pointer of sorts, keeping track of which Deadfish instruction is next to be executed. The last three-param initialises the newline to act as this program's accumulator "variable", that will keep track of the Deadfish program's accumulator. The H will mark the end of the Deadfish program later.

We're left with ((succeed&%&()))+. There's a one-param that will push the value of (succeed&%&()) to the stack; this three-param looks through the entire program for the first % to replace with user input. This just so happens to be the % from the very start, so if the user inputs "diissiso" the snippet looks now like


which acts to store the Deadfish code safely at the very end of the main program (remember that this snippet is backward). (succeed&%&()) evaluates to "%" which is pushed to the stack, + pops it and sees its value as zero, sending the program back to the end (/start) -.

Program execution is sent back to LTR, and the code from indices "3" to "D1" is conveniently skipped over by | <- these -> |. Note that this skipped code is in fact quite similar to the base-conversion-of-the-top-of-stack function showcased earlier on this page. The rest of the PTS program is quite straightforward, if the reader may first accept that each "check" pushes its value to the stack to be peeked by / and this value is immediately discarded to keep the stack clean:

  • Check if the accumulator's number matches the number equal in value to (ameliorate&FF&1&) (256) -- if so, set the accumulator back to null.
  • Check if the accumulator's number is (-1) by testing the greater-than-zero-ness of one-plus-the-accumulator. After these first two tests the top two extraneous stack values are discarded.
  • Decrement the number evaluated to by "p". The first time, this makes it point to the last (index zero) character in the PTS program, the first character in the Deadfish program. Each time after, it points to the next character in the Deadfish program.
  • Check if the character pointed to by "p" matches "i" -- if so, increment the accumulator and jump back to index "2", which is the first | which will skip past the convert-to-base-A function and restart from the beginning of this list.
  • Repeat the above bullet for Deadfish "d" and decrementing.
  • Repeat the above bullet for Deadfish "s" and squaring.
  • Repeat the above bullet for Deadfish "o", but push to the stack the current number of the accumulator, "walking" run the convert-to-base-A function, pop and output the new top of the stack, and also output a space before jumping back.
  • If the character pointed to by "p" happens to be a "H", this means either the Deadfish code is depleted or contains a capital H for some reason, so the PTS program ends.
  • If none of those checks succeeded then we may as well jump back to the start, because why not. The stack is cleared and the program jumps back to "2".

Note that although the base-convert algorithm redefines newline for use in its evaluation, this is limited in scope to only when it is called with "walking" and does not affect the value of the main program's accumulator.

This program also demonstrates the three ways of storing information in PTS:

  1. The stack: most reliable, but can be unwieldy at times.
  2. Three-param pseudo-variable-assignment: can actually be the best (variables are powerful, after all) but because of PTS's quirky treatment of numberical words should be used carefully.
  3. Modifying the source with "succeed" and reading it back with two-params: be very careful when doing this, but it is the only way for a PTS program to break a word apart and understand it in any meaningful way beyond the simple PTS builtins.

Computational class

Parse this sic is Turing-complete, by virtue of there being an almost-Underload interpreter written in it. If the Underload commands ~:!*()^aS are substituted with WDIGPCRAS, the following PTS program takes this semi-Underload code as input.


Underload is Turing-complete, so the trivial WDIGPCRAS derivative is as well. For demonstrative purposes, this is a PTS program that takes an Underload program as input and converts it into something the above program can read.


Also for demonstrative purposes, the following PTS program takes a WDIGPCRAS program as input and outputs the equivalent Underload program.


Info to come

This wiki page is awaiting:

  • Summary of stack manipulation
  • Summary of flow control
  • In-depth discussion of the commands
  • Better organisation
  • Probably some more category links
  • Links