This is an introduction to the imaginary
interpreter built into
The reason I am building REPLs and emacs modes based around imaginary interpreters (which are not at all deterministic or logically sound) is that I believe they will be very powerful and useful in the future.
It’s important to develop a language-agnostic harness for working with arbitrarily many imagined languages.
Solving the problems of utilising current LMs will make it easier down the line to utilise more advanced ones.
The interpreter prompt
- An interpreter prompt is selected depending on if a specialised prompt exists for the chosen language.
- The generic
iiprompts is comprised of:
- kickstarter: A subprompt declaring that the following are examples of the specified language.
- Consecutive Input/Output pairs.
iiprompts are comprised of:
- kickstarter: A subprompt which is typically a banner.
- postpostprocessor: A script that takes the interpreter history and generates a new “user prompt”.
- The generic
- An interpreter prompt accepts as a first argument the history of the interaction with the interpreter. This way, the interpreter has an imaginary state as you work with it.
- Accepts a language as an argument
- Docker bash-host interop:
iicommunicates with arbitrary LMs via the bash (docker-host) interop of
rlwrapis used to keep a history of the inputs specific to each interpreter.
REPLthat keeps builds a transcript and passes that as input to the interpreter prompt.
ii (Imaginary Interpreter for bash)
The imaginary interpreter may be implemented
for different languages, by using
Pen.el’s prompt functions via the bash-docker interop.
An imaginary python interpreter
When a supported language such as Python is chosen, a prompt specifically designed for it may be used.
Using the bash interop
-p ensures that the entire prompt along
with the generated output is returned.
-u ensures that the cache is updated and a
new generation is returned.
Withholding the first argument
By supplying an empty string as the first
argument, the history is not passed to the
interpreter prompt. Instead, the prompt
function will use the
as it has been supplied as the default value
for the first variable.
Python 3.8.5 (default, Jan 27 2021, 15:41:15) Type 'copyright', 'credits' or 'license' for more information IPython 7.21.0 -- An enhanced Interactive Python. Type '?' for help. In : 5 + 5 Out: 10
In : 5 + 5 Out: 10
On the right, an imaginary interpreter.
An imaginary interpreter with any language
Demo of ruby using the generic interpreter
This will use a generic prompt which does any language, but the name of the language has been specified as Rubylang.
ii, if a specialised interpreter
prompt for a given language can be found then
that will be used.
However, since no interpreter can be found for ‘Rubylang’, the generic interpreter is used.
However, the generic interpreter can still imagine the ‘Ruby’ language to a degree, but is far less accurate.
The beauty of this, of course, is that we don’t need to prime the interpreter with a banner or terminal history, and we don’t need to know what the prompt for Ruby looks like.
And a demo of a more catered imaginary interpreter
These are used as post-processors in the prompt and in
String utilities (
If this article appears incomplete, it may be intentional. Try prompting for a continuation.