[swift-evolution] [Proposal] Custom operators

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

Inline:

2016-04-09 0:17 GMT+03:00 David Waite <david at alkaline-solutions.com>:

> 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160409/1875731b/attachment-0001.html>