aboutsummaryrefslogtreecommitdiffstats
path: root/README.md
diff options
context:
space:
mode:
authorRose Hogenson <rhogenson@posteo.net>2022-04-22 20:44:29 -0700
committerRose Hogenson <rhogenson@posteo.net>2022-04-22 20:44:29 -0700
commit645bb59af4ec249b86521643e19bb0f5d353a1f9 (patch)
tree205f64a137670e8cd554cb08e6bd5387d590b4e8 /README.md
parent0f2e3dc954c13681495399ff261d4dc34c1f2aa0 (diff)
downloadchromatopelma-645bb59af4ec249b86521643e19bb0f5d353a1f9.tar.zst
Update the README for Github markdown.
Diffstat (limited to 'README.md')
-rw-r--r--README.md20
1 files changed, 8 insertions, 12 deletions
diff --git a/README.md b/README.md
index e82a611..90631ba 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,6 @@
-% Cute scheme design overview
-% Rose Hogenson; Cute scheme development team
-% April 22, 2022
+# Cute Scheme
-# Background
+## Background
Scheme is a simple language, and has a number of open specifications.
These two qualities make it a popular target for hobby compilers. The
@@ -15,13 +13,13 @@ runtime. For a program that uses eval, it will by necessity need to have
the full compiler bundled as part of the runtime. My goal is to write a
self-hosting scheme compiler targeting a minimal bytecode.
-# Objective
+## Objective
Cute scheme is a partial r7rs implementation with a focus on ease of
implementation and a reusable library. The frontend is written in r7rs
Scheme, and compiles to a minimal bytecode.
-# Detailed design
+## Detailed design
The cute scheme compiler (like most compilers) consists of a number of
phases that gradually transform a program from scheme code through
@@ -29,7 +27,7 @@ numerous intermediate representations. The csc compiler has 2 such
intermediate representations, not counting bytecode itself. These two
languages are called IR1 and IR2.
-## IR1
+### IR1
IR1 can be thought of as scheme code with all the macros expanded. An
IR1 program or library is a tree structure composed of one of a few
@@ -172,7 +170,7 @@ The builtin forms of IR1 are described below.
And that's all the IR1 types. The design of the macro expander is
sketched briefly below.
-## Macro expansion
+### Macro expansion
Macro expansion essentially consists of a compiler from scheme code to
IR1. As the compiler walks the input scheme expression, it holds an
@@ -190,8 +188,6 @@ expression doesn't look like a macro invocation, it could be a procedure
call, a constant, or a variable reference. Either way it will get
compiled to the corresponding IR1 construct.
-### Syntax-rules
-
The `syntax-rules` syntax transformer takes as input a `syntax-rules`
form, and the output is a syntax transformer. Recall that a syntax
transformer accepts a scheme expression and emits IR1. In this way,
@@ -306,7 +302,7 @@ variable that was in-scope when the macro was defined. It's possible
that this behavior isn't quite right for macros that generate other
macros, but the above paragraph is breaking my brain.
-## IR2
+### IR2
IR2 is what is known as "continuation passing style". When I learned
about continuation passing style in school, we learned that it's
@@ -343,7 +339,7 @@ The syntax types for IR2 are given below.
(continuation call/cc-continuation))
```
-## IR3
+### IR3
I've only just started thinking about IR3, but it's the closure
conversion step for IR2. Afterwards, we will transform all