--- title: Execution Description Language (EDL) url: https://www.emergentmind.com/topics/execution-description-language-edl type: topic --- # Execution Description Language (EDL) Execution Description Language (EDL) is a natural-language–style, stepwise intermediate representation for database query generation, specifically designed to mediate between a user's natural-language question (NLQ) and a corresponding SQL query. EDL is structured as an explicit, numbered list of execution operators, each mapping directly to a classical relational database operation. This approach systematizes query planning in neural text-to-SQL systems by decomposing semantic parsing into two discrete stages: NLQ-to-EDL and EDL-to-SQL. EDL has been introduced and formalized in the CRED-SQL framework to reduce semantic drift and improve compositional accuracy, especially in large-scale, cross-domain databases [2508.12769]. ## 1. Formal Definition and Syntax EDL adopts a formal, process-oriented syntax organized as a sequence of operator invocations, each associated with a particular execution step. The top-level grammar is provided in Backus–Naur Form (BNF) as follows: \[ \begin{aligned} \langle \text{EDLDoc}\rangle\; &::=\; \langle \text{StepList}\rangle \\ \langle \text{StepList}\rangle\; &::=\; \langle \text{Step}\rangle\,(\texttt{\n}\;\langle \text{Step}\rangle)^* \\ \langle \text{Step}\rangle\; &::=\; \texttt{\#}\,\langle \text{StepNum}\rangle\,\texttt{.}\,\langle \text{OpInvocation}\rangle \\ \langle \text{StepNum}\rangle\; &::=\; [\texttt{1}\!-\!\texttt{9}][\texttt{0}\!-\!\texttt{9}]* \\ \langle \text{OpInvocation}\rangle\; &::=\; \langle \text{Operator}\rangle\;\langle \text{ArgList}\rangle \\ \langle \text{Operator}\rangle &::=\; \texttt{ScanTable}\mid \texttt{Join}\mid \texttt{ReserveRows}\mid \texttt{GroupBy}\mid \texttt{HavingClause}\mid \texttt{Sort}\mid \texttt{Limit}\mid \texttt{SelectColumn}\mid \\ &\quad\;\;\texttt{Subquery}\mid \texttt{SetOp}\mid \texttt{ArithmeticCalc}\mid \dots \\ \langle \text{ArgList}\rangle &::=\; \text{free-form English describing table names, aliases, columns, conditions, etc.} \end{aligned} \] EDL plans are explicit trees, with leaf nodes typically instantiating `ScanTable` or `Subquery`, and internal nodes performing operations such as `Join`, `ReserveRows` (filter), `GroupBy`, or arithmetic calculation. Step referentiality enables chaining of prior computation by explicit step number. A summary of core operators appears below. | Operator | Function | Example Usage | |------------------------|-------------------------------|----------------------------------------------------| | ScanTable | Retrieve table rows | Retrieve all rows from [city] as T1 | | Join | Join two tables | Join [Pets] as P on HP.[PetID] = P.[PetID] | | ReserveRows | Filter rows | From #1, keep rows where ... | | GroupBy | Aggregation grouping | Group #4 by [District] | | HavingClause | Aggregate-level filtering | HAVING count(*) > 5 | | Sort | Sort rows | Sort by [Population], descending | | Limit | Row count truncation | Limit to 10 rows | | SelectColumn | Project columns | Select [major], [age] from #7 | | Subquery | Nested result | Retrieve all cities with ... as T2 | | SetOp | Set operation | Intersect #3 and #4 | | ArithmeticCalc | Computed columns | Compute avg_population as ... | | DateCalculation | Temporal computation | Extract year from [BirthDate] | | Cast | Type conversion | Cast [Amount] as float | | Ranking | Row ranking | Rank students by GPA | | SubstringExtraction | Substring from column | Extract prefix from [Name] | | CaseStatement | Conditional value selection | CASE WHEN ... END | ## 2. Exemplification of EDL for Query Planning EDL plans are constructed for both simple and complex NLQs. Two illustrative transformations are given: **Example 1: Single-table Aggregation** - **NLQ:** "Find the number of cities in each district whose population is greater than the average population of cities?" - **EDL:** 1. Scan Table: Retrieve all rows from the [city] table as T1. 2. Subquery: Retrieve all rows from the [city] table as T2. 3. Arithmetic Calculation: Compute avg_population as the average of T2.[Population]. 4. Reserve Rows: From #1, keep rows where T1.[Population] > #3.avg_population. 5. Group By: Group #4 by the [District] column. 6. Select Column: Select count(*) as city_count from #5. **Example 2: Multi-table Join with Negation** - **NLQ:** "Find the major and age of students who do not have a cat pet." - **EDL:** 1. Scan Table: Retrieve all rows from the [Student] table as S. 2. Scan Table: Retrieve all rows from the [Has_Pet] table as HP. 3. Join: Join [Pets] as P on HP.[PetID] = P.[PetID]. 4. Reserve Rows: From #3, keep rows where P.[PetType] = 'cat'. 5. Select Column: Select HP.[StuID] from #4. 6. Reserve Rows: From #1, keep rows whose S.[StuID] is not in #5. 7. Select Column: From #6 select [major], [age]. These examples highlight EDL's explicit operator chaining and transparent tracking of dataflow and selection logic [2508.12769]. ## 3. Mapping from NLQ to EDL: Model and Training The NLQ-to-EDL process is cast as a supervised sequence generation task. Spider and Bird SQL annotations are automatically converted to EDL via GPT-4o, with database execution ensuring semantic alignment. Datasets of ⟨NLQ, gold-EDL⟩ pairs are constructed (Spider-EDL and Bird-EDL). - **LLM Base:** Qwen2.5-Coder-32B (open-source, code-specialized LLM) - **Finetuning:** LoRA, rank-8, learning rate $5 \times 10^{-5}$, two epochs. - **Prompt Template (Inference):** 1. Task cue: "Translate the following question into an EDL plan." 2. Schema context (tables and columns). 3. Three to five few-shot examples (NLQ→EDL). 4. The query to parse. The learning objective is next-token cross-entropy loss: \[ \mathcal{L}_{\text{T2E}}(\theta) = -\sum_{i=1}^N \log p_\theta(e_i \mid q_i, d_i) \] with $q_i$ the NLQ, $d_i$ the schema context, and $e_i$ the gold EDL. Inference uses autoregressive decoding with top-1 selection; beam search is optional. A final consistency check (EDL→SQL→DB) for non-empty results can be used, but is rarely necessary in practice [2508.12769]. ## 4. EDL-to-SQL Mapping: Deterministic and Model-Based Approaches EDL-to-SQL conversion is implemented via two main strategies: - **(a) Structure-to-sequence LLMs:** The EDL (numbered steps) and schema are serialized as input; the output is SQL. The model is trained with a standard cross-entropy objective on ⟨EDL, SQL⟩ pairs. - **(b) Deterministic template-based code:** Each operator is mapped to its SQL clause via explicit pseudocode logic: ```python # Pseudocode for mapping EDL to SQL Initialize: SELECT_list ← [] FROM_clause ← "" JOIN_clauses ← [] WHERE_clause ← "" GROUP_BY ← [] HAVING_clause ← "" ORDER_BY ← "" LIMIT ← None For each step in EDL in ascending order: op, args ← parse(step) match op: case ScanTable(table T as alias A): FROM_clause ← f"FROM {T} AS {A}" case Join(table T as alias A on condition C): JOIN_clauses.append(f"JOIN {T} AS {A} ON {C}") case ReserveRows(condition C): if GROUP_BY not set: WHERE_clause ← f"WHERE {C}" else: HAVING_clause ← f"HAVING {C}" case GroupBy(columns cols): GROUP_BY ← cols case SelectColumn(col c): SELECT_list.append(c) case ArithmeticCalc(newcol nc = expr): SELECT_list.append(f"{expr} AS {nc}") case Sort(column c, order dir): ORDER_BY ← f"ORDER BY {c} {dir}" case Limit(n): LIMIT ← n case SetOp(type S, q1, q2): SQL ← f"({q1}) {S.upper()} ({q2})" At end: SQL ← ( SELECT {", ".join(SELECT_list)} {FROM_clause} {" ".join(JOIN_clauses)} {WHERE_clause if any} {GROUP_BY ? "GROUP BY " + ",".join(GROUP_BY) : ""} {HAVING_clause if any} {ORDER_BY if any} {f"LIMIT {LIMIT}" if LIMIT else ""} ) ``` Faithfulness is obtained because the operator mapping is explicit and 1-to-1. Empirical results show >98% execution accuracy across LLMs when gold EDL is mapped to SQL [2508.12769]. ## 5. Training Objectives and Evaluation Metrics Supervised training is performed for both NLQ-to-EDL and EDL-to-SQL mappings, each using token-wise cross-entropy losses: \[ \min_\theta\; \sum_{i=1}^{N}\;\mathcal{L}_{\mathrm{CE}}\left(p_\theta(\widetilde e_i\mid q_i,d_i),\,e_i\right) \,,\quad \min_\phi\; \sum_{i=1}^{N}\;\mathcal{L}_{\mathrm{CE}}\left(p_\phi(\widetilde s_i\mid \widetilde e_i,d_i),\,s_i\right) \] Evaluation uses two principal metrics: - **Execution Accuracy (EX):** Fraction of test queries for which the predicted execution matches the gold execution. \[ \mathrm{EX} = \frac{1}{M}\sum_{i=1}^M \mathbf{1}\bigl(\mathrm{exec}(\widetilde s_i) = \mathrm{exec}(s_i)\bigr) \] - **Schema-retrieval Recall@k:** Proportion of gold tables covered by the top-k retrieved tables. \[ \mathrm{Recall}@k = \frac{|\{\text{gold tables}\}\cap \{\text{top-}k\text{ retrieved}\}|}{|\{\text{gold tables}\}|} \] These two metrics rigorously quantify both upstream schema selection effectiveness and end-to-end semantic fidelity [2508.12769]. ## 6. Empirical Performance and Impact The integration of EDL into CRED-SQL yields measurable gains over prior art, especially in large, complex schemas. - On SpiderUnion (GPT-4o), CLSR schema retrieval achieves recall@1 of 40.23% (vs. 8.51% for CRUSH) and recall@3 of 77.07% (vs. 30.56%). - End-to-end (Qwen2.5-Coder-32B): CRUSH+NLQ→SQL achieves 51.5% EX; CRED-SQL with EDL achieves 73.4% EX (+21.9 points). - Intermediate representation comparison (Spider, GPT-4o, DIN-SQL): NLQ→SQL 78.1% EX; NLQ→EDL→SQL 83.3% EX (+5.2 points). - On BirdUnion (MAC-SQL backbone, GPT-4o): CRED-SQL+EDL yields 58.28% EX (vs. 51.17% baseline, +7.11 points). A full breakdown across upstream and open/closed LLMs shows that EDL consistently improves both schema selection and execution accuracy over direct SQL-generation or previous intermediate representations such as QPL. The adoption of EDL, especially when paired with strong schema retrieval as in CRED-SQL, substantially reduces semantic drift and ensures more faithful mappings in neural semantic parsing pipelines [2508.12769]. Source: https://www.emergentmind.com/topics/execution-description-language-edl