# 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.