-
-
Notifications
You must be signed in to change notification settings - Fork 35
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.
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
Changes from all commits
5e73fad
a9427ca
65bded4
3f4e63f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||
---|---|---|---|---|---|---|---|---|
|
@@ -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. | ||||||||
|
||||||||
> Example invalid messages resulting in a _Missing Selector Annotation error_: | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Making the wording flow a bit better
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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) |
||||||||
> | ||||||||
|
@@ -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_. | ||||||||
|
||||||||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
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.