1 files changed, 67 insertions, 0 deletions
diff --git a/notes/250920-goals.md b/notes/250920-goals.md
new file mode 100644
index 0000000..559609b
--- /dev/null
+++ b/notes/250920-goals.md
@@ -0,0 +1,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?](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.