Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Just want to make sure the pull request is noticed.
The proposal is ready for merge. Note that we can now "squash and merge" on
Github.

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

Re: [swift-evolution] [Proposal] Custom operators

[Ben Rimmington via swift-evolution]

Антон Жилин:
> No new suggestions have come in 2 days, and so I have created a pull request!
> https://github.com/apple/swift-evolution/pull/253

1. Assignment operators in Swift 2.2 have an `assignment` keyword:

infix operator += {
  associativity right
  precedence 90
  assignment
}

2. If assignments can't be chained, should they be non-associative?

3. Instead of `precedencegroup`, I suggest an abstract declaration:

operator Multiplicative {
  associativity(left)
  precedence(> Additive)
}
infix operator * : Multiplicative

4. In your proposal, `NilCoalesting` should be `NilCoalescing`.

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

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

No new suggestions have come in 2 days, and so I have created a pull
request! Here it is:
https://github.com/apple/swift-evolution/pull/253

If new glitches are suddenly discovered, Core team will still have the
ability to correct them.
So far we have mostly come to consensus.

- Anton

2016-04-10 13:18 GMT+03:00 Maximilian Hünenberger :

>
> Am 10.04.2016 um 11:48 schrieb Антон Жилин :
>
>
> 2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger :
>
>
> [...]
>
>
> The only minor syntax issue I have is that it is not immediately clear
>> which operators belong to a precedence group. The former syntax with the
>> "members(+, -)" solved this issue. However this has (currently) an
>> extensibility problem:
>>
> If you define a new operator and it should belong to a precedencegroup
>> where you have no access to its source (like Additive) then the whole
>> argument about having operators in one place.
>>
>
> My thoughts went as follows.
> We should be able to add operators to existing groups, for example,
> defined in the Standard Library.
> If so, then this this statement should belong to operator, not precedence
> group.
> But we have to declare the operator anyway, so adding `: Additive` or
> something to the declaration does not cause huge code bloat. Especially
> considering operators are not defined very often.
> Now, we have two ways to do the same thing. External declaration is
> necessary and not so bad. So, following a widely known principle, I remove
> `members`.
>
>
> [...]
>
>
> My issue can be solved by the IDE: It could display all operators which
> are contained in a precedencegroup with quick look or the new interface
> view in Xcode. However this excludes other IDEs which don't have such
> features.
>
> But as I said it is only a minor issue.
>
> Best regards
> - Maximilian
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger via swift-evolution]

> Am 10.04.2016 um 11:48 schrieb Антон Жилин :
> 
>> 2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger :
> 
> [...]
> 
>> The only minor syntax issue I have is that it is not immediately clear which 
>> operators belong to a precedence group. The former syntax with the 
>> "members(+, -)" solved this issue. However this has (currently) an 
>> extensibility problem:
>> If you define a new operator and it should belong to a precedencegroup where 
>> you have no access to its source (like Additive) then the whole argument 
>> about having operators in one place.
> 
> My thoughts went as follows.
> We should be able to add operators to existing groups, for example, defined 
> in the Standard Library.
> If so, then this this statement should belong to operator, not precedence 
> group.
> But we have to declare the operator anyway, so adding `: Additive` or 
> something to the declaration does not cause huge code bloat. Especially 
> considering operators are not defined very often.
> Now, we have two ways to do the same thing. External declaration is necessary 
> and not so bad. So, following a widely known principle, I remove `members`.
> 
> [...]


My issue can be solved by the IDE: It could display all operators which are 
contained in a precedencegroup with quick look or the new interface view in 
Xcode. However this excludes other IDEs which don't have such features.

But as I said it is only a minor issue.

Best regards
- Maximilian

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

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Inline:

2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger :

>
> Am 09.04.2016 um 19:43 schrieb Антон Жилин :
> [...]
>
> Now, I see only 1 large question/problem risen by David Waite:
> Should precedence relationships be defined inside or outside of precedence
> groups?
> That is: should we be able to add arbitrary relationships between existing
> groups?
> [...]
>
>
> I'm in favor of declaring precedence relationships inside precedencegroup
> declarations. So they have a fixed place where they are defined.
>

I'm inclined to agree, but still not completely sure. Maybe someone else
could add a vote? Chris? :)

The only minor syntax issue I have is that it is not immediately clear
> which operators belong to a precedence group. The former syntax with the
> "members(+, -)" solved this issue. However this has (currently) an
> extensibility problem:
>
If you define a new operator and it should belong to a precedencegroup
> where you have no access to its source (like Additive) then the whole
> argument about having operators in one place.
>

My thoughts went as follows.
We should be able to add operators to existing groups, for example, defined
in the Standard Library.
If so, then this this statement should belong to operator, not precedence
group.
But we have to declare the operator anyway, so adding `: Additive` or
something to the declaration does not cause huge code bloat. Especially
considering operators are not defined very often.
Now, we have two ways to do the same thing. External declaration is
necessary and not so bad. So, following a widely known principle, I remove
`members`.

Another minor issue regarding your implementation of the standard library
> operators: "Additive" and all "Bitwise" precedencegroups should be above
> "Range"
>
> // so this is also possible without parentheses
> (1+2) ... (3+5)
>
> This issue can be brought up again during another proposal which
> implements this proposal. So the standard library changes *should not*
> belong to this proposal (or least be clarified).
>

Agreed. I will edit that part to form a hierarchy that exactky matches
current state of things.


>
> Kind regards
> - Maximilian
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger via swift-evolution]

> Am 09.04.2016 um 19:43 schrieb Антон Жилин :
> [...]
> Now, I see only 1 large question/problem risen by David Waite:
> Should precedence relationships be defined inside or outside of precedence 
> groups?
> That is: should we be able to add arbitrary relationships between existing 
> groups?
> [...]

I'm in favor of declaring precedence relationships inside precedencegroup 
declarations. So they have a fixed place where they are defined.


The only minor syntax issue I have is that it is not immediately clear which 
operators belong to a precedence group. The former syntax with the "members(+, 
-)" solved this issue. However this has (currently) an extensibility problem:
If you define a new operator and it should belong to a precedencegroup where 
you have no access to its source (like Additive) then the whole argument about 
having operators in one place.


Another minor issue regarding your implementation of the standard library 
operators: "Additive" and all "Bitwise" precedencegroups should be above "Range"

// so this is also possible without parentheses
(1+2) ... (3+5)

This issue can be brought up again during another proposal which implements 
this proposal. So the standard library changes should not belong to this 
proposal (or least be clarified).

Kind regards
- Maximilian___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

As always, link to the proposal:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md

Without further ado, I changed syntax for declaring that an operator
belongs to a group. It now looks like:
infix operator <> : Comparative

Next, I added a notion of default precedence group for infix operators:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md#default-precedence-group

Next, I added a notion of special operatrors that will allow nice
declarations in the Standard Library:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md#special-operators

I have a question on this: is that right? Because corresponding operator
functions still won't be declared anywhere.

Now, I see only 1 large question/problem risen by David Waite:
Should precedence relationships be defined inside or outside of precedence
groups?
That is: should we be able to add arbitrary relationships between existing
groups?

If we discuss this and no more problems are discovered, then I think, we
will be ready for review.

2016-04-09 16:40 GMT+03:00 Chris Lattner :

> > On Apr 9, 2016, at 6:36 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> > I do think it is useful to be able to specify precedence relationships
> without having to define a “group”, to avoid boilerplate when you have one
> operator at a logical level (“??” for example).
>
> Thought there is the obvious counterpoint: sugaring this one case doesn’t
> seem worthwhile, given how infrequently operators are defined.  It is quite
> reasonable to start simple and always require an operator to be a member of
> a group.  We could eliminate that boilerplate at some point down the road
> if it is an issue in practice.
>
> -Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Rainer Brockerhoff via swift-evolution]

Chris, thanks for commenting, but see below:

On 4/9/16 10:33, Chris Lattner via swift-evolution wrote:
>> On Apr 8, 2016, at 5:16 AM, Rainer Brockerhoff via swift-evolution 
>>  wrote:
>>> - I definitely agree that a partial ordering between precedences is all 
>>> that we need/want, and that unspecified relations should be an error.
>>> ...
>>> Question for you: have you considered introducing named precedence groups, 
>>> and having the relationships be between those groups?  For example, I could 
>>> see something like:
>>>
>>> operator group additive {}
>>> operator group multiplicative { greaterThan: additive }
>>> operator group exponential { greaterThan: additive }
>>
>> Also +10, would be interested in your opinion about:
>>
>> 1) disallowing adding new operator groups outside the stdlib;
> 
> I don’t see why we would do that.  This would lead us directly into
> the world of C++ operator overloading, where everyone reuses existing
> operators instead of defining their new and unique operators.  IMO it
> is much better to "know that you don’t know” what a symbol is, rather
> than assuming it has the obvious semantics and being surprised
> because it was overloaded.

I agree with you a 100% regarding new operators, but notice I said
"adding new operator GROUPS". I don't see much sense in adding a new
precedence group beyond the ones already defined.

This goes along with your comment later in this thread:
> ...This would require using parentheses to disambiguate...
which I always do — I never remember most of the precedences.


>> 2) disallowing adding operators to uncommon groups like subscripting,
>> function calls, etc.
> Subscripting and function calls are not operators.

Oops, right. I meant in the context of "expressions", as used in the
Swift book.

-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

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

Re: [swift-evolution] [Proposal] Custom operators

[Chris Lattner via swift-evolution]

> On Apr 9, 2016, at 6:36 AM, Chris Lattner via swift-evolution 
>  wrote:
> I do think it is useful to be able to specify precedence relationships 
> without having to define a “group”, to avoid boilerplate when you have one 
> operator at a logical level (“??” for example).

Thought there is the obvious counterpoint: sugaring this one case doesn’t seem 
worthwhile, given how infrequently operators are defined.  It is quite 
reasonable to start simple and always require an operator to be a member of a 
group.  We could eliminate that boilerplate at some point down the road if it 
is an issue in practice.

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

Re: [swift-evolution] [Proposal] Custom operators

[Chris Lattner via swift-evolution]

On Apr 8, 2016, at 12:28 PM, Антон Жилин  wrote:
> The question 4 (`prefix operator ! { }` or `prefix operator !`) seems dead 
> simple, because if we need to declare precedence group in body of infix 
> operators, then other operators should have it for consistency.
> 
> It's not.
> I suggest an alternative syntax for that:
> infix operator <> : Comparative
> 
> Colon immediately after the operator may not look the best, but it's the only 
> disadvantage I can find. It looks like inheritance and has similar meaning.

I agree, this is an nice approach.  You’re basically saying that the <> 
operator is a member of the set of Comparative operators, thereby “inheriting” 
its precedence behaviors.

-Chris

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

Re: [swift-evolution] [Proposal] Custom operators

[Chris Lattner via swift-evolution]

> On Apr 8, 2016, at 5:16 AM, Rainer Brockerhoff via swift-evolution 
>  wrote:
>> - I definitely agree that a partial ordering between precedences is all that 
>> we need/want, and that unspecified relations should be an error.
>> ...
>> Question for you: have you considered introducing named precedence groups, 
>> and having the relationships be between those groups?  For example, I could 
>> see something like:
>> 
>>  operator group additive {}
>>  operator group multiplicative { greaterThan: additive }
>>  operator group exponential { greaterThan: additive }
> 
> Also +10, would be interested in your opinion about:
> 
> 1) disallowing adding new operator groups outside the stdlib;
> 

I don’t see why we would do that.  This would lead us directly into the world 
of C++ operator overloading, where everyone reuses existing operators instead 
of defining their new and unique operators.  IMO it is much better to "know 
that you don’t know” what a symbol is, rather than assuming it has the obvious 
semantics and being surprised because it was overloaded.

> 2) disallowing adding operators to uncommon groups like subscripting,
> function calls, etc.


Subscripting and function calls are not operators.

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

Re: [swift-evolution] [Proposal] Custom operators

[Chris Lattner via swift-evolution]

> On Apr 8, 2016, at 10:46 AM, Антон Жилин via swift-evolution 
>  wrote:
> 
> Right, `infix` operators without a precedence group logically should be able 
> to be used, just with parentheses everywhere.
> 
> But users will most likely want to use such operators with `=` without 
> parentheses. It means, such operators should still belong to some precedence 
> groups.
> 
> I suggest that for each such operator, an separate unnamed group should be 
> created. It will have no associativity and precedence greater than Ternary (I 
> actually agree this is the right choice).
> 
> I also think it is OK that other operators will not be able to specify 
> precedence relation with such "unprecedented" operators

Right, I agree.  I consider it to be the "safe default" for an operator to be 
non-associative and unordered with respect to all other operators.  This would 
require using parentheses to disambiguate, which seems safer than a default 
precedence level.  This proposal also eliminates the notion of a strictly 
ordered set of precedences.

I do think it is useful to be able to specify precedence relationships without 
having to define a “group”, to avoid boilerplate when you have one operator at 
a logical level (“??” for example).

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

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Inline:

2016-04-09 0:17 GMT+03:00 David Waite :

> Based on commit ‘01317e1a’:
>
> I think that it makes sense for membership to live outside of a precedence
> group. An example is if I wanted to add a new assignment operator ( maybe
> ??= 'assign if nil’), I would want it to have the same precedence as
> existing assignment operators, including precedence with other custom
> operators.
>

Right, the proposal currently allows defining membership both inside and
outside the precedence group, but I agree that with terse enough syntax,
"outside only" will suffice.

Secondly, I think the relationships between precedence groups should be
> defined outside of an existing precedence group. If I have two libraries
> that declare operators in their own custom groups, I may need to define a
> relationship between those groups.
>

This is a highly discussable question. "Outside" option makes it easy to
merge standard library operators into a single hierarchy again. Maybe this
question can be formulated as follows: should module creator have total
control over its operators, or can their behaviour be modified by user?


> This leads the group declaration itself being just of a name and
> associativity.
>
> If group precedence is declared externally, there isn’t a need to support
> ‘>’. Since we are declaring a relationship and not evaluating a
> relationship, there are side-effects that developers will need to
> understand if they are trying to comprehend precedence groups in aggregate.
> Having the groups appear consistently in the same order when defining
> precedence may help with this.
>

I don't think supporting `>` puts much burden on grammar and consistency,
but yeah, it gets some points for external precedence.


> I still assume these relationships are meant to be constrained to a DAG,
> although there might be cases where cycles (or even having multiple graphs)
> would still be unambiguous. I can’t wrap my head around implementation to
> the point of understanding evaluation if not a DAG yet, nor practical
> reasons to have cycles in relations.
>
> Two groups may be unable to be declared to be equivalent. First, they need
> to be of the same associativity. Second are also possibilities of graph
> cycles once the relationships of both groups are overlaid. This is actually
> the trouble I alluded to in my first email in the thread.
>

This time the proposal actually reflects these ideas.

Finally, an infix operator is part of one and only one group. It might make
> sense to have a default group (with no associativity) for operators to fall
> into if they do not declare a precedence group.
>

I have written about creating a separate unnamed group for each operator.
That is nonsense, of course, that should be a single named group without
associativity.

Oh wait, Yet another quasi-syntax based on the above:
>
> precedencegroup Additive, associativity: left
> precedencerelation Additive < Multiplicative
> precedencerelation Range < Additive
> infix operator +, group: Additive
>

I actually like this syntax (the absence of body, especially), but that
commas are inconsistent with the rest of the language. My take at it (hope
somebody can do better):

precedencegroup Additive : associativity(left)
precedencerelation Additive < Multiplicative
precedencerelation Range < Additive
infix operator + : Additive


>
> -DW
>
> On Apr 8, 2016, at 1:28 PM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The question 4 (`prefix operator ! { }` or `prefix operator !`) seems
> dead simple, because if we need to declare precedence group in body of
> infix operators, then other operators should have it for consistency.
>
> It's not.
> I suggest an alternative syntax for that:
> infix operator <> : Comparative
>
> Colon immediately after the operator may not look the best, but it's the
> only disadvantage I can find. It looks like inheritance and has similar
> meaning.
> So, in this scheme, all operators will have no body.
>
> I also described two methods to declare that operator belongs to a
> precedence group: in `members` and in operator declaration.
> I suggest that this new syntax looks brief/natural enough to remove
> `members` option entirely. "There should be one - and preferably only one -
> obvious way to do it."
>
> - 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

Re: [swift-evolution] [Proposal] Custom operators

[David Waite via swift-evolution]

Based on commit ‘01317e1a’:

I think that it makes sense for membership to live outside of a precedence 
group. An example is if I wanted to add a new assignment operator ( maybe ??= 
'assign if nil’), I would want it to have the same precedence as existing 
assignment operators, including precedence with other custom operators.

Secondly, I think the relationships between precedence groups should be defined 
outside of an existing precedence group. If I have two libraries that declare 
operators in their own custom groups, I may need to define a relationship 
between those groups.

This leads the group declaration itself being just of a name and associativity.

If group precedence is declared externally, there isn’t a need to support ‘>’. 
Since we are declaring a relationship and not evaluating a relationship, there 
are side-effects that developers will need to understand if they are trying to 
comprehend precedence groups in aggregate. Having the groups appear 
consistently in the same order when defining precedence may help with this.

I still assume these relationships are meant to be constrained to a DAG, 
although there might be cases where cycles (or even having multiple graphs) 
would still be unambiguous. I can’t wrap my head around implementation to the 
point of understanding evaluation if not a DAG yet, nor practical reasons to 
have cycles in relations.

Two groups may be unable to be declared to be equivalent. First, they need to 
be of the same associativity. Second are also possibilities of graph cycles 
once the relationships of both groups are overlaid. This is actually the 
trouble I alluded to in my first email in the thread.

Finally, an infix operator is part of one and only one group. It might make 
sense to have a default group (with no associativity) for operators to fall 
into if they do not declare a precedence group.

Oh wait, Yet another quasi-syntax based on the above:

precedencegroup Additive, associativity: left
precedencerelation Additive < Multiplicative
precedencerelation Range < Additive

infix operator +, group: Additive

-DW

> On Apr 8, 2016, at 1:28 PM, Антон Жилин via swift-evolution 
>  wrote:
> 
> The question 4 (`prefix operator ! { }` or `prefix operator !`) seems dead 
> simple, because if we need to declare precedence group in body of infix 
> operators, then other operators should have it for consistency.
> 
> It's not.
> I suggest an alternative syntax for that:
> infix operator <> : Comparative
> 
> Colon immediately after the operator may not look the best, but it's the only 
> disadvantage I can find. It looks like inheritance and has similar meaning.
> So, in this scheme, all operators will have no body.
> 
> I also described two methods to declare that operator belongs to a precedence 
> group: in `members` and in operator declaration.
> I suggest that this new syntax looks brief/natural enough to remove `members` 
> option entirely. "There should be one - and preferably only one - obvious way 
> to do it."
> 
> - Anton
> 
> 2016-04-08 19:59 GMT+03:00 Антон Жилин  >:
> Thank you for your reply, Chris!
> I was thinking about purging directives from the proposal, and that was what 
> I needed to do it.
> So, the proposal is now completely overhauled:
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>  
> 
> 
> Yes, Maximilian and I have considered operator/precedence groups and they 
> have now moved from alternatives to main part of the proposal.
> 
> Questions:
> 1. Is it OK that associativity is moved to precedence groups and that every 
> operator must belong to a precedence group?
> 2. Dictionary-like or "functional keywords"? That is, `associativity: left` 
> or `associativity(left)`? So far, only second form has been used somewhere 
> inside declarations.
> 3. First-lower or first-upper? `additive` or `Additive`?
> 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?
> 
> Just in case, some questions/concerns copied from previous discussion:
> 
> 1. All precedence groups have a "parent".
> It means, all operators will want to have precedence higher than Comparative 
> or Ternary, or, at least, Assignment.
> 
> 2. Moreover, I could not find any case where I had to write anything other 
> than precedence(>, ...)
> Of cause, I cheated, because I can control all these declarations.
> Mere people will have to use `<` to say that Additive, for example, should 
> have less priority than their custom operator.
> 
> But... can you build a custom operator where `<` will actually be needed? I 
> have even stronger doubts on `=`.
> Maybe we can even contract this feature to `parent(Comparative)` or something 
> without losing any expressivity?
> 
> 3. Can we allow operators to have less priority than `=`?
> If yes, can you give an example of suc

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

The question 4 (`prefix operator ! { }` or `prefix operator !`) seems dead
simple, because if we need to declare precedence group in body of infix
operators, then other operators should have it for consistency.

It's not.
I suggest an alternative syntax for that:
infix operator <> : Comparative

Colon immediately after the operator may not look the best, but it's the
only disadvantage I can find. It looks like inheritance and has similar
meaning.
So, in this scheme, all operators will have no body.

I also described two methods to declare that operator belongs to a
precedence group: in `members` and in operator declaration.
I suggest that this new syntax looks brief/natural enough to remove
`members` option entirely. "There should be one - and preferably only one -
obvious way to do it."

- Anton

2016-04-08 19:59 GMT+03:00 Антон Жилин :

> Thank you for your reply, Chris!
> I was thinking about purging directives from the proposal, and that was
> what I needed to do it.
> So, the proposal is now completely overhauled:
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Yes, Maximilian and I have considered operator/precedence groups and they
> have now moved from alternatives to main part of the proposal.
>
> Questions:
> 1. Is it OK that associativity is moved to precedence groups and that
> every operator must belong to a precedence group?
> 2. Dictionary-like or "functional keywords"? That is, `associativity:
> left` or `associativity(left)`? So far, only second form has been used
> somewhere inside declarations.
> 3. First-lower or first-upper? `additive` or `Additive`?
> 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?
>
> Just in case, some questions/concerns copied from previous discussion:
>
> 1. All precedence groups have a "parent".
> It means, all operators will want to have precedence higher than
> Comparative or Ternary, or, at least, Assignment.
>
> 2. Moreover, I could not find any case where I had to write anything other
> than precedence(>, ...)
> Of cause, I cheated, because I can control all these declarations.
> Mere people will have to use `<` to say that Additive, for example, should
> have less priority than their custom operator.
>
> But... can you build a custom operator where `<` will actually be needed?
> I have even stronger doubts on `=`.
> Maybe we can even contract this feature to `parent(Comparative)` or
> something without losing any expressivity?
>
> 3. Can we allow operators to have less priority than `=`?
> If yes, can you give an example of such operator?
>
> - Anton
>
> 2016-04-08 8:59 GMT+03:00 Chris Lattner :
>
>>
>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> First of all, sorry for the delay. I still hope to finish the discussion
>> and push the proposal to review for Swift 3.0.
>> Link for newcomers:
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Sadly, I've moved into the territory opposite to what I had in mind in
>> the beginning: absense of conflict resolution.
>> I wanted lightweight directives, but am moving to closed precedence
>> groups.
>>
>> It's just IMHO, and I think I just need input on this from more people. I
>> still have not heard anything from Core team.
>>
>>
>> Hi Антон,
>>
>> I’m sorry for the delay, I have been out of town recently.  I haven’t
>> read the upstream thread so I hope this isn’t too duplicative.  Here is my
>> 2c:
>>
>> - I completely agree that numeric precedences are lame, it was always the
>> “plan” that they’d be removed someday, but that obviously still hasn’t
>> happened :-)
>> - I definitely agree that a partial ordering between precedences is all
>> that we need/want, and that unspecified relations should be an error.
>>
>> That said, I feel like #operator is a major syntactic regression, both in
>> consistency and predictability.  We use # for two things: directives (like
>> #if) and for expressions (#file).  The #operator is a declaration of an
>> operator, not an expression or a directive.  For declarations, we
>> consistently use a keyword, which allows contextual modifiers before them,
>> along with a body (which is sometimes optional for certain kinds of
>> decls).  I feel like you’re trying to syntactically reduce the weight of
>> something that doesn’t occur very often, which is no real win in
>> expressiveness, and harms consistency.
>>
>> Likewise #precedence is a relationship between two operators.  I’d
>> suggest putting them into the body of the operator declaration.
>>
>> OTOH, the stuff inside the current operator declaration is a random
>> series of tokens with no apparent structure.  I think it would be
>> reasonable to end up with something like:
>>
>> infix operator <> {
>>   associativity: left
>>   precedenceLessThan: *
>>   precedenceEqualTo: -
>>  }
>>
>> Or whatever.  The rationale he

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Right, `infix` operators without a precedence group logically should be
able to be used, just with parentheses everywhere.

But users will most likely want to use such operators with `=` without
parentheses. It means, such operators should still belong to some
precedence groups.

I suggest that for each such operator, an separate unnamed group should be
created. It will have no associativity and precedence greater than Ternary
(I actually agree this is the right choice).

I also think it is OK that other operators will not be able to specify
precedence relation with such "unprecedented" operators.

- Anton

8 Apr 2016, Ross O'Brien wrote:

> If I want to define a new operator, it seems like an unnecessary overhead
> to have to immediately decide which precedence group it should belong to
> before it can be used (assuming it doesn't interact with other operators).
> At the moment, new operators are implicitly assigned a 'default' precedence
> of 100; can we make it so that new operators are implicitly assigned to a
> 'default' group with an effective precedence of 100? (I believe this is
> currently the precedence of Ternary, but I'm not sure if I'd have Ternary
> be the default group).
>
> On Fri, Apr 8, 2016 at 5:59 PM, Антон Жилин  > wrote:
>
>> Thank you for your reply, Chris!
>> I was thinking about purging directives from the proposal, and that was
>> what I needed to do it.
>> So, the proposal is now completely overhauled:
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Yes, Maximilian and I have considered operator/precedence groups and they
>> have now moved from alternatives to main part of the proposal.
>>
>> Questions:
>> 1. Is it OK that associativity is moved to precedence groups and that
>> every operator must belong to a precedence group?
>> 2. Dictionary-like or "functional keywords"? That is, `associativity:
>> left` or `associativity(left)`? So far, only second form has been used
>> somewhere inside declarations.
>> 3. First-lower or first-upper? `additive` or `Additive`?
>> 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?
>>
>> Just in case, some questions/concerns copied from previous discussion:
>>
>> 1. All precedence groups have a "parent".
>> It means, all operators will want to have precedence higher than
>> Comparative or Ternary, or, at least, Assignment.
>>
>> 2. Moreover, I could not find any case where I had to write anything
>> other than precedence(>, ...)
>> Of cause, I cheated, because I can control all these declarations.
>> Mere people will have to use `<` to say that Additive, for example,
>> should have less priority than their custom operator.
>>
>> But... can you build a custom operator where `<` will actually be needed?
>> I have even stronger doubts on `=`.
>> Maybe we can even contract this feature to `parent(Comparative)` or
>> something without losing any expressivity?
>>
>> 3. Can we allow operators to have less priority than `=`?
>> If yes, can you give an example of such operator?
>>
>> - Anton
>>
>> 2016-04-08 8:59 GMT+03:00 Chris Lattner > >:
>>
>>>
>>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
>>> swift-evolution@swift.org
>>> > wrote:
>>>
>>> First of all, sorry for the delay. I still hope to finish the discussion
>>> and push the proposal to review for Swift 3.0.
>>> Link for newcomers:
>>>
>>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>>
>>> Sadly, I've moved into the territory opposite to what I had in mind in
>>> the beginning: absense of conflict resolution.
>>> I wanted lightweight directives, but am moving to closed precedence
>>> groups.
>>>
>>> It's just IMHO, and I think I just need input on this from more people.
>>> I still have not heard anything from Core team.
>>>
>>>
>>> Hi Антон,
>>>
>>> I’m sorry for the delay, I have been out of town recently.  I haven’t
>>> read the upstream thread so I hope this isn’t too duplicative.  Here is my
>>> 2c:
>>>
>>> - I completely agree that numeric precedences are lame, it was always
>>> the “plan” that they’d be removed someday, but that obviously still hasn’t
>>> happened :-)
>>> - I definitely agree that a partial ordering between precedences is all
>>> that we need/want, and that unspecified relations should be an error.
>>>
>>> That said, I feel like #operator is a major syntactic regression, both
>>> in consistency and predictability.  We use # for two things: directives
>>> (like #if) and for expressions (#file).  The #operator is a declaration of
>>> an operator, not an expression or a directive.  For declarations, we
>>> consistently use a keyword, which allows contextual modifiers before them,
>>> along with a body (which is sometimes optional for certain kinds of
>>> decls).  I feel like you’re trying to syntactically reduce the weight of
>>> something that doesn’t occur very often, which is no real win in
>>> expressi

Re: [swift-evolution] [Proposal] Custom operators

[Ross O'Brien via swift-evolution]

If I want to define a new operator, it seems like an unnecessary overhead
to have to immediately decide which precedence group it should belong to
before it can be used (assuming it doesn't interact with other operators).
At the moment, new operators are implicitly assigned a 'default' precedence
of 100; can we make it so that new operators are implicitly assigned to a
'default' group with an effective precedence of 100? (I believe this is
currently the precedence of Ternary, but I'm not sure if I'd have Ternary
be the default group).

On Fri, Apr 8, 2016 at 5:59 PM, Антон Жилин 
wrote:

> Thank you for your reply, Chris!
> I was thinking about purging directives from the proposal, and that was
> what I needed to do it.
> So, the proposal is now completely overhauled:
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Yes, Maximilian and I have considered operator/precedence groups and they
> have now moved from alternatives to main part of the proposal.
>
> Questions:
> 1. Is it OK that associativity is moved to precedence groups and that
> every operator must belong to a precedence group?
> 2. Dictionary-like or "functional keywords"? That is, `associativity:
> left` or `associativity(left)`? So far, only second form has been used
> somewhere inside declarations.
> 3. First-lower or first-upper? `additive` or `Additive`?
> 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?
>
> Just in case, some questions/concerns copied from previous discussion:
>
> 1. All precedence groups have a "parent".
> It means, all operators will want to have precedence higher than
> Comparative or Ternary, or, at least, Assignment.
>
> 2. Moreover, I could not find any case where I had to write anything other
> than precedence(>, ...)
> Of cause, I cheated, because I can control all these declarations.
> Mere people will have to use `<` to say that Additive, for example, should
> have less priority than their custom operator.
>
> But... can you build a custom operator where `<` will actually be needed?
> I have even stronger doubts on `=`.
> Maybe we can even contract this feature to `parent(Comparative)` or
> something without losing any expressivity?
>
> 3. Can we allow operators to have less priority than `=`?
> If yes, can you give an example of such operator?
>
> - Anton
>
> 2016-04-08 8:59 GMT+03:00 Chris Lattner :
>
>>
>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> First of all, sorry for the delay. I still hope to finish the discussion
>> and push the proposal to review for Swift 3.0.
>> Link for newcomers:
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Sadly, I've moved into the territory opposite to what I had in mind in
>> the beginning: absense of conflict resolution.
>> I wanted lightweight directives, but am moving to closed precedence
>> groups.
>>
>> It's just IMHO, and I think I just need input on this from more people. I
>> still have not heard anything from Core team.
>>
>>
>> Hi Антон,
>>
>> I’m sorry for the delay, I have been out of town recently.  I haven’t
>> read the upstream thread so I hope this isn’t too duplicative.  Here is my
>> 2c:
>>
>> - I completely agree that numeric precedences are lame, it was always the
>> “plan” that they’d be removed someday, but that obviously still hasn’t
>> happened :-)
>> - I definitely agree that a partial ordering between precedences is all
>> that we need/want, and that unspecified relations should be an error.
>>
>> That said, I feel like #operator is a major syntactic regression, both in
>> consistency and predictability.  We use # for two things: directives (like
>> #if) and for expressions (#file).  The #operator is a declaration of an
>> operator, not an expression or a directive.  For declarations, we
>> consistently use a keyword, which allows contextual modifiers before them,
>> along with a body (which is sometimes optional for certain kinds of
>> decls).  I feel like you’re trying to syntactically reduce the weight of
>> something that doesn’t occur very often, which is no real win in
>> expressiveness, and harms consistency.
>>
>> Likewise #precedence is a relationship between two operators.  I’d
>> suggest putting them into the body of the operator declaration.
>>
>> OTOH, the stuff inside the current operator declaration is a random
>> series of tokens with no apparent structure.  I think it would be
>> reasonable to end up with something like:
>>
>> infix operator <> {
>>   associativity: left
>>   precedenceLessThan: *
>>   precedenceEqualTo: -
>>  }
>>
>> Or whatever.  The rationale here is that “infix” is primal on the
>> operator decl (and thus is outside the braces) but the rest of the stuff
>> can be omitted, so it goes inside.
>>
>> Just in terms of the writing of the proposal, in the "Change precedence
>> mechanism” keep in mind t

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Thank you for your reply, Chris!
I was thinking about purging directives from the proposal, and that was
what I needed to do it.
So, the proposal is now completely overhauled:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md

Yes, Maximilian and I have considered operator/precedence groups and they
have now moved from alternatives to main part of the proposal.

Questions:
1. Is it OK that associativity is moved to precedence groups and that every
operator must belong to a precedence group?
2. Dictionary-like or "functional keywords"? That is, `associativity: left`
or `associativity(left)`? So far, only second form has been used somewhere
inside declarations.
3. First-lower or first-upper? `additive` or `Additive`?
4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?

Just in case, some questions/concerns copied from previous discussion:

1. All precedence groups have a "parent".
It means, all operators will want to have precedence higher than
Comparative or Ternary, or, at least, Assignment.

2. Moreover, I could not find any case where I had to write anything other
than precedence(>, ...)
Of cause, I cheated, because I can control all these declarations.
Mere people will have to use `<` to say that Additive, for example, should
have less priority than their custom operator.

But... can you build a custom operator where `<` will actually be needed? I
have even stronger doubts on `=`.
Maybe we can even contract this feature to `parent(Comparative)` or
something without losing any expressivity?

3. Can we allow operators to have less priority than `=`?
If yes, can you give an example of such operator?

- Anton

2016-04-08 8:59 GMT+03:00 Chris Lattner :

>
> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> First of all, sorry for the delay. I still hope to finish the discussion
> and push the proposal to review for Swift 3.0.
> Link for newcomers:
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Sadly, I've moved into the territory opposite to what I had in mind in the
> beginning: absense of conflict resolution.
> I wanted lightweight directives, but am moving to closed precedence groups.
>
> It's just IMHO, and I think I just need input on this from more people. I
> still have not heard anything from Core team.
>
>
> Hi Антон,
>
> I’m sorry for the delay, I have been out of town recently.  I haven’t read
> the upstream thread so I hope this isn’t too duplicative.  Here is my 2c:
>
> - I completely agree that numeric precedences are lame, it was always the
> “plan” that they’d be removed someday, but that obviously still hasn’t
> happened :-)
> - I definitely agree that a partial ordering between precedences is all
> that we need/want, and that unspecified relations should be an error.
>
> That said, I feel like #operator is a major syntactic regression, both in
> consistency and predictability.  We use # for two things: directives (like
> #if) and for expressions (#file).  The #operator is a declaration of an
> operator, not an expression or a directive.  For declarations, we
> consistently use a keyword, which allows contextual modifiers before them,
> along with a body (which is sometimes optional for certain kinds of
> decls).  I feel like you’re trying to syntactically reduce the weight of
> something that doesn’t occur very often, which is no real win in
> expressiveness, and harms consistency.
>
> Likewise #precedence is a relationship between two operators.  I’d suggest
> putting them into the body of the operator declaration.
>
> OTOH, the stuff inside the current operator declaration is a random series
> of tokens with no apparent structure.  I think it would be reasonable to
> end up with something like:
>
> infix operator <> {
>   associativity: left
>   precedenceLessThan: *
>   precedenceEqualTo: -
>  }
>
> Or whatever.  The rationale here is that “infix” is primal on the operator
> decl (and thus is outside the braces) but the rest of the stuff can be
> omitted, so it goes inside.
>
> Just in terms of the writing of the proposal, in the "Change precedence
> mechanism” keep in mind that swift code generally doesn’t care about the
> order of declarations (it doesn’t parse top down in the file like C does)
> so the example is a bit misleading.
>
> Question for you: have you considered introducing named precedence groups,
> and having the relationships be between those groups?  For example, I could
> see something like:
>
> operator group additive {}
> operator group multiplicative { greaterThan: additive }
> operator group exponential { greaterThan: additive }
>
> Then:
>
> infix operator + {
>   associativity: left
>   precedence: additive
>  }
> infix operator - {
>   associativity: left
>   precedence: additive
>  }
>
> etc.
>
> -Chris
>
___
swift-evolution ma

Re: [swift-evolution] [Proposal] Custom operators

[Rainer Brockerhoff via swift-evolution]

On 4/8/16 02:59, Chris Lattner via swift-evolution wrote:
>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution 
>>  wrote:
>> Link for newcomers:
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>  
>> 
>>
>> Sadly, I've moved into the territory opposite to what I had in mind in the 
>> beginning: absense of conflict resolution.
>> I wanted lightweight directives, but am moving to closed precedence groups.
>>
>> It's just IMHO, and I think I just need input on this from more people. I 
>> still have not heard anything from Core team.
> ... 
> I’m sorry for the delay, I have been out of town recently.  I haven’t read 
> the upstream thread so I hope this isn’t too duplicative.  Here is my 2c:
> 
> - I completely agree that numeric precedences are lame, it was always the 
> “plan” that they’d be removed someday, but that obviously still hasn’t 
> happened :-)

+10!

> - I definitely agree that a partial ordering between precedences is all that 
> we need/want, and that unspecified relations should be an error.
> ...
> Question for you: have you considered introducing named precedence groups, 
> and having the relationships be between those groups?  For example, I could 
> see something like:
> 
>   operator group additive {}
>   operator group multiplicative { greaterThan: additive }
>   operator group exponential { greaterThan: additive }

Also +10, would be interested in your opinion about:

1) disallowing adding new operator groups outside the stdlib;

2) disallowing adding operators to uncommon groups like subscripting,
function calls, etc.

TIA...
-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

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

Re: [swift-evolution] [Proposal] Custom operators

[Chris Lattner via swift-evolution]

> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution 
>  wrote:
> 
> First of all, sorry for the delay. I still hope to finish the discussion and 
> push the proposal to review for Swift 3.0.
> Link for newcomers:
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>  
> 
> 
> Sadly, I've moved into the territory opposite to what I had in mind in the 
> beginning: absense of conflict resolution.
> I wanted lightweight directives, but am moving to closed precedence groups.
> 
> It's just IMHO, and I think I just need input on this from more people. I 
> still have not heard anything from Core team.

Hi Антон,

I’m sorry for the delay, I have been out of town recently.  I haven’t read the 
upstream thread so I hope this isn’t too duplicative.  Here is my 2c:

- I completely agree that numeric precedences are lame, it was always the 
“plan” that they’d be removed someday, but that obviously still hasn’t happened 
:-)
- I definitely agree that a partial ordering between precedences is all that we 
need/want, and that unspecified relations should be an error.

That said, I feel like #operator is a major syntactic regression, both in 
consistency and predictability.  We use # for two things: directives (like #if) 
and for expressions (#file).  The #operator is a declaration of an operator, 
not an expression or a directive.  For declarations, we consistently use a 
keyword, which allows contextual modifiers before them, along with a body 
(which is sometimes optional for certain kinds of decls).  I feel like you’re 
trying to syntactically reduce the weight of something that doesn’t occur very 
often, which is no real win in expressiveness, and harms consistency.

Likewise #precedence is a relationship between two operators.  I’d suggest 
putting them into the body of the operator declaration.

OTOH, the stuff inside the current operator declaration is a random series of 
tokens with no apparent structure.  I think it would be reasonable to end up 
with something like:

infix operator <> {
  associativity: left
  precedenceLessThan: *
  precedenceEqualTo: -
 }

Or whatever.  The rationale here is that “infix” is primal on the operator decl 
(and thus is outside the braces) but the rest of the stuff can be omitted, so 
it goes inside.

Just in terms of the writing of the proposal, in the "Change precedence 
mechanism” keep in mind that swift code generally doesn’t care about the order 
of declarations (it doesn’t parse top down in the file like C does) so the 
example is a bit misleading.

Question for you: have you considered introducing named precedence groups, and 
having the relationships be between those groups?  For example, I could see 
something like:

operator group additive {}
operator group multiplicative { greaterThan: additive }
operator group exponential { greaterThan: additive }

Then:

infix operator + {
  associativity: left
  precedence: additive
 }
infix operator - {
  associativity: left
  precedence: additive
 }

etc.

-Chris


> Still, new operators must be able to be added to existing precedence groups.
> Extensions cannot be used, because namespaces of types and precedencegroups 
> will not intersect.
> So I have to return to declaration of operators, if noone finds a better way 
> and if noone objects:
> 
> precedencegroup Additive {
> members(+, -)
> associativity(left)
> precedence(> Comparative)
> }
> infix operator +
> infix operator -
> infix operator &+ { precedencegroup(Additive) }
> 
> All operators must have precedence groups.
> I thought of allowing operators to be single-operator precedence groups, but 
> it wouldn't give any real benefits.
> I also thought of allowing operators without precedence, but almost all 
> operators will want at least `precedence(>Assignment)`.
> 
> Now, what questions did arise from standard library operator declarations?
> 
> 1. All precedence groups have a "parent".
> It means, all operators will want to have precedence higher than Comparative 
> or Ternary, or, at least, Assignment.
> 
> 2. Moreover, I could not find any case where I had to write anything other 
> than precedence(>, ...)
> Of cause, I cheated, because I can control all these declarations.
> Mere people will have to use `<` to say that Additive, for example, should 
> have less priority than their custom operator.
> 
> But... can you build a custom operator where `<` will actually be needed? I 
> have even stronger doubts on `=`.
> Maybe we can even contract this feature to `parent(Comparative)` or something 
> without losing any expressivity?
> 
> 3. Can we allow operators to have less priority than `=`?
> If yes, can you give an example of such operator?
> 
> 4. Operators `is`, `as`, `as?`, `as!`, `?:`, `=` are not proper Swift 
> operators.
> But we can still support these to

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

First of all, sorry for the delay. I still hope to finish the discussion
and push the proposal to review for Swift 3.0.
Link for newcomers:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md

Sadly, I've moved into the territory opposite to what I had in mind in the
beginning: absense of conflict resolution.
I wanted lightweight directives, but am moving to closed precedence groups.

It's just IMHO, and I think I just need input on this from more people. I
still have not heard anything from Core team.

My main question would be: maximally "mergeable" directives or closed
declarations?

Now, another iteration of syntax discussion.
I've created a sample of definitions of precedence operators for standard
library, using precedence groups (at the end of the proposal).

There is no evidence that an operator could logically belong to multiple
precedence groups.
Really, precedence groups are just a way of writing multiple identical
operator declarations in a shorter way.

Precedence groups will be closed, meaning that no precedence relations can
be added to them outside of their bodies.
It will make merging all standard library operators in a giant hierarchy
less tempting, although possible.
Still, that would be possible. We could disallow that specifically as a
future direction (only for standard library).

Still, new operators must be able to be added to existing precedence groups.
Extensions cannot be used, because namespaces of types and precedencegroups
will not intersect.
So I have to return to declaration of operators, if noone finds a better
way and if noone objects:

precedencegroup Additive {
members(+, -)
associativity(left)
precedence(> Comparative)
}
infix operator +
infix operator -
infix operator &+ { precedencegroup(Additive) }

All operators must have precedence groups.
I thought of allowing operators to be single-operator precedence groups,
but it wouldn't give any real benefits.
I also thought of allowing operators without precedence, but almost all
operators will want at least `precedence(>Assignment)`.

Now, what questions did arise from standard library operator declarations?

1. All precedence groups have a "parent".
It means, all operators will want to have precedence higher than
Comparative or Ternary, or, at least, Assignment.

2. Moreover, I could not find any case where I had to write anything other
than precedence(>, ...)
Of cause, I cheated, because I can control all these declarations.
Mere people will have to use `<` to say that Additive, for example, should
have less priority than their custom operator.

But... can you build a custom operator where `<` will actually be needed? I
have even stronger doubts on `=`.
Maybe we can even contract this feature to `parent(Comparative)` or
something without losing any expressivity?

3. Can we allow operators to have less priority than `=`?
If yes, can you give an example of such operator?

4. Operators `is`, `as`, `as?`, `as!`, `?:`, `=` are not proper Swift
operators.
But we can still support these tokens for consistency.
Their only appearence would be in the standard library.
Alternatively, we can hide their precedence groups and make them a special
case.
It's more a question of implementation complexity.

5. I removed associativity from Ternary, removed BitwiseXor from bitwise
hierarchy.
And made numerous other changes that probably need to be reviewed.

2016-04-06 9:17 GMT+03:00 Maximilian Hünenberger :

>
>
> Am 05.04.2016 um 22:32 schrieb Антон Жилин :
>
> Added
> 
> group version, "lessThan" problem can be solved nicely. `<`, `=`, `>` signs
> would be allowed there.
>
> > Should we allow "precedence(... equalTo ...)" for operators if we have
> precedence groups?
> I think no.
>
> I have a question to your group syntax.
> Since all operators in a precedence group must have equal associativity
> for parsing to work and look logically (right?), wouldn't it be better to
> declare associativity in groups?
> If so, then body of operator declaration won't contain anything, and we
> can remove it:
>
> precedenceGroup Additive {
> associativity(left)
> +, -
> }
> infix operator +
> infix operator -
>
> Does this body of precedenceGroup look OK from syntactic PoV?
>
>
> Associativity in precedence groups is fine however the operators should
> then be grouped possibly: "operators(+, -)"
>
>
> Now, I have another idea.
> As operator declarations themselves don't contain anything anymore, remove
> operator declarations at all. We don't need to pre-declare function names,
> for example.
> Next, `precedenceGroup` could be as well replaced with `precedenceLevel`,
> or just `precedence`, and I would not worry about additional keywords.
> So, our example would look like this:
>
> precedence Additive {
> associativity(left)
> +, -
> }
> precedence

Re: [swift-evolution] [Proposal] Custom operators

[Rainer Brockerhoff via swift-evolution]

On 4/4/16 15:21, Daniel Duan via swift-evolution wrote:
>> Антон Жилин via swift-evolution  writes:
>>
>> Swift 2.2 is out, and I restart discussion on syntax for custom operators.
>> I insist that this time we should focus less on linguistic aspects.
> ...[snip]
> 
> 3.  It may be a good exercise to work out how would each of the builtin
> operators would be defined with this change and mention it (not the entire
> definition, but the fact that it's possible, or reasons why it produces
> any difference) in the proposal.

Quoting the book:
“Swift’s operator precedences and associativity rules are simpler and
more predictable than those found in C and Objective-C. ”
Excerpt From: Apple Inc. “The Swift Programming Language (Swift 2.2
Prerelease).” iBooks.

A word of caution. I've been programming since 1969 (and this does
include languages like PL/I and B6700 ALGOL, for instance). For the past
35 years or so, mostly C and Objective-C. Nevertheless I've been bitten
far too often by misremembering operator precedences — and I refuse to
tack the rules up on my wall, or print them upside down on my t-shirt.

With advancing experience, as complexity increases and available neurons
decrease, I find myself _always_ using parentheses, or even intermediate
variables. It looks unwieldy but it's easier to reason about and to
debug. Why should I have to remember what `a && b || c` means in
practice in a particular language?

With newly-declared operators (especially not newly-declared by ME!) the
potential for confusion becomes ever-higher.

I caution against proposals that allow excess flexibility in defining
operator precedence. Even the existing numerical precedence values can
be abused, and expanding them by using some sort of tree, or (say)
floating-point values, is just a "foolish consistency".

I'd say, have the established precedence groups defined by name, and
allow adding new operators to only some of these groups. Inside those,
group by associativity - perhaps the few right-associative types should
not allow any new operators to be added.

All IMHO of course.
-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

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

Re: [swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger via swift-evolution]

> Am 05.04.2016 um 22:32 schrieb Антон Жилин :
> 
> Added group version, "lessThan" problem can be solved nicely. `<`, `=`, `>` 
> signs would be allowed there.
> 
> > Should we allow "precedence(... equalTo ...)" for operators if we have 
> > precedence groups?
> I think no.
> 
> I have a question to your group syntax.
> Since all operators in a precedence group must have equal associativity for 
> parsing to work and look logically (right?), wouldn't it be better to declare 
> associativity in groups?
> If so, then body of operator declaration won't contain anything, and we can 
> remove it:
> 
> precedenceGroup Additive {
> associativity(left)
> +, -
> }
> infix operator +
> infix operator -
> 
> Does this body of precedenceGroup look OK from syntactic PoV?

Associativity in precedence groups is fine however the operators should then be 
grouped possibly: "operators(+, -)"

> 
> Now, I have another idea.
> As operator declarations themselves don't contain anything anymore, remove 
> operator declarations at all. We don't need to pre-declare function names, 
> for example.
> Next, `precedenceGroup` could be as well replaced with `precedenceLevel`, or 
> just `precedence`, and I would not worry about additional keywords.
> So, our example would look like this:
> 
> precedence Additive {
> associativity(left)
> +, -
> }
> precedence Multiplicative {
> associativity(left)
> *, /
> }
> precedence(Additive < Multiplicative)
> 
> As a future direction, we could add extensions to precedence levels.
> We could go further and replace `precedence` with `operator`, abandoning the 
> idea of priority for prefix and postfix operators (that I honestly don't 
> like).

Regarding pre- and postfix operators: there was a separate thread which 
discussed exactly this. The biggest problem was that if a prefix "-" has lower 
precedence than an infix operator like "^" this calculation is ambiguous from a 
human perspective:

-3 ^ 3

"-" has visually the higher precedence and the result would be 9. However the 
actual result is -9.

If we have precedence on pre- and postfix operators we would break existing 
code. A migratory could then enforce the old precedence levels with braces. But 
then we can resolve existing (visual) ambiguities and "mathematical 
incorrectness" by making the precedence of prefix "-" higher than the current 
comparative operators and not declare its precedence to higher precedence 
operators (precedence > 140)

Such that this expression is ambiguous to the compiler:

3 - -3 // also mathematically incorrect
// and should be rewritten to
3 - (-3)
// or just
3 + 3

> infix operator Additive {
> members(+, -)
> associativity(left)
> }
> infix operator Multiplicative {
> members(*, /)
> associativity(left)
> precedence(> Additive)
> }
> 
> Some other questions:
> Do we need transitive precedence propagation?

Yes because it would be quite a pain to declare every precedence between all 
precedence groups:
#needed precedence declarations ~ O(#of precedence groups ^ 2)

> Do we need resolution of conflicts, i.e. merging multiple definitions of same 
> operators and groups, where possible?
> 

I think we shouldn't define operators in a precedence group because if we want 
to have an operator in two different groups then we have two operator 
definitions which can result in a conflict.
I'm not sure if we need the same operator in different groups. Therefore I'd 
suggest to declare all standard library operators in this form in order to see 
if we need this.

So my current syntax suggestion is:

infix operator + { associativity(left) }
prefix operator -
infix operator && { associativity(left) }

infix precedenceGroup Additive {
associativity(left)
members(+)
}

infix precedenceGroup Logical {
associativity(left)
members(&&)
}

prefix precedenceGroup Sign {
members(-)
}

precedence(Additive > Logical)
precedence(Sign > Logical)

// warning: duplicate precedence declarations
precedence(Logical < Additive)



I declare associativity in operator declarations and precedence group 
declarations since it lets the compiler check whether the "members" have the 
right associativity.

Best regards
- Maximilian ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Added

group version, "lessThan" problem can be solved nicely. `<`, `=`, `>` signs
would be allowed there.

> Should we allow "precedence(... equalTo ...)" for operators if we have
precedence groups?
I think no.

I have a question to your group syntax.
Since all operators in a precedence group must have equal associativity for
parsing to work and look logically (right?), wouldn't it be better to
declare associativity in groups?
If so, then body of operator declaration won't contain anything, and we can
remove it:

precedenceGroup Additive {
associativity(left)
+, -
}
infix operator +
infix operator -

Does this body of precedenceGroup look OK from syntactic PoV?

Now, I have another idea.
As operator declarations themselves don't contain anything anymore, remove
operator declarations at all. We don't need to pre-declare function names,
for example.
Next, `precedenceGroup` could be as well replaced with `precedenceLevel`,
or just `precedence`, and I would not worry about additional keywords.
So, our example would look like this:

precedence Additive {
associativity(left)
+, -
}
precedence Multiplicative {
associativity(left)
*, /
}
precedence(Additive < Multiplicative)

As a future direction, we could add extensions to precedence levels.
We could go further and replace `precedence` with `operator`, abandoning
the idea of priority for prefix and postfix operators (that I honestly
don't like).

infix operator Additive {
members(+, -)
associativity(left)
}
infix operator Multiplicative {
members(*, /)
associativity(left)
precedence(> Additive)
}

Some other questions:
Do we need transitive precedence propagation?
Do we need resolution of conflicts, i.e. merging multiple definitions of
same operators and groups, where possible?

2016-04-05 22:52 GMT+03:00 Maximilian Hünenberger :

>
> Am 05.04.2016 um 17:29 schrieb Антон Жилин :
>
> David Waite stated a major drawback of precedence groups.
>
> People will often create tiny precedence groups for their modules, and
> user will find that some of them should actually be the same. They will add
> precedenceEqualTo, but all these equivalent groups will still exist. This
> problem cannot occur with transitive precedence propagation. So precedence
> groups really create more problems than solve.
>
> - Anton
>
>
> Do you mean these drawbacks?
>
> "
>
> However, this may create more issues than it solves (two frameworks
> creating their own custom operators, putting them in custom precedence
> groups, and the consumer decides the two precedence groups are really
> equivalent)
>
> -DW
>
> "
>
> What is the problem? Changing the relative precedence of external
> operators in your file? Doesn't the same "problem" occur in your proposal
> (only with one operator)?
>
> What is the difference between overriding an operator function like this:
>
> func + (l: Int, r: Int) -> Int {
>return 0
> }
>
> This can also mess up your code...
> I'm sorry if I haven't understood your point.
>
> From the other email:
>
> I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky?
> Maybe:
>
> associativity(left)
> precedence(lessThan: +)
> precedence(equalTo: +)
>
> It also solves my concern about dictionary inside braces.
>
>
> I prefer "precedence(+ lessThan *)". However I don't think it's Swift
> style since "lessThan" is like an infix operator *with letters *although
> the symmetry between "+" and "*" would be nicely handled by such operator.
>
> Precedence groups have a great benefit of additional symmetry. Transitive
> precedence propagation, on the other hand, also has benefits:
>
> 1. It does not introduce new entities, just some rules for compiler
> 2. It does not add new keywords. In your current wording, we have to take
> precedence and precedenceGroup as keywords, that's why I
> originally preferred directives
>
>
> Both 1 and 2 are true but I still prefer to use declarations since they
> provide exactly one location where to put operators with equal precedence.
>
> By the way "precedence" is already a keyword... One more to go :)
>
> 3. We actually think in terms of operators, not groups.
> If I want to say that my operator should have the same priority as `+`,
> I'd rather say that I want it to have priority of plus and minus, not
> "belong to multiplicative group".
> If I declare <$> and want it to have same priority as <*>, it would be
> more difficult to invent some name for their group like FunctorManipulator.
>
>
> I think this deserves more discussion:
> Should we allow "precedence(... equalTo ...)" for operators if we have
> precedence groups?
>
> Such a precedence declaration would be contrary to my argument above:
> declare equal operator precedences in one place, which is more maintainable.
>
> On the other hand, in your solution you have a list of global rules
> and don't re

Re: [swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger via swift-evolution]

> Am 05.04.2016 um 17:29 schrieb Антон Жилин :
> 
> David Waite stated a major drawback of precedence groups.
> 
> People will often create tiny precedence groups for their modules, and user 
> will find that some of them should actually be the same. They will add 
> precedenceEqualTo, but all these equivalent groups will still exist. This 
> problem cannot occur with transitive precedence propagation. So precedence 
> groups really create more problems than solve.
> 
> - Anton

Do you mean these drawbacks?

"
> However, this may create more issues than it solves (two frameworks creating 
> their own custom operators, putting them in custom precedence groups, and the 
> consumer decides the two precedence groups are really equivalent)
> 
> -DW
"

What is the problem? Changing the relative precedence of external operators in 
your file? Doesn't the same "problem" occur in your proposal (only with one 
operator)?

What is the difference between overriding an operator function like this:

func + (l: Int, r: Int) -> Int {
   return 0
}

This can also mess up your code...
I'm sorry if I haven't understood your point.

From the other email:

> I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky? 
> Maybe:
> 
> associativity(left)
> precedence(lessThan: +)
> precedence(equalTo: +)
> 
> It also solves my concern about dictionary inside braces.

I prefer "precedence(+ lessThan *)". However I don't think it's Swift style 
since "lessThan" is like an infix operator with letters although the symmetry 
between "+" and "*" would be nicely handled by such operator.

> Precedence groups have a great benefit of additional symmetry. Transitive 
> precedence propagation, on the other hand, also has benefits:
> 
> 1. It does not introduce new entities, just some rules for compiler
> 2. It does not add new keywords. In your current wording, we have to take 
> precedence and precedenceGroup as keywords, that's why I originally preferred 
> directives

Both 1 and 2 are true but I still prefer to use declarations since they provide 
exactly one location where to put operators with equal precedence.

By the way "precedence" is already a keyword... One more to go :)

> 3. We actually think in terms of operators, not groups.
> If I want to say that my operator should have the same priority as `+`, I'd 
> rather say that I want it to have priority of plus and minus, not "belong to 
> multiplicative group".
> If I declare <$> and want it to have same priority as <*>, it would be more 
> difficult to invent some name for their group like FunctorManipulator.
> 

I think this deserves more discussion:
Should we allow "precedence(... equalTo ...)" for operators if we have 
precedence groups?

Such a precedence declaration would be contrary to my argument above: declare 
equal operator precedences in one place, which is more maintainable.

> On the other hand, in your solution you have a list of global rules and don't 
> really need braces. How about this?
> 
> #precedenceGroup(Additive)
> #precedenceGroup(Multiplicative)
> #precedence(Additive, less, Multiplicative)
> #operator(+, infix, associativity: left, group: Additive)
> #operator(*, infix, associativity: left, group: Multiplicative)
> #operator(<>, infix)
> 
> So precedence group is just a tag that can be used in precedence rules and 
> assigned to operators at declaration.

Although it is consistent with your proposal for me it is too much repetition 
and "code noise". Compare:

infix operator + { associativity: left }
infix operator * { associativity: left }
infix operator <> {}
precedenceGroup Additive { + }
precedenceGroup Multiplicative { * }
precedence(Additive lessThan Multiplicative)

Which is in my opinion way more readable even without syntax highlighting.


Thank You for sharing Your thoughts which have enriched me! :)

Best regards
- Maximilian
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

David Waite stated a major drawback of precedence groups.

People will often create tiny precedence groups for their modules, and user
will find that some of them should actually be the same. They will add
precedenceEqualTo, but all these equivalent groups will still exist. This
problem cannot occur with transitive precedence propagation. So precedence
groups really create more problems than solve.

- Anton

Apr 5, 2016, Антон Жилин wrote:
>
> On the other hand, in your solution you have a list of global rules
> and don't really need braces. How about this?


> #precedenceGroup(Additive)
> #precedenceGroup(Multiplicative)
> #precedence(Additive, less, Multiplicative)
> #operator(+, infix, associativity: left, group: Additive)
> #operator(*, infix, associativity: left, group: Multiplicative)
> #operator(<>, infix)
>
> So precedence group is just a tag that can be used in precedence rules and
> assigned to operators at declaration.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Apr 5, 2016, Maximilian Hünenberger wrote:

>
> Am 04.04.2016 um 08:06 schrieb Антон Жилин  >:
>
> Is it OK to have "less, equal, greater" in precedence name?
>
> What do you mean by OK? Other operators like == are weird:
>
> precedence(== == <)
> // in comparison to
> precedence(== equalTo <)
>

I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky?
Maybe:

associativity(left)
precedence(lessThan: +)
precedence(equalTo: +)

It also solves my concern about dictionary inside braces.

After thinking more about it I came to the conclusion that we should have
> something like "precedence groups" where all operators have the same
> precedence:
>
> precedenceGroup Additive {
> +, -
> }
>
> precedenceGroup Multiplicative {
> *, /
> }
>
> precedence(Additive lessThan Multiplicative)
>
> infix operator +- {
> associativity: left
> }
>
> extension Additive {
> +-, -+, ++, --
> }
>

Precedence groups have a great benefit of additional symmetry. Transitive
precedence propagation, on the other hand, also has benefits:

1. It does not introduce new entities, just some rules for compiler
2. It does not add new keywords. In your current wording, we have to take
precedence and precedenceGroup as keywords, that's why I
originally preferred directives
3. We actually think in terms of operators, not groups.
If I want to say that my operator should have the same priority as `+`, I'd
rather say that I want it to have priority of plus and minus, not "belong
to multiplicative group".
If I declare <$> and want it to have same priority as <*>, it would be more
difficult to invent some name for their group like FunctorManipulator.

On the other hand, in your solution you have a list of global rules
and don't really need braces. How about this?

#precedenceGroup(Additive)
#precedenceGroup(Multiplicative)
#precedence(Additive, less, Multiplicative)
#operator(+, infix, associativity: left, group: Additive)
#operator(*, infix, associativity: left, group: Multiplicative)
#operator(<>, infix)

So precedence group is just a tag that can be used in precedence rules and
assigned to operators at declaration.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger via swift-evolution]

Inline

> Am 04.04.2016 um 08:06 schrieb Антон Жилин :
> 
> Thank you for a helpful answer!
> I like the idea of overriding precedence from another module. We won't need 
> to introduce additional keywords or visibility for operators. I will add it 
> to the proposal.
> 
> I assume you mean precedence inside braces of operator, then operator scope 
> makes sense. Self operator could be omit as well, following the idea that we 
> are introducing a new operator and want to compare it to others:
> 
> infix operator * {
> associativity: left
> precedenceLess: ^
> precedenceEqual: /
> precedenceGreater: +
> }
> infix operator / {
> associativity: left
> precedenceLess: ^
> precedenceEqual: *
> precedenceGreater: +
> }
> 
> Equivalent precedence rules would be allowed for symmetry in the operator 
> definitions.
> We would still be able to reopen the scope and add precedence and 
> associativity rules.
> I agree that this scheme has advantage of being a smaller change.
> 
> I'm still concerned about syntax.
> Is it OK to have "less, equal, greater" in precedence name?

What do you mean by OK? Other operators like == are weird:

precedence(== == <)
// in comparison to
precedence(== equalTo <)

> Is it OK to have both curly brackets and dictionary syntax (a precedent, I 
> guess)?

That could be a consistency problem. However I'd like to keep a declaration 
syntax instead of defining operators through compiler directives.

> Is it OK to leave prefix and postfix operators always with empty braces?
> 

I'm fine with that.

> Would it be better to have multiple precedence comparisons at once:
> precedenceGreater: +, -, *, /
> Or one comparison per line will be more readable?
> 
> I will add this to alternatives, but will not swap it with currently stated 
> syntax for now, waiting for some more response.
> 
> What do you think?
> 
> - Anton

After thinking more about it I came to the conclusion that we should have 
something like "precedence groups" where all operators have the same precedence:

precedenceGroup Additive {
+, -
}

precedenceGroup Multiplicative {
*, /
}

// first we could allow an operator to be only
// in one p.Group. Later when we can infer
// precedences we can allow operators to be
// in more than one p.Group (if that is even necessary)


// precedence declaration
precedence(Additive lessThan Multiplicative)

// precedence declarations take
// "precedenceGroup"s and "operator"s.


// It could also work with extensions so you
// can easily insert it in the precedence hierarchy:

infix operator +- {
associativity: left
}

// more operator declarations ...

extension Additive {
+-, -+, ++, --
}

// the syntax I used is highly discussable.
// this should mainly be a concept suggestion.
// I think it allows for greater flexibility since you can define
// operator precedences much easier.

With kind regards
- Maximilian
> 
> 2016-04-04 8:06 GMT+03:00 Maximilian Hünenberger :
>> See inline
>> 
>>> Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution 
>>> :
>>> 
>>> There is a problem here of duplicated operators or custom precedence, and 
>>> how that gets passed between modules.
>>> Assume there are three modules, A, B and C. B defines a custom operator **. 
>>> A and C each define a custom operator ++, and their meanings are different 
>>> (though, even if their meanings were the same, I'm not sure if they could 
>>> unify).
>>> 
>>> Module D uses A and B as dependencies and sets a custom precedence on ++ 
>>> and **. Module E uses B and C and has a different precedence on ++ and **. 
>>> You're working on Module F which uses D and E. Which ++ and which 
>>> precedence does F get implicitly?
>>> 
>> 
>> We could allow operator precedence overriding to resolve ambiguity. However 
>> this overriding should only be module internal since it would override the 
>> existing precedences in the other modules.
>> 
>> @AHTOH
>> Why do you use #keyword ?
>> I think defining a operator with
>> 
>> infix operator + {
>>  associativity: left
>> }
>> 
>> is perfectly fine since it is similar to class/struct/enum declaration.
>> 
>> // and it's precedence
>> precedence(+ lessThan *)
>> 
>> Note the missing "," and ":" before and after "lessThan" in order to give 
>> both operators the same importance (minor issue).
>> 
>> I feel that
>> 
>> #precedence(+, lessThan: *)
>> 
>> puts too much importance on the first operator.
>> 
>> Best regards
>> - Maximilian
>>> ___
>>> 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

Re: [swift-evolution] [Proposal] Custom operators

[Daniel Duan via swift-evolution]

> Антон Жилин via swift-evolution  writes:

> 
> Swift 2.2 is out, and I restart discussion on syntax for custom operators.
> I insist that this time we should focus less on linguistic aspects.


I have a few thoughts and a question regarding precedence:

1.  I strongly agree that the numeric precedence system is not great. From
a implementation point of view, the way to specify them in your proposal
essentially gave all visible operators a partial order, in which we can
draw a directed gragh with operators being the nodes and their relation
being arcs. A part of the graph might look like: '^' --> '*' --> '+', the
nodes being the math operators. We can tell '*' has a higher precedence
than '+', '^' has a higher precedence than '*' and '+', by follwing the
arcs. If one operator is not reachable from another, and vice versa, then
composing these two is illegal. We need to teach the compiler this concept.

2.  Currently, it's not possible to specify precedence for pre- and postfix
operators. Chris Lattner has mentioned that the
following result is not desirable:

∆x + y

… where ∆ has a lower precendence than + while it's required to have no
space between ∆ and the operand. My understanding is that if spaces were
to be allowed here, parsing such expression without ambiguity is a
non-trivial challenge. So, will it be possible to specify precedence for
pre/postfix operators under your proposal?

3.  It may be a good exercise to work out how would each of the builtin
operators would be defined with this change and mention it (not the entire
definition, but the fact that it's possible, or reasons why it produces
any difference) in the proposal.

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

Re: [swift-evolution] [Proposal] Custom operators

[Ross O'Brien via swift-evolution]

How is a non-transitive relation different from a conflict?
If we use:
#precedence(+, lessThan: *)
#precedence(*, lessThan: ^)
#precedence(^, lessThan: +)
Surely that should be an error, even with none of the operators actually
used?

The compiler would be asked to verify two things: that the relationships of
all operators in the program can be expressed with a topological ordering,
and any pair of operators used together in an expression in the program has
an unambiguous precedence in that ordering. (I have no idea how relatable
this comparison actually is, but it seems like it would be a simpler
problem than analysing NSLayoutConstraints for violations.)

On Mon, Apr 4, 2016 at 7:49 AM, Антон Жилин 
wrote:

> In the poposed model, all relations are not transitive. Example:
>
> #precedence(+, lessThan: *)
> #precedence(*, lessThan: ^)
> 1 ^ 2 + 3  // error
> #precedence(+, lessThan: ^)
> 1 ^ 2 + 3  // now ok
>
> Would it be better to have such indirect relations inferred? Or would it
> put too much responsibility on the compiler?
> Maybe add it to future directions?
>
> Cycles of length >2 are also allowed. This was not added intentionally,
> but follows from other specified rules.
> Example: ^ (binary) < & (binary) < + < * < ^ (power). OK, & < + is a bit
> stretched, otherwise quite logical.
>
> > - I wonder if there are cases in the standard operators which would be
> better modeled as a non-linear chain.
> In the standard library, non-linearity will be primarily used to break a
> single hierarchy into multiple small ones. I doubt that any trees or cycles
> will form, although that would be good news.
>
> - Anton
>
> 2016-04-04 8:55 GMT+03:00 David Waite :
>
>> Interesting model!
>>
>> If I understand correctly: this changes the precedence from being based
>> on a numeric value, to being represented as a bit of a DAG of precedence
>> groups. A precedence group is defined implicitly for each operator, with
>> one group around each set of operators where equalTo has been declared.
>>
>> The groups are lazily evaluated, so if an expression can be resolved
>> without ambiguity due to lack of reachability between two individual
>> operators in the DAG, there is no issue/error.
>>
>> Comments:
>> - I wonder if there are cases in the standard operators which would be
>> better modeled as a non-linear chain.  The compiler could warn around usage
>> which is defined by operator precedence, but is commonly considered
>> ambiguous or error prone.
>>
>> For example, if users commonly get confused about the conjunctive and
>> disjunctive levels (logical ‘and’ and ‘or’) being different levels with
>> precedence, you could just omit the lessThan relationship between the two
>> of them. The compiler would then error on ambiguous cases, prompting the
>> user to use parenthesis.
>>
>> - I’d prefer instead of operator precedence groups just being implicit by
>> use of #precedence equalTo, that the operators are bound to a group
>> explicitly. Something like
>> #precedence(+, group: “additive”)
>> #precedence(“additive”, lessThan: “multiplicative”)
>>
>> However, this may create more issues than it solves (two frameworks
>> creating their own custom operators, putting them in custom precedence
>> groups, and the consumer decides the two precedence groups are really
>> equivalent)
>>
>> -DW
>>
>> On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Swift 2.2 is out, and I restart discussion on syntax for custom
>> operators. I insist that this time we should focus less on linguistic
>> aspects.
>>
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>>
>>
>
> ___
> 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

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

In the poposed model, all relations are not transitive. Example:

#precedence(+, lessThan: *)
#precedence(*, lessThan: ^)
1 ^ 2 + 3  // error
#precedence(+, lessThan: ^)
1 ^ 2 + 3  // now ok

Would it be better to have such indirect relations inferred? Or would it
put too much responsibility on the compiler?
Maybe add it to future directions?

Cycles of length >2 are also allowed. This was not added intentionally, but
follows from other specified rules.
Example: ^ (binary) < & (binary) < + < * < ^ (power). OK, & < + is a bit
stretched, otherwise quite logical.

> - I wonder if there are cases in the standard operators which would be
better modeled as a non-linear chain.
In the standard library, non-linearity will be primarily used to break a
single hierarchy into multiple small ones. I doubt that any trees or cycles
will form, although that would be good news.

- Anton

2016-04-04 8:55 GMT+03:00 David Waite :

> Interesting model!
>
> If I understand correctly: this changes the precedence from being based on
> a numeric value, to being represented as a bit of a DAG of precedence
> groups. A precedence group is defined implicitly for each operator, with
> one group around each set of operators where equalTo has been declared.
>
> The groups are lazily evaluated, so if an expression can be resolved
> without ambiguity due to lack of reachability between two individual
> operators in the DAG, there is no issue/error.
>
> Comments:
> - I wonder if there are cases in the standard operators which would be
> better modeled as a non-linear chain.  The compiler could warn around usage
> which is defined by operator precedence, but is commonly considered
> ambiguous or error prone.
>
> For example, if users commonly get confused about the conjunctive and
> disjunctive levels (logical ‘and’ and ‘or’) being different levels with
> precedence, you could just omit the lessThan relationship between the two
> of them. The compiler would then error on ambiguous cases, prompting the
> user to use parenthesis.
>
> - I’d prefer instead of operator precedence groups just being implicit by
> use of #precedence equalTo, that the operators are bound to a group
> explicitly. Something like
> #precedence(+, group: “additive”)
> #precedence(“additive”, lessThan: “multiplicative”)
>
> However, this may create more issues than it solves (two frameworks
> creating their own custom operators, putting them in custom precedence
> groups, and the consumer decides the two precedence groups are really
> equivalent)
>
> -DW
>
> On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift 2.2 is out, and I restart discussion on syntax for custom operators.
> I insist that this time we should focus less on linguistic aspects.
>
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Thank you for a helpful answer!
I like the idea of overriding precedence from another module. We won't need
to introduce additional keywords or visibility for operators. I will add it
to the proposal.

I assume you mean precedence inside braces of operator, then operator scope
makes sense. Self operator could be omit as well, following the idea that
we are introducing a new operator and want to compare it to others:

infix operator * {
associativity: left
precedenceLess: ^
precedenceEqual: /
precedenceGreater: +
}
infix operator / {
associativity: left
precedenceLess: ^
precedenceEqual: *
precedenceGreater: +
}

Equivalent precedence rules would be allowed for symmetry in the operator
definitions.
We would still be able to reopen the scope and add precedence and
associativity rules.
I agree that this scheme has advantage of being a smaller change.

I'm still concerned about syntax.
Is it OK to have "less, equal, greater" in precedence name?
Is it OK to have both curly brackets and dictionary syntax (a precedent, I
guess)?
Is it OK to leave prefix and postfix operators always with empty braces?

Would it be better to have multiple precedence comparisons at once:
precedenceGreater: +, -, *, /
Or one comparison per line will be more readable?

I will add this to alternatives, but will not swap it with currently stated
syntax for now, waiting for some more response.

What do you think?

- Anton

2016-04-04 8:06 GMT+03:00 Maximilian Hünenberger :

> See inline
>
> Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution <
> swift-evolution@swift.org>:
>
> There is a problem here of duplicated operators or custom precedence, and
> how that gets passed between modules.
> Assume there are three modules, A, B and C. B defines a custom operator
> **. A and C each define a custom operator ++, and their meanings are
> different (though, even if their meanings were the same, I'm not sure if
> they could unify).
>
> Module D uses A and B as dependencies and sets a custom precedence on ++
> and **. Module E uses B and C and has a different precedence on ++ and **.
> You're working on Module F which uses D and E. Which ++ and which
> precedence does F get implicitly?
>
>
> We could allow operator precedence overriding to resolve ambiguity.
> However this overriding should only be module internal since it would
> override the existing precedences in the other modules.
>
> @AHTOH
> Why do you use #keyword ?
> I think defining a operator with
>
> infix operator + {
>  associativity: left
> }
>
> is perfectly fine since it is similar to class/struct/enum declaration.
>
> // and it's precedence
> precedence(+ lessThan *)
>
> Note the missing "," and ":" before and after "lessThan" in order to give
> both operators the same importance (minor issue).
>
> I feel that
>
> #precedence(+, lessThan: *)
>
> puts too much importance on the first operator.
>
> Best regards
> - Maximilian
>
> ___
> 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

Re: [swift-evolution] [Proposal] Custom operators

[David Waite via swift-evolution]

Interesting model!

If I understand correctly: this changes the precedence from being based on a 
numeric value, to being represented as a bit of a DAG of precedence groups. A 
precedence group is defined implicitly for each operator, with one group around 
each set of operators where equalTo has been declared.

The groups are lazily evaluated, so if an expression can be resolved without 
ambiguity due to lack of reachability between two individual operators in the 
DAG, there is no issue/error.

Comments:
- I wonder if there are cases in the standard operators which would be better 
modeled as a non-linear chain.  The compiler could warn around usage which is 
defined by operator precedence, but is commonly considered ambiguous or error 
prone. 

For example, if users commonly get confused about the conjunctive and 
disjunctive levels (logical ‘and’ and ‘or’) being different levels with 
precedence, you could just omit the lessThan relationship between the two of 
them. The compiler would then error on ambiguous cases, prompting the user to 
use parenthesis.

- I’d prefer instead of operator precedence groups just being implicit by use 
of #precedence equalTo, that the operators are bound to a group explicitly. 
Something like
#precedence(+, group: “additive”)
#precedence(“additive”, lessThan: “multiplicative”)

However, this may create more issues than it solves (two frameworks creating 
their own custom operators, putting them in custom precedence groups, and the 
consumer decides the two precedence groups are really equivalent)

-DW

> On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution 
>  wrote:
> 
> Swift 2.2 is out, and I restart discussion on syntax for custom operators. I 
> insist that this time we should focus less on linguistic aspects.
> 
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>  
> 
> 

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

Re: [swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger via swift-evolution]

See inline

> Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution 
> :
> 
> There is a problem here of duplicated operators or custom precedence, and how 
> that gets passed between modules.
> Assume there are three modules, A, B and C. B defines a custom operator **. A 
> and C each define a custom operator ++, and their meanings are different 
> (though, even if their meanings were the same, I'm not sure if they could 
> unify).
> 
> Module D uses A and B as dependencies and sets a custom precedence on ++ and 
> **. Module E uses B and C and has a different precedence on ++ and **. You're 
> working on Module F which uses D and E. Which ++ and which precedence does F 
> get implicitly?
> 

We could allow operator precedence overriding to resolve ambiguity. However 
this overriding should only be module internal since it would override the 
existing precedences in the other modules.

@AHTOH
Why do you use #keyword ?
I think defining a operator with

infix operator + {
 associativity: left
}

is perfectly fine since it is similar to class/struct/enum declaration.

// and it's precedence
precedence(+ lessThan *)

Note the missing "," and ":" before and after "lessThan" in order to give both 
operators the same importance (minor issue).

I feel that

#precedence(+, lessThan: *)

puts too much importance on the first operator.

Best regards
- Maximilian

> I'm wondering whether we can treat operators the way we recently decided to 
> treat selectors: if there is an ambiguity, it should be possible not just to 
> specify which module they came from, but their fixity or argument types. If 
> module D decides that '++' should refer to 'traditional postfix number 
> incrementation', and F decides that it should be an infix 'conjoin two 
> numbers as a string and turn the result into a number (e.g. 5 ++ 4 -> 54)' 
> then a #selector-like operator signature would come in really handy.
> 
> 
>> On Sun, Apr 3, 2016 at 12:10 PM, Taras Zakharko via swift-evolution 
>>  wrote:
>> I think this is a great suggestion! One potential problem I can see (if I 
>> understood this correctly) is that modules are allowed to set up their own 
>> precedence rules for operators defined elsewhere. I think this might lead to 
>> some difficult to debug errors if a developer of one module (who is used to 
>> certain conventions) then has to work with a different, independent module 
>> (where the conventions are different). This is one area where numerical 
>> precedence weights seem to be superior as they at least refer to a common 
>> subjective coordinate system. 
>> 
>> Maybe one should also have visibility for precedence, for instance having 
>> precedence module-internal by default?
>> 
>> Best, 
>> 
>>  — Taras  
>> 
>>> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution 
>>>  wrote:
>>> 
>>> Swift 2.2 is out, and I restart discussion on syntax for custom operators. 
>>> I insist that this time we should focus less on linguistic aspects.
>>> 
>>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>> 
>>> Introduction
>>> 
>>> Replace syntax of operator definition:
>>> 
>>> infix operator <> { precedence 100 associativity left }
>>> With a directive:
>>> 
>>> #operator(<>, fixity: infix, associativity: left)
>>> Also replace numeric definition of precedence with separate comparative 
>>> precedence definitions:
>>> 
>>> #precedence(+, lessThan: *)
>>> #precedence(+, equalTo: -)
>>> Swift-evolution thread: link to the discussion thread for that proposal
>>> 
>>> Motivation
>>> 
>>> Problems with numeric definition of precedence
>>> 
>>> In the beginning, operators had nice precedence values: 90, 100, 110, 120, 
>>> 130, 140, 150, 160.
>>> 
>>> As time went, new and new operators were introduced. Precedence could not 
>>> be simply changed, as this would be a breaking change. Ranges got 
>>> precedence 135, as got precedence 132. ?? had precedence greater than <, 
>>> but less thanas, so it had to be given precedence 131.
>>> 
>>> Now it is not possible to insert any custom operator between < and ??. It 
>>> is an inevitable consequence of current design: it will be impossible to 
>>> insert an operator between two existing ones at some point.
>>> 
>>> Problems with a single precedence hierarchy
>>> 
>>> Currently, if an operator wants to define precedence by comparison to one 
>>> operator, it must do so for all other operators.
>>> 
>>> In many cases, this is not wished. Example: a & b < c is a common error 
>>> pattern. a / b as Double is another one. C++ compilers sometimes emit 
>>> warnings on these. Swift does not.
>>> 
>>> The root of the problem is that precedence is defined between all 
>>> operators. If & had precedence defined only by comparison to other bitwise 
>>> operators and / – only to arithmetic operators, we would have to place 
>>> parentheses in such places, not get subtle bugs, and not ever have to look 
>>> 

Re: [swift-evolution] [Proposal] Custom operators

[Félix Cloutier via swift-evolution]

That doesn't sound future-proof. If it was in place and Range hadn't existed 
since the earliest Swift public release, it wouldn't be possible to define its 
precedence now.

Félix

> Le 3 avr. 2016 à 11:41:00, Ben Rimmington via swift-evolution 
>  a écrit :
> 
>  -operator-precedence.md>
> 
> Another way to eliminate numerical precedence is by using keywords:
> 
> infix operator << {
>associativity none
>exponentiative
> }
> 
> infix operator * {
>associativity left
>multiplicative
> }
> 
> infix operator + {
>associativity left
>additive
> }
> 
> infix operator == {
>associativity none
>comparative
> }
> 
> infix operator += {
>associativity right
>assignment
> }
> 
> All operators would need to use one of the existing precedence groups (Table 
> 2):
> 
>  Swift_StandardLibrary_Operators/>
> 
> -- Ben
> 
> ___
> 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

Re: [swift-evolution] [Proposal] Custom operators

[Ben Rimmington via swift-evolution]

Another way to eliminate numerical precedence is by using keywords:

infix operator << {
associativity none
exponentiative
}

infix operator * {
associativity left
multiplicative
}

infix operator + {
associativity left
additive
}

infix operator == {
associativity none
comparative
}

infix operator += {
associativity right
assignment
}

All operators would need to use one of the existing precedence groups (Table 2):



-- Ben

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

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Right, the proposal in its current form does not really aim to resolve such
conflicts, although it makes them occur less often by "merging" precedence
and associativity when possible.

At first, I also tried to resolve such conflicts by naming operators. But I
found that compiler instructions will be too complex in some cases:

#operator(+, name: numericAdd, fixity: infix, associativity: left)
#operator(+, name: arrayAppend, fixity: infix, associativity: right)

func numericAdd(left: A, right: B) -> C
func numericAdd(left: B, right: C) -> B
func arrayAppend(left: A, right: A) -> B
func arrayAppend(left: B, right: C) -> A

A() + B() + C()

Compiler will have to find by brute-force that this expression can only
represent arrayAppend(A(), arrayAppend(B(), C())), and others result in
errors. To me, this scheme seems pretty absurd.

That said, it might be a good idea to add visibility for operators.
Hiding already imported operators, on the other hand, would be inconsistent
with othr elements of the language. It is currently impossible to hide
contents of module A from C where C imports B and B imports A. Not that I'm
against such a feature in general.

- Anton


2016-04-03 14:26 GMT+03:00 Ross O'Brien :

> There is a problem here of duplicated operators or custom precedence, and
> how that gets passed between modules.
> Assume there are three modules, A, B and C. B defines a custom operator
> **. A and C each define a custom operator ++, and their meanings are
> different (though, even if their meanings were the same, I'm not sure if
> they could unify).
>
> Module D uses A and B as dependencies and sets a custom precedence on ++
> and **. Module E uses B and C and has a different precedence on ++ and **.
> You're working on Module F which uses D and E. Which ++ and which
> precedence does F get implicitly?
>
> I'm wondering whether we can treat operators the way we recently decided
> to treat selectors: if there is an ambiguity, it should be possible not
> just to specify which module they came from, but their fixity or argument
> types. If module D decides that '++' should refer to 'traditional postfix
> number incrementation', and F decides that it should be an infix 'conjoin
> two numbers as a string and turn the result into a number (e.g. 5 ++ 4 ->
> 54)' then a #selector-like operator signature would come in really handy.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[James Campbell via swift-evolution]

In these case of module operator conflicts perhaps there could be a way we
could import these operators ?

Likes a #importOperators(OtherModule) or some kind of build flag.

*___*

*James⎥Future Prime Minister*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Sun, Apr 3, 2016 at 12:26 PM, Ross O'Brien via swift-evolution <
swift-evolution@swift.org> wrote:

> There is a problem here of duplicated operators or custom precedence, and
> how that gets passed between modules.
> Assume there are three modules, A, B and C. B defines a custom operator
> **. A and C each define a custom operator ++, and their meanings are
> different (though, even if their meanings were the same, I'm not sure if
> they could unify).
>
> Module D uses A and B as dependencies and sets a custom precedence on ++
> and **. Module E uses B and C and has a different precedence on ++ and **.
> You're working on Module F which uses D and E. Which ++ and which
> precedence does F get implicitly?
>
> I'm wondering whether we can treat operators the way we recently decided
> to treat selectors: if there is an ambiguity, it should be possible not
> just to specify which module they came from, but their fixity or argument
> types. If module D decides that '++' should refer to 'traditional postfix
> number incrementation', and F decides that it should be an infix 'conjoin
> two numbers as a string and turn the result into a number (e.g. 5 ++ 4 ->
> 54)' then a #selector-like operator signature would come in really handy.
>
>
> On Sun, Apr 3, 2016 at 12:10 PM, Taras Zakharko via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I think this is a great suggestion! One potential problem I can see (if I
>> understood this correctly) is that modules are allowed to set up their own
>> precedence rules for operators defined elsewhere. I think this might lead
>> to some difficult to debug errors if a developer of one module (who is used
>> to certain conventions) then has to work with a different, independent
>> module (where the conventions are different). This is one area where
>> numerical precedence weights seem to be superior as they at least refer to
>> a common subjective coordinate system.
>>
>> Maybe one should also have visibility for precedence, for instance having
>> precedence module-internal by default?
>>
>> Best,
>>
>>  — Taras
>>
>> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Swift 2.2 is out, and I restart discussion on syntax for custom
>> operators. I insist that this time we should focus less on linguistic
>> aspects.
>>
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Introduction
>>
>> Replace syntax of operator definition:
>>
>> infix operator <> { precedence 100 associativity left }
>>
>> With a directive:
>>
>> #operator(<>, fixity: infix, associativity: left)
>>
>> Also replace numeric definition of precedence with separate comparative
>> precedence definitions:
>>
>> #precedence(+, lessThan: *)
>> #precedence(+, equalTo: -)
>>
>> Swift-evolution thread: link to the discussion thread for that proposal
>> 
>>
>> 
>> Motivation
>> Problems
>> with numeric definition of precedence
>>
>> In the beginning, operators had nice precedence values: 90, 100, 110,
>> 120, 130, 140, 150, 160.
>>
>> As time went, new and new operators were introduced. Precedence could not
>> be simply changed, as this would be a breaking change. Ranges got
>> precedence 135, as got precedence 132. ?? had precedence greater than <,
>> but less thanas, so it had to be given precedence 131.
>>
>> Now it is not possible to insert any custom operator between < and ??.
>> It is an inevitable consequence of current design: it will be impossible to
>> insert an operator between two existing ones at some point.
>>
>> Problems
>> with a single precedence hierarchy
>>
>> Currently, if an operator wants to define precedence by comparison to one
>> operator, it must do so for all other operators.
>>
>> In many cases, this is not wished. Example: a & b < c is a common error
>> pattern. a / b as Double is another one. C++ compilers sometimes emit
>> warnings on these. Swift does not.
>>
>> The root of the problem is that precedence is defined between all
>> operators. If & had precedence defined only by comparison to other
>> bitwise operators and / – only to arithm

Re: [swift-evolution] [Proposal] Custom operators

[Ross O'Brien via swift-evolution]

There is a problem here of duplicated operators or custom precedence, and
how that gets passed between modules.
Assume there are three modules, A, B and C. B defines a custom operator **.
A and C each define a custom operator ++, and their meanings are different
(though, even if their meanings were the same, I'm not sure if they could
unify).

Module D uses A and B as dependencies and sets a custom precedence on ++
and **. Module E uses B and C and has a different precedence on ++ and **.
You're working on Module F which uses D and E. Which ++ and which
precedence does F get implicitly?

I'm wondering whether we can treat operators the way we recently decided to
treat selectors: if there is an ambiguity, it should be possible not just
to specify which module they came from, but their fixity or argument types.
If module D decides that '++' should refer to 'traditional postfix number
incrementation', and F decides that it should be an infix 'conjoin two
numbers as a string and turn the result into a number (e.g. 5 ++ 4 -> 54)'
then a #selector-like operator signature would come in really handy.


On Sun, Apr 3, 2016 at 12:10 PM, Taras Zakharko via swift-evolution <
swift-evolution@swift.org> wrote:

> I think this is a great suggestion! One potential problem I can see (if I
> understood this correctly) is that modules are allowed to set up their own
> precedence rules for operators defined elsewhere. I think this might lead
> to some difficult to debug errors if a developer of one module (who is used
> to certain conventions) then has to work with a different, independent
> module (where the conventions are different). This is one area where
> numerical precedence weights seem to be superior as they at least refer to
> a common subjective coordinate system.
>
> Maybe one should also have visibility for precedence, for instance having
> precedence module-internal by default?
>
> Best,
>
>  — Taras
>
> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift 2.2 is out, and I restart discussion on syntax for custom operators.
> I insist that this time we should focus less on linguistic aspects.
>
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Introduction
>
> Replace syntax of operator definition:
>
> infix operator <> { precedence 100 associativity left }
>
> With a directive:
>
> #operator(<>, fixity: infix, associativity: left)
>
> Also replace numeric definition of precedence with separate comparative
> precedence definitions:
>
> #precedence(+, lessThan: *)
> #precedence(+, equalTo: -)
>
> Swift-evolution thread: link to the discussion thread for that proposal
> 
>
> 
> Motivation
> Problems
> with numeric definition of precedence
>
> In the beginning, operators had nice precedence values: 90, 100, 110, 120,
> 130, 140, 150, 160.
>
> As time went, new and new operators were introduced. Precedence could not
> be simply changed, as this would be a breaking change. Ranges got
> precedence 135, as got precedence 132. ?? had precedence greater than <,
> but less thanas, so it had to be given precedence 131.
>
> Now it is not possible to insert any custom operator between < and ??. It
> is an inevitable consequence of current design: it will be impossible to
> insert an operator between two existing ones at some point.
>
> Problems
> with a single precedence hierarchy
>
> Currently, if an operator wants to define precedence by comparison to one
> operator, it must do so for all other operators.
>
> In many cases, this is not wished. Example: a & b < c is a common error
> pattern. a / b as Double is another one. C++ compilers sometimes emit
> warnings on these. Swift does not.
>
> The root of the problem is that precedence is defined between all
> operators. If & had precedence defined only by comparison to other
> bitwise operators and / – only to arithmetic operators, we would have to
> place parentheses in such places, not get subtle bugs, and not ever have to
> look at the huge operator precedence table.
>
> Problems
> with current operator definition syntax
>
> Some argue that current operator syntax is not consistent with other
> language constructs. Properties of operators have dictionary semantics and
> should be defined as such. It is a rather weak argument right now, but
> af

Re: [swift-evolution] [Proposal] Custom operators

[Taras Zakharko via swift-evolution]

I think this is a great suggestion! One potential problem I can see (if I 
understood this correctly) is that modules are allowed to set up their own 
precedence rules for operators defined elsewhere. I think this might lead to 
some difficult to debug errors if a developer of one module (who is used to 
certain conventions) then has to work with a different, independent module 
(where the conventions are different). This is one area where numerical 
precedence weights seem to be superior as they at least refer to a common 
subjective coordinate system. 

Maybe one should also have visibility for precedence, for instance having 
precedence module-internal by default?

Best, 

 — Taras  

> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution 
>  wrote:
> 
> Swift 2.2 is out, and I restart discussion on syntax for custom operators. I 
> insist that this time we should focus less on linguistic aspects.
> 
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>  
> 
> 
> Introduction
> 
> Replace syntax of operator definition:
> 
> infix operator <> { precedence 100 associativity left }
> With a directive:
> 
> #operator(<>, fixity: infix, associativity: left)
> Also replace numeric definition of precedence with separate comparative 
> precedence definitions:
> 
> #precedence(+, lessThan: *)
> #precedence(+, equalTo: -)
> Swift-evolution thread: link to the discussion thread for that proposal 
> 
>  
> Motivation
> 
>  
> Problems
>  with numeric definition of precedence
> 
> In the beginning, operators had nice precedence values: 90, 100, 110, 120, 
> 130, 140, 150, 160.
> 
> As time went, new and new operators were introduced. Precedence could not be 
> simply changed, as this would be a breaking change. Ranges got precedence 
> 135, as got precedence 132. ?? had precedence greater than <, but less 
> thanas, so it had to be given precedence 131.
> 
> Now it is not possible to insert any custom operator between < and ??. It is 
> an inevitable consequence of current design: it will be impossible to insert 
> an operator between two existing ones at some point.
> 
>  
> Problems
>  with a single precedence hierarchy
> 
> Currently, if an operator wants to define precedence by comparison to one 
> operator, it must do so for all other operators.
> 
> In many cases, this is not wished. Example: a & b < c is a common error 
> pattern. a / b as Double is another one. C++ compilers sometimes emit 
> warnings on these. Swift does not.
> 
> The root of the problem is that precedence is defined between all operators. 
> If & had precedence defined only by comparison to other bitwise operators and 
> / – only to arithmetic operators, we would have to place parentheses in such 
> places, not get subtle bugs, and not ever have to look at the huge operator 
> precedence table.
> 
>  
> Problems
>  with current operator definition syntax
> 
> Some argue that current operator syntax is not consistent with other language 
> constructs. Properties of operators have dictionary semantics and should be 
> defined as such. It is a rather weak argument right now, but after reworking 
> of precedence, the new syntax will be more to place. More reasons are given 
> below.
> 
>  
> Conflicts
>  of operator definitions
> 
> Consider two operator definitions in different modules.
> 
> Module A:
> 
> infix operator |> { precedence 137 associativity left }
> Module B:
> 
> infix operator |> { precedence 138 associativity left }
>  
> Proposed
>  solution
> 
>  
> Change
>  syntax for operator definition
> 
> #operator(<>, fixity: infix, associativity: left)
> #operator(!, fixity: postfix)
> First parameter of #operator directive is name of the operator. Then goes 
> required parameter fixity that can be infix,prefix, or postfix. Then, for 
> infix operators, go

Re: [swift-evolution] [Proposal] Custom operators

[Haravikk via swift-evolution]

> On 3 Apr 2016, at 11:45, Антон Жилин  wrote:
> 
> > Assuming these are defined in separate modules, how do we determine the 
> > order of • and ~?
> 
> By default, priority between any two operators is undefined. If two modules 
> don't know about each other, but the user wishes to prioritize them, then he 
> will write:
> 
> #precedence(•, lessThan: ~)
> 
> If • suddenly wishes to cooperate with ~, then it will add directives:
> 
> #operator(~, fixity: infix, associativity: left)
> #precedence(•, lessThan: ~)
> 
> It doesn't matter if ~ or user have already added them: if they do not 
> contain contradictory information, there will be no conflict.

Ah, I misunderstood then, so a warning/error will be raised if no precedence 
exists? Thanks for the explanation! I’ll probably still favour overkill 
brackets, but this makes sense.

In any event I’m on +1 for the more standardised syntax and the switch to using 
#directives, makes a lot of sense since these are really just customisable 
compiler symbols.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

> Assuming these are defined in separate modules, how do we determine the
order of • and ~?

By default, priority between any two operators is undefined. If two modules
don't know about each other, but the user wishes to prioritize them, then
he will write:

#precedence(•, lessThan: ~)

If • suddenly wishes to cooperate with ~, then it will add directives:

#operator(~, fixity: infix, associativity: left)
#precedence(•, lessThan: ~)

It doesn't matter if ~ or user have already added them: if they do not
contain contradictory information, there will be no conflict.

> On a related note, I never encounter precedence issues because I always
use parenthesis, since I know I’ll just forget the precedence rules so it’d
be a mistake for me to rely on them. If we’re adding operators in
precedence hierarchies then that only makes it even harder to
learn/remember, so I wonder if we might actually be better served by
removing precedence entirely?

That's exactly what I'm trying to do! I propose that there should be no
hierarchy. Each pair of operators will have to define priority explicitly,
if they need it.

I'll give an example of what I mean by "removing hierarchy":

#precedence(+, lessThan: *)
#precedence(*, lessThan: ^)
2 ^ 3 + 6   # error
#precedence(+, lessThan: ^)
2 ^ 3 + 6   # now ok

- Anton

2016-04-03 13:31 GMT+03:00 Haravikk :

> Interesting, I like the idea of changing how precedence is defined, but
> I’m curious how under the new scheme we would go about inserting a new
> operator unambiguously? For example:
>
> #precedence(•, lessThan: *)
> #precedence(~, lessThan: *)
>
> Assuming these are defined in separate modules, how do we determine the
> order of • and ~?
>
> On a related note, I never encounter precedence issues because I always
> use parenthesis, since I know I’ll just forget the precedence rules so it’d
> be a mistake for me to rely on them. If we’re adding operators in
> precedence hierarchies then that only makes it even harder to
> learn/remember, so I wonder if we might actually be better served by
> removing precedence entirely? i.e- the compiler would instead require the
> use of parenthesis to eliminate ambiguity like so:
>
> let a = 5 + 6 // Correct, as there aren’t enough operators for ambiguity
> let b = 5 + 6 * 7 + 8 // Incorrect, as it relies on precedence to be
> meaningful
> let c = (5 + 6) * (7 + 8) // Correct, as parenthesis eliminates
> ambiguity/the need for precedence
>
> This not only eliminates the need to learn, remember and/or lookup
> precedence, but it’s clearer and avoids mistakes, and IMO it’s actually
> more readable despite the added noise.
>
> On 3 Apr 2016, at 10:36, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift 2.2 is out, and I restart discussion on syntax for custom operators.
> I insist that this time we should focus less on linguistic aspects.
>
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Introduction
>
> Replace syntax of operator definition:
>
> infix operator <> { precedence 100 associativity left }
>
> With a directive:
>
> #operator(<>, fixity: infix, associativity: left)
>
> Also replace numeric definition of precedence with separate comparative
> precedence definitions:
>
> #precedence(+, lessThan: *)
> #precedence(+, equalTo: -)
>
> Swift-evolution thread: link to the discussion thread for that proposal
> 
>
> 
> Motivation
> Problems
> with numeric definition of precedence
>
> In the beginning, operators had nice precedence values: 90, 100, 110, 120,
> 130, 140, 150, 160.
>
> As time went, new and new operators were introduced. Precedence could not
> be simply changed, as this would be a breaking change. Ranges got
> precedence 135, as got precedence 132. ?? had precedence greater than <,
> but less thanas, so it had to be given precedence 131.
>
> Now it is not possible to insert any custom operator between < and ??. It
> is an inevitable consequence of current design: it will be impossible to
> insert an operator between two existing ones at some point.
>
> Problems
> with a single precedence hierarchy
>
> Currently, if an operator wants to define precedence by comparison to one
> operator, it must do so for all other operators.
>
> In many cases, this is not wished. Example: a & b < c is a common error
> pattern. a / b as Double is another one. C++ compilers sometimes emit
> warnings on these. Swift does not.
>
> The root of the problem is that precedence is defined between all
> op

Re: [swift-evolution] [Proposal] Custom operators

[Haravikk via swift-evolution]

Interesting, I like the idea of changing how precedence is defined, but I’m 
curious how under the new scheme we would go about inserting a new operator 
unambiguously? For example:

#precedence(•, lessThan: *)
#precedence(~, lessThan: *)

Assuming these are defined in separate modules, how do we determine the order 
of • and ~?

On a related note, I never encounter precedence issues because I always use 
parenthesis, since I know I’ll just forget the precedence rules so it’d be a 
mistake for me to rely on them. If we’re adding operators in precedence 
hierarchies then that only makes it even harder to learn/remember, so I wonder 
if we might actually be better served by removing precedence entirely? i.e- the 
compiler would instead require the use of parenthesis to eliminate ambiguity 
like so:

let a = 5 + 6   // Correct, as there aren’t enough 
operators for ambiguity
let b = 5 + 6 * 7 + 8   // Incorrect, as it relies on 
precedence to be meaningful
let c = (5 + 6) * (7 + 8)   // Correct, as parenthesis eliminates 
ambiguity/the need for precedence

This not only eliminates the need to learn, remember and/or lookup precedence, 
but it’s clearer and avoids mistakes, and IMO it’s actually more readable 
despite the added noise.

> On 3 Apr 2016, at 10:36, Антон Жилин via swift-evolution 
>  wrote:
> 
> Swift 2.2 is out, and I restart discussion on syntax for custom operators. I 
> insist that this time we should focus less on linguistic aspects.
> 
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>  
> 
> 
> Introduction
> 
> Replace syntax of operator definition:
> 
> infix operator <> { precedence 100 associativity left }
> With a directive:
> 
> #operator(<>, fixity: infix, associativity: left)
> Also replace numeric definition of precedence with separate comparative 
> precedence definitions:
> 
> #precedence(+, lessThan: *)
> #precedence(+, equalTo: -)
> Swift-evolution thread: link to the discussion thread for that proposal 
> 
>  
> Motivation
> 
>  
> Problems
>  with numeric definition of precedence
> 
> In the beginning, operators had nice precedence values: 90, 100, 110, 120, 
> 130, 140, 150, 160.
> 
> As time went, new and new operators were introduced. Precedence could not be 
> simply changed, as this would be a breaking change. Ranges got precedence 
> 135, as got precedence 132. ?? had precedence greater than <, but less 
> thanas, so it had to be given precedence 131.
> 
> Now it is not possible to insert any custom operator between < and ??. It is 
> an inevitable consequence of current design: it will be impossible to insert 
> an operator between two existing ones at some point.
> 
>  
> Problems
>  with a single precedence hierarchy
> 
> Currently, if an operator wants to define precedence by comparison to one 
> operator, it must do so for all other operators.
> 
> In many cases, this is not wished. Example: a & b < c is a common error 
> pattern. a / b as Double is another one. C++ compilers sometimes emit 
> warnings on these. Swift does not.
> 
> The root of the problem is that precedence is defined between all operators. 
> If & had precedence defined only by comparison to other bitwise operators and 
> / – only to arithmetic operators, we would have to place parentheses in such 
> places, not get subtle bugs, and not ever have to look at the huge operator 
> precedence table.
> 
>  
> Problems
>  with current operator definition syntax
> 
> Some argue that current operator syntax is not consistent with other language 
> constructs. Properties of operators have dictionary semantics and should be 
> defined as such. It is a rather weak argument right now, but after reworking 
> of precedence, the new syntax will be more to place. More reasons are given 
> below.
> 
>  
> Conflicts
>  of operator definitions
> 
> Consider two operator definitions in different modules.
> 
> Module A:
> 
> infix operator |> { precedence 137 associativity left }
> Module B:
> 
> infix operator |> { precedence 138 associa