208 lines
11 KiB
Markdown
208 lines
11 KiB
Markdown
|
|
# Dervish / BEX — Complete Conversation Summary
|
||
|
|
|
||
|
|
## Overview
|
||
|
|
|
||
|
|
4 Gemini conversations from 2026-07-03 (all from same session, branching at different points).
|
||
|
|
All revolve around BEX grammar inference algorithms and the Dervish MCP tool.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Chat 1: "LLMs, Agenten und Schema-Inferenz" (32 turns)
|
||
|
|
**Model:** 3.5 Flash | **Link:** share/8fce4fbdf14a
|
||
|
|
|
||
|
|
### Flow
|
||
|
|
1. Starts with arXiv:1004.2372 (Bex et al. — XML schema inference via k-OREs)
|
||
|
|
2. Gemini proposes 4 application areas for LLM agents:
|
||
|
|
- **① Workflow Discovery** — infer state machines from agent traces
|
||
|
|
- **② Dynamic Schema Generation** — distill JSON/XML schemas from unstructured data for grammar-guided decoding
|
||
|
|
- **③ API Reverse Engineering** — infer API structure from probe calls
|
||
|
|
- **④ Prompt Injection Defense** — detect structural anomalies in incoming data
|
||
|
|
3. User picks **#3** (API reverse engineering), explores MCP tools
|
||
|
|
4. Shifts focus to **#1 extended: Code Generation patterns** (IaC, CI/CD pipelines)
|
||
|
|
5. **Key insight:** BEX can learn the *unwritten conventions* of existing codebases
|
||
|
|
6. User requests Python implementation of all BEX algorithms from paper pseudocode
|
||
|
|
7. Multiple BEX papers explored:
|
||
|
|
- Bex et al. 2010 (k-OREs, the main paper)
|
||
|
|
- Bex, Neven, Vansummeren 2008 (DTD inference — simpler, less powerful)
|
||
|
|
- Bex, Neven, Schwentick, Vansummeren 2010 (concise regex + DTDs)
|
||
|
|
8. **Paradigm shift:** XML → **YAML-native**. YAML is trees too, no XML intermediate needed
|
||
|
|
9. User requests actual pseudocode extraction from PDFs (not AI-generated hallucinations)
|
||
|
|
10. **Escalation:** User frustrated when Gemini can't find real papers about formal grammars helping agents (hallucinates fake sources). Ends with user abandoning Gemini as search engine
|
||
|
|
|
||
|
|
### Key Decisions
|
||
|
|
- Focus on **code generation patterns** as primary application
|
||
|
|
- **YAML-native** approach (no XML intermediate)
|
||
|
|
- Multiple BEX papers needed for full algorithm coverage
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Chat 2: "Regex Power Beyond Formal Definitions" (14 turns)
|
||
|
|
**Model:** 3.5 Flash | **Link:** share/d100a2d42200
|
||
|
|
|
||
|
|
### Flow
|
||
|
|
1. Regex primitives (concatenation, disjunction, iteration) vs modern regex
|
||
|
|
2. **Grammar Induction** from positive examples only (Gold's Theorem — impossible in general case)
|
||
|
|
3. BEX algorithms as the practical solution to this problem
|
||
|
|
4. Improvements on BEX: interleaving (.), higher k-values
|
||
|
|
5. User: "I have implemented BEX but I'm intrigued by interleaving"
|
||
|
|
6. Dervish README walkthrough
|
||
|
|
7. **embabel agent** discussion: JVM-based agent framework with typed actions
|
||
|
|
8. GOAP (Goal-Oriented Action Planning) + Dervish — infer action preconditions from examples
|
||
|
|
9. **Convention monitoring idea:** Dervish observes agent, detects when patterns become conventions
|
||
|
|
|
||
|
|
### Key Decisions
|
||
|
|
- BEX improvements needed: interleaving, higher k
|
||
|
|
- Dervish could act as **passive convention observer** for agents
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Chat 3: "Dervish: Grammar Inference for LLM Agents" (32 turns)
|
||
|
|
**Model:** 3.1 Pro | **Link:** share/0f836d3c25ba
|
||
|
|
|
||
|
|
### Flow (Turns 1-27 — shared with Chat 4)
|
||
|
|
|
||
|
|
#### Phase: README Polish (Turns 1-5)
|
||
|
|
- README paste → improve "MDL" wording
|
||
|
|
- Add **generative schema** section (infer grammar → generate sample data)
|
||
|
|
- Add "Why not just use a schema?" section
|
||
|
|
|
||
|
|
#### Phase: Architecture Discovery (Turns 6-10)
|
||
|
|
- Question: **Can Dervish analyze Java/Kotlin codebases?**
|
||
|
|
- Answer: Language structure ≠ code conventions. Dervish needs *behavioral* sequences
|
||
|
|
- **Turn 7: DomainRouter pre-detection** idea — detect context (source code vs YAML) before choosing algorithm
|
||
|
|
- **Turn 8: MDL Ensemble insight** — Dervish already runs all algorithms and picks best by MDL. No need for pre-detection!
|
||
|
|
- **Turn 9: Single-pass heuristic** — maybe we don't need all algorithms, can derive coverage levels from one pass
|
||
|
|
|
||
|
|
#### Phase: TreeSitter Revolution (Turns 10-17)
|
||
|
|
- **Turn 10: Language-agnostic breakthrough** — Dervish is absolutely language-agnostic, can analyze any codebase
|
||
|
|
- **Turn 11: Prior art needed** — is there existing research on grammar inference from ASTs?
|
||
|
|
- **Turn 12: TreeSitter AST pipeline** — extract AST nodes → flatten to sequences → Dervish infers grammar
|
||
|
|
- **Turn 13-14: Concrete Java examples** — spring boot controllers, which AST nodes matter
|
||
|
|
- **Turn 15: Repository vs directory scoping** — how does Dervish know where conventions boundaries are?
|
||
|
|
- **Turn 16: Avoiding per-language heuristics** — must be zero-config
|
||
|
|
- **Turn 17: Novelty confirmed** — no prior work on grammar inference from TreeSitter ASTs. This is a genuine research contribution
|
||
|
|
|
||
|
|
#### Phase: Roadmap Definition (Turns 18-20)
|
||
|
|
- **Formal roadmap defined:**
|
||
|
|
- **1.0: Code Repository Analysis** — TreeSitter → AST nodes → Dervish grammar
|
||
|
|
- **1.1: Structured Data** (YAML, XML, JSON) — existing feature, enhance
|
||
|
|
- **1.2: Markdown/Document AST** — DISCUSSED THEN **DROPPED** (too fuzzy)
|
||
|
|
- **2.0: Cross-file conventions** — class hierarchies, test patterns, file-level relationships
|
||
|
|
- **1.2 dropped** — documents too fuzzy
|
||
|
|
|
||
|
|
#### Phase: Implementation Design (Turns 21-27)
|
||
|
|
- **Features first, combined later** — code analysis separate from structured data
|
||
|
|
- **Interesting nodes** — NOT per-language heuristic! Use **TreeSitter's built-in tag queries** (tags.scm)
|
||
|
|
- Universal query approach: a single query works across languages (annotation→@meta, call_expression→@call, try_statement→@block)
|
||
|
|
- **Community tags.scm** for 100% coverage (Zero maintenance)
|
||
|
|
- **Single-pass frequency analysis** — count symbol frequency across files, filter outliers < threshold
|
||
|
|
- **Concrete example with Spring Boot:**
|
||
|
|
- Raw AST: `['@RestController', '@RequestMapping', '@PostMapping', 'log.info', 'dto.getItems', 'dto.getItems.isEmpty', 'orderService.process', 'ResponseEntity.ok']`
|
||
|
|
- After frequency filter: remove `dto.getItems` (occurs in 1/10 files)
|
||
|
|
- Result: convention grammar for Spring Boot controllers
|
||
|
|
- **Critical concern (Turn 27):** Will Dervish find genuinely novel insights or just obvious patterns?
|
||
|
|
|
||
|
|
#### Phase: Broader Vision (Turns 28-32 — UNIQUE TO CHAT 3)
|
||
|
|
- **BEX in LLM training/design** — structural tokenization (replace BPE with grammar-guided), Skeleton-of-Thought patterns
|
||
|
|
- **Paper title proposals:**
|
||
|
|
1. "DERVISH: Neuro-Symbolic Code Generation via MDL-Optimized Structural Grammars"
|
||
|
|
2. "AST2Regex: Mining Implicit Conventions from Abstract Syntax Trees"
|
||
|
|
3. "Grammar is All You Need: Zero-Shot Convention Learning for LLMs"
|
||
|
|
- **Terminology debate:** "skeleton" bad, prefer "grammar" or "schema"
|
||
|
|
- **Grammar-Constrained Decoding (GCD)** research — position Dervish as bridging structured output generation
|
||
|
|
- Final task: deep research into GCD + neuro-symbolic generation literature
|
||
|
|
|
||
|
|
### Key Decisions
|
||
|
|
- **TreeSitter AST → Dervish pipeline** is the core architecture
|
||
|
|
- **No per-language heuristics** — use TreeSitter's universal node types and community tag queries
|
||
|
|
- **Single-pass frequency analysis** filters noise
|
||
|
|
- **1.2 (documents) dropped** — focus on code repos + structured data
|
||
|
|
- **Features isolated** before integration
|
||
|
|
- **This is novel research** — no prior work on grammar inference from TreeSitter ASTs
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Chat 4: "Dervish: Grammar Inference for LLM Agents" (27 turns)
|
||
|
|
**Model:** 3.1 Pro | **Link:** share/a5ff288e0fdf
|
||
|
|
|
||
|
|
### Relationship to Chat 3
|
||
|
|
- **IDENTICAL to Chat 3 for Turns 1-27** (same conversation, same user messages, same AI responses)
|
||
|
|
- **Ends at Turn 27** — Chat 3 continues with 5 additional turns (28-32)
|
||
|
|
- Chat 4 = the "short branch" of the conversation
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Divergence Map
|
||
|
|
|
||
|
|
```
|
||
|
|
Chat 1 (32 turns) — LLMs/Agenten/Schema
|
||
|
|
─────────────────────────────────
|
||
|
|
Separate conversation, different focus (MCP, YAML-native, PDF algorithms)
|
||
|
|
|
||
|
|
Chat 2 (14 turns) — Regex theory
|
||
|
|
─────────────────────────────────
|
||
|
|
Separate conversation, different focus (regex theory, embabel, GOAP)
|
||
|
|
|
||
|
|
Chat 3 (32 turns) — Dervish: Grammar Inference
|
||
|
|
Chat 4 (27 turns) — Dervish: Grammar Inference
|
||
|
|
│
|
||
|
|
├── Turns 1-5: README polish (MDL wording, generative schema section)
|
||
|
|
├── Turns 6-10: Architecture (DomainRouter, MDL ensemble, TreeSitter idea)
|
||
|
|
├── Turns 11-17: TreeSitter deep dive (language-agnostic, prior art, roadmapping)
|
||
|
|
├── Turns 18-20: Formal roadmap, 1.2 dropped
|
||
|
|
├── Turns 21-27: Implementation design (tags queries, frequency analysis, Spring Boot example)
|
||
|
|
│
|
||
|
|
└── Turn 27: "Will it find genuine insights?" (SAME question in both)
|
||
|
|
├── Chat 3 continues (Turns 28-32)
|
||
|
|
│ ├── 28: BEX in LLM training (structural tokenization, SoT)
|
||
|
|
│ ├── 29: Paper search on GCD approaches
|
||
|
|
│ ├── 30: arXiv paper title proposals
|
||
|
|
│ ├── 31: Terminology debate (grammar vs skeleton)
|
||
|
|
│ └── 32: GCD research assignment
|
||
|
|
│
|
||
|
|
└── Chat 4 ENDS at Turn 27
|
||
|
|
```
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Planned Feature Roadmap (from Chats 3-4)
|
||
|
|
|
||
|
|
### Phase 1.0: Code Repository Analysis (TreeSitter AST → Dervish)
|
||
|
|
1. **Language detection** (file extension, MIME type)
|
||
|
|
2. **TreeSitter parsing** with language-specific grammar
|
||
|
|
3. **UNIVERSAL_STRUCTURE_QUERY** (single query for all languages):
|
||
|
|
- `(call_expression) @call`
|
||
|
|
- `(annotation) @meta` / `(decorator) @meta`
|
||
|
|
- `(try_statement) @block` / `(catch_clause) @block`
|
||
|
|
- Alternatively: load community `tags.scm` for each language
|
||
|
|
4. **Single-pass frequency analysis** — count symbol frequency across files, filter outliers below threshold
|
||
|
|
5. **Dervish inference** on cleaned sequences → compact grammar
|
||
|
|
6. **Output:** ~60-200 token rule representing codebase conventions
|
||
|
|
|
||
|
|
### Phase 1.1: Structured Data (existing feature, enhance)
|
||
|
|
- YAML/XML/JSON sequences → grammar inference
|
||
|
|
- Already partially implemented in Dervish
|
||
|
|
|
||
|
|
### Phase 1.2: Markdown/Document AST (DROPPED)
|
||
|
|
- Too fuzzy, documents vary too much
|
||
|
|
- Not a priority
|
||
|
|
|
||
|
|
### Phase 2.0: Cross-File Conventions (future)
|
||
|
|
- Class hierarchies, test patterns, file-level relationships
|
||
|
|
- Beyond single-file AST analysis
|
||
|
|
|
||
|
|
### Broader Research (Chat 3 extra turns)
|
||
|
|
- **Structural tokenization** — replace BPE with grammar-guided tokenization
|
||
|
|
- **Grammar-Constrained Decoding (GCD)** — position Dervish in the GCD ecosystem
|
||
|
|
- **arXiv paper** — "DERVISH: Neuro-Symbolic Code Generation via MDL-Optimized Structural Grammars"
|
||
|
|
- **Literature review** — deep search on GCD + neuro-symbolic generation
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Repository State
|
||
|
|
- **Main repo:** grammar-inference-engine (git submodule at `projects/grammar-inference-engine/`)
|
||
|
|
- **Branch:** `feature/dervish-2`
|
||
|
|
- **Remote:** `origin → https://forgejo.corentic.eu/tobi/grammar-inference-engine`
|
||
|
|
- **Current code:** BEX algorithms (CRX, iDRegEx), MCP server, basic ORES/SORE/CHARE types
|
||
|
|
- **Need 5th Gemini share link** — user mentioned 5 chats, we only have 4
|