Split SIP33 into two SIPs #905

soronpo · 2017-10-25T21:44:12Z

As requested by the October 2017's SIP committee, the SIP was split into two:

SIP33 now only specify infix types precedence (maintains its number)
SIPNN (no numbered) specifies prefix types.

SethTisue · 2017-10-26T19:26:31Z

@soronpo I'm supposed to make sure that you received the feedback from the SIP committee — apparently you did :-)

could you also take a minute to review the parts of #907 that pertain to your SIP and verify that @darjutak represented them accurately?

soronpo · 2017-10-26T19:34:31Z

could you also take a minute to review the parts of #907 that pertain to your SIP and verify that @darjutak represented them accurately?

They were represented as commented by the committee (aside for a minor error which I commented on now). Accurately depends on my perspective which might be different than the committee's, but that should not part of the minutes 😄

jvican · 2017-10-27T07:01:28Z

I'm reviewing this next Monday and I'll give @soronpo some feedback on the motivation as we discussed privately.

heathermiller · 2017-10-27T07:02:51Z

(@jvican: @darjutak and I will hold you to it! 😈 )

jvican

Hey Oron, I've left you some comments that I think can improve the proposal. Thank you for taking the time to write it up. In general, I think it still needs a little bit of work to convince the Committee that prefix types are not too niche. I think your best card to play is to argue about consistency of the language, but for that you need to ensure that language features are sorted out beforehand and that the compiler knows how to distinguish between type and term operations.

jvican · 2017-10-29T22:18:31Z

_sips/sips/2017-10-25-adding-prefix-types.md

+
+---
+
+## Proposal


Can you move this after the motivation section?

jvican · 2017-10-29T22:24:32Z

_sips/sips/2017-10-25-adding-prefix-types.md

+---
+
+## Motivation
+Developers expect terms and types to be expressed the same for mathematical and logical operations.


Reading just this line I have several questions:

Can you elaborate on why developers expect that?

Perhaps also make a point to make the language more consistent?

Can you explain in which use cases or domain are prefix types more likely to be useful?

Can you come up with more interesting and shorter examples that show the value of prefix types?

Can you find other programming languages that support prefix types and tell us about their experience using them?

In my opinion, this motivation is not enough to gauge attention from the Committee... motivations are self-contained explanations that research on why the language is lacking without a certain lanaguage feature. They are usually rich in details and examples, and they try to be as objective as possible. For example, saying "developers expect terms and types to be expressed the same for mathematical and logical operations" is not backed up by any empirical or objective data, and it sounds overly subjective.

I feel that you can make a much better case for prefix types if you turn your statement around: try to go to the data and analysis first, and then you draw some conclusions from there. Prefix types look like a language feature that has not perceived lots of attention in other languages -- in this case, I think it's important to explain in which scenarios (with concrete examples) would they be useful.

I understand what you mean. The problem is justifying this can be just as easily a chicken and egg issue. Nobody uses prefix types because they are not available and the alternative is "good enough". Will a survey passed among the community be acceptable by the committee?

I cannot tell the committee it is not a niche because it is. It will only serve the typelevel community, but it enables us to think less about the language, in general. Currently, we have to think differently for typelevel operations, because the language made it different.

Other than the potential for confusion with variance annotation, I don't understand the reluctance to include this feature in the language:

Prefix types are not for doing the same thing but different. They add something that we can't do at all.

The implementation is very simple and should not affect the compiler in any way.

I understand what you mean. The problem is justifying this can be just as easily a chicken and egg issue. Nobody uses prefix types because they are not available and the alternative is "good enough".

If this hasn't been tested before enough, how are we sure that it merits being accepted in the Scala Language Specification? 😄

Other than the potential for confusion with variance annotation, I don't understand the reluctance to include this feature in the language:

Let's see what the Committee thinks. I'll discuss it with Martin too. Thank you for your feedback and updating this document!

jvican · 2017-10-29T22:27:43Z

_sips/sips/2017-10-25-adding-prefix-types.md

+
+The [singleton-ops library](https://github.com/fthomas/singleton-ops) with [Typelevel Scala](https://github.com/typelevel/scala) (which implemented [SIP-23](http://docs.scala-lang.org/sips/pending/42.type.html)) enable developers to express literal type operations more intuitively. For example:
+
+```scala


Can you add text that complements this snippet of code? For examples, saying "let's define foo and bar for..." or something similar. You can draw inspiration from SIP-35 Opaque types.

jvican · 2017-10-29T22:30:18Z

_sips/sips/2017-10-25-adding-prefix-types.md

+type bad = 2 ~~ -2 //Error:(9, 20) ';' expected but integer literal found.
+type work_around = 2 ~~ (-2) //works for Typelevel scala, but fails in Dotty
+```
+It is not yet clear if this is an implementation issue, or if the spec should be changed to allow this as well.


I think it's important that this is sorted out before presenting the proposal to the Committee (you want to give the impression that you've researched and understood future interactions with prefix types). In particular, why is this happening?

You may also ask the Dotty team about more clarifications in the issue tracker if you cannot find the root of the problem. /cc @smarter

After investigating this further for TLS, I figured out that the SIP23 proposal (and implementation) should be changed to support infix and negative literal type interaction. Interestingly, implementing prefix types resolves this issue, because a - prefix type has a special case to handle negative literal types. Here is a branch I made that fixes SIP23:
https://github.com/soronpo/scala/blob/3aeb19a7ff9e9c2a1dda61899d4c6482cdd8343e/src/compiler/scala/tools/nsc/ast/parser/Parsers.scala#L1052
You can see that a Spec change is required to handle NegativeNumericLiteral inside a compound type.
The prefix expression implementation does the same thing, so that is why we don't have such a bug with infix expressions and negative literal values.

I think that SIP-23 should handle negated numeric literal types more smoothly than it does at present (see the example at the head of typelevel/scala#157). However I think that the prefix type proposal goes beyond and is somewhat orthogonal to this, so I think it deserves a separate SIP.

@soronpo Can you update this last part and we merge? Thanks for your hard work Oron.

soronpo added 6 commits October 25, 2017 18:25

Splitting SIP33

455a604

New SIP files

1eeb612

Merge branch 'master' of https://github.com/scala/docs.scala-lang

f304d57

Updates SIP 33 and new SIP-NN(prefix types)

5cc5971

Added updated PR links

010ec45

redundant file

97bddb1

jvican self-assigned this Oct 27, 2017

jvican reviewed Oct 29, 2017

View reviewed changes

soronpo added 5 commits November 29, 2017 14:26

Merge https://github.com/scala/docs.scala-lang

aa8603f

Update to prefix types SIP, according to feedback on the PR.

173b2fb

Update to SIP33 and added example to prefix types use

2174172

Minor grammer change.

9334cd2

Update history table

513b47c

jvican merged commit 9acaa81 into scala:master Nov 29, 2017


		The [singleton-ops library](https://github.com/fthomas/singleton-ops) with [Typelevel Scala](https://github.com/typelevel/scala) (which implemented [SIP-23](http://docs.scala-lang.org/sips/pending/42.type.html)) enable developers to express literal type operations more intuitively. For example:

		```scala


		---

		## Proposal

Split SIP33 into two SIPs #905

Split SIP33 into two SIPs #905

Uh oh!

Conversation

soronpo commented Oct 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SethTisue commented Oct 26, 2017

Uh oh!

soronpo commented Oct 26, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jvican commented Oct 27, 2017

Uh oh!

heathermiller commented Oct 27, 2017

Uh oh!

jvican left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

soronpo Oct 31, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

soronpo Oct 31, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

soronpo commented Oct 25, 2017 •

edited

Loading

soronpo commented Oct 26, 2017 •

edited

Loading

soronpo Oct 31, 2017 •

edited

Loading

soronpo Oct 31, 2017 •

edited

Loading