SIP-NN - Match infix & prefix types to meet expression rules #674

soronpo · 2017-02-07T18:52:24Z

No description provided.

Added comment about dotty

jvican

Thanks for submitting this proposal! I've left some comments that you may find useful. Let me know what you think about them!

For those eager to discuss this proposal (in a more high-level fashion than just reviewing), please head over to the Scala Contributors proposal thread.

jvican · 2017-02-09T17:34:30Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+
+### Extended proposal alternative
+It is possible to extend this proposal and allow the developer to annotate the expected associativity and precedence per operation. 
+(Author's note: I personally don't like this, but if such a solution is better for the community, then I will gladly modify this SIP to reflect that.)


I don't think this is a good idea as it adds a significant layer of complexity on the language and forces Scala developers to inspect the library-defined operations to know what's their precedence and how they can be used.

I would propose this is not included in this document and, if someone wants this feature, that a new proposal is submitted!

jvican · 2017-02-09T17:35:08Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+
+
+
+---


Are these dashes intended?

Yes, I like to keep things separate, but since you asked, removed.

jvican · 2017-02-09T17:36:14Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+
+* **Prefix operators bracketless unary use**: While expressions have prefix unary operators, there are none for types. See the [Prefix Operations](http://scala-lang.org/files/archive/spec/2.12/06-expressions.html#prefix-operations) section of the Scala specification. 
+This is a lacking feature of the type language Scala offers. See also interactions of this feature with other Scala features, further down this text. 
+(Author's note: Not crucial as infix precedence, but good for completeness) 


Can you remove author's notes? 😄. The document will be exposed to all the community and add a little bit of overhead to the document.

Moving notes to commit description.

jvican · 2017-02-09T17:37:11Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+* **Infix operator precedence and associativity**: 
+Infix types are 'mostly' left-associative, 
+while the expression operations are more intuitive with different precedence weights.
+Please see [Infix Types](http://scala-lang.org/files/archive/spec/2.12/03-types.html#infix-types) and [Infix Operations](http://scala-lang.org/files/archive/spec/2.12/06-expressions.html#infix-operations) sections of the Scala specifications for more details. 


Can you roughly explain what the current rules for infix operations are? A little bit of context will help the reader understand what you're proposing.

OK. Gave a short description and provided an example. I can also place a screenshot of the entire section.

jvican · 2017-02-09T17:37:47Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+Currently scala allows symbol operators (`-`, `*`, `~~>`, etc.) for both type names and definition names.
+Unfortunately, there is a 'surprise' element since the two differ in behaviour:
+
+* **Infix operator precedence and associativity**: 


Should we make these subtitles instead of bold text?

Will gladly do so. What do you mean by 'subtitles'? I'm not that familiar with MD.

Something like '###' would be enough 😄.

jvican · 2017-02-09T17:49:45Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+This means that if unary prefix types are added, then `+42` will be a type expansion of `unary_+[42]`.
+
+#### Scala meta
+Open question how this SIP affects `scala-meta`.


Scalameta's parser would need to be changed, but I think this section can go away. The trailing commas SIP doesn't mention Scala Meta (IIRC) and it's a detail not relevant to discuss the proposal in depth (any change to parser rules needs changes in tooling).

OK. Will remove the 'Scala meta' subsection.

jvican · 2017-02-09T17:52:12Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+---
+
+## Backward Compatibility
+Changing infix type associativity and precedence affects code that uses type operations and conforms to the current specification.


FTR, it would be very interesting to see how often type alias precedence is used. If you really care about this (and want to enrich the proposal with high-quality data that helps the Committee decide), you can explore it using Scala Meta. Run it it common Scala projects and give us some stats (note that this is optional 😉).

jvican · 2017-02-09T17:53:07Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+See the following [Typelevel Scala issue](https://github.com/typelevel/scala/issues/69) for the suggestion.
+
+### Other languages
+Would love some help to complete what happens in different programming languages.


Can we put this in the description instead of the document? 😄

jvican · 2017-02-09T17:54:59Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+### Other languages
+Would love some help to complete what happens in different programming languages.
+
+### Discussions


Can we make more explicit that any comment on this proposal should go to the Discourse thread? Something like: "If you're interested in discussing this proposal, head over to this Scala Contributors thread and let me know what you think".

Added at the top.

jvican · 2017-02-09T17:55:19Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+
+### Discussions
+[Scala Contributors](https://contributors.scala-lang.org/t/sip-nn-make-infix-type-alias-precedence-like-expression-operator-precedence/471)
+


Can we put this into "Bibliography"?

@jvican

- Removed author's notes, and Adding them here: 1. Unary types are not crucial as infix type precedence, but good for completeness. 2. For the proposal section, I can copy-paste the specifications from expression and modify them to types, if it so required. 3. Would love some help to complete what happens in different programming languages. 4. I think it is very unlikely that variance annotation will interact with literal types, so the confusion is not that critical. 5. Backward compatibility: I don't know if providing a flag to select the precedence is good or not. IMHO, it is better to create a tool that adds brackets to convert code to the old associativity. @jvican's suggestion to use a tool to analyze libraries and check if they are compatible or not is interesting. Don't know if I have time to make it. It is more useful for me to explore the scala compiler code, and make a PR for this SIP 😄 - Modified the example to `/` instead of `*` because currently dotty has bug and does not allow `*` infix type. - Removed scala meta section. - Removed extended proposal alternative: It is possible to extend this proposal and allow the developer to annotate the expected associativity and precedence per operation. I personally don't like this, but if such a solution is better for the community, then I will gladly modify this SIP to reflect that. See the following [Typelevel Scala issue](typelevel/scala#69) for the suggestion.

DarkDimius · 2017-02-10T13:57:19Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+---
+layout: sip
+disqus: true
+title: SIP-NN - Make types behave like expressions 


I think the current title is too general, it's not clear what is this sip about if you only read the title.
May I suggest:
Types have precedence and associativity rules as expressions

The proposal is more than just infix types.
Match infix & prefix types to meet expression rules is better?

I agree with @DarkDimius that a better name is desirable -- this one makes you wonder: "Behave like expression in regard to what?". I think Dmitry's suggestion is good, I would just add 'Make' at the beginning of the sentence: Make types have precedence and associativity rules as expressions. I'm not sure whether 'like' would be more appropriate in that case, maybe you can choose @soronpo, my non-native English is not that good.

Yeah, I think that's way better @soronpo, let's go with that name!

jvican

Thanks for taking into account my feedback @soronpo, I've answered some of your last questions and I think this is good to go. I'd like to merge as soon as we fix the problems in the CI (unknown ETA, but hopefully soon).

jvican · 2017-02-10T14:09:34Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+Currently scala allows symbol operators (`-`, `*`, `~~>`, etc.) for both type names and definition names.
+Unfortunately, there is a 'surprise' element since the two differ in behaviour:
+
+* **Infix operator precedence and associativity**: 


Something like '###' would be enough 😄.

jvican · 2017-02-10T14:10:22Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+
+---
+## Proposal
+The proposal is split into two; type infix precedence, and prefix unary types. Note to the SIP committee: It might be better to vote on the two parts separately.   


Let's do it this way, yes. We'll see how this experiment goes, we haven't actually had this situation happened yet.

jvican · 2017-02-10T14:10:37Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+```scala
+val works : 1 + (2 * 3) + 4 = 11
+val fails : 1 + 2 * 3 + 4 = 11 //left associative:(((1+2)*3)+4))) = 13
+```


Yes, good enough.

jvican · 2017-02-10T14:14:42Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+---
+layout: sip
+disqus: true
+title: SIP-NN - Make types behave like expressions 


I agree with @DarkDimius that a better name is desirable -- this one makes you wonder: "Behave like expression in regard to what?". I think Dmitry's suggestion is good, I would just add 'Make' at the beginning of the sentence: Make types have precedence and associativity rules as expressions. I'm not sure whether 'like' would be more appropriate in that case, maybe you can choose @soronpo, my non-native English is not that good.

- Changed title to reflect more what's inside the SIP. - Visual modifications

jvican · 2017-02-13T15:10:16Z

Can you please rebase on top of #685?

jvican · 2017-02-13T15:21:15Z

Hi @soronpo, are you sure you have rebased from latest master? Can you try again? Drone has worked for @DarkDimius PRs, but something is off here because Drone hasn't even recognised your latest commit (and this happens because .drone.yml is not there).

soronpo · 2017-02-13T16:35:33Z

@jvican I screwed something in the template, because this looks awful at http://docs.scala-lang.org/sips/pending/make-types-behave-like-expressions.html
Any suggestion of what I should fix? I copied mine from http://docs.scala-lang.org/sips/pending/refer-other-arguments-in-args.html which looks the same.

jvican · 2017-02-13T16:42:45Z

It probably has to do with spaces, can you check with the template of the binaryCompatible SIP?

soronpo · 2017-02-13T16:59:52Z

Perhaps #687 will resolve this. I compared with binaryCompatible and it had an extra annotation for code segments

jvican · 2017-02-13T17:00:24Z

I think it's the good way to fix it , thanks! 👍

TomasMikula · 2017-08-08T12:25:48Z

sips/pending/_posts/2017-02-07-make-types-behave-like-expressions.md

+  //Error!
+  //Left  expands to Plus[Plus[N1,Div[N2,N3]],N4] (Surprising)
+  //Right expands to Plus[Div[Plus[N1,N2],N3],N4]
+  implicitly[(N1 + N2 / N3 + N4) =:= (N1 + (N2 / N3) + N4)]


I think "Left" and "Right" are mixed up here.

Thanks. Fixed that in #855

TomasMikula · 2017-08-08T12:55:49Z

👍 for this SIP.

Here's perhaps a more concise demonstration of the problem:

type +[A, B] = Either[A, B]
type *[A, B] = (A, B)
type O = Nothing
type I = Unit

            1 + 1 * 0  ==  (1 + (1 * 0))  // true
implicitly[(I + I * O) =:= (I + (I * O))] // error: Cannot prove that I + I * O =:= I + (I * O).

soronpo · 2017-08-08T21:39:15Z

Updated PR in #855

soronpo and others added 7 commits February 7, 2017 19:38

Added SIP

c75ad08

Update SIP

5eb415c

Update SIP

1d6b25c

Update 2017-02-07-make-types-behave-like-expressions.md

4a7f32d

Update 2017-02-07-make-types-behave-like-expressions.md

4638248

Update 2017-02-07-make-types-behave-like-expressions.md

2659193

Update 2017-02-07-make-types-behave-like-expressions.md

6719504

Added comment about dotty

jvican approved these changes Feb 9, 2017

View reviewed changes

jvican mentioned this pull request Feb 9, 2017

site builds are timing out #680

Closed

DarkDimius reviewed Feb 10, 2017

View reviewed changes

jvican reviewed Feb 10, 2017

View reviewed changes

soronpo changed the title ~~SIP-NN - Make types behave like expressions~~ SIP-NN - Match infix & prefix types to meet expression rules Feb 10, 2017

soronpo added 2 commits February 10, 2017 16:31

More updates from feedback

84d5cc5

- Changed title to reflect more what's inside the SIP. - Visual modifications

Rebase

7750b93

pushing again. crossing fingers.

57f8d0a

Merge https://github.com/scala/scala.github.com

9d24b3c

jvican merged commit d77ce94 into scala:master Feb 13, 2017

TomasMikula reviewed Aug 8, 2017

View reviewed changes


		### Discussions
		[Scala Contributors](https://contributors.scala-lang.org/t/sip-nn-make-infix-type-alias-precedence-like-expression-operator-precedence/471)




		---

SIP-NN - Match infix & prefix types to meet expression rules #674

SIP-NN - Match infix & prefix types to meet expression rules #674

Conversation

soronpo commented Feb 7, 2017

jvican left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

soronpo Feb 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jvican Feb 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jvican Feb 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

soronpo Feb 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jvican left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jvican commented Feb 13, 2017

jvican commented Feb 13, 2017

soronpo commented Feb 13, 2017

jvican commented Feb 13, 2017

soronpo commented Feb 13, 2017

jvican commented Feb 13, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomasMikula commented Aug 8, 2017

soronpo commented Aug 8, 2017

soronpo Feb 9, 2017 •

edited

Loading

jvican Feb 9, 2017 •

edited

Loading

jvican Feb 9, 2017 •

edited

Loading

soronpo Feb 10, 2017 •

edited

Loading