<commit_before># Goals

* A LISP **inspired by Scheme and Clojure** compiling to Go.
* Kashmir should feature a safe but versatile type system - more flexible than
the one in Go and at least as safe.
* The type system should offer type inference (Hindley-Milner style) that only
requires type annotations on top-level forms.
* The prototype compiler should be easy to change.
* Align with the built-in types of Go and provide simple interoperability.

## Secondary Goals

* The first versions might not include parametric polymorphism (generics) in
functions and types but the underlying type checker should be able to support
it without a big rewrite.
* Macros, not needed for first version.

## Non-goals (in first versions)

* Fast compiler. Emphasis lies on a simple implementation with easy-to-change
behaviour, not compiler speed.
* A "Go backend" for Scheme or Clojure.
* Easy workflow. After running the Kashmir compiler the user might have to step
in to a directory of output Go files and run `go build` etc.<commit_msg>Revise project goals<commit_after># Goals

These are the primary goals and tradeoffs as well as non-goals for the
first iterations of Kashmir. To be extra clear, *this is currently an
experimental language and it might change drastically*.

* A LISP-like language **inspired by Scheme and Clojure** compiling to
  Go. Not perhaps a "real LISP", at least not until macros are
  implemented.
* Kashmir should feature a safe but versatile type system - more
  flexible than the one in Go and at least as safe.
* Generics.
* The type system should offer heavy type inference. Possibly require
  type annotations on top-level forms.
* Align with the built-in types of Go and provide simple
  interoperability.
* The prototype compiler should be easy to change.

## Secondary Goals

* Macros, not needed for first version, but still a long-term goal.

## Shortcuts/Tradeoffs

The first versions of Kashmir should **not** focus on:

* A fast compiler. Emphasis lies on a simple implementation with
  correct semantics, not compilation speed.
* Easy workflow. After running the Kashmir compiler the user might
  have to step in to a directory of output Go files and run `go build`
  etc.
* Producing beautiful Go code.
* Easy Kashmir &rarr Go interopability. It might turn out easy after
  all, but that is not an explicit goal.

## Non-goals

* A "Go backend" for Scheme or Clojure. There's no compatibility with
  any existing LISP, or any other language for that matter.
* A Haskell-clone.
{'fraction_non_alphanumeric': 0.05252686032630322, 'fraction_numerical': 0.0, 'mean_word_length': 4.089068825910931, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4350113', 'n_tokens_mistral': 702, 'n_tokens_neox': 642, 'n_words': 381}