blob: da707d2c8516f12190d268f99ec7cfbdc45f9596 (
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
|
# Chapter 0: Genesis
This chapter explains the core value representation of Zisp, and goes
through the processes of parsing, decoding, running, and optionally,
compiling code.
0. [Value](0-value.html)
Zisp uses a uniform 64-bit representation for all values, densely
packed into signaling or non-canonical NaN values.
1. [Parse](1-parse.html) (see also [grammar](grammar/))
The parser receives a stream of bytes and transforms them into a
minimal set of data types with very little processing.
2. [Decode](2-decode.html)
The decoder runs configurable and extensible pre-processing steps
over data received from the parser, enriching it with more complex
value types, and handling primitive source code transforms.
3. [Execute](3-execute.html)
Code is executed within a mutable module context, on which it can
have side effects such as creating new definitions or establishing
links to other modules.
4. [Compile](4-compile.html)
Procedures from within the compiler module can be used to demand
the compilation of other modules, with various options, yielding
static or dynamic object files. These may be loaded immediately,
replacing the previously uncompiled module code in memory.
## Appendices
+ Appendix A: [Memory](A-memory.html)
Zisp foregoes use of a platform-provided heap allocator as much as
possible, in favor of an efficient heap allocator specialized for
the implementation details of Zisp.
|
