GLISP — Language Description (Repository Overview)

GLISP is a description of a language, not a conventional programming-language spec. The documents in this repo are explanatory and prescriptive: they define a closed world (no external references), emphasize mechanical parsing over informal intuition, and keep a strict parser ⇄ evaluator separation. There is no formal grammar here; instead, the description documents show surface forms and their mechanical transformations into homoiconic structures.

Parser: performs only mechanical transformations (e.g., name: value ↦ (: name value)).
Evaluator: assigns meaning (e.g., interpreting (: …) as binding or mutation, depending on context).

---

Quick Reference (Core Ideas)

• Application modes (surface):
  • Cmdfix — application-by-space with zero or more arguments; highest precedence; left‑associative; primary in {} and ().
    • print ↦ (print)
    • print x ↦ (print x)
  • Juxtfix — application-by-space with one or more arguments; highest precedence; left‑associative; primary inline and in data structures.
    • print ↦ print (reference)
    • print x ↦ (print x)
• Sections by newline: a section‑creating transformer (e.g., :/!) followed by newline opens a block (cmdfix per line); followed by content creates an inline section (juxtfix).
• Mode switchers:
  • ; — creates a sequence and forces cmdfix on each item, in all contexts: a; b; c ↦ {(a) (b) (c)}.
  • $ — prevents cmdfix on the head: in cmdfix $f ↦ f, $f x y ↦ (f x y); in juxtfix $f remains a reference.
• Delimiters (principal operations):
  • () Application (cmdfix)
  • [] Struct (collection/binding)
  • {} Block (sequential execution; cmdfix per line)
  • 〚〛 Array (indexed collection)
  • ⟨⟩ Symbolic (mathematical expressions)
  • ⌊⌋ Binary (bit patterns)
• Data structures just collect:

  [f x y]            # struct collects 3 items
  〚f x y〛             # array collects 3 items
  ⟨f x y⟩            # symbolic collects 3 items
  ⌊version:4 ihl:4⌋  # binary collects pairs
  

• System atoms are simple patterns recognized mechanically (no protocol checks): ./, ../, ://.
• Homoiconicity preserved: sequences and structure are never collapsed by the parser.
• UFCS — Uniform Function Call Syntax: UFCS allows a navigation datum to serve as the head of an application, with the left side becoming the first argument.

---

Repository Map (What each file is for)

• 00_Glisp_Philosophy.md — Philosophy & Goals
  Rationale for GLISP as a description rather than a grammar. Defines the closed‑world stance, the parser/evaluator divide, and the commitment to mechanical transformations and homoiconicity.

• 01_Glisp_Basis.md — Basis (Atoms, Delimiters, Transformers)
  Core building blocks: what counts as an atom, the role of transformers, the recognized delimiters and default configuration knobs. Establishes baseline notation and vocabulary used across the description.

• 02_Glisp_Parser.md — Parser (Mechanical Transformations)
  The parser’s job and only its job: mechanical rewrites and precedence. Documents suffix glue, head‑graft, and then regular parsing (in that order of precedence); explains how section triggers work (newline vs inline), how delimiters materialize structures, and how sequences are formed.

• 03_Glisp_Lang.md — Language Description (Surface → Structure)
  The user‑level surface forms and their parser outputs. Defines cmdfix vs juxtfix, block vs inline sections, mode switchers (;, $), data structures ([], 〚〛, ⟨⟩, ⌊⌋), struct positional entries (_0, _1, …), and binding rules per context (what val/var mean in {} vs []).

• 04_Glisp_Memory.md — Memory (Bindings, Mutability, Shadowing)
  The evaluator‑side model for environments: how val/var introduce bindings, when shadowing is allowed, and how mutations (name: value / name = value) behave. Clarifies that the memory model is independent of cmdfix/juxtfix; those are parser‑surface modes only.

• 05_Glisp_Symbolic.md — Symbolic Sub‑language
  The symbolic bracket ⟨⟩, mathematical/symbolic forms, and calculus sugar. Reiterates that symbolic contexts collect only; when sequences are needed, ; is used and preserved structurally.

• README.md (this file)
  Orientation and quick reference so readers can navigate the description set without guessing terminology or intent.

---

Minimal Examples

Sections by newline vs inline

# Block section (: + newline)
x :
  print              # cmdfix → (print)
  save data          # cmdfix → (save data)

# Inline section (: + content)
x : print save       # juxtfix → (print save)
x : print            # juxtfix → print (reference)

Mode switchers

a; b; c              # → {(a) (b) (c)} (sequence; last result by evaluator)
$filter x y          # cmdfix‑safe head reference → (filter x y)

Data structures collect

point: [10 20 30]
rows:  〚[1 2] [3 4]〛
expr:  ⟨a + b⟩
mask:  ⌊version:4 ihl:4⌋

---

Reading Strategy

1. Start with 00 & 01 to adopt the vocabulary (atom, transformer, delimiters) and the parser/evaluator split.
2. Read 02 to internalize the parser’s precedence and mechanics.
3. Use 03 as the main reference for surface forms and what they mechanically become.
4. Consult 04 when reasoning about bindings, scope, and mutation.
5. Use 05 for symbolic/math notations.

Keep in mind: the parser is intentionally simple and uniform. If something looks like interpretation, it belongs to the evaluator and is documented in 04.

---

Configuration Notes

• Structures have no trigger; they materialize via delimiters only:

  #structure=["materialize":"[]"]
  

• Arrays use 〚〛; symbolic keeps § as trigger (details in the parser doc).
• $ is included in #glue.prefix so the head can be taken as a reference in cmdfix contexts.

---

Contributing (Style & Consistency)

• Use the terms transformer (not “operator”) and atom/datum (not “token”).
• Do not introduce external references; GLISP is a closed world description.
• Preserve homoiconicity in examples: sequences/structures must not be collapsed by the parser.
• Respect the parser ⇄ evaluator divide: parser explanations remain mechanical; semantic meaning belongs in 04.
• Prefer changes that integrate rather than delete; avoid losing detail.

---