What’s unique: the Gene data type

Gene’s central idea is a single unified structure that always carries (1) a type, (2) key/value properties, and (3) positional children:

(type ^prop1 value1 ^prop2 value2 child1 child2 ...)

The key point is that the type, each property name, each property value, and each child can themselves be any Gene data. Everything composes uniformly. In practice this is powerful and liberating: you can build rich, self-describing structures without escaping to a different “meta” representation, and the AST and runtime values share the same shape.

This isn’t JSON, and it isn’t plain S-expressions: type + properties + children are first-class in one representation, so you can attach structured metadata without wrapper nodes, and build DSLs / transforms without inventing a separate annotation system.

Dynamic + general-purpose (FP and OOP)

Gene aims to be usable for “regular programming,” not only DSLs:

* FP-style basics: fn, expression-oriented code, and an AST-friendly representation

* OOP support: class, new, nested classes, namespaces (still expanding coverage)

* Runtime/tooling: bytecode compiler + stack VM in Nim, plus CLI tooling (run, eval, repl, parse, compile)

Macro-like capability: unevaluated args + caller-context evaluation

Gene supports unevaluated arguments and caller-context evaluation (macro-like behavior). You can pass expressions through without evaluating them, and then explicitly evaluate them later in the caller’s context when needed (e.g., via primitives such as caller_eval / fn! for macro-style forms). This is intended to make it easier to write DSL-ish control forms without hardcoding evaluation rules into the core language.

Optional local LLM backend via llama.cpp

I also added an optional local LLM backend: Gene has a genex/llm namespace that can call local GGUF models through llama.cpp via FFI (primarily because I wanted local inference without external services).

Repo: https://github.com/gene-lang/gene

I’d love feedback on:

* whether the “type/props/children” core structure feels compelling vs plain s-exprs,

* the macro/unevaluated-args ergonomics (does it feel coherent?),

* and what would make the project most useful next (stdlib, interop, docs, performance, etc.).