SIP Meeting Minutes - 25th October 2016

Language

    Minutes

    The following agenda was distributed to attendees:

    Topic Reviewer
    Discussion of the voting system N/A
    SIP-20: Improved Lazy Val Initialization Sébastien Doeraene
    SIP-27: Trailing commas Eugene Burmako

    Jorge Vicente Cantero was the Process Lead and acting secretary of the meeting.

    • Decided to reaccept for review: SIP-27: Trailing commas
    • Under review: SIP-20: Improved Lazy Val Initialization

    Date, Time and Location

    The meeting took place at 5:00pm Central European Time / 8:00am Pacific Daylight Time on Tuesday, October 25th, 2016 via Google Hangouts.

    Minutes were taken by Jorge Vicente Cantero, acting secretary.

    Attendees

    Attendees Present:

    Apologies

    Proceedings

    Opening Remarks

    After some controversy sprung by the latest SIP-27 vote, the SIP Process Lead cancelled the vote on the SIP-27: Trailing Commas, and invited the Committee to discuss new voting rules to help clarify the process voting system.

    The issue was caused by a legal void on the rounding of the 70% rule. Traditionally, votes are not rounded up. However, the SIP Process Lead took the decision to round up the SIP-27 vote percentage, which was 66%. This decision was taken in the best spirit of the rule, which was only introduced to ensure that simple majorities (50%) are not enough for accepting a proposal.

    Before the meeting, the SIP Process Lead shared this email with all the Committee members:

    The majority-plus-two rule sets a concrete threshold and fits the spirit of the rule (not having simple majority, but a supermajority). The 70% rule is too strict, especially for committees that are not big, as ours. After some research, we can choose the two-thirds rule used in a lot of political parties, parliaments, boards and committees.

    Deciding the voting system

    Sébastien starts the discussion pointing out that he would like to have a simple percentage, without any rounding. Heather argues that this percentage changes depending on the number of the present Committee Members. Seth comments that it has been proposed in several online channels that all the Committee members should vote, even if they cannot attend the meeting. All the Committee agrees on this, but the main consequence is that the voting period is not predictable anymore, since there’s not a fixed deadline to vote. Martin proposes to choose this fixed deadline case-by-case.

    Martin proposes that there’s a meta rule to only accept a proposal if 50% of all the Committee members vote for it, and then to have another percentage on the actual vote. Seth, Eugene and Heather don’t like this idea. Heather brings up the issue of abstentions, should they still be considered as no’s even if people are on vacation or cannot vote?. Adriaan says this is a fair concern, and thinks that there should be a fixed deadline for voting.

    All the Committee agrees that with the new rules the Committee wouldn’t vote publicly, because Committee members can notify their vote after the meeting and before the fixed deadline.

    Martin proposes to keep the old rules, the 70% percentage rule. Jorge proposes to have simpler and more predictable rules, and replace 70% with the two-thirds rule. Martin comes back to the abstentions point: he doesn’t want them to be considered as no, because with the current rules Committee members could block the whole decision process. Some Committee members point out that this wouldn’t happen because then the quorum wouldn’t be reached. The discussion shifts towards the quorum point: is it necessary anymore? Heather and Adriaan say that it is, because it ensures that a reasonable number of Committee members meet to discuss proposals and convince each other about the pros and cons. All the Committee finally decides to not consider abstentions as no’s. Adriaan, however, suggests that we should penalize people that abstain too often.

    Martin proposes a new system that helps survive the abstention issue mentioned before. For a proposal to pass, at least 50% of all the Committee and two-thirds of all the people voting (not counting abstentions) must accept it. The quorum rule is kept. After some discussion, the Committee unanimously votes in favor of Martin’s new system, along with not considering abstentions as no’s and allowing all the Committee members to vote after the meeting. These rules are formalized here.

    Discussion of SIP-27: Trailing Commas

    Eugene describes what happened in the last meeting. Martin asks if there is a concrete proposal. Jorge says that he thinks that Dale would push for the new line specialized case. Martin proposes to push for a more concrete proposal because the specification cannot be so open-ended to properly analyze the consequences of the suggested changes. Therefore, he suggests to vote on the proposal to see either if we continue its review or we stop its discussion.

    Seth and Adriaan voice their opinions on trailing commas again, they don’t agree this is a problem that should be solved in the language. Martin changes his view on the subject, and provided that the proposal does no harm to the syntax of the language and doesn’t cause problems, he would accept the change. He also says that it wouldn’t be good to contradict last month’s vote on the proposal. Heather says that she’s in favor of trailing commas because makes beginners be less confused by the syntax and help people get started with the language. Iulian doesn’t like the specialized version, he would prefer a general version. Josh is not present, but he will vote via email in the next week.

    Outcome: All the Committee (except Seth and Adriaan) decides to vote on accepting the proposal again for a final review. For this review, Dale has to update his proposal championing for one of the different changes to the syntax, and making a succinct specification whose consequences can be analysed by the Committee. Trailing commas will be reviewed in November.

    Discussion of SIP-20: Improved Lazy Val Initialization

    Sébastien comments the changes that Dmitry has introduced to the proposal. Several new schemes have been added to the proposal based on his experience in Dotty, in which the championed scheme is already implemented.

    There are no clear winner in the case of local lazy vals, but there seems to be two clear candidates for the non-local lazy vals (V4 and V6). Both are faster than the existing implementation in the contended case but V4 general is 4x and V6 is only 2x. However, for the uncontended case V4 general is 30% slower than the existing implementation, while V6 is on par, up to +-5%. Dmitry recommends the V6 case because it’s a pure win. Memory-wise, V6 would have a smaller memory footprint.

    Sébastien comments on the increase of the bytecode for the getter of the lazy val, which is 4x bigger. This could make a difference, although the benchmarks do not show any negative impact of it (probably because the previous implementation was bigger than the limits set by the JVM to benefit from code inlining).

    Jorge comments that there’s no implementation of this proposal for scalac. This means that someone should step up and provide such implementation, because Dmitry does not have time for it. Adriaan comments on the fact that V6 uses sun.misc.Unsafe, which he prefers that the compiler doesn’t depend on to run in other platforms that don’t allow it (Google App Engine). Sébastien highlights that the proposal could use var handles, which are planned to be shipped on Java 9.

    Heather proposes to mark this proposal as dormant, since it’s lacking an implementation. She wants to let other people claim its ownership and provide an implementation if they care about this issue. Jorge proposes to ask first Dmitry if he wants to champion V4, otherwise it would be marked as dormant.

    Outcome: The Committee agrees to wait for Dmitry’s response and then mark the proposal as dormant. The idea is to let someone pick it up and provide an implementation. Ideally, this implementation should run on Java 8 and not depend on var handles.

    Closing remarks

    See you next time!

    Scala Improvement Proposals (SIPs)
    SIP Meetings
    Submitting a SIP
    Problem with this page?
         Please help us fix it!