[swift-evolution] [Proposal] Custom operators

[Антон Жилин]

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 Антон Жилин <antonyzhilin at gmail.com>:

> 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/NNNN-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 <clattner at apple.com>:
>
>>
>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
>> swift-evolution at 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/NNNN-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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160408/bc7c8ee2/attachment.html>