1. nejucomo
  2. eonhs


Clone wiki

eonhs / Home

E on Haskell

The eonhs project (pronounced like "E on H.S.") is an interpreter for the E language. The first major implementation oasis is a Kernel-E compatible interpreter without any networking support.

The project is unrelated to E-on-Haskell, except that we may cherry pick ideas and code.

See also a list of other interpreters for E.


This codebase presently consists of a parser and interpreter with unit tests for a tiny subset of the grammar and semantics of Kernel-E.

Implemented Features:

  • High level eval takes a scope and source code and returns a value.
  • Basic types. The only existing methods are arithmetic number methods such as .add(other).
  • Pattern binding with def or =~
    • Patterns can include constant ⟪ identifier ⟫, variable ⟪ 'var' identifier ⟫, and slot ⟪ '&' identifier ⟫ bindings.
  • Method call.
  • Slots: variable and constant slots.
  • References:
    • ⟪ '&' identifier ⟫ resolves directly to an object (which should act slot-like).
    • ⟪ identifier ⟫ is expanded in the parser to ⟪ '(' '&' identifier ')' '.' "get" '(' ')' ⟫
  • Object Definition:
    • Named and un-named objects.
    • Named to-methods.
    • match-clauses.
    • Closures.

There is some unittest coverage, but it is not thorough.

See the ChangeLog for more details in rough chronological order.


See the RoadMap for implementation path specifics, or TODO for fine-grained short-term specifics.

E Compatibility

The roadmap is first to implement a Kernel-E interpreter with internal-only eventual sends, wait-clauses, and pipelining.

See also: OpenQuestions.

This is based on the overview reference for Kernel-E. Once the project is more developed, clarifications of the language definition will be tracked in this project's issue tracker and wiki.

Once that stage is reached, a Pluribus library for Haskell would be a separate project (and not dependent on the E interpreter).

Finally, with those two major components, a full E implementation is possible.

Language Variations

I am also interested in exploring alternative design spaces for the language, but my current priority is to first make a compatible Kernel-E interpreter to have a better position with which to judge alternatives.


The implementation is written in Haskell using GHC and cabal packaging and dependency management.

Implementation Notes:

Parked Design Ideas