Dial interpreter third implementation

tags : [[Dial implementation]] [[language design]]

I have now attempted to implement Dial twice, both as spins on the Make A Lisp project. For my third and hopefully final attempt, I’m going to try a different approach, using lessons taken from [[Lisp in Small Pieces]].

Dial will once again be written in [[Rust]].

Plan

Syntax

Dial’s syntax will mostly be [[Clojure]]-like S-expressions, with some exceptions. It will use Clojure’s def and fn keywords. List and vector syntax will be interchangeable, as in [[Racket]].

(let (a 1
      b 2
      c 3)
  (+ a b c))

Bindings may optionally be bracketed.

(let ((a 1)
      [b 2]
      c 3)
  (+ a b c))

Scoping rules

All named values are immutable. let bindings, function parameters, etc. cannot be mutated.

Types

Dial’s types will mostly be Clojure-like as well. We will not define cons cells, since linked lists in Rust are superfluous.

Primitives

• true and false
• Integers
• Floating point numbers
• Strings
• Lists (e.g. '(1 2 3))
  • All lists will also be iterable and take advantage of Rust’s iteration features
• Keywords (e.g. :foo)
• Symbols (quoted values, e.g. 'Apple)

Deferable

These types may come after v1, since they could be articulated with lists.

• Vectors (e.g. [1 2 3])
• Hash maps (e.g. {a 1 b 2})

Parser (read)

I have largely already figured out how the parser should work thanks to nom. The only forms I don’t support at the moment are quoted expressions and a handful of special syntax types like hash maps.

A valid program that’s outputted by read will return a quoted expression.

eval

The interpreter should be thought of as a function that, given a program, an environment, and a [[continuation]], should result in a value.

Should I implement continuations?

Pros

• Interesting language feature
• Will allow for implementation of tail call optimization

Cons

• Difficult to implement in Rust
• Possibly memory intensive if all done on the heap
• Not especially useful / can live without it