Skip to content

[CHANGE] Type namespace != Function/Procedure/Variable namespace#96

Closed
Sir-NoChill wants to merge 6 commits into
masterfrom
spec/unify-namespaces
Closed

[CHANGE] Type namespace != Function/Procedure/Variable namespace#96
Sir-NoChill wants to merge 6 commits into
masterfrom
spec/unify-namespaces

Conversation

@Sir-NoChill

Copy link
Copy Markdown
Collaborator

This is a suggestion also pulled from my other PR just to clarify the naming rules on structs. I propose that type names live in a different namespace to the rest of the named statements in gazprea.

That means that things like

typealias main = integer;
struct foo (main a, main b);

procedure main() returns integer { ... }
function foo() returns foo { ... }

would be legal. This deviates from what we did last year with structs sharing the function namespace due to declaration syntax. To that effect, I propose that we change struct declaration syntax but that can live in another PR, or if this seems like a sensible idea I could merge it into this one.

Introduce spec/namespaces.rst as the single source of truth for Gazprea's
namespace rules: a type namespace (structs, typealiases) and a separate
variable/function/procedure namespace. Subsequent commits remove the
conflicting per-file descriptions that this page replaces.
Add spec/namespaces to the Language Specification toctree, immediately after
identifiers, so the new page is included in the rendered docs.
The Namespaces section in identifiers.rst described a one-namespace model in
which struct literals shared the function namespace, contradicting the
two-namespace model used elsewhere. Replace it with a cross-reference to the
canonical spec/namespaces page. No remaining references to the removed
ssec:namespace label exist.
State that structs live in the type namespace and never conflict with
variables, functions, or procedures, replacing the old claim that structs
share the function and procedure namespaces. Rename the section label from the
duplicated ssec:function_namespacing to ssec:struct_namespacing to remove the
ambiguous-label collision (one of three identical definitions).
Replace the claim that functions share the struct and procedure namespaces with
the correct rule: functions and procedures share one namespace and do not
conflict with types. The section label ssec:function_namespacing is retained and
is now unique after the struct section was renamed.
Replace the claim that procedures share the struct and function namespaces with
the correct rule: procedures and functions share one namespace and do not
conflict with types. Rename the section label from the duplicated
ssec:function_namespacing to ssec:procedure_namespacing, removing the last of
the three colliding label definitions.
@Sir-NoChill Sir-NoChill requested review from novo52 and rcunrau June 22, 2026 17:30
@rcunrau

rcunrau commented Jun 29, 2026 via email

Copy link
Copy Markdown
Collaborator

@novo52

novo52 commented Jun 29, 2026

Copy link
Copy Markdown

I can't remember what we gain/lose by making this change. I know we discussed it - did we also document our thoughts?

Benefit:

  • Matches the conventions of existing C-like languages
  • struct literals will look nicer (as they now must, to be unambiguous), having member names in the literals.
    Detriment:
  • Students have to make namespaces? IDK if this is actually a detriment

See my commit
The "after" contains a nice example of what is and is not allowed; ignore the "before"—it was an earlier revision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants