SELECT. is an esoteric programming language designed in 2012 by Esolang wiki user "Por gammer" (not me!). It is ostensibly a Brainfuck derivative, but in practice it is very different to program. The specification is given on the Esolang wiki, as well as some rules for how to derive the major mathematical operations, a short example, and a proof of Turing-completeness. On this page, you will find a download of a functioning implementation of the language (in the form of an interpreter), documentation for said implementation, and a program for generating SELECT. code from a higher-level language, as well as a long list of complete and functioning example programs.

Download select.py here.

This interpreter depends on the mpmath library (use "easy_install mpmath") and the Python/TK graphics library (see link for installation details). It is written for and tested on Python 2.6. Please let me know if you've proven it functional on or patched it for another version, and I'll include it here.

python select [-v] <filename> [p=<precision>] [v=<defaultvalue>]

Options:

• -v specifies verbose output. Among other things, it echoes the value of any pixel drawn via the PRINT. command to the command line.
• p=<precision> lets you specify the number of decimal digits of precision. The interpreter does not support arbitrary precision, because mpmath does not. Default value is 15.
• v=<defaultvalue> lets you specify which value unmodified tape cells contain. By default, it uses a random number between 1 and 1.0000001. Be aware that small increases in this value can quickly overflow your precision and result in strange and perplexing behavior.

The most useful feature provided by this interpreter which is not specified in the language spec is the text output granted by the -v option. In addition to echoing PRINT.ed values to the shell (one line per PRINT.), it prints =======Clearing Display======= whenever CLEAR. is issued, allowing you to visually separate outputted numbers.

This interpreter also accepts several commands that the langage does not include. Currently, these are:

• COLOR. Set the current color according to the value of the current cell like so: For x+yi, red=x/256, green=x%256, blue=y%256.
• HALT. Stop interpretation immediately (without closing the output canvas window).

• The first line of a valid program must contain the string (x,y,z) where x, y, and z are positive integers. The interpreter will create a Tk window x*z by y*z plus window decoration, if any. Yes, it will try to make a window bigger than your screen if you tell it to!
• The interpreter will allow you to raise zero to a negative power, giving infinity as a result, rather than giving an error. This is an intentional design decision.
• The interpreter WILL give an error and quit if you try to take a log base one.
• Although I made it as fast as the libraries on which it depends allow, there's just no getting around the fact that doing hundreds of operations on 100-digit complex numbers is slow. Be patient.

Go directly to generator function listing.

SELECT. is a very verbose language, much much more so than Brainfuck (to which the author demeaningly compares it). For example, here is an (original-value-preserving) addition in BF:

[>>+>+<<-]>>>[<<<+>>>-]<<[>+>+<<-]>>[<<+>>-]<

And here is the same thing in SELECT.:

      ADD:
      RIGHT. RIGHT. EXP. LEFT. LEFT. SELECT.
      RIGHT. RIGHT. RIGHT. EXP. LEFT. LEFT. SELECT.
      RIGHT. 
         
         (multiply)
         RIGHT. RIGHT. EXP. LEFT. LEFT. SELECT.
         RIGHT. RIGHT. EXP. LEFT. SELECT.
         RIGHT. LOG. RIGHT. SELECT.
         LEFT. 
      LOG. RIGHT. SELECT.
       
      END ADD

The difference in number of commands is not that great. BF uses 45, SELECT. uses 33, so SELECT. actually comes out ahead. For more complex computations, SELECT. is even better. However, the length of a command in BF is one character, while in SELECT., the average length of a command is SIX characters! Obviously, it could become quite tedious to write SELECT. programs by hand, and this isn't even the best reason to do automatic code generation! The best reason is that writing it by hand isn't very fun, but let's instead discuss a peculiarity of the language that makes it especially hard to hand-implement anything.

FACT: The amount of information on the SELECT. tape must always increase. The tape starts out with nothing but the value k on it, everywhere, but in order to create a different value (other than one), you need two different cells initialized with the same number. Sometimes you even need more than that!

The addition program above changes four cells into new values, and this is minimal (as opposed to BF's two clobbered cells). If you take a pair of identical cells and change one of them into a useful number, you usually cannot change it back using only that pair again. You need another cell with just the right value in it. So another cell gets clobbered. In practice, this means successively changing the k's on the tape into some other value. There is no equivalent to BF's clear routine [-].

The implications are obvious: there is no way, in practice to maintain a modifiable data structure (other than a boolean array) at a fixed position on the tape. Almost all interesting data must be treated as immutable. (One can maintain a fixed boolean array by using i and -i as the alphabet. The CONJ. instruction then serves as a bit flip. These make good choices for booleans because you can enter and maintain a loop from an i but nothing from a -i.) As a result, it becomes extremely helpful to have a collection of algorithms worked out which:

1. Minimize the number of cells used in calculating a given result
2. Can place a desired result at a desired or known position
3. And can guarantee a specific number of tape cells will be clobbered by the calculation, no matter which code branch is taken
4. All within a system which can automatically track the location of previously derived values and deliver them to the location on the tape where they are required.

Having such a library in place removes some of the SELECT. programmer's mental load. The code generator described and linked below does all of the above while outputting well-commented usefully-indented code which could be manually edited and debugged if desired.

Download selectcodegen.py here.

Python 2.6. w/ standard libraries.

python selectcodegen.py <filename>

The file from which code is generated should contain the exact string: ######GENERATION CODE######
That's six (6) # symbols on each side. This string should appear on its own line followed by a valid python program containing a series of function calls to code generators. The first call must be to init() and the last call must be to writetofile(). (Calling init() or writetofile() multiple times in the same file with different target filenames is fine, but every writetofile() should be followed immediately by another init() in order to generate functional code.)

Note that everything from the first occurrence of ######GENERATION CODE###### to the second occurrence of the same (or the end of the file if it is only used once) will be executed and then appended to the generated code file, which thus automatically places the SELECT. code and the code used to generate it in the same file. Thus, each .sel file so created is a valid input to both select.py (as a SELECT. program) and selectcodegen.py (as code to generate itself).

Unless otherwise stated in a function's documentation, the code generated by this generator is "right-growing," meaning that no function will modify cells to the left of the location of the tape pointer at codepoint where the function begins generating. In addition, no function will modify the cells which contain its arguments. Furthermore, the code generated by a given function will leave the tape pointer no further left than the rightmost cell that code modifies. In the case that the function in question is intended to generate code which computes a function or specific value (which is most of them), the final result of that computation will be under the tape pointer at the codepoint corresponding to the end of the code generated by that function.

To summarize: Unless otherwise stated, no function generates code which modifies the function's arguments, the tape to the left of where it started generating, or the tape to the right of where it finished generating. (startleftgr() and endleftgr() can be wrapped around a code section to make it left-growing instead.)

The "Tape Requirements/Results" column uses the following notation: k means a cell still in its original state, so k*15 is a sequence of 15 consecutive identical cells. ? is a cell containing any value. x and y are arguments. () is placed around the value which is located at the tape pointer. ' after a value means conjugation. ... means the list continues in different ways subject to arguments.

Using the above-described code generator, I have written a number of example programs to show test the features of both the interpreter and code generator. Many of them do not include the code that generated them. Of particular interest are "circle.sel" which demonstrates bounded loops by drawing a circle, and "fulltest.sel" which tests all of the other functions in the code generator library, including every elementary function. These examples may also include works-in-progress or non-working code. Try them and find out!

Example Repository

Explore the example repository.