> For the complete documentation index, see [llms.txt](https://docs.aeternity.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aeternity.com/aeternity-developer-tools/markdown/aerepl.md).
# æREPL
The æREPL (æternity Read-Eval-Print Loop) is an interactive shell for the Sophia programming language that enables developers to experiment with and test Sophia code in real-time. This powerful development tool allows users to evaluate Sophia expressions, define functions and types, work with contract code, and maintain state - all without needing to connect to a remote network or use Docker containers. The interface is inspired by GHCi (Haskell's interactive environment) and provides convenient features like type checking, file loading, and state management.
The REPL maintains its own internal state and supports multiple output formats, including Sophia-compatible syntax, FATE runtime representation, and JSON encoding. It can be used either through its command-line interface or as a library through its generic server interface, making it versatile for different development workflows. The tool serves as an essential resource for developers working with Sophia, allowing them to rapidly prototype code, test contract behavior, and better understand the language's features in an isolated environment.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.aeternity.com/aeternity-developer-tools/markdown/aerepl.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
