Add SIP-23: Literal-based singleton types #346

folone · 2014-06-27T14:52:15Z

Hello folks,

Looks like we've discussed all the details on the mailing lists (scala-language and scala-sips), and there seem to be a general agreement on what this feature has to look like. So I decided to be bold, and go ahead with porting the draft document to markdown, incorporating all the suggestions from mailing lists as well as comments from the document itself.

Just read through the SIP Submission Process document, and it looks like I've messed up some intermediate steps (for example I've posted to scala-language instead of scala-debates). Hope this is okay. Also not sure if I can have number 42 for this SIP. Hope this is okay too :)

Please let me know what you think.

/cc @xeno-by @retronym @adriaanm @paulp @odersky @milessabin @gkossakowski @heathermiller

xeno-by · 2014-06-27T20:52:19Z

+1 for SIP-42 :)

heathermiller · 2014-06-27T21:38:36Z

You'd be SIP-23. Not 42.

heathermiller · 2014-06-28T02:41:46Z

Just had time to read through the entire SIP. Looks great George! I'm happy to pull this in, can either @adriaanm or @retronym give a quick OK?

folone · 2014-06-29T19:24:40Z

Thanks @heathermiller! Just to make sure: is it completely impossible to skip a few numbers and get 42 for this one? :)

adriaanm · 2014-06-30T15:00:04Z

Thanks for writing this up, @folone! I'll have a look this week. Hopefully in the first half.

heathermiller · 2014-07-01T05:25:43Z

Yes, this isn't for fun – this is a serious language improvement proposal.

folone · 2014-07-01T07:20:49Z

@heathermiller Those two things are not mutually exclusive in my world :) I get what you're saying though, sorry for being silly: sometimes I cannot help it.
Another thing I wanted to clarify: there's an open PR with SIP-23: #295. Should I ignore it and still use 23?

folone · 2014-07-01T07:21:04Z

@adriaanm Thanks, looking forward to your comments!

10000

xeno-by · 2014-07-01T07:32:21Z

The index 42 comes from the fact that this feature was codenamed 42.type from the very beginning. I can see how having the SIP called SIP-42 might be confusing, but there's also history, which might be cool to honor. WDYT?

odersky · 2014-07-01T08:33:44Z

On Tue, Jul 1, 2014 at 9:32 AM, Eugene Burmako notifications@github.com
wrote:

The index 42 comes from the fact that this feature was codenamed 42.type
from the very beginning. I can see how having the SIP called SIP-42 might
be confusing, but there's also history, which might be cool to honor. WDYT?

Let's keep SIP numbers serial. SIP-42 is cute, but no reason throw our
numbering out. We can always reword 42.type to 23.type in the proposal.

Martin

—

Reply to this email directly or view it on GitHub
#346 (comment)
.

Martin Odersky
EPFL and Typesafe

xeno-by · 2014-07-01T08:36:01Z

Allright, fair enough. Let's keep 42.type though :)

folone · 2014-07-01T09:28:00Z

@xeno-by I'll make sure 42.type will not be going anywhere :)

milessabin · 2014-07-01T19:53:55Z

TBH, I reckon that 23 is a better magic number than 42 anyway ;-)

Cheers,

Miles

On Tue, Jul 1, 2014 at 10:28 AM, George Leontiev notifications@github.com
wrote:

@xeno-by https://github.com/xeno-by I'll make sure 42.type is not going
anywhere :)

—
Reply to this email directly or view it on GitHub
#346 (comment)
.

Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: miles@milessabin.com
g+: http://www.milessabin.com
http://twitter.com/milessabin

folone · 2014-07-02T08:58:36Z

@heathermiller I went ahead and changed the number to SIP-23. Will wait for @adriaanm and/or @retronym to have a look at the document, address their review and then, after everyone thinks the document is good to go, will squash everything into one commit.

heathermiller · 2014-07-02T13:12:24Z

10000

Sounds good! Thanks a lot George :)

folone · 2014-07-07T18:27:16Z

So, someone just told me that @adriaanm is going on vacation end of this month, and I should bother him really hard if I want this merged any time before mid fall :)

adriaanm · 2014-07-07T18:32:50Z

Someone was right. Thanks for the ping. It's in my starred items/TODO list :)

folone · 2014-07-07T18:40:50Z

@adriaanm thank you!

adriaanm · 2014-07-08T11:48:58Z

As you know, I like the SIP and I'll champion it.

The main reason for my slow down is that I wanted to rethink our SIP process. I'd like to split it in two phases: accept the SIP as "a good idea" (votes by the community, potential veto by SIP committee), and then refine/flesh out the SIP (the champion on the SIP committee guides the process, decides on timeline,...). I haven't really read up on state of the art in our own SIP process, I must admit.

We all agree the SIP is a great idea, but we need to flesh out things like interaction with type inference and erasure (need to specify the wide type of the literals). I also agree it should be adopted in 2.12 (or even 2.11 under -Xexperimental).

I have some concerns with the implementation. I think we should distinguish ConstantType (expression is pure and constant-folded) and SingletonType (expression always has the same value, but may have side-effects). In any case, the final SIP (we can accept it into phase 1 before) should contain a section that explains how to update the spec, and all implementation details should be collected in a separate section.

Regarding the interaction with type inference, I think a <: Singleton bound should suffice. To get a hold of a type's value, I'd propose valueOf[T] (and while we're at it, zeroOf[T]).

folone · 2014-07-08T20:02:38Z

Agreed. Will look into the things you mentioned. By the way, what would zeroOf[T] return?

adriaanm · 2014-07-09T08:29:47Z

By the way, what would zeroOf[T] return?

https://github.com/scala/scala/blob/2.12.x/src/reflect/scala/reflect/internal/TreeGen.scala#L260

heathermiller · 2014-07-09T09:19:26Z

@adriaanm, RE: your points about the SIP process... I fully agree that the SIP process needs to be refined – it's simply too much to seem open to accepting changes to the language/libs without a more refined process to ensure that both the idea and the implementation are solid on all fronts.

And I agree with this two-phase idea.

Publishing the SIP on http://docs.scala-lang.org/sips (following discussion on the mailing lists etc) seems like the halfway marker through phase one.

So, given that, would it make sense to pull just the SIP document in, so it's a bit more visible and discussable?

adriaanm · 2014-07-09T09:25:05Z

Makes sense, polish can happen in another PR.
Maybe we can still add a line that I'm championing this PR, but that doesn't yet mean it will be adopted for sure?

I'll try to write something up for the docs site to explain the process before the end of the month.

heathermiller · 2014-07-09T09:32:46Z

Sure, sounds good. ping @folone?

Also, the writing of the SIP can be refined as implementation details etc are discussed, and the SIP can simply be marked as "Updated Marchtember eleventeenth, 2014" as refinements are made. Just one option.

@adriaanm

- Add @adriaanm as this SIP's champion - Mention that there is no commitment to definitely have it in - Add last update date

adriaanm · 2014-07-09T10:11:20Z

LGTM!

heathermiller · 2014-07-09T10:11:59Z

Awesome, thanks guys :)

Add SIP-23: Literal-based singleton types

folone · 2014-07-09T10:12:58Z

@heathermiller @adriaanm You guys are super fast! I was just about to ping you.

xeno-by · 2014-07-09T10:15:59Z

\o/

milessabin · 2014-07-13T12:47:31Z

@adriaanm can you flesh out what you have in mind with valueOf and zeroOf a little more? Are these intended to be methods (ie. like typeOf)? In which case presumably we would need corresponding implicit witnesses ... are you proposing to fold that into type tags or add something new?

milessabin · 2014-07-13T12:51:03Z

It's a fix for SI-5103 which would make shapeless's singleton-type related macros go away, not singleton types for literals. The latter (ie. this SIP) will be useful (eg. for specifying shapeless record types in some cases) but the use case section is overselling it wrt shapeless.

milessabin · 2014-07-13T12:59:59Z

We're also missing singleton types for Symbol literals. To some extent this is understandable given that Scala doesn't internally represent singleton types for symbols, but this is itself an omission given that symbols have first class literal syntax.

I've approximated symbol singleton types in shapeless by tagging Symbol with the singleton type of the corresponding String literal, ie. 'foo : Symbol @@ String("foo"). It'd be nice to have a direct way of expressing that.

Examples of use here where singleton-typed Symbols are used as record keys.

adriaanm · 2014-07-22T08:50:11Z

@adriaanm can you flesh out what you have in mind with valueOf and zeroOf a little more?

I hadn't fleshed it out more than that valueOf[x.type] would lower the singleton type to the value x. You're right that the interesting part lies in synthesizing the implicit ev: HasValue[T] for the type argument T...

milessabin · 2014-07-22T17:49:40Z

@adriaanm FYI, this is how it's done in shapeless: Witness/WitnessWith, some syntax and a few examples.

adriaanm · 2016-08-14T15:57:54Z

Hi, we discussed this SIP in the SIP meeting last week. I have a few questions & suggestions to get this going again:

feature interactions

The sip is great with examples and motivation, but needs a bit more work in the feature interactions area (always the hardest part, but really important!)

do we need the lowering macro in the stdlib? if so, can it be integrated with, say SingletonTypeTag somehow?
since we're adding a type with new meaning, we should specify its behavior with respect to asInstanceOf, isInstanceOf and type patterns. Since the first two are specified in terms of the pattern, let's start there. Currently, x asInstanceOf y.type does not mean the same thing as x: y.type in a pattern, since the asInstanceOf does not imply x eq y. Existing code will break if we enforce this.
Also note that literal paths in singleton types do not have an eq method, so we're using ==, which is fine, but needs to be specified. Maybe some day we can factor out the top of the hierarchy, as dotty is doing -- would be good to ping them about this.
the logic behind widening types inferred for val signatures is crucial to make this SIP convenient/useful -- lets add a description to the specification how this works
quasiquotes need to be updated

misc

the sip description currently refers throughout to the implementation. I think it would be better to first focus on the concept and then discuss implementation in a separate appendix (it's too tempting to drive the spec from the implementation needs otherwise)

DarkDimius · 2016-08-15T09:22:35Z

since we're adding a type with new meaning, we should specify its behavior with respect to asInstanceOf, isInstanceOf and type patterns. Since the first two are specified in terms of the pattern, let's start there. Currently, x asInstanceOf y.type does not mean the same thing as x: y.type in a pattern, since the asInstanceOf does not imply x eq y. Existing code will break if we enforce this.

Also, note that this.type already exists and casting to it is used in some code patterns.

milessabin · 2016-08-16T07:56:25Z

Several years of experience with shapeless and shapeless-based libraries suggests that, yes, we do need the ability to drop from the type to the value level. Adding language level support here removes the need for macros elsewhere.
I'm open to suggestions, but I don't see how this could be integrated cleanly with TypeTags. We need a unique value, which will only be available for singleton types, whereas TypeTags are defined for both singleton and non-singleton types.
I don't follow what you mean by "we're adding a type with new meaning" ... are you referring specifically to ValueOf? ValueOf is intended to have as little semantics as possible ... in effect it's just a newtype to allow us to materialize a unique value without polluting the implicit scope for the underlying type.
Agreed on describing the narrowing/widening logic. I modified the behaviour from where you left it to make it as small a change from the status quo as possible, but the status quo (esp. wrt the significance of final) wasn't particularly well documented, so the more the better.
Can you say what needs updating in quasiquotes? I think they should function as intended, and respect the setting of the flag in the running compiler.

paulp · 2016-08-16T15:12:11Z

I don't follow what you mean by "we're adding a type with new meaning" ... are you referring specifically to ValueOf?

I believe he's referring to LiteralType.

milessabin · 2016-08-16T15:37:04Z

I believe he's referring to LiteralType.

Ah, right. Both LiteralType and FoldableConstantType are internal to the implementation. I agree they should be documented as part of the implementation, but I don't think they should be mentioned in the SIP or the SLS.

As types they aren't new ... they're singleton types of particular values and have been represented in Scala's type system, albeit without syntax, for aeons.

paulp · 2016-08-16T16:29:06Z

You can read "we're adding a type with new meaning" as "we're adding a type syntax with previously inexpressible meaning."

Add SIP-42.

1daf491

SIP-42 -> SIP-23

217022e

folone changed the title ~~Add SIP-42.~~ Add SIP-23: Literal-based singleton types Jul 2, 2014

Update the header of SIP-23:

b800dd5

- Add @adriaanm as this SIP's champion - Mention that there is no commitment to definitely have it in - Add last update date

heathermiller added a commit that referenced this pull request Jul 9, 2014

Merge pull request #346 from folone/topic/sip-42

27c57fb

Add SIP-23: Literal-based singleton types

heathermiller merged commit 27c57fb into scala:master Jul 9, 2014

folone deleted the topic/sip-42 branch July 9, 2014 10:13

adriaanm mentioned this pull request Aug 14, 2016

SIP-23 Implementation of literal types scala/scala#5310

Merged

Add SIP-23: Literal-based singleton types #346

Add SIP-23: Literal-based singleton types #346

Uh oh!

Conversation

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

feature interactions

misc

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!