blob: b5681c871775894881a295ca7af9bae1657d1b48 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
# Bad Diode's Lisp
For some time I've been meaning to learn more about compilers and programming
language theory. And so I found myself again delving into a rabbit hole of
wheel-reinvention for the purpose of fun and learning.
The language, `bdl` is inspired by `Scheme`, but it doesn't aim to be compatible
with it grammatically or in terms of behaviour. Instead, the core language is
much smaller and we will grow it organically as needed. As such, it is heavily
in flux and not ready for any kind of production usage.
Currently `bdl` conforms with the grammar described below. It is a dynamically
typed language, garbage collected and supports lambdas, lexical scopes and
closures.
Up to [v0.7][v0.7] we were building a fully functional tree-walking interpreter.
A writeup for the different building blocks can be found in [a series of
articles][bdl-series] that go into great detail about the implementation and
basic concepts behind the language.
From [v0.7][v0.7] to [v0.8][v0.8], we created a second interpreter
implementation. It was built by following along the second part of the [Crafting
Interpreters][crafting-interpreters] book. This reimagining of the project uses
a single-pass compiler to generate bytecode for an custom abstract virtual
machine. This interpreter is much faster than the tree-walking version and still
supports closures, but it has no garbage collector and leaks memory. It was
a good learning exercise but the VM is too abstracted for my taste and I don't
wish to maintain a half-baked implementation.
Current development focuses on building from the fundamentals of previous
iterations to create a native compiler that could be used with multiple backends
for code generation (e.g. `LLVM`, `x86_64`/`aarch64` assembly, `uxn` bytecode,
etc.). One of the goals of this part is to have trivial `C` interop when
compiled natively, meaning it should be possible to call `bdl` code from `C` and
`C` functions from `bdl` (though some wrappers may be necessary).
[bdl-series]: https://git.badd10de.dev/bdl/tag/?h=v0.7
[v0.7]: https://git.badd10de.dev/bdl/tag/?h=v0.7
[v0.8]: https://git.badd10de.dev/bdl/tag/?h=v0.8
# Grammar
```
program : <statement>* EOF
<statement> : <definition> | <expression>
<definition> : ( def <symbol> <expression> )
| ( fun <symbol> ( <symbol>* ) <body> )
<expression> : <constant>
| ( lambda ( <symbol>* ) <body> )
| ( if <expression> <expression> <expression> )
| ( if <expression> <expression> )
| ( set! <symbol> <expression> )
| ( <expression> <expression>* )
<body> : <statement>*
<constant> : <bool> | <number> | <string> | <symbol>
<bool> : true | false
<number> : -?<digit>+
<string> : " <character>+ "
<digit> : 0 | 1 | ... | 9
<symbol> : <character>+
```
# Resources
- [Structure and Interpretation of Computer Programs][sicp]
- [Crafting Interpreters][crafting-interpreters]
- [Building a Scheme from scratch][scheme-from-scratch]
- [Compiling a Lisp][compiling-a-lisp]
- [An Incremental Approach to Compiler Construction][ghuloum11]
- [Make-A-Lisp Guide][mal]
- [An Introduction to Scheme and its Implementation][intro-to-scheme-and-imp]
- [Scheme to C][scheme-to-c]
[sicp]: https://mitpress.mit.edu/sites/default/files/sicp/index.html
[crafting-interpreters]: https://craftinginterpreters.com/
[scheme-from-scratch]: http://peter.michaux.ca/articles/scheme-from-scratch-introduction
[compiling-a-lisp]: https://bernsteinbear.com/blog/compiling-a-lisp-0/
[ghuloum11]: http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf
[mal]: https://github.com/kanaka/mal/blob/master/process/guide.md
[intro-to-scheme-and-imp]: https://www.cs.utexas.edu/ftp/garbage/cs345/schintro-v14/schintro_toc.html#SEC271
[scheme-to-c]: https://github.com/akeep/scheme-to-c
|
