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
|
# Using libgccjit?
The installed size of libgccjit varies from 18 MB (armhf) to 53 MB
(riscv64), with 37 MB for amd64.
That's quite large. I wonder how much it could be stripped down if
you linked to it statically and didn't use all parts of it?
If I did use it to implement Zisp, I suppose I could offer the choice
of generating binaries that don't actually link to the full Zisp
runtime.
So, the final situation could be as follows, for example:
- The "meat" of Zisp would be a .so whose size is in the order of tens
of MBs.
- A tiny wrapper executable linked to this .so would be the entry
point to both an AOT compiler and a REPL for Zisp.
- Fully dynamic "lisp machine" applications (in the spirit of Emacs)
that are both written in Zisp and support dynamic Zisp evaluation
would have this .so as a runtime dependency, or need pretty much all
of it to be compiled in.
- However, the Zisp AOT compiler could also output binaries (dynlibs
and executables) that don't actually have zisp.so as a runtime
dependency.
What if someone just wants to use a tiny script written in Zisp? If
you want to use a tiny script written in Perl, Python, etc. you still
need the entire thing, so maybe it'd be acceptable for such scripts to
have full Zisp package as a runtime dependency.
Alternatively, Zisp could be split into a number of dynlibs that
implement different parts of it: zisp-gc.so, zisp-parser.so,
zisp-intrpr.so, zisp-comp.so, and so on, where zisp-comp.so would
probably be the largest. There could be a "Zisp interpreter" package
that doesn't depend on that one.
Alternatively #2, there could be a ZispScript language that consists
of a strict subset of Zisp (e.g. no static typing, no eval) and an
interpreter for this language could simply be a program that happens
to be written in Zisp but doesn't depend on the full Zisp .so since it
doesn't use the native compiler. However, what if someone wants to
write a program that *includes* a Zisp interpreter...
I think a combination of the two above ideas would be best: ZispScript
would be implemented by a library written in Zisp, zispscript.so,
which can be linked to if you want to write a program that can execute
ZispScript at runtime, and also the ZispScript package would come with
a little wrapper executable that invokes zispscript.so to interpret
scripts with a #!/usr/bin/zispscript shebang or such.
|
