goals of zetz

[aep]

As noted in #148 , we need to significantly reduce the language to make it maintainable by a single person with 3 jobs and a kid.
I have not made any progress on figuring out a path towards that because it's no longer clear what goals we all want to archive once formal proving is off the table.

i'd like everyone to drop their goals into this discussion to see what is common. i'll start:

• use it to create cross platform libraries that are included in other high level languages
  one code base for npm module, python module, etc

• use it for embedded systems where C is the only option
  but without the pain of C's undefined behavior pitfalls

as a result of those goals here's my wishlist:

• must emit to C so we can use it with proprietary compilers (common in embedded)
• must be able to easily include existing C code. don't require rewriting the world to make it useful
• must be an unambiguous human readable syntax and context-free gramar (C has some absurdly broken parser rules)
• should have some sort of macro language that is explicit and not an ugly string matcher hack like c-prepro
• must not require a runtime other than C, specifically NEVER a garbage collector
• should make a reasonable effort to reduce undefined behavior, specifically DO protect against common mistakes

[jwerle]

In addition to the goals stated by @aep, i'd like to make sure we continue to have the following or implement at some point:

• must support third party modules (currently possible with git)
  • should semantic versioning?
  • should support module resolutions for when mod A depends mod B and on v1 of mod C , mod B depends on v2 of mod B
• must be configurable to allow for exotic things like compiling to WASM
• should provide a feature-rich stdlib
  • should rely on user space as little as possible
• should allow for things like cosmopolitan to be used/injected during the build steps
• must have better error messages