The fact that they’re extensible records seems (almost) the whole point, otherwise you can just use Coq modules. “Open” namespaces _can_ be encoded in Coq, exploiting its lookup rules — much more easily than anything in math-comp, and I do it by hand, but it’s still annoying.
Yeah, not sure I understand the 'not being extensible thing'. I'm sort of thinking of namespaces like in Lean, C++, etc. Like you can split namespaces over multiple files and build them up incrementally. But we might be talking about different things?
One thing I want to figure out is a nice way to scope data constructors under the name of a type, like in Rust and Lean. Would be cool to have some sort of systematic approach to extending 'paths' like this, but I dunno what that would look like…
Like, I kind of think of the 'path' as like a 'bookmark' that makes it easy for the programmer to find stuff in a sort of soup of nodes… like, it's more of a user interface thing? I dunno though
A joy of a dependently-typed language is that first-class abstractions don't just have a cost at runtime (which can be optimized away), but also at proof time. And now your inliner is a piece of ltac or proof automation, that is either way a cost.
Wanted: partial evaluation and staging for proof search.
And I don't mean the idealized proof search of a logic, but the one from a proof assistant, and one supporting domain-specific proof automation.