Context
Split from #2312, which originally bundled five distinct pieces of work. #2312 now covers only the two well-defined engine fixes (Julia operator-by-text matching, Solidity generic-wrapper transparency) plus wiring COMPLEXITY_RULES/HALSTEAD_RULES for julia and solidity. This issue tracks the remaining three items from #2312's original scope, none of which are mechanical rules ports:
1. Pattern-matching branch-counting design (haskell, ocaml, ocaml-interface, fsharp, fsharp-signature, gleam, clojure, erlang)
These languages need a design decision on what counts as a "branch" for pattern-match/guard constructs (an N-arm match/case expression, guard clauses, etc.) before any ComplexityRules/HalsteadRules can be written. Per #2312's original body: "needs its own design doc given 'what counts as a branch for an N-arm pattern match' needs to be decided once and applied consistently... rather than re-litigated per language." This should land as a design doc first, then mechanical rules ports for each of the eight languages once the design is settled.
2. Verilog
No existing dataflow-rule investigation to build on (unlike r/julia/groovy/solidity, which had prior dataflow work to extend). Needs its own from-scratch grammar investigation — HDL always/case/if semantics differ meaningfully from imperative control flow and don't obviously map onto the existing ComplexityRules/HalsteadRules shape.
3. Dart
Blocked on #2182 (function body isn't a child of function_signature/method_signature in tree-sitter-dart). Do not attempt until that's fixed.
Suggested approach
Tackle the pattern-matching design question as its own design doc first (item 1), since the decision needs to be made once and applied to all eight affected languages rather than re-derived per language. Verilog (item 2) and Dart (item 3, once unblocked) can proceed independently once that design work isn't a prerequisite for them specifically.
Context
Split from #2312, which originally bundled five distinct pieces of work. #2312 now covers only the two well-defined engine fixes (Julia operator-by-text matching, Solidity generic-wrapper transparency) plus wiring
COMPLEXITY_RULES/HALSTEAD_RULESfor julia and solidity. This issue tracks the remaining three items from #2312's original scope, none of which are mechanical rules ports:1. Pattern-matching branch-counting design (haskell, ocaml, ocaml-interface, fsharp, fsharp-signature, gleam, clojure, erlang)
These languages need a design decision on what counts as a "branch" for pattern-match/guard constructs (an N-arm
match/caseexpression, guard clauses, etc.) before anyComplexityRules/HalsteadRulescan be written. Per #2312's original body: "needs its own design doc given 'what counts as a branch for an N-arm pattern match' needs to be decided once and applied consistently... rather than re-litigated per language." This should land as a design doc first, then mechanical rules ports for each of the eight languages once the design is settled.2. Verilog
No existing dataflow-rule investigation to build on (unlike r/julia/groovy/solidity, which had prior dataflow work to extend). Needs its own from-scratch grammar investigation — HDL
always/case/ifsemantics differ meaningfully from imperative control flow and don't obviously map onto the existingComplexityRules/HalsteadRulesshape.3. Dart
Blocked on #2182 (function body isn't a child of
function_signature/method_signaturein tree-sitter-dart). Do not attempt until that's fixed.Suggested approach
Tackle the pattern-matching design question as its own design doc first (item 1), since the decision needs to be made once and applied to all eight affected languages rather than re-derived per language. Verilog (item 2) and Dart (item 3, once unblocked) can proceed independently once that design work isn't a prerequisite for them specifically.