Skip to content

Syntax and validation for struct.new_desc#101

Open
tlively wants to merge 7 commits into
exact-heaptype-refactorfrom
struct-new-desc-syntax-validation
Open

Syntax and validation for struct.new_desc#101
tlively wants to merge 7 commits into
exact-heaptype-refactorfrom
struct-new-desc-syntax-validation

Conversation

@tlively

@tlively tlively commented Jul 7, 2026

Copy link
Copy Markdown
Member

And struct.new_default_desc. Also update the valiation for struct.new and struct.new_default to require empty descriptors. Add an explanation of expansion to desctype to the validation conventions section and teach SpecTec about the new ExpandDesc relation to avoid errors during rendering.

And struct.new_default_desc. Also update the valiation for struct.new and struct.new_default to require empty descriptors. Add an explanation of expansion to desctype to the validation conventions section and teach SpecTec about the new ExpandDesc relation to avoid errors during rendering.
@tlively
tlively requested a review from rossberg July 7, 2026 03:36
@rossberg

rossberg commented Jul 7, 2026

Copy link
Copy Markdown
Member

Heads-up: busy with POPL deadline, will review next week.

@tlively

tlively commented Jul 7, 2026

Copy link
Copy Markdown
Member Author

Sounds good, thanks for the heads up. I'll continue to upload PRs, but no rush on the reviews.

@tlively tlively mentioned this pull request Jul 7, 2026
51 tasks
@tlively
tlively changed the base branch from main to refactor-exact-types July 14, 2026 14:11
@tlively
tlively changed the base branch from refactor-exact-types to exact-heaptype-refactor July 14, 2026 14:13

@rossberg rossberg left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of nits below, but I think they are actually moot considering the following more important question:

I'm not sure why we need both Expand and ExpandDesc instead of merely modifying the existing Expand. As defined, Expand: deftype ~~ comptype and ExpandDesc: deftype ~~ comptype actually are equivalent (the latter pattern-matching describestype? descriptortype? as both empty).

(One motivation to have both might be to avoid a lot of clutter in the future, should we allow describes on more types than just structs — instead of matching describestype? descriptortype? all over the place, the existing Expand could be a shorthand building that in. However, in that case we'd need different notation, or rendered "deftype ≈ comptype" could ambiguously mean either expanding to a the underlying comptype via Expand, ignoring the desc clauses, or expanding to a desctype with empty desc clause via ExpandDesc.)

In addition, I think you missed a bunch of uses of Expand on structs in 7.1.

$${relation-ignore: Expand Expand_use}
$${definition-ignore: expanddt}

We use the same notation to denote the expansion of a :ref:`defined type <syntax-deftype>` or :ref:`type use <syntax-typeuse>` to a :ref:`desctype <syntax-desctype>` as well.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to avoid the first-person "we" in the spec. Just say "The same notation also denotes...".

relation ExpandDesc: deftype ~~ desctype hint(macro "%expanddt_to_desctype") hint(tabular)
hint(prose "The :ref:`expansion <aux-expand-deftype-to-desctype>` of %1 is %2") ;; TODO(3, ?): avoid hardcoding reST

rule ExpandDesc: deftype ~~ desctype -- if $expanddt_to_desctype(deftype) = desctype

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: for consistency

Suggested change
rule ExpandDesc: deftype ~~ desctype -- if $expanddt_to_desctype(deftype) = desctype
rule Expand_desc: deftype ~~ desctype -- if $expanddt_to_desctype(deftype) = desctype

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.

2 participants