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
|
# What are the goals of Zisp?
_2025 September_
Today someone asked me to elaborate on what I mean when I say I'd
really like a systems language with a garbage collector.
Although Zisp started out with a different intention (a modern
re-invention of Scheme), I now actually want it to become that
language I'm dreaming of.
So, there's what I mean by that:
- Reasonably sized runtime that is (normally) dynamically linked,
comparable to say glibc + libgcc. (Not like Java, C#, Python,
Racket, etc. that need end-users to have a runtime installed that
takes dozens if not hundreds of MBs of disk space. Actually, dozens
may be necessary; see: [Using libgccjit?](250920-libgccjit.html).)
- Code can be compiled to provide relatively high performance. When
static types are used throughout, it should produce code whose
performance is within the same order of magnitude as C or at least
somewhat close to that. Similar to Java, Haskell, and OCaml in this
regard, if I remember their typical performance metrics correctly.
- The GC's behaviour must be well defined, and possible to control
closely, to achieve optimal results in your program's bottlenecks.
- As a consequence of the last two points: The number of cases you end
up wanting to "drop down to C or ASM" for performance reasons should
be minimal. Only in the most performance critical situations should
you ever need to consider adding hand written C or ASM to your
codebase, but ideally never. There may actually be a sort of low
level DSL within the language that can produce snippets of machine
code directly, so you never need to write any C, period. Hand
written platform specific ASM should only be needed in situations
you'd have needed to do the same had you been writing C.
- It must be possible to link against dynlibs conforming to the
platform's ABI (e.g. C/C++ libs) and easily call functions from
them. It must be possible to produce such dynlibs that others can
link against and call your functions. (Not sure how to consolidate
this with GC yet.)
- Static types are optional; the produced code falls back to using a
generic dynamic object representation if there isn't enough type
info. This dynamic object type is well defined (like a C tagged
union) as part of the language's ABI. Through this and some other
design choices, programmers would be enabled to write simple high
level "script" code when performance doesn't matter.
- The runtime should either include a reasonably fast interpreter, so
it can offer an `eval()` function, or better yet: The compiler is
part of the runtime. Because we want to be Lispy, and allow for
rich dynamic applications like Emacs to be written in the language,
that can modify themselves at runtime.
- The language is essentially "a Lisp" and uses a kind of s-expression
to represent code, and the parser for that format is of course part
of the runtime. Hygienic macros a la Scheme are of course part of
the language.
Also, at this point it should be obvious that although I started this
as a little toy project, I actually dream of it becoming a serious
language project that could, one day, offer an alternative to C, C++,
Java, Python, and so on. Yes, both low-level languages with high
performance and high-level scripting languages.
|
