Skip to content

Silent op-name shadowing: bare lt/eq resolve to String foreigns, add/sub to Nat defns — wrong types in HOFs instead of errors #72

Description

@hierophantos

Found by the N6e-E5 grounding audit (probe-verified at HEAD fbf44e29); worse than the unbound-op class because it produces silently wrong resolution, not an error.

Symptom

  • Bare lt / eq in value position resolve to the String foreign fns (lib/prologos/data/string.prologos:11-12 declares string<?/string=? :as lt/:as eq), so [filter lt xs] over numbers gets a String -> String -> Bool value — a type error at best, silent nonsense at worst.
  • Bare add / sub resolve to Nat-specific defns, not the generic trait methods (which are derive-skipped, Spec-store bare-name keying: same-named specs from different modules silently clobber #66).
  • These never reach the unbound-variable fallback, so the E5.3 hint machinery structurally cannot cover them.

Why it matters

Post-N6e the ergonomic spellings (+, -, ord-lt, keyword sections) exist — but a user writing the plausible lt/eq/add gets shadowed silently instead of guided. This is a namespace/shadowing design question (who owns short op names; should stdlib foreigns claim them; bare-name resolution priority), not a diagnostics quickie — deliberately NOT folded into N6e-E5.

Pointers

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions