From a528b8dac4bb474e5126b72dba8b2ac7597f8886 Mon Sep 17 00:00:00 2001 From: Julian Noble Date: Mon, 13 Jul 2026 02:23:00 +1000 Subject: [PATCH] G-055 detail: lseq operand typing probe - indexexpression fit vs expr syntax validation (user query 2026-07-13) Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com --- goals/G-055-tclcore-regen-workflow.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/goals/G-055-tclcore-regen-workflow.md b/goals/G-055-tclcore-regen-workflow.md index 027a042d..d9b3b4af 100644 --- a/goals/G-055-tclcore-regen-workflow.md +++ b/goals/G-055-tclcore-regen-workflow.md @@ -118,6 +118,19 @@ other commands including the multi-form ::after. form's expr-typed end accepts the word 'count' - real lseq resolves it as the start_count form. Tightening the expr operands (or making them version-conditional per TIP 746 below) removes the false candidate. + Probed 2026-07-13 (user suggestion: -type indexexpression instead): a poor + lexical fit for lseq operands on 9.0.3 - indexexpression (lindex-style + int/end/end+-N/M+-N) UNDER-accepts real-valid operands 1e2, 2*3, 6/2, + sqrt(9) and the man page's own {[llength $l]-1} idiom, and OVER-accepts + end/end-1 (real lseq rejects); number|indexexpression repairs only the + number literals. The precise discriminator is expr SYNTAX validation: the + problem words (count/to/end) all fail Tcl's expr PARSER as invalid + barewords while every real-valid shape parses - but a validator must parse + without evaluating (operand exprs may contain command substitution), i.e + tclparser 'parse expr' (G-069/G-070) or equivalent, not catch{expr}. Also + noted: count-position operands reject doubles where start/end accept them + ('lseq 1.5' errors, 'lseq 1.5 3.5' works) - a value-dependent constraint no + lexical type expresses. - TIP 746 (user-flagged 2026-07-12, https://core.tcl-lang.org/tips/doc/trunk/tip/746.md) removes the expr behaviour from lseq operands in Tcl 9.1: the lseq model's number|expr operand