a loose collection of goals and ideas for this as-yet-unnamed language.  the
main goal is really just (a) to have fun, and (b) to make a c replacement that
provides the things i personally wish the language was better on.

* very small, self-contained executables
  + hello world should ideally be on the order of a couple kilobytes
  + only functions which get referenced from main (and so on recursively)
    get any code generated, even for the stdlib
  + favor size over performance where reasonable
  + effectively no language runtime

* fast compilation
  + grammar must be very easy to parse
  + more important than high performance
  + more important than minor ergonomic sacrifices
  + possibly built-in hot code reloading somewhere down the line
  + in general:
    - the most important thing for coding to be fun is a tight feedback loop

* explicit
  + procedures that allocate should have an arena parameter
  + no operator overloading, but builtin vector/matrix types (eventually)

* aesthetically minimalist
  + not too many keywords or features
  + no semicolons
  + no significant whitespace
  + no parentheses around conditions
  + type inference wherever possible

* more modern type system than c
  + distinction between pointers and arrays
  + slice types (ptr, len)
    - strings are slices, like rust &str or c++ str_view
  + dynamic arrays (ptr, len, cap)
    - manipulation of dynamic arrays is handled by normal functions
  + type-safe generics
  + parametric polymorphism (at compile time)
  + built-in types for vector and matrix math
  + scalar types have explicit bit sizes
    - u8, i32, u64, f32, f64
  + bit set support!
  + type inference
    - let x = y
    - can do like .ENUM_NAME when expecting an enum value, even though
      otherwise it's `let x = EnumType.ENUM_NAME`
  + pascal-style postfix dereference, no need for a->b or (*a).b
    - possibly also auto-dereference when accessing fields

* c interop
  + c type aliases in stdlib
  + can turn off name mangling on exported identifiers
  + ability to specify different calling conventions on:
    - functions imported from outside
    - functions exported

* better module system than c
  + proper module import, no header files
  + types and procedures in any order
    - can be thrown out if it turns out to slow down the compiler, but
      finding these first allows to hand all procedures to a thread pool for
      parsing and optimization
    - removes the need for function prototypes, opaque structs, etc.
  + like in odin, all files in a directory are compiled together and have
    the same toplevel scope; to isolate things in a package, put them in
    a different directory
  + no A::B like in c++ or rust, just a normal A.B

* portable
  + should be as easy as possible (like that's saying much...) to port to new platforms
  + at minimum support amd64 and wasm
    - try and make it work with windows
  + consider having a version of the compiler which uses LLVM for release builds

* useful
  + not just a toy language!
  + begin dogfooding with it as soon as that's viable
  + write a text editor, develop the compiler with that
  + eventually bootstrap into a self-hosting one, maybe
  + utility procedures in the standard library
    - string manipulation: searching, splitting, comparing, etc.
    - utf8 encoding & decoding
    - libc bindings
    - command-line argument parsing
    - consistent allocator interface
    - arena allocators
    - memory context allocator (like c# autorelease pool)
    - file i/o, can read whole thing into string easily
  + try to get _reasonable_ levels of optimization, within the constraints of
    simplicity and very fast compilation