[Returned for revision] SE-0077: Improved operator declarations

Joe_Groff · June 23, 2016, 3:24am

Proposal link: swift-evolution/0077-operator-precedence.md at master · apple/swift-evolution · GitHub

Hello Swift Community,

The review of SE-0077: "Improved operator declarations" ran from May 17...23. On June 22, 2016, the core team decided to return the first version of this proposal for revision. The core design proposed is a clear win over the Swift 2 design, but the core team feels that revisions are necessary for usability and consistency with the rest of the language:

- The proposed associativity(left) and precedence(<) syntax for precedence group attributes doesn’t have a precedent elsewhere in Swift. Furthermore, it isn’t clear which relationship < and > correspond to in the precedence syntax. The core team feels that it’s more in the character of Swift to use colon-separated “key-value” syntax, with associativity, strongerThan, and weakerThan keyword labels:

precedencegroup Foo {
  associativity: left
  strongerThan: Bar
  weakerThan: Bas
}

-If “stronger” and “weaker” relationships are both allowed, that would enable different code to express precedence relationships in different, potentially confusing ways. To promote consistency and clarity, the core team recommends the following restriction: Relationships between precedence groups defined within the same module must be expressed exclusively in terms of strongerThan. weakerThan can only be used to extend the precedence graph relative to another module’s groups, subject to the transitivity constraints already described in the proposal. This enforces a consistent style internally within modules defining operators.

- The proposal states that precedence groups live in a separate namespace from other declarations; however, this is unprecedented in Swift, and leads to significant implementation challenges. The core team recommends that precedence groups exist in the same namespace as all Swift declarations. It would be an error to reference a precedence group in value contexts.

- Placing precedence groups in the standard namespace makes the question of naming conventions for precedencegroup declarations important. The core team feels that this is an important issue for the proposal to address. As a starting point, we recommend CamelCase with a -Precedence suffix, e.g. AdditivePrecedence. This is unfortunately redundant in the context of a precedencegroup declaration; however, precedencegroups should be rare in practice, and it adds clarity at the point of use in operator declarations in addition to avoiding naming collisions. The standard library team also requests time to review the proposed names of the standard precedence groups

- This proposal quietly drops the assignment modifier that exists on operators today. This modifier had one important function–an operator marked assignment gets folded into an optional chain, allowing foo?.bar += 2 to work as foo?(.bar += 2) instead of failing to type-check as (foo?.bar) += 2. In practice, all Swift operators currently marked assignment are at the equivalent of the Assignment precedence level, so the core team recommends making this optional chaining interaction a special feature of the Assignment precedence group.

- This proposal also accidentally includes declarations of &&= and ||= operators, which do not exist in Swift today and should not be added as part of this proposal.

Thanks Anton Zhilin for the proposal, and thanks to everyone who participated in the review! I will be taking over from Chris as review manager for the next round of revision.

-Joe

Chris_Lattner · June 23, 2016, 4:56am

One clarification: we still consider this to be in scope for Swift 3. Anton, we would appreciate it if you could revise the proposal, but if not, let us know.

Thanks!

-Chris

···

On Jun 22, 2016, at 8:24 PM, Joe Groff <jgroff@apple.com> wrote:

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Hello Swift Community,

The review of SE-0077: "Improved operator declarations" ran from May 17...23. On June 22, 2016, the core team decided to return the first version of this proposal for revision. The core design proposed is a clear win over the Swift 2 design, but the core team feels that revisions are necessary for usability and consistency with the rest of the language:

xwu · June 23, 2016, 9:24am

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Hello Swift Community,

The review of SE-0077: "Improved operator declarations" ran from May
17...23. On June 22, 2016, the core team decided to *return* the first
version of this proposal for revision. The core design proposed is a clear
win over the Swift 2 design, but the core team feels that revisions are
necessary for usability and consistency with the rest of the language:

- The proposed associativity(left) and precedence(<) syntax for
precedence group attributes doesn’t have a precedent elsewhere in Swift.
Furthermore, it isn’t clear which relationship < and > correspond to in
the precedence syntax. The core team feels that it’s more in the character
of Swift to use colon-separated “key-value” syntax, with associativity,
strongerThan, and weakerThan keyword labels:

precedencegroup Foo {

  associativity: left

  strongerThan: Bar

  weakerThan: Bas

}

-If “stronger” and “weaker” relationships are both allowed, that would
enable different code to express precedence relationships in different,
potentially confusing ways. To promote consistency and clarity, the core
team recommends the following restriction: Relationships between precedence
groups defined within the same module must be expressed exclusively in
terms of strongerThan. weakerThan can only be used to extend
the precedence graph relative to another module’s groups, subject to the
transitivity constraints already described in the proposal. This enforces a
consistent style internally within modules defining operators.

This definitely looks cleaner, but the terminology "stronger" and "weaker"
is pretty non-standard. Typically, precedence is said to be above or below
(equivalently, over or under, higher or lower) or, alternatively, before or
after. IMO, before and after are particularly apt terms for operators,
because `*` having precedence before `+` means precisely that `*` is
evaluated before `+`. It's kind of a mixed metaphor to associate precedence
with being stronger and weaker, though I suppose in life as well the
stronger get to go first in line if they want to...

- The proposal states that precedence groups live in a separate namespace
from other declarations; however, this is unprecedented in Swift, and leads
to significant implementation challenges. The core team recommends
that precedence groups exist in the same namespace as all Swift
declarations. It would be an error to reference a precedence group in value
contexts.

- Placing precedence groups in the standard namespace makes the question
of naming conventions for precedencegroup declarations important. The core
team feels that this is an important issue for the proposal to address. As
a starting point, we recommend CamelCase with a -Precedence suffix, e.g.
AdditivePrecedence. This is unfortunately redundant in the context of a
precedencegroup declaration; however, precedencegroups should be rare in
practice, and it adds clarity at the point of use in operator declarations
in addition to avoiding naming collisions.

Conceptually, precedence groups feel to me like enum cases in a squishy
kind of way, only you're not defining them all in one place. I wonder if
that intuition has wide enough appeal that lowerCamelCase might be more
apt. If you stretch that analogy further, it might make sense for
precedence groups to live in their own namespace as though they're cases
for an unutterable enum.

// A way of thinking about namespacing precedence groups
// Not actually proposed to be a real thing
enum _PrecedenceGroup : Int {
  case assignment = 90, ternary = 100, disjunctive = 110 /* etc. */
}

···

On Wed, Jun 22, 2016 at 10:24 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

The standard library team also requests time to review the proposed names
of the standard precedence groups

- This proposal quietly drops the assignment modifier that exists on
operators today. This modifier had one important function–an operator
marked assignment gets folded into an optional chain, allowing foo?.bar
+= 2 to work as foo?(.bar += 2) instead of failing to type-check as (foo?.bar)
+= 2. In practice, all Swift operators currently marked assignment are at
the equivalent of the Assignment precedence level, so the core team
recommends making this optional chaining interaction a special feature of
the Assignment precedence group.

- This proposal also accidentally includes declarations of &&= and ||= operators,
which do not exist in Swift today and should not be added as part of this
proposal.

Thanks Anton Zhilin for the proposal, and thanks to everyone who
participated in the review! I will be taking over from Chris as review
manager for the next round of revision.

-Joe

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Anton_Zhilin · June 23, 2016, 1:18pm

1. I've revised the proposal to mostly meet the recommendations.

https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-
operator-precedence.md

2. My reaction to the rationale:

precedencegroup Foo {
associativity: left
strongerThan: Bar
weakerThan: Bas
}

I agree with colons, but I would prefer above and below. Anyway, core
team will have at least one more chance to change their mind.

- The proposal states that precedence groups live in a separate
namespace from other declarations; however, this is unprecedented in
Swift, and leads to significant implementation challenges. The core team
recommends that precedence groups exist in the same namespace as all
Swift declarations.

How unfortunate. We will need to discuss naming convention and try not
to add too much visual clutter.

3. I also have a suggestion to discuss.

Under "Joining unrelated precedence groups" I see an algorithm that does
not match anything I've seen in network theory.

My suggestion is to make it a warning, not an error. It will reduce the
pressure on the language and compilers.

When we break down precedence hierarchy in a follow-up proposal,
developers will be able to use a library that will join precedence
groups and make their old code compile, although with warnings.

- Anton

Anton_Zhilin · June 25, 2016, 1:45pm

From the rationale follows that by default, we get the following

precedence group declarations:

precedencegroup RangePrecedence { ... }

Everyone agrees? Any ideas on how to reduce redundancy without adding name
conflicts?

anandabits · June 23, 2016, 2:52pm

1. I've revised the proposal to mostly meet the recommendations.

Thanks continuing to push this forward! I’m really looking forward to this change and hope the revision is met with acceptance.

https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-
operator-precedence.md

2. My reaction to the rationale:

precedencegroup Foo {
  associativity: left
  strongerThan: Bar
  weakerThan: Bas
}

I agree with colons, but I would prefer above and below. Anyway, core
team will have at least one more chance to change their mind.

This is the first time I have encountered the “stronger” and “weaker” terminology in this context. I am curious about the rationale for preferring those.

FWIW, I also prefer `above` and `below`. The terms I am most familiar with in discussing precedence are “higher” and “lower” (and is the vocabulary used here: Order of operations - Wikipedia for example). However, as with `strongerThan` and `weakerThan`, these would require `higherThan` and `lowerThan` in order to read well. `above` and `below` have a strong relationship to that common vocabulary while being more concise because they do not require including a word that only serves to make our code read like a phrase while offering no information.

···

On Jun 23, 2016, at 8:18 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

- The proposal states that precedence groups live in a separate
namespace from other declarations; however, this is unprecedented in
Swift, and leads to significant implementation challenges. The core team
recommends that precedence groups exist in the same namespace as all
Swift declarations.

How unfortunate. We will need to discuss naming convention and try not
to add too much visual clutter.

3. I also have a suggestion to discuss.

Under "Joining unrelated precedence groups" I see an algorithm that does
not match anything I've seen in network theory.

My suggestion is to make it a warning, not an error. It will reduce the
pressure on the language and compilers.

When we break down precedence hierarchy in a follow-up proposal,
developers will be able to use a library that will join precedence
groups and make their old code compile, although with warnings.

- Anton
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Ross_O_Brien · June 23, 2016, 9:35am

I agree that the colon-separated syntax looks cleaner. However, I agree
with Xiaodi about the stronger/weaker terms being less clear (if only
because I associate those terms with memory management in Swift, not
operator precedence). My personal preference would be for something like
'appliedBefore'/'appliedAfter', so for example:

precedencegroup Multiplication
{
appliedBefore: Addition
appliedAfter: Parentheses
}

···

On Thu, Jun 23, 2016 at 10:24 AM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:

On Wed, Jun 22, 2016 at 10:24 PM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Hello Swift Community,

The review of SE-0077: "Improved operator declarations" ran from May
17...23. On June 22, 2016, the core team decided to *return* the first
version of this proposal for revision. The core design proposed is a clear
win over the Swift 2 design, but the core team feels that revisions are
necessary for usability and consistency with the rest of the language:

- The proposed associativity(left) and precedence(<) syntax for
precedence group attributes doesn’t have a precedent elsewhere in Swift.
Furthermore, it isn’t clear which relationship < and > correspond to in
the precedence syntax. The core team feels that it’s more in the character
of Swift to use colon-separated “key-value” syntax, with associativity,
strongerThan, and weakerThan keyword labels:

precedencegroup Foo {

  associativity: left

  strongerThan: Bar

  weakerThan: Bas

}

-If “stronger” and “weaker” relationships are both allowed, that would
enable different code to express precedence relationships in different,
potentially confusing ways. To promote consistency and clarity, the core
team recommends the following restriction: Relationships between precedence
groups defined within the same module must be expressed exclusively in
terms of strongerThan. weakerThan can only be used to extend
the precedence graph relative to another module’s groups, subject to the
transitivity constraints already described in the proposal. This enforces a
consistent style internally within modules defining operators.

This definitely looks cleaner, but the terminology "stronger" and "weaker"
is pretty non-standard. Typically, precedence is said to be above or below
(equivalently, over or under, higher or lower) or, alternatively, before or
after. IMO, before and after are particularly apt terms for operators,
because `*` having precedence before `+` means precisely that `*` is
evaluated before `+`. It's kind of a mixed metaphor to associate precedence
with being stronger and weaker, though I suppose in life as well the
stronger get to go first in line if they want to...

- The proposal states that precedence groups live in a separate namespace
from other declarations; however, this is unprecedented in Swift, and leads
to significant implementation challenges. The core team recommends
that precedence groups exist in the same namespace as all Swift
declarations. It would be an error to reference a precedence group in value
contexts.

- Placing precedence groups in the standard namespace makes the question
of naming conventions for precedencegroup declarations important. The core
team feels that this is an important issue for the proposal to address. As
a starting point, we recommend CamelCase with a -Precedence suffix, e.g.
AdditivePrecedence. This is unfortunately redundant in the context of a
precedencegroup declaration; however, precedencegroups should be rare in
practice, and it adds clarity at the point of use in operator declarations
in addition to avoiding naming collisions.

Conceptually, precedence groups feel to me like enum cases in a squishy
kind of way, only you're not defining them all in one place. I wonder if
that intuition has wide enough appeal that lowerCamelCase might be more
apt. If you stretch that analogy further, it might make sense for
precedence groups to live in their own namespace as though they're cases
for an unutterable enum.
// A way of thinking about namespacing precedence groups
// Not actually proposed to be a real thing
enum _PrecedenceGroup : Int {
  case assignment = 90, ternary = 100, disjunctive = 110 /* etc. */
}
The standard library team also requests time to review the proposed names
of the standard precedence groups

- This proposal quietly drops the assignment modifier that exists on
operators today. This modifier had one important function–an operator
marked assignment gets folded into an optional chain, allowing foo?.bar
+= 2 to work as foo?(.bar += 2) instead of failing to type-check as (foo?.bar)
+= 2. In practice, all Swift operators currently marked assignment are
at the equivalent of the Assignment precedence level, so the core team
recommends making this optional chaining interaction a special feature of
the Assignment precedence group.

- This proposal also accidentally includes declarations of &&= and ||= operators,
which do not exist in Swift today and should not be added as part of this
proposal.

Thanks Anton Zhilin for the proposal, and thanks to everyone who
participated in the review! I will be taking over from Chris as review
manager for the next round of revision.

-Joe

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Anton_Zhilin · June 23, 2016, 9:49am

Good news for me! I will surely submit a pull request today.

- Anton

···

2016-06-23 7:56 GMT+03:00 Chris Lattner <clattner@apple.com>:

On Jun 22, 2016, at 8:24 PM, Joe Groff <jgroff@apple.com> wrote:

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Hello Swift Community,

The review of SE-0077: "Improved operator declarations" ran from May
17...23. On June 22, 2016, the core team decided to *return* the first
version of this proposal for revision. The core design proposed is a clear
win over the Swift 2 design, but the core team feels that revisions are
necessary for usability and consistency with the rest of the language:

One clarification: we still consider this to be in scope for Swift 3.
Anton, we would appreciate it if you could revise the proposal, but if not,
let us know.

Thanks!

-Chris

Ross_O_Brien · June 23, 2016, 3:14pm

I've got another suggestion for the bike shedding, and a question.

The naming suggestion: why not simply 'precedes' and 'succeeds'? This
avoids the conjoined words problem. Then you're just writing
'Multiplication { succeeds: Exponentiation, precedes: Addition }'.

The question: this syntax lets you declare a precedence group C and
position it between two groups A and B in the precedence order. If no
existing precedence relationship exists between A and B when this happens
(I'm assuming neither is imported), then creating C between A and B
implicitly creates that relationship.
Suppose wanted to define C's precedence so its operation preceded both A
and B, or succeeded both A and B. Does that require an explicit declaration
of which of A or B takes precedence? If not, would this be legal?:
'precedencegroup C { strongerThan: A, strongerThan: B }'

···

On Thu, Jun 23, 2016 at 3:52 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

On Jun 23, 2016, at 8:18 AM, Anton Zhilin via swift-evolution < > swift-evolution@swift.org> wrote:

1. I've revised the proposal to mostly meet the recommendations.

Thanks continuing to push this forward! I’m really looking forward to
this change and hope the revision is met with acceptance.

https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-
operator-precedence.md

2. My reaction to the rationale:

precedencegroup Foo {
  associativity: left
  strongerThan: Bar
  weakerThan: Bas
}

I agree with colons, but I would prefer above and below. Anyway, core
team will have at least one more chance to change their mind.

This is the first time I have encountered the “stronger” and “weaker”
terminology in this context. I am curious about the rationale for
preferring those.

FWIW, I also prefer `above` and `below`. The terms I am most familiar
with in discussing precedence are “higher” and “lower” (and is the
vocabulary used here: Order of operations - Wikipedia for
example). However, as with `strongerThan` and `weakerThan`, these would
require `higherThan` and `lowerThan` in order to read well. `above` and
`below` have a strong relationship to that common vocabulary while being
more concise because they do not require including a word that only serves
to make our code read like a phrase while offering no information.

- The proposal states that precedence groups live in a separate
namespace from other declarations; however, this is unprecedented in
Swift, and leads to significant implementation challenges. The core team
recommends that precedence groups exist in the same namespace as all
Swift declarations.

How unfortunate. We will need to discuss naming convention and try not
to add too much visual clutter.

3. I also have a suggestion to discuss.

Under "Joining unrelated precedence groups" I see an algorithm that does
not match anything I've seen in network theory.

My suggestion is to make it a warning, not an error. It will reduce the
pressure on the language and compilers.

When we break down precedence hierarchy in a follow-up proposal,
developers will be able to use a library that will join precedence
groups and make their old code compile, although with warnings.

- Anton
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

L_Mihalkovic · June 23, 2016, 5:12pm

Has a meta-circular syntax been considered for the precedence group definitions? Aside from limiting the proliferation of new keywords, it would also make them discoverable by reflection when the api gets added in 4.0. My apologies if it was already discarded.
Regards
LM
(From mobile)

···

On Jun 23, 2016, at 3:18 PM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

1. I've revised the proposal to mostly meet the recommendations.

https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-
operator-precedence.md

2. My reaction to the rationale:

precedencegroup Foo {
  associativity: left
  strongerThan: Bar
  weakerThan: Bas
}

I agree with colons, but I would prefer above and below. Anyway, core
team will have at least one more chance to change their mind.

- The proposal states that precedence groups live in a separate
namespace from other declarations; however, this is unprecedented in
Swift, and leads to significant implementation challenges. The core team
recommends that precedence groups exist in the same namespace as all
Swift declarations.

How unfortunate. We will need to discuss naming convention and try not
to add too much visual clutter.

3. I also have a suggestion to discuss.

Under "Joining unrelated precedence groups" I see an algorithm that does
not match anything I've seen in network theory.

My suggestion is to make it a warning, not an error. It will reduce the
pressure on the language and compilers.

When we break down precedence hierarchy in a follow-up proposal,
developers will be able to use a library that will join precedence
groups and make their old code compile, although with warnings.

- Anton
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · June 25, 2016, 2:30pm

I mean, we have `protocol IteratorProtocol`, so this is par for the course!

···

On Sat, Jun 25, 2016 at 09:46 Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote:

From the rationale follows that by default, we get the following
precedence group declarations:

precedencegroup RangePrecedence { ... }

Everyone agrees? Any ideas on how to reduce redundancy without adding name
conflicts?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

dabrahams · June 28, 2016, 6:02pm

Although I was the one who suggested “stronger/weaker”, on reflection I
think “higher/lower” are the most standard terms here.

···

on Thu Jun 23 2016, Xiaodi Wu <swift-evolution@swift.org> wrote:

On Wed, Jun 22, 2016 at 10:24 PM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Hello Swift Community,

The review of SE-0077: "Improved operator declarations" ran from May
17...23. On June 22, 2016, the core team decided to *return* the first
version of this proposal for revision. The core design proposed is a clear
win over the Swift 2 design, but the core team feels that revisions are
necessary for usability and consistency with the rest of the language:

- The proposed associativity(left) and precedence(<) syntax for
precedence group attributes doesn’t have a precedent elsewhere in Swift.
Furthermore, it isn’t clear which relationship < and > correspond to in
the precedence syntax. The core team feels that it’s more in the character
of Swift to use colon-separated “key-value” syntax, with associativity,
strongerThan, and weakerThan keyword labels:

precedencegroup Foo {

  associativity: left

  strongerThan: Bar

  weakerThan: Bas

}

-If “stronger” and “weaker” relationships are both allowed, that would
enable different code to express precedence relationships in different,
potentially confusing ways. To promote consistency and clarity, the core
team recommends the following restriction: Relationships between precedence
groups defined within the same module must be expressed exclusively in
terms of strongerThan. weakerThan can only be used to extend
the precedence graph relative to another module’s groups, subject to the
transitivity constraints already described in the proposal. This enforces a
consistent style internally within modules defining operators.

This definitely looks cleaner, but the terminology "stronger" and "weaker"
is pretty non-standard. Typically, precedence is said to be above or below
(equivalently, over or under, higher or lower) or, alternatively, before or
after.

--
Dave

glessard · June 23, 2016, 4:44pm

How about `before` and `after`, then?

(altitude is not precedence)

This truly is a precedence relationship, and expressing it using height relationships isn’t particularly useful. What we need to express is that when there is possible ambiguity between two operators, which one should be used first? Obviously, it’s the one that comes “before”, or perhaps the one that “precedes” the other.

Cheers,
Guillaume Lessard

···

On 23 juin 2016, at 09:32, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

Ross O'Brien via swift-evolution <swift-evolution@...> writes:

The naming suggestion: why not simply 'precedes' and 'succeeds'? This

avoids the conjoined words problem. Then you're just writing
'Multiplication { succeeds: Exponentiation, precedes: Addition }'.

I still believe that `above` and `below` are clearer.

griotspeak · June 23, 2016, 4:13pm

If we chose something other than strongerThan and weakerThan, I would
really like to see something like

evaluateBefore, evaluateAfter
foundBefore, foundAfter
lookupBefore, lookupAfter

···

On Thu, Jun 23, 2016 at 11:32 AM, Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote:

Ross O'Brien via swift-evolution <swift-evolution@...> writes:

> The naming suggestion: why not simply 'precedes' and 'succeeds'? This
avoids the conjoined words problem. Then you're just writing
'Multiplication { succeeds: Exponentiation, precedes: Addition }'.

I still believe that `above` and `below` are clearer.

> Suppose wanted to define C's precedence so its operation preceded both A
and B, or succeeded both A and B. Does that require an explicit
declaration of which of A or B takes precedence? If not, would this be
legal?:
> 'precedencegroup C { strongerThan: A, strongerThan: B }'

Any number of strongerThan and weakerThan relationships should be legal.
Order of these relationships does not matter. We model them as edges of a
DAG of all declared operators.

There will be no problems during parsing. For example,
Shunting yard algorithm - Wikipedia
only requests equality and less-than relationships between two operators.

- Anton

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Anton_Zhilin · June 23, 2016, 3:32pm

Ross O'Brien via swift-evolution <swift-evolution@...> writes:

The naming suggestion: why not simply 'precedes' and 'succeeds'? This

avoids the conjoined words problem. Then you're just writing
'Multiplication { succeeds: Exponentiation, precedes: Addition }'.

I still believe that `above` and `below` are clearer.

Suppose wanted to define C's precedence so its operation preceded both A

and B, or succeeded both A and B. Does that require an explicit
declaration of which of A or B takes precedence? If not, would this be
legal?:

'precedencegroup C { strongerThan: A, strongerThan: B }'

Any number of strongerThan and weakerThan relationships should be legal.
Order of these relationships does not matter. We model them as edges of a
DAG of all declared operators.

There will be no problems during parsing. For example,

only requests equality and less-than relationships between two operators.

- Anton

Anton_Zhilin · June 23, 2016, 8:13pm

L. Mihalkovic via swift-evolution <swift-evolution@...> writes:

Has a meta-circular syntax been considered for the precedence group

definitions? Aside from limiting the

proliferation of new keywords, it would also make them discoverable by

reflection when the api gets added

in 4.0. My apologies if it was already discarded.
Regards
LM

Could you please explain what you mean by "meta-circular syntax for the
precedence group definitions"? An example?

Anton_Zhilin · June 25, 2016, 3:33pm

Xiaodi Wu via swift-evolution <swift-evolution@...> writes:

I mean, we have `protocol IteratorProtocol`, so this is par for the

course!

precedencegroup RangePrecedence { ... }

Brandon sent me a bright idea: we should rename precedencegroup to
precedence. Compare:

precedence RangePrecedence { ... }
protocol IteratorProtocol { ... }

This is not totally new, but Precedence suffix and comparison to protocols
is what makes it shine. Anyone else like the idea?

L_Mihalkovic · June 24, 2016, 3:35am

Inline
Regards
(From mobile)

L. Mihalkovic via swift-evolution <swift-evolution@...> writes:

Has a meta-circular syntax been considered for the precedence group

definitions? Aside from limiting the

proliferation of new keywords, it would also make them discoverable by

reflection when the api gets added

in 4.0. My apologies if it was already discarded.
Regards
LM

Could you please explain what you mean by "meta-circular syntax for the
precedence group definitions"? An example?

=define it using existing swift constructs rather than by extending swift with new kwd looks like grp matches a struct.

···

On Jun 23, 2016, at 10:13 PM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · June 25, 2016, 4:03pm

Yes!

···

On Sat, Jun 25, 2016 at 11:33 Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote:

Xiaodi Wu via swift-evolution <swift-evolution@...> writes:

> I mean, we have `protocol IteratorProtocol`, so this is par for the
course!
> precedencegroup RangePrecedence { ... }

Brandon sent me a bright idea: we should rename precedencegroup to
precedence. Compare:

precedence RangePrecedence { ... }
protocol IteratorProtocol { ... }

This is not totally new, but Precedence suffix and comparison to protocols
is what makes it shine. Anyone else like the idea?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Anton_Zhilin · June 24, 2016, 12:47pm

L. Mihalkovic via swift-evolution <swift-evolution@...> writes:

> Could you please explain what you mean by "meta-circular syntax for

the

> precedence group definitions"? An example?
=define it using existing swift constructs rather than by extending

swift with new kwd looks like grp

matches a struct.

I still don't fully understand without an example :(
If you mean something like this:

protocol PrecedenceGroup_Additive {
associatedtype StrongerThan_Comparative
associatedtype WeakerThan_Multiplicative
}

Then this is just ugly.