rl'

rlp (ruelang') will be a lazily-evaluated purely-functional language heavily imitating Haskell.

Architecture

Build Info

• rlp is built using Cabal
• rlp's documentation is built using Sphinx

$ cabal build       # Build the rlpc compiler
$ cabal install     # Install rlpc to $PATH
$ cabal haddock     # Build the API docs w/ Haddock
$ make -C doc html  # Build the primary docs w/ Sphinx

# run the test suite
$ cabal test --test-show-details=direct

Use

TLDR

# Compile and evaluate examples/rlp/QuickSort.rl
$ rlpc examples/QuickSort.rl
# Compile and evaluate t.cr, with evaluation info dumped to t.log
$ rlpc -ddump-eval -l t.log t.cr
# Compile and evaluate t.rl, dumping the desugared Core
$ rlpc -ddump-desugared t.rl
# Compile and evaluate t.rl with all compiler messages enabled
$ rlpc -dALL t.rl

Options

Usage: rlpc [-l|--log FILE] [-d DEBUG FLAG] [-f COMPILATION FLAG] 
            [-e|--evaluator gm|ti] [--heap-trigger INT] [-x|--language rlp|core]
            FILES...

Available debug flags include:

• -ddump-desugared: dump Core generated from rl'
• -ddump-parsed-core: dump raw Core AST
• -ddump-parsed: dump raw rl' AST
• -ddump-eval: dump evaluation logs
• -dALL: disable debug message filtering. enables all debug messages

Potential Features

Listed in order of importance.

• ADTs
• First-class functions
• Higher-kinded types
• Typeclasses
• Parametric polymorphism
• Hindley-Milner type inference
• Newtype coercion
• Parallelism

Milestones

(This list is incomplete.)

Items are marked off not as they are 100% implemented, but rather once I consider them stable enough that completion is soley a matter of getting around to it -- no tough design decisions, theorising, etc. remain. For example, as of writing this, the rl' frontend parser is not fully featured, yet it is marked off on this list; finishing it would require cranking out the remaining grammatical rules, and no work on complex tasks like layout parsing remains.

• Backend
  • Core language
    • AST
  • Low-level execution model (TI)
    • Arithmetic
    • Conditionals
    • Structured data
    • Garbage collection
  • Low-level execution model (GM)
    • Arithmetic
    • Conditionals
    • Structured data
    • Garbage Collection
  • Emitter
    • Code-gen (target yet to be decided)
  • Core linter (Type-checker)
  • Core2Core pass (optimisations and misc. preprocessing)
    • GM prep
      • Non-strict case-floating
    • Let-floating
    • TCO
    • DCE
• Frontend
  • High-level language
    • AST
    • Lexer
    • Parser
  • Translation to the core language
    • Constraint solver
    • do-notation
  • CLI
• Documentation
  • State transition rules
  • How does the evaluation model work?
  • The Hindley-Milner type system
  • CLI usage
  • Tail call optimisation
  • Parsing rlp
  • Trees That Grow
• Tests
  • Generic example programs
  • Parser

December Release Plan

• Tests
  • Core lexer
  • Core parser
  • Evaluation model
• Benchmarks
• Stable Core lexer
• Stable Core parser
• Stable evaluation model
  • Garbage Collection
• Stable documentation for the evaluation model

February Release Plan

• Beta rl' to Core
• UX improvements
  • Actual compiler errors -- no more unexceptional error calls
  • Better CLI dump flags
  • Annotate the AST with token positions for errors (NOTE: As of Feb. 1, this has been done, but the locational info is not yet used in error messages)
• Compiler architecture diagram
• More examples

March Release Plan

• Tests
  • rl' parser
  • rl' lexer
• Ditch TTG in favour of a simpler AST focusing on extendability via Fix, Free, Cofree, etc. rather than boilerplate-heavy type families

Indefinite Release Plan

This list is more concrete than the milestones, but likely further in the future than the other release plans.

• Overall codebase cleaning
  • Complete all TODOs
  • Replace mtl with effectful
• rl' type-checker
• Stable rl' to Core
• Core polish
  • Better, stable parser
  • Better, stable lexer
  • Less hacky handling of named data
  • Less hacky pragmas
• Choose a target. LLVM, JS, C, and WASM are currently top contenders
• https://proglangdesign.net/wiki/challenges