February SIP Meeting Minutes #762
Conversation
|
@heathermiller You missed this one, have a look! |
|
Whoa this is detailed! |
There was a problem hiding this comment.
Hey @travissarles, this is a great deal of work. Thank you for putting this together!
I've left a few comments, merely with formalities or some suggestions. I've seen that there's some data missing, I'll help you out to fill it in soon.
Regarding the conclusions I mention, I will give you all the bits of knowledge to write them up. For instance, the new number of the numbered SIPs, et cetera.
| * Lukas Rytz ([@lrytz](https://github.com/lrytz)), Lightbend | ||
| * Seth Tisue ([@SethTisue](https://github.com/SethTisue)), Lightbend | ||
| * Iulian Dragos ([@dragos](https://github.com/dragos)), Independent | ||
| ????* Heather Miller ([@heathermiller](https://github.com/heathermiller)), Scala Center |
There was a problem hiding this comment.
Can we put Heather in a section named "Absent attendees"? Ah! We should also put Josh Suereth there 😄. This is the full list of Committee members. http://docs.scala-lang.org/sips/sip-submission.html
There was a problem hiding this comment.
I agree it's good to say who wasn't there.
|
|
||
| * Martin Odersky ([@odersky](https://github.com/odersky)), EPFL | ||
| * Dmitry Petrashko (@DarkDimius)(https://github.com/DarkDimius), EPFL | ||
| * Lukas Rytz ([@lrytz](https://github.com/lrytz)), Lightbend |
There was a problem hiding this comment.
Lukas attended the meeting representing Adriaan. What do you think if we remove Adriaan and we make this fact explicit in this line? 😄
There was a problem hiding this comment.
agree, it should be clear that Lukas isn't on the committee
| ### SIP 25 - @static fields and methods in Scala objects(SI-4581) | ||
| Jorge asks Dmitry to explain the biggest changes since the last proposal. | ||
| The biggest changes were addressing the feedback of reader. | ||
| **Dmitry** says which included three questions. first cover whether the static can be tail ____ annotation (1:30) which doesn't actually impact compilation but only warns if it isn't possible to make something static. I don't think so because static effects binary compatibility. Also, it depends on the superclass. If the superclass defined a field with the same name, the subclass can't have it. If we decide to make something static, we only be able to do it if the superclass doesn't have the fields with the same name. If static is done automatically and not triggered by the user we will enforce very strong requirements on superclass objects which is no-go. |
There was a problem hiding this comment.
"First, he covers whether the static annotation can behave like the tail recursive annotation."
There was a problem hiding this comment.
I don't think so -> Dmitry doesn't think the static annotation should have the same sematnics because it effects binary compatibility.
| The biggest changes were addressing the feedback of reader. | ||
| **Dmitry** says which included three questions. first cover whether the static can be tail ____ annotation (1:30) which doesn't actually impact compilation but only warns if it isn't possible to make something static. I don't think so because static effects binary compatibility. Also, it depends on the superclass. If the superclass defined a field with the same name, the subclass can't have it. If we decide to make something static, we only be able to do it if the superclass doesn't have the fields with the same name. If static is done automatically and not triggered by the user we will enforce very strong requirements on superclass objects which is no-go. | ||
|
|
||
| I proposed a scheme (which I elaborate more on the details frictions in the SIP). I present several examples of possible issues in this case. |
There was a problem hiding this comment.
Can we replace all reference to "I" by "He" or the person that is speaking? I think it reads more natural!
There was a problem hiding this comment.
"Details frictions" didn't make sense to me but that's what I heard when i replayed it a few times. This one was hard to summarize but the last two were easier.
|
|
||
| **Martin** How can that be done? | ||
|
|
||
| **Dmitry** Just refer to the class in bytecode. Just mention the signature |
|
|
||
| **Dmitry** We don't require them but I'm not sure about Scalac. Does Scalac use initializers or trait setters? | ||
|
|
||
| **Sébastien** Trait setters |
There was a problem hiding this comment.
Missing dot at the end, same for some other interventions in the conversation.
| **Jorge** We have to pass here both on this proposal as is right now but I think this could be dangerous in the case where we don't have an implementation for Scalac because maybe the details change and assume something in Scalac that the SIP is not able to predict or guard against it. Let's wait until next month and I will double check whether this is possible or not. Then I will get in touch with the Lightbend team to see whether this can be implemented or not. We'll decide in a month whether it should be accepted. | ||
|
|
||
| **Sébastien** ScalaJS already implemented it under another name but it's supposed to be conservative with respect to the aesthetic SIP in the sense that things that are allowed now with @jsstatic will also be allowed with @static. @static might open up a little bit more. | ||
|
|
There was a problem hiding this comment.
Can we add a short "Conclusion" paragraph at the end of every discussion to summarize the decision that was taken? You can get inspiration from other minutes in the past 😄.
|
|
||
| ### SIP-NN - Allow referring to other arguments in default parameters (22:30) | ||
| Sébastien is the reviewer | ||
| **Sébastien** The SIP is a generalization of why we can use in default values of parameters. Especially referring to other arguments. In current Scala we can refer to arguments in previous parameter lists. This SIP wants to open that up. The way it's currently written, any parameter whether it's in the same parameter list or a previous one, it's also allowed to refer to argument on the right. The text needs to be elaborated on use cases. Doesn't address implementation concerns. Jorge answered on the PR with analysis of feasibility. I'm convinced that the version where we can also refer to a parameter on the right is infeasible because you can have arbitrary cycles and you don't know _______ ( 24:55) and it's completely impossible. Other than that, in principle the SIP looks reasonable. It's possible to implement but it will cause more bytecode because now the third parameter will always need to receive the first two parameters to decide its value. We cannot decide that whether based on the default value actually refers to the previous parameters because that would be unstable in respect to binary compatibility. You need to always give to the default accessor all the prior parameters and that means it can potentially increase bytecode size. That needs to be analyzed maybe with a prototype, compare with Scala library. |
| Sébastien is the reviewer | ||
| **Sébastien** The SIP is a generalization of why we can use in default values of parameters. Especially referring to other arguments. In current Scala we can refer to arguments in previous parameter lists. This SIP wants to open that up. The way it's currently written, any parameter whether it's in the same parameter list or a previous one, it's also allowed to refer to argument on the right. The text needs to be elaborated on use cases. Doesn't address implementation concerns. Jorge answered on the PR with analysis of feasibility. I'm convinced that the version where we can also refer to a parameter on the right is infeasible because you can have arbitrary cycles and you don't know _______ ( 24:55) and it's completely impossible. Other than that, in principle the SIP looks reasonable. It's possible to implement but it will cause more bytecode because now the third parameter will always need to receive the first two parameters to decide its value. We cannot decide that whether based on the default value actually refers to the previous parameters because that would be unstable in respect to binary compatibility. You need to always give to the default accessor all the prior parameters and that means it can potentially increase bytecode size. That needs to be analyzed maybe with a prototype, compare with Scala library. | ||
|
|
||
| **Jorge** I implemented this. I did a study and analysis of whether referring to parameters on the right is visible and I've explained in a comment in the PR why it's not. Basically this is a change that would require breaking binary compatibility and this would be targeting 2.13 so we are not gonna see it any time soon. I think that it would be very useful to have a look at the numbers to see how it affects bytecode size. I'll run some benchmarks and report the results in the PR. |
There was a problem hiding this comment.
Link to the implementation prototype: scala/scala#5641.
|
|
||
| **Eugene** If it's on the lefthand side of the equals signs type member, then it's covariant. As long as it's in a binding position, unary infix, should work. | ||
|
|
||
| **Jorge** Will vote later. |
There was a problem hiding this comment.
In the conclusion, we should put that the vote took part outside the meeting and that this proposal was numbered. All the Committee members have accepted the change (even the abstent members).
|
In general we don't have to transcribe the entire meeting. I think that this would, in general, take way too long. It'd make more sense in future minutes to just make summaries of the discussions. However, this LGTM except for the minor tweaks I suggested 🙂 Well done señor @travissarles! |
| | [SIP 25 - @static fields and methods in Scala objects(SI-4581)](http://docs.scala-lang.org/sips/pending/static-members.html) | Dmitry Petrashko, Sébastien Doeraene and Martin Odersky | | ||
| | [SIP-NN - Match infix & prefix types to meet expression rules](http://docs.scala-lang.org/sips/pending/make-types-behave-like-expressions.html) | Oron Port | | ||
|
|
||
| Jorge Vicente Cantero was the Process Lead and acting secretary of the meeting. |
There was a problem hiding this comment.
Well, technically Travis was the secretary of the meeting this time o_o
| The meeting took place at 5:00pm Central European Time / 8:00am Pacific Daylight | ||
| Time on Tuesday, 14th February 2016 via Google Hangouts. | ||
|
|
||
| Minutes were taken by Jorge Vicente Cantero, acting secretary. |
There was a problem hiding this comment.
Again, it was @travissarles... :)
| * Lukas Rytz ([@lrytz](https://github.com/lrytz)), Lightbend | ||
| * Seth Tisue ([@SethTisue](https://github.com/SethTisue)), Lightbend | ||
| * Iulian Dragos ([@dragos](https://github.com/dragos)), Independent | ||
| ????* Heather Miller ([@heathermiller](https://github.com/heathermiller)), Scala Center |
There was a problem hiding this comment.
You can delete me because I definitely wasn't present :-(
| * Sébastien Doeraene ([@sjrd](https://github.com/sjrd)), EPFL | ||
| * Eugene Burmako ([@xeno-by](https://github.com/xeno-by)), EPFL | ||
| * Jorge Vicente Cantero ([@jvican](https://github.com/jvican)), Process Lead | ||
| ?????* Adriaan Moors ([@adriaanm](https://github.com/adriaanm)), Lightbend |
There was a problem hiding this comment.
@jvican Adriaan was on vacation, right? So we should also remove him.
| **Sébastien** SIP addendum, Type Members: In current Scala in the same way that you can only refer to parameters on terms previous parameter lists you can also only refer to path-dependent types of parameters in previous parameter lists and there is a small section in the SIP that says in the same vein we should allow to refer to path-dependent types of parameters in the same parameter list probably on the left. But for that one I don't have a good intuition of what effects it would have on type inference because type inference works parameter list per parameter list. The fact that you cannot refer to path-dependent types from the same parameter list means you can complete type inference from one parameter list without juggling path-dependent types within the same thing. Then when you move to the next one it's already inferred from the previous parameters. So it seems simpler but it's just a guest. Martin, would that be problematic? | ||
|
|
||
| **Martin** It would be a completely sweeping change. It's one of the key types that suddenly becomes recursive. So you can imagine what that means. Every time we construct such a type we can't do it inductively anymore. So basically it's the difference between polytypes and method types. I'm not saying it's impossible but it would be a huge change the compiler to do that. It's probably beyond what we can do for Scalac and just for Dotty we could think about it but it would be a very big change. | ||
|
|
There was a problem hiding this comment.
A conclusion is missing here, as well as the decision that was taken!
| * Lukas Rytz ([@lrytz](https://github.com/lrytz)), Lightbend | ||
| * Seth Tisue ([@SethTisue](https://github.com/SethTisue)), Lightbend | ||
| * Iulian Dragos ([@dragos](https://github.com/dragos)), Independent | ||
| ????* Heather Miller ([@heathermiller](https://github.com/heathermiller)), Scala Center |
There was a problem hiding this comment.
I agree it's good to say who wasn't there.
| * Sébastien Doeraene ([@sjrd](https://github.com/sjrd)), EPFL | ||
| * Eugene Burmako ([@xeno-by](https://github.com/xeno-by)), EPFL | ||
| * Jorge Vicente Cantero ([@jvican](https://github.com/jvican)), Process Lead | ||
| ?????* Adriaan Moors ([@adriaanm](https://github.com/adriaanm)), Lightbend |
|
|
||
| * Martin Odersky ([@odersky](https://github.com/odersky)), EPFL | ||
| * Dmitry Petrashko (@DarkDimius)(https://github.com/DarkDimius), EPFL | ||
| * Lukas Rytz ([@lrytz](https://github.com/lrytz)), Lightbend |
There was a problem hiding this comment.
agree, it should be clear that Lukas isn't on the committee
|
|
||
| ### SIP 25 - @static fields and methods in Scala objects(SI-4581) | ||
| Jorge asks Dmitry to explain the biggest changes since the last proposal. | ||
| The biggest changes were addressing the feedback of reader. |
| The biggest changes were addressing the feedback of reader. | ||
| **Dmitry** says which included three questions. first cover whether the static can be tail ____ annotation (1:30) which doesn't actually impact compilation but only warns if it isn't possible to make something static. I don't think so because static effects binary compatibility. Also, it depends on the superclass. If the superclass defined a field with the same name, the subclass can't have it. If we decide to make something static, we only be able to do it if the superclass doesn't have the fields with the same name. If static is done automatically and not triggered by the user we will enforce very strong requirements on superclass objects which is no-go. | ||
|
|
||
| I proposed a scheme (which I elaborate more on the details frictions in the SIP). I present several examples of possible issues in this case. |
|
|
||
| I proposed a scheme (which I elaborate more on the details frictions in the SIP). I present several examples of possible issues in this case. | ||
|
|
||
| The other question was clarify how does the static effect initialization order and also describe if it effects binary compatibility. In general, emitting fields as static changes when they get initialized. They get initialized when the class is being class-loaded. The SIP in the current state requires static fields to be the first field defined in the object which means that these fields will be initialized before the other fields (indepenently of whether they are marked static or not). This leads to the fact that inside the object itself it will be possible to observe if something is static or not. Unless you rely on some class loader magic or reflection. At the same time, it is still possible to observe whether a field is static or not using multiple classes. Let's say you have a superclass of the object. If the superclass tries to see if the static field is initialized. In the case the field is static, it will be initialized before the superclass constructor executes. In case it's not static, it won't be initialized. |
|
|
||
| **Sébastien** That's not written in the SIPs. | ||
|
|
||
| **Dmitry** Will update. The last question is whether it will effect binary compatibility. YES! The point is you should be able to call and access stuff which is static through a more efficient way on the JVM. So removing @static annotation will be a binary incompatible change. If we add forwarders, adding static won't be a binary incompatible change because you'll still have fowarders which forward to the static thing. Both methods and fields. |
There was a problem hiding this comment.
needs backquotes around @static so we aren't @-mentioning that GitHub user. there are other places that need this fix too
|
|
||
| **Martin** Or write it in Java | ||
|
|
||
| **Dmitry** The current situations has several solutions. The first is write it in Java, the second is make it a source dependency, download the source, and compile it in runtime and the third one use your best judgement is to try to write Scala which you assume will be safe. At the same time there is a tool which is called MIMA (sp?) which helps you to see whether you did it right. MIMA allows you to compare two already-compiled artifacts and say whether they're compatible or not. This SIP proposes something which will complement MIMA in indicating whether the thing will be compatible with the next version. So currently if you were to write a file in Scala compiled with 2.10 and then compile it to 2.11, MIMA can after-the-fact say that it's incompatible and previous version should have been more conservative with the features it used. It does it after the fact when 2.11 was already released. Your artifacts are already on Bintray and it's too late. stableABI augments this use case by allowing you to get a guarantee that this artifact will be reliably compiled by all the compilers which call themselves Scala, across all the major versions, and can be used by the code compiled by those compilers. The idea would be that stableABI classes can be either used for projects which need to survive multiple Scala major versions or for other languages which don't have such a strong binary API guarantee such as Java and Kotlin. And additionally it has a very strong use case of allowing to use features of future compilers and future language releases in libraries which try to support users who are still on the old versions. |
| title: SIP Meeting Minutes - 29th November 2016 | ||
| --- | ||
|
|
||
| # Minutes |
There was a problem hiding this comment.
Hey @travissarles, can you open a new PR for the minutes in February?
| Attendees Present: | ||
|
|
||
| * Martin Odersky ([@odersky](https://github.com/odersky)), EPFL | ||
| * Dmitry Petrashko (@DarkDimius)(https://github.com/DarkDimius), EPFL |
There was a problem hiding this comment.
The markup is wrong here. The handle should be in square brackets and the whole thing in round parens.
|
|
||
| Absent: | ||
| * Heather Miller ([@heathermiller](https://github.com/heathermiller)), Scala Center | ||
| * Josh Suereth ([jsuereth](https://github.com/jsuereth)), |
| ### SIP 25 - @static fields and methods in Scala objects(SI-4581) | ||
| Jorge asks Dmitry to explain the biggest changes since the last proposal. | ||
| The biggest changes were addressing the feedback of reader. | ||
| **Dmitry** First, he covers whether the static annotation can behave like the tail recursive annotation, which doesn't actually impact compilation but only warns if it isn't possible to make something static. Dmitry doesn't think the static annotation should have the same semantics because it affects binary compatibility. Also, it depends on the superclass. If the superclass defined a field with the same name, the subclass can't have it. If we decide to make something static, we only be able to do it if the superclass doesn't have the fields with the same name. If static is done automatically and not triggered by the user we will enforce very strong requirements on superclass objects which is no-go. |
There was a problem hiding this comment.
I think you should add a newline before this to break it off the previous paragraph.
|
|
||
| ### SIP-NN - [Allow referring to other arguments in default parameters](https://github.com/scala/scala.github.com/pull/653) (22:30) | ||
| Sébastien is the reviewer | ||
| **Sébastien** The SIP is a generalization of why we can use in default values of parameters. Especially referring to other arguments. In current Scala we can refer to arguments in previous parameter lists. This SIP wants to open that up. The way it's currently written, any parameter whether it's in the same parameter list or a previous one, it's also allowed to refer to argument on the right. The text needs to be elaborated on use cases. Doesn't address implementation concerns. Jorge answered on the PR with analysis of feasibility. I'm convinced that the version where we can also refer to a parameter on the right is infeasible because you can have arbitrary cycles and you don't know _______ ( 24:55) and it's completely impossible. Other than that, in principle the SIP looks reasonable. It's possible to implement but it will cause more bytecode because now the third parameter will always need to receive the first two parameters to decide its value. We cannot decide that whether based on the default value actually refers to the previous parameters because that would be unstable in respect to binary compatibility. You need to always give to the default accessor all the prior parameters and that means it can potentially increase bytecode size. That needs to be analyzed maybe with a prototype, compare with Scala library. |
There was a problem hiding this comment.
Here too, add a newline to break the lead-in from what Sebastien said.
travissarles
force-pushed
the
meetingminutes
branch
from
9030661 to
8558c27
Compare
|
@jvican anything else? |
|
@travissarles i'm reviewing both PRs tomorrow 😄. |
|
|
||
| **Sébastien** ScalaJS already implemented it under another name but it's supposed to be conservative with respect to the aesthetic SIP in the sense that things that are allowed now with @jsstatic will also be allowed with @static. @static might open up a little bit more. | ||
|
|
||
| **Conclusion** We need an implementation for Scalac. Lightbend hasn't discussed working on this yet. We will pass on this proposal. |
There was a problem hiding this comment.
Conclusion: The static SIP proposal has to be implemented in Scala, as it's already present in Dotty. Triplequote (Iulian Dragos and Mirco Dotta) has offered to provide an implementation targeting 2.12.3.
|
|
||
| The current SIP tries to make it behave as expected by the users in common cases. | ||
|
|
||
| Conclusion: |
| **Conclusion** We need an implementation for Scalac. Lightbend hasn't discussed working on this yet. We will pass on this proposal. | ||
|
|
||
| ### SIP-NN - [Allow referring to other arguments in default parameters](https://github.com/scala/scala.github.com/pull/653) (22:30) | ||
| Sébastien is the reviewer |
There was a problem hiding this comment.
"is the reviewer of this proposal."
|
|
||
| **Martin** It would be a completely sweeping change. It's one of the key types that suddenly becomes recursive. So you can imagine what that means. Every time we construct such a type we can't do it inductively anymore. So basically it's the difference between polytypes and method types. I'm not saying it's impossible but it would be a huge change the compiler to do that. It's probably beyond what we can do for Scalac and just for Dotty we could think about it but it would be a very big change. | ||
|
|
||
| **Conclusion** This is a sweeping change. There could be some unexpected corner cases. We will not see it any time soon. |
There was a problem hiding this comment.
Conclusion: The proposal has been numbered as SIP-32. The reference to type members seems tricky in implementation and interaction and it may be removed as the analysis of this SIP continues. The reference to other arguments in the same parameter list has been implemented by Jorge in scala/scala#5641.
|
|
||
| **Martin** That is true. You want to make a rule that newer compilers can ____ (1:02:54) the older ones but not the other way around. | ||
|
|
||
| **Conclusion**: We will sleep on this. |
There was a problem hiding this comment.
Conclusion: This proposal has been numbered as SIP-34. This is a complicated proposal that needs synchronization between the Scala and Dotty team to decide which encodings are good enough to make binary compatible. When Dmitry, the author of this proposal, figures out which features should be binary compatible and has more information on the future implementation, the SIP Committee will start the review period.
|
|
||
| **Jorge** We will vote later. | ||
|
|
||
| **Conclusion** The vote took place outside the meeting and the proposal was numbered. All of the committee members (including those absent) have accepted the change. |
There was a problem hiding this comment.
This proposal has been numbered as SIP-33.
No description provided.