[Review] SE-0077: Improved operator declarations

Updated the proposal:

I included many of alternate solutions. Please, reply, if I missed any.

Still I do not hurry to swap any of alternate solution with syntax used
throughout the proposal, although many of them are objectively better.

- Anton

···

2016-05-21 1:17 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 5:06 PM, Brandon Knope <bknope@me.com> wrote:

On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:

My working version is still the one in the proposal, but I'm planning to
add the alternative versions we discussed, including your and Brent's
variants.

IMHO, original version is heavy, but clear (not to confuse with "clean").
Your lighter version looks more clean, but somewhat less consistent and
more free in terms of grammar.

Also, I've got another version, which is considerably ligher than current
one, while being as structured:

precedence Multiplicative {
    associativity(left)
    above(Additive)
    below(Exponentiative)
}

Why not:

precedence Multiplicative {
    associativity left
    above Additive
    below Epxonentiative
}

Just seeing if removing the parens reduces some of the noise.

I would be happy with this. It is almost the same as what I had
suggested, just using > and < rather than above and below (because that was
what the proposal was using). Using words instead is fine with me. The
parens are my biggest objection in this version. In the original version I
also didn’t like the verbosity of `precedencegroup` and the redundant
statement `precedence` inside the braces.

Sorry if I missed this suggestion earlier and it was denied :P

Brandon

- Anton

2016-05-21 0:25 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

Yes, in this case it should be allowed, because this relationship already
existed in imported modules. I will add that, too, thanks!

Cool.

What is the latest syntax you are using? Did you consider any of the
lighter weight options? That subthread died without conclusion (unless I
missed something somehow).

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com>:

The transitivity rule plus the ability to define precedence
relationships in both directions on a new precedence group allows a new
precedence group to create a precedence relationship between existing
unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope
relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship
between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define
relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships
between standard precedence groups that are confusing for the reader.

====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A
(it would not be defining a *new* relationship between A and C in that
case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment

and Ternary groups.

Do you mean that most operators should define greater precedence than
Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

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

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

I included many of alternate solutions. Please, reply, if I missed any.

Still I do not hurry to swap any of alternate solution with syntax used throughout the proposal, although many of them are objectively better.

Looks good. I really hope we do go with one of the better syntax forms though.

The one thing I don't like is "upper" and "lower". Those don't make sense to me in this context. Any of < and >, above and below, greaterThan and lessThan, gt and lt would be better IMO.

···

Sent from my iPad

On May 21, 2016, at 7:48 AM, Антон Жилин <antonyzhilin@gmail.com> wrote:

- Anton

2016-05-21 1:17 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 5:06 PM, Brandon Knope <bknope@me.com> wrote:

On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

My working version is still the one in the proposal, but I'm planning to add the alternative versions we discussed, including your and Brent's variants.

IMHO, original version is heavy, but clear (not to confuse with "clean"). Your lighter version looks more clean, but somewhat less consistent and more free in terms of grammar.

Also, I've got another version, which is considerably ligher than current one, while being as structured:

precedence Multiplicative {
    associativity(left)
    above(Additive)
    below(Exponentiative)
}

Why not:

precedence Multiplicative {
    associativity left
    above Additive
    below Epxonentiative
}

Just seeing if removing the parens reduces some of the noise.

I would be happy with this. It is almost the same as what I had suggested, just using > and < rather than above and below (because that was what the proposal was using). Using words instead is fine with me. The parens are my biggest objection in this version. In the original version I also didn’t like the verbosity of `precedencegroup` and the redundant statement `precedence` inside the braces.

Sorry if I missed this suggestion earlier and it was denied :P

Brandon

- Anton

2016-05-21 0:25 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

Yes, in this case it should be allowed, because this relationship already existed in imported modules. I will add that, too, thanks!

Cool.

What is the latest syntax you are using? Did you consider any of the lighter weight options? That subthread died without conclusion (unless I missed something somehow).

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com>:

The transitivity rule plus the ability to define precedence relationships in both directions on a new precedence group allows a new precedence group to create a precedence relationship between existing unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships between standard precedence groups that are confusing for the reader.
====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A (it would not be defining a *new* relationship between A and C in that case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment and Ternary groups.

Do you mean that most operators should define greater precedence than Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

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

Looking real good (especially the alternative section :P)!

What's the rationale for using upper and lower?

My objection to this is how it can be read: "precedence addition associativity left upper XXX lower XXX"

I think upper and lower kind of break the flow of how it is read.

This seems clearer (when read as you are skimming code): "precedence addition associativity left above XXX below XXX"

While I'm at it...might I suggest something controversial?

associativity -> associate

Example when read: "precedence addition associate left above XXX below XXX"

Reads pretty nice I think.

Brandon

···

On May 21, 2016, at 8:48 AM, Антон Жилин <antonyzhilin@gmail.com> wrote:

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

I included many of alternate solutions. Please, reply, if I missed any.

Still I do not hurry to swap any of alternate solution with syntax used throughout the proposal, although many of them are objectively better.

- Anton

2016-05-21 1:17 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 5:06 PM, Brandon Knope <bknope@me.com> wrote:

On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

My working version is still the one in the proposal, but I'm planning to add the alternative versions we discussed, including your and Brent's variants.

IMHO, original version is heavy, but clear (not to confuse with "clean"). Your lighter version looks more clean, but somewhat less consistent and more free in terms of grammar.

Also, I've got another version, which is considerably ligher than current one, while being as structured:

precedence Multiplicative {
    associativity(left)
    above(Additive)
    below(Exponentiative)
}

Why not:

precedence Multiplicative {
    associativity left
    above Additive
    below Epxonentiative
}

Just seeing if removing the parens reduces some of the noise.

I would be happy with this. It is almost the same as what I had suggested, just using > and < rather than above and below (because that was what the proposal was using). Using words instead is fine with me. The parens are my biggest objection in this version. In the original version I also didn’t like the verbosity of `precedencegroup` and the redundant statement `precedence` inside the braces.

Sorry if I missed this suggestion earlier and it was denied :P

Brandon

- Anton

2016-05-21 0:25 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

Yes, in this case it should be allowed, because this relationship already existed in imported modules. I will add that, too, thanks!

Cool.

What is the latest syntax you are using? Did you consider any of the lighter weight options? That subthread died without conclusion (unless I missed something somehow).

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com>:

The transitivity rule plus the ability to define precedence relationships in both directions on a new precedence group allows a new precedence group to create a precedence relationship between existing unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships between standard precedence groups that are confusing for the reader.
====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A (it would not be defining a *new* relationship between A and C in that case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment and Ternary groups.

Do you mean that most operators should define greater precedence than Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

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

Sorry, "upper" and "lower" was my mistake that I copy-pasted all over the
place. Just in case, I added those alternate word variants, as well.

- Anton

···

2016-05-21 16:31 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

Sent from my iPad

On May 21, 2016, at 7:48 AM, Антон Жилин <antonyzhilin@gmail.com> wrote:

Updated the proposal:

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

I included many of alternate solutions. Please, reply, if I missed any.

Still I do not hurry to swap any of alternate solution with syntax used
throughout the proposal, although many of them are objectively better.

Looks good. I really hope we do go with one of the better syntax forms
though.

The one thing I don't like is "upper" and "lower". Those don't make sense
to me in this context. Any of < and >, above and below, greaterThan and
lessThan, gt and lt would be better IMO.

- Anton

2016-05-21 1:17 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 5:06 PM, Brandon Knope <bknope@me.com> wrote:

On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution < >> swift-evolution@swift.org> wrote:

My working version is still the one in the proposal, but I'm planning to
add the alternative versions we discussed, including your and Brent's
variants.

IMHO, original version is heavy, but clear (not to confuse with "clean").
Your lighter version looks more clean, but somewhat less consistent and
more free in terms of grammar.

Also, I've got another version, which is considerably ligher than current
one, while being as structured:

precedence Multiplicative {
    associativity(left)
    above(Additive)
    below(Exponentiative)
}

Why not:

precedence Multiplicative {
    associativity left
    above Additive
    below Epxonentiative
}

Just seeing if removing the parens reduces some of the noise.

I would be happy with this. It is almost the same as what I had
suggested, just using > and < rather than above and below (because that was
what the proposal was using). Using words instead is fine with me. The
parens are my biggest objection in this version. In the original version I
also didn’t like the verbosity of `precedencegroup` and the redundant
statement `precedence` inside the braces.

Sorry if I missed this suggestion earlier and it was denied :P

Brandon

- Anton

2016-05-21 0:25 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

Yes, in this case it should be allowed, because this relationship
already existed in imported modules. I will add that, too, thanks!

Cool.

What is the latest syntax you are using? Did you consider any of the
lighter weight options? That subthread died without conclusion (unless I
missed something somehow).

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com> >>>> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com>:

The transitivity rule plus the ability to define precedence
relationships in both directions on a new precedence group allows a new
precedence group to create a precedence relationship between existing
unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope
relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create
relationship between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define
relationship between imported groups A and C".
The rationale behind this is that otherwise one can create
relationships between standard precedence groups that are confusing for the
reader.

====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C >
A (it would not be defining a *new* relationship between A and C in that
case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment

and Ternary groups.

Do you mean that most operators should define greater precedence than
Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

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

@CoreTeam Please, don't forget to merge pull request with fixes and
alternatives from review period.

@AnyoneElse Today is (formally) the last day of review. It may be your last
chance!

Apple repo link:

My repo with some latest changes:

- Anton

If we're going to go with words, how about "before" and "after"

As in "The Multiplicitive precedence group gets evaluated before Additive
and after Exponentiative"

···

On Mon, May 23, 2016 at 4:10 PM, Антон Жилин <swift-evolution@swift.org> wrote:

@CoreTeam Please, don't forget to merge pull request with fixes and
alternatives from review period.

@AnyoneElse Today is (formally) the last day of review. It may be your
last chance!

Apple repo link:

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

My repo with some latest changes:

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

- Anton

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

Thanks for doing this. While I’m a little apprehensive about the implementation, I don’t expect it to be a problem in practice; a DAG is a pretty safe data structure, and the size of the graph (i.e. the number of precedence groups in a program) probably won’t be that big in practice. And it’s so much better than arbitrary precedence numbers.

To discuss later: what are the naming guidelines for precedence groups? (What part of speech? Why UpperCamelCase?) Are they in a separate scope from normal names? Can you qualify them with module names?

(Operator declarations in general are weirdly global right now, because they need to be resolvable without doing full lookup work, and because it was easier to implement them that way. So making precedence groups special as well is probably fine, at least for now.)

Jordan

···

On May 23, 2016, at 13:10, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

@CoreTeam Please, don't forget to merge pull request with fixes and alternatives from review period.

@AnyoneElse Today is (formally) the last day of review. It may be your last chance!

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

My repo with some latest changes:
https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-operator-precedence.md

While I’m a little apprehensive about the implementation

It was simple in the beginning, then two additions were made:
1. Global transitivity checking
2. Precedence relationships that, by transitivity rule, create relationship
between two imported groups, is an error (John McCall)

I don't know how to do any of these checks without nxn connectivity table.
Is that even possible?

Are they in a separate scope from normal names?

Yes, otherwise Range would be a conflict with standard library structure.

Can you qualify them with module names?

Right now, I guess, no, although that would be nice to have. I agree that
this can be discussed later.

- Anton

···

2016-05-24 6:14 GMT+03:00 Jordan Rose <jordan_rose@apple.com>:

On May 23, 2016, at 13:10, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:

@CoreTeam Please, don't forget to merge pull request with fixes and
alternatives from review period.

@AnyoneElse Today is (formally) the last day of review. It may be your
last chance!

Apple repo link:

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

My repo with some latest changes:

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

Thanks for doing this. While I’m a little apprehensive about the
implementation, I don’t expect it to be a problem in practice; a DAG is a
pretty safe data structure, and the size of the graph (i.e. the number of
precedence groups in a program) probably won’t be that big in practice. And
it’s so much better than arbitrary precedence numbers.

To discuss later: what are the naming guidelines for precedence groups?
(What part of speech? Why UpperCamelCase?) Are they in a separate scope
from normal names? Can you qualify them with module names?

(Operator declarations in general are weirdly global right now, because
they need to be resolvable without doing full lookup work, and because it
was easier to implement them that way. So making precedence groups special
as well is probably fine, at least for now.)

Jordan

> Can you qualify them with module names?
Right now, I guess, no, although that would be nice to have. I agree that this can be discussed later.

I wonder if we should force people today to put a `public` keyword on their `operator` and `precedence` (or whatever) declarations, so that when we eventually *do* stop doing the weird global thing we're currently doing, existing code won't break (as much).

···

--
Brent Royal-Gordon
Architechies

I assume that Core team is scheduling a discussion or already discussing
the proposal, and that really takes time in our case.

In reply to Brent, I think that we can start requiring `public` if (when?)
operator visibility levels are added.

- Anton

···

2016-05-24 13:53 GMT+03:00 Brent Royal-Gordon <brent@architechies.com>:

> > Can you qualify them with module names?
> Right now, I guess, no, although that would be nice to have. I agree
that this can be discussed later.

I wonder if we should force people today to put a `public` keyword on
their `operator` and `precedence` (or whatever) declarations, so that when
we eventually *do* stop doing the weird global thing we're currently doing,
existing code won't break (as much).

--
Brent Royal-Gordon
Architechies

I'm starting to worry about the proposal, too. Any news?

- Anton

···

2016-05-31 1:07 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:

I assume that Core team is scheduling a discussion or already discussing
the proposal, and that really takes time in our case.

In reply to Brent, I think that we can start requiring `public` if (when?)
operator visibility levels are added.

- Anton

2016-05-24 13:53 GMT+03:00 Brent Royal-Gordon <brent@architechies.com>:

> > Can you qualify them with module names?
> Right now, I guess, no, although that would be nice to have. I agree
that this can be discussed later.

I wonder if we should force people today to put a `public` keyword on
their `operator` and `precedence` (or whatever) declarations, so that when
we eventually *do* stop doing the weird global thing we're currently doing,
existing code won't break (as much).

--
Brent Royal-Gordon
Architechies

They posted:

The core team has caught up except for three proposals that have gone through the review period, but which haven’t been decided yet:

The details of SE-0086 are still being discussed. The proposal overall is certain to be approved, but the specific list of affected types may or may not change.

The core team has not yet had time to discuss SE-0077, SE-0091 - we typically have a weekly core team meeting to discuss proposals, and ran out of time to discuss them (due to design discussion required for other proposals). We will discuss them (as well as the other reviews about to complete) next time we meet.

With WWDC looming, the core team is getting a bit DoS’d, so reviews and detailed discussions may end up getting deferred for a couple of weeks.

-- E

···

On Jun 9, 2016, at 12:31 PM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

I'm starting to worry about the proposal, too. Any news?

- Anton