serene/dev.org

Serene Development

• Serene's Development Resources
• Resources
  • Parser
  • Lisp
    • Quasiquotation
  • Rust
  • LLVM
  • Data structures
  • Other languages
  • Cranelift
  • Memory management
  • Concurrency
  • Garbage collection
  • JIT
  • Compiler
    • Branch instructions
    • Execution Instrumentation
  • Lang
    • Scheme
  • Utilities
    • Emacs mode
• Considerations
  • Hashmaps
    • DOS attack
• TODOs
  • Bootstrap
    • Language Spec
    • A proper List implementation
    • Vector implementation
    • Hashmap implementation
    • Meta data support
    • Docstring support
    • FFI interface
    • Load path and namespace loading
    • nREPL
    • Emacs mode
    • Number implementation
    • String implementation
    • Enum implementation
    • Protocol
    • Struct implementation
    • Error handling
    • Multi arity functions
    • QuasiQuotation
    • Linter
    • Document generator
    • Spec like functionality
    • Laziness implementation
    • Investigate the Semantic Error tree and tracking
    • Standard libraries
      • IO library
      • Test library

Serene's Development Resources

This document is dedicated to the process of developing Serene. It contains a collection of resources from the early days of the project and resources that need to be studied and A list of tasks and features that needs to be done. This document is written using org-mode. You can use this cheatsheet as a quick guide for the format but you will get more out of it using org-mode.

Resources

For a generic list of resources on compiler design take a look at the list of resource to create a programming language and this list

Parser

First of all you need to read All you need to know about Parser algorithms. Then here is the list or parsers that we have considered

• Rust parser combinator framework
• LR(1) parser generator for Rust
• A parser combinator library for Rust
• Parsing Expression Grammar (PEG) parser generator for Rust
• General purpose parser

Lisp

• Make a Lisp

Quasiquotation

• Backquote in CL
• Backquote spec in Common Lisp the Language, 2nd Edition
• Backquote and pretty printing

Rust

• The Rust book (in EPUB format)

LLVM

• Brief overview of LLVM
• A bit in depth details on LLVM
• Official LLVM tutorial C++
• Interactive C++ with Cling
• My First LLVM Compiler
• A Complete Guide to LLVM for Programming Language Creators

Data structures

• Pure functional datastructures papaer
• Dynamic typing: syntax and proof theory
• Representing Type Information in Dynamically Typed Languages
• An empirical study on the impact of static typing on software maintainability

Other languages

• Julia: A Fresh Approach toNumerical Computing

Cranelift

• Source tree

Memory management

• Visualizing memory management in Golang
• TCMalloc : Thread-Caching Malloc
• A visual guide to Go Memory Allocator from scratch (Golang)

Concurrency

• Scheduling In Go (Series)

Garbage collection

• GC on V8
• Perceus: Garbage Free Reference Counting with Reuse
• Boehm GC

JIT

• Machine code generator for C++

Compiler

• Stack frame layout on x86-64

Branch instructions

It would be cool to have macro to instruct the compiler about the likelyhood of a branch in a conditional. Something similar to kernel's likely and unlikely macros

Execution Instrumentation

The compiler should be able to embed some code in the program to collect data about the different execution paths or function instrumentation and other useful data the can help the compiler to optimize the program even further. For example Imagine a scenario which we compile a program with out any optimization ( in debug mode ) and using some test cases or real usage of the program in several iteration we collect data about the compiled application in a file (let's call it the ADF short for Analytic Data File), and the we can pass that ADF file to the compiler to let it compile and optimize the program by using the usual passes alonge side with some extra passes that operate on ADF

Lang

Scheme

• Chicken Scheme - Easy-to-use compiler and interpreter, with lots of libraries
• Stalin - Brutally optimizing Scheme compiler, with lots of optimization flags

Utilities

• Pointers Are Complicated

Emacs mode

• Adding A New Language to Emacs
• The Definitive Guide To Syntax Highlighting

Considerations

Hashmaps

DOS attack

• https://www.anchor.com.au/blog/2012/12/how-to-explain-hash-dos-to-your-parents-by-using-cats/
• https://en.wikipedia.org/wiki/Collision_attack

TODOs

Bootstrap

TODO Language Spec   DOCS

TODO A proper List implementation

TODO Vector implementation

TODO Hashmap implementation

TODO Meta data support

TODO Docstring support   DOCS

• For functions and macros
• For namespaces and projects
• API to interact with docstrings and helps

TODO FFI interface

TODO Load path and namespace loading

TODO nREPL

TODO Emacs mode   Misc

TODO Number implementation

TODO String implementation

TODO Enum implementation

TODO Protocol

TODO Struct implementation

TODO Error handling

TODO Multi arity functions

TODO QuasiQuotation

TODO Linter   Misc

TODO Document generator   DOCS Misc

TODO Spec like functionality

TODO Laziness implementation

TODO Investigate the Semantic Error tree and tracking

Basically we should be able to create an error tree on semantic analysis time and trace semantic errors on different layers and intensively. Is it a good idea ?

Standard libraries

TODO IO library

TODO Test library