Vision 👁

[MonoidMusician]

A way to inspect, interact with, edit, and dialogue with the compiler on Dhall expressions, in the browser or another context. The first step is displaying the AST in some form (done), then modifying the AST (in progress), then feedback (typechecking errors, and unification results) and organizing the information (selecting certain expressions, viewing different files, etc.). Operations like typechecking and normalization should be transparent and inspectable – run on any expression, at any time, with the errors containing inspectable expressions too, and helpful feedback, with links to more information. Eventually the goal is to have a full-featured editor, handling files (importing/reading/saving), history (ooh the possibilities with history are endless), uhm and whatever other features are needed I guess. Git integration, GitHub? Plugins? Dhall-scripted plugins? Rich text comments and social comments?

Dhall/API Features

It should have a standards-compliant, feature-rich API, on par with the Haskell implementation, and more (😉). Should operate both on the command-line and in a web browser (or Electron), with an emphasis a great UX through HTML. It should be able to interoperate with as many sources as the platform allows – local files/folders 📁, remote imports 🕸, user input ⌨️, etc., both in Dhall syntax 🔡 and binary and JSON CBOR 🔢.

Holey ASTs

Incomplete ASTs should be able to be typechecked and normalized as much as possible. Typechecking will run a unification algorithm on the holes 🕳, to either fill them in directly (if they are a type whose value can be determined), or fill in their type from usages (that is, the feedback will be like “This is a hole with type Natural, you may insert these kinds of expressions into it: [list]”). It will ensure that the unifications are consistent before succeeding.

AST holes will be internally indexed (e.g. by a natural number), but this should be (relatively) invisible to the user – the necessary tying together of holes should be visual and interactive, including highlighting the origin when it its reference is hovered over, automatic substitution, info/hint popups for the gathered information inferred for the holes, &c. Typechecking will use holes and derivations from holes (e.g. its type, and maybe its fields, etc.), so information about unifications down the line can be traced back to the original (without having to create and chase fresh numeric pointers).

Pretty, Functional User Interface

The UI should look nice and make actions accessible/discoverable. Information should be accessible from wherever it makes sense – usually this means both gathered in a list and accessible from the AST nodes directly (e.g. for context information as well as typechecking errors). Navigation should be clear and visual 👓. Other interactions should be easy and transparent 💠. History should be maintained where it makes sense 📜. Confirmation required for permanent actions 🆗. &c.

Navigation

There will be lots of navigation actions possible. Navigation should include clicking on the AST directly, using shortcuts (hopefully mnemonic!), and iconic ⚜️ buttons that indicate the type of movement happening ⏫. Perhaps there will be a navigation trigger key which opens a menu of the possible actions ⬅️↕️➡️, and keys or mouse action will further modify or complete it.

Icons for actions

Icons will be used for the majority of interaction. For discrete actions, they will indicate their action; for states (like "collapsed"), they will indicate the current state but preview the new state on hover (e.g. a non-collapsed node would show an open eye 👁, and then a closed eye 😴 on hover; and vice-versa for a collapsed node 😴👁), maybe with a fancy transition when the mouse is activated on it 🐭 😼. Maybe there will be additional interactions (right click, double click, long click), but keep it simple now and anyhow. Maybe there will be an interaction monad that components run in that handles focus and such (unless the browser can be used to manage focus even for expressions, which aren't really focusable ... I guess tabindex?). Maybe there will be buttons that require dragging or expand into a context menu type thingy, but radial 🎪.

Visual organization (panes)

Need to figure out a way to organize things into panes 🔢 (especially if recursion is allowed with expressions in typechecking errors ... hmm ... maybe it will highlight the part of the original expression and point towards the type or normalization obtained from it ... need to track provenance in expressions). There will be potentially very many panes happening at once, with different files, and different expressions from typechecking and normalization. In fact, each expression will have the ability to show its type and its normalization, or errors if it doesn't typecheck.