Skip to content

Add details to "Missing Selector Annotation error" section #438

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

Closed
wants to merge 4 commits into from
Closed

Add details to "Missing Selector Annotation error" section #438

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
5e73fad
Add details to "Missing Selector Annotation error" section:
catamorphism Jul 24, 2023
a9427ca
Apply suggestions from code review
catamorphism Jul 24, 2023
65bded4
Add details to "Missing Selector Annotation error" section:
catamorphism Jul 24, 2023
3f4e63f
Re-word 'Missing Selector Annotation error' section and remove valid …
catamorphism Jul 27, 2023
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
19 changes: 9 additions & 10 deletions spec/formatting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -677,8 +677,14 @@ These are divided into the following categories:
> ```

- A **_Missing Selector Annotation error_** is an error that occurs when the _message_
contains a _selector_ that does not have an _annotation_,
or contains a _variable_ that does not directly or indirectly reference a _declaration_ with an _annotation_.
contains a _selector_ without an _annotation_.

An implementation MUST NOT emit this error for a _selector_ _expression_
that would have an _annotation_
if each local _variable_ in it were replaced
with the _expression_ of its binding _declaration_,
repeating this process until the _expression_
contains no local _variable_s.
Copy link
Collaborator

Choose a reason for hiding this comment

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

This approach is a bit problematic because option values cannot be expressions, and this is clearly including their replacement as well.

@stasm This is an example of a situation where aligning our data model closely with our syntax is making it more difficult to speak about it. If we went the other way than proposed in #436 and e.g. defined a variable expression in the data model, we could use that term here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@eemeli I see your point.

The validity property is easy to express in terms of types:

The type of a local _variable_ is the type of the _expression_ in its _declaration_.
The type of an external variable is `Unannotated`.

The type of an _expression_ is:
* `Annotated` if the _expression_ has an _annotation_.
* `Annotated` if the _operand_ of the expression is a _variable_ whose type is `Annotated`.
* `Unannotated` otherwise.

A `selector` must have type `Annotated`.

I'm not sure how this language would be received, but we are talking about a static dataflow property, whether or not we call it that :)

I also agree that it would be easier to write an unambiguous specification if the object language was the language described by the abstract syntax, rather than the concrete syntax.


> Example invalid messages resulting in a _Missing Selector Annotation error_:
Copy link
Member

Choose a reason for hiding this comment

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

Making the wording flow a bit better

Suggested change
> Example invalid messages resulting in a _Missing Selector Annotation error_:
> **Example**.
> Here are some invalid _messages_ that would result in a _Missing Selector Annotation error_:

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This text is modeled on the existing text for the other kinds of data model errors. Perhaps a separate PR could add this change in a way that's consistent for all the error descriptions?

Copy link
Member

Choose a reason for hiding this comment

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

We should discuss styling as a group. I'm considering creating a style guide (beyond the minimal guidance in README.md)

>
Expand All @@ -695,15 +701,8 @@ These are divided into the following categories:
> when * {Value is not one}
> ```
>
> ```
> let $one = {|The one| :func}
> let $two = {$one}
> match {$two}
> when 1 {Value is one}
> when * {Value is not one}
> ```

- **Duplicate Option Name errors** occur when the same _name_
- **Duplicate Option Name errors** occur when the same _name_
appears on the left-hand side
of more than one _option_ in the same _expression_.

Expand Down