The Slope Interpreter

The Slope interpreter is implemented in Go. There is also ongoing work to create a V port. In the meantime there is one main interpreter. It is available here, which also contains build instructions. However, you can visit the slope quick start for a brief rundown of building the interpreter and some basic slope programming.

The scope of this page is running the interpreter itself: how it works, what you might need to know, what your options are, etc. As such, it will be assumed that you have followed either the quick start or the repository file and now have the Slope interpreter on your system, preferably on your $PATH.


The default mode that the interpreter will run in if you pass it no arguments is the repl. To run Slope in this fashion just run the interpreter with no arguments: slope.

You will be presented with a brief header and cursor allowing you to type input. Anything you type will be interpreted as Slope code and the evaluated result will be printed to the screen after the characters =>, in addition to any output your code would produce.

The input line at the REPL allows for line editing via emacs/readline style key chords, such as Ctrl+A to go to the beginning of the line. A full list of key bindings is available.

If you press the TAB after typing the beginning of a word the REPL will attempt to complete the given word if it is able. It does this by looking at the available procedures (both built in and in modules). If pressing TAB completes a word, but not to the word you wanted, try pressing TAB again and you may get another result. The REPL will cycle through the completion list as your continually press the TAB key (going in a circle through the list).

Persistent command history is also available by pressing UP or DOWN. Any time you press enter the command you entered gets added to a history file. By pressing UP the command entry line will be filled with an editable version of the last command you had entered. You can navigate far back into history if you desire and move closer to the current, blank, entry line by pressing DOWN. This history persists between REPL sessions.

All features of the Slope language work at the REPL. Using the usage procedure is particularly useful at the REPL, as it lets you search for and find information about the procedures available to you at any given moment.


The more common way to run Slope programs is by executing a file. Shebang's work fine, so feel free to make your files executable and call the interpreter via a shebang. Otherwise, you can run the itnerpreter with a path to your slope file (traditionally ending with the file suffix .slo): slope ./my-file.slo. In either case, shebang or file path, the interpreter will lex, parse, and evaluate your file. It will then exit.


The last way to execute code is via the -run option. This option allows you to run a "one-liner". Following the option name, -run, you can put a quoted string of Slope code. It will be evaluated and then the interpreter will exit. For example, you could run the following simple program at your command prompt:

slope -run '(display "Hello, world\n")'


The Slope interpreter allows for files in a specific directory to be automatically loaded. For this to occur slope should be invoked with the -L flag. This works running as a REPL, with files, or with -run. When that flag is passed the interpreter will do its normal setup routine then preload all files in the preload folder then go on to executing your REPL session, file, or -run script.

The directory will be searched for and the first valid folder it finds will be used. The list of search paths is as follows:

  2. $XDG_DATA_HOME/slope/preload/
  3. ~/.local/share/slope/preload/

Unlike modules, arbitrary code execution can occur with preloads (not just define expressions). The rationalle is that you, the user, have put this code there. As such it is considered safe and in your control. Preloads are a really easy way to make procedures and variables outside of the standard library, but that you regularly use, available to you without having to manually load them.

Module Considerations

The interpreter will search for modules at a certain location. That location is determined by using whichever of the following is found to exist first (checking in the given order):

  2. $XDG_DATA_HOME/slope/modules
  3. ~/.local/share/slope/modules
  4. /usr/local/lib/slope/modules

Note that the fourth item, above, is the global (system-wide) module directory. A local module will always be used before a global module.

Other than knowing that the interpreter will search the above paths, more information about modules are not in scope for this document. For the full language details regarding modules see the module section of the slope language documentation.