Really interesting, as your comments usually are. I've started diving into type
theory and things you, @timothee and others have contributed are part of the
reason.
A modification proposal: the minimal one-pragma approach is elegant, but let's
not break import visibility semantics: the meaning of `*` could remain as it is
and one could pass an optional parameter to `prototype` to denote extensibility:
`{.prototype(open).}`
or
`{.prototype(extensible).}`
These could also be valid inside the defining module.
A general thought: prototypical/exemplary definitions seem to go against most
peoples' intuition in the context of statically typed languages. It feels
JavaScript-y. Comparable to the witness construct you proposed during the
discussion about symbol aliases started by @timothee. Back then I felt that
supplying "explanatory example code" to the compiler sounded really weird. But
now I think that that was irrational, especially with meta-programming making
generating various kinds of types possible, at least in principle.
If it was easier to experiment with types, people could get creative and I
believe some substantial practical progress could be made. A DSL for type
calculus and transformation rules which produces the compiler code for type
verification and resolution and defines new type implementations with Nim's
existing types as building blocks; is that a pipe dream or a realistic goal?
