Skip to content

Clarify option literalness details #1027

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Feb 21, 2025
Merged

Clarify option literalness details #1027

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
42126aa
Clarify option literalness details
gibson042 Feb 20, 2025
3877131
Reword description of option value literalness information
gibson042 Feb 20, 2025
cd79606
Update spec/formatting.md
aphillips Feb 20, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion spec/formatting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -140,6 +140,7 @@ from the surrounding text.
To allow for _function handlers_ to ensure that certain _option_ values are set by _literals_,
the _resolved value_ of each _option_ value MUST include information about
whether the _option_ value is a _literal_ or a _variable_.
Note that this information is irrelevant for a _resolved value_ that is not used as the value of an _option_.
Copy link
Collaborator

@eemeli eemeli Feb 20, 2025

Choose a reason for hiding this comment

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

Hmm. Is it perhaps not clear that "option value" is a syntax feature? This phrase seems to imply that a resolved value could be an option value, and that doesn't really make sense.

We probably ought to explicitly define option value as a term in the Syntax section.

Copy link
Member

@macchiati macchiati Feb 20, 2025

Choose a reason for hiding this comment

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

We probably ought to explicitly define option value as a term in the Syntax section.

Absolutely!

Copy link
Member

@aphillips aphillips Feb 20, 2025

Choose a reason for hiding this comment

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

Let's do that in a separate PR.


The form that _resolved values_ take is implementation-dependent,
and different implementations MAY choose to perform different levels of resolution.
Expand Down Expand Up @@ -329,6 +330,7 @@ the following steps are taken:

6. If the call succeeds,
resolve the value of the _expression_ as the result of that function call.
The value MUST NOT be marked as a literal option value.

If the call fails or does not return a valid value,
emit the appropriate _Message Function Error_ for the failure.
Expand Down Expand Up @@ -395,7 +397,7 @@ For each _option_:
1. If supported, emit a _Bad Option_ error.
1. Else:
1. If the _option_ value consists of a _literal_:
1. Include that information in `rv`.
1. Mark `rv` as a literal option value.
Copy link
Member

@aphillips aphillips Feb 20, 2025

Choose a reason for hiding this comment

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

I like this wording change very much

Copy link
Collaborator

@eemeli eemeli Feb 20, 2025

Choose a reason for hiding this comment

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

This change does seem good.

1. Set `res[id]` to be `rv`.
1. Return `res`.

Expand Down