Add the minutes of September meeting 2016

Author: jvican

sips/minutes/_posts/2016-08-20-sip-20th-september-minutes.md

@@ -0,0 +1,238 @@
+---
+layout: sip-landing
+title: SIP Meeting Minutes - 20th September 2016
+---
+
+# Minutes
+
+The following agenda was distributed to attendees:
+
+| Topic | Reviewer |
+| --- | --- |
+| [SIP-NN: Scala Meta SIP](https://github.com/scala/scala.github.com/pull/567) | Iulian Dragos and Josh Suereth |
+| [SIP-21: Spores](http://docs.scala-lang.org/sips/pending/spores.html) | Martin Odersky |
+| [SIP-26: Unsigned Integer Data Types](https://github.com/scala/slip/pull/30) | Martin Odersky |
+| [SIP-27: Trailing commas](https://github.com/scala/scala.github.com/pull/533#issuecomment-232959066) | Eugene Burmako |
+
+Jorge Vicente Cantero was the Process Lead and acting secretary of the meeting.
+
+The following proposal was accepted:
+
+* SIP-27: Trailing commas
+
+The following proposal was rejected:
+
+* SIP-26: Unsigned Integer Data Types
+
+The following proposal will have a follow-up evaluation:
+
+* SIP-21: Spores
+
+The following proposals were numbered:
+
+* SIP-28: Inline (part of Scala Meta SIP)
+* SIP-29: Meta (part of Scala Meta SIP)
+
+## Date, Time and Location
+
+The meeting took place at 5:00pm Central European Time / 8:00am Pacific Daylight
+Time on Tuesday, September 20th, 2016 via Google Hangouts.
+
+Minutes were taken by Jorge Vicente Cantero, acting secretary.
+
+## Attendees
+
+Attendees Present:
+
+* Martin Odersky ([@odersky](github.com/odersky)), EPFL
+* Seth Tisue ([@SethTisue](github.com/SethTisue)), EPFL
+* Iulian Dragos ([@dragos](github.com/dragos)), Independent
+* Heather Miller ([@heathermiller](github.com/heathermiller)), Scala Center
+* Sébastien Doeraene ([@sjrd](github.com/sjrd)), EPFL
+* Eugene Burmako ([@xeno-by](github.com/xeno-by)), EPFL
+* Josh Suereth ([@jsuereth](github.com/jsuereth)), Google
+* Jorge Vicente Cantero ([@jvican](github.com/jvican)), Process Lead
+
+## Guests
+
+* Dale Wijnand ([@dwijnand](github.com/dwijnand)), author of SIP-27
+
+## Apologies
+
+* Andrew Marki ([@som-snytt](github.com/som-snytt)), independent
+* Adriaan Moors ([@adriaanm](github.com/adriaanm)), Lightbend
+
+## Proceedings
+### Opening Remarks
+
+As acting Process Lead, Jorge gave the welcome to Iulian Dragos, who has just
+joined the Committee. He's a natural fit for the Committee, because of
+his historical significance in the evolution of Scala and his vast experience in
+the current Scala compiler (scalac).
+
+Following to his introduction, he described the main points to the agenda and
+proceed to introduce the discussions.
+
+### Discussion of SIP-NN: Scala Meta SIP
+
+Josh and Iulian are the reviewers of the proposal. Josh starts explaining what
+the proposal is about. Scala Meta is split into two main parts: inline
+and meta. The purpose of this meeting is to number the proposal and kick start a
+previous discussion. Jorge proposes to vote, and Iulian points out that before
+voting he considers that inline and meta should be separate.
+
+Sébastien argues that it may not be possible, since they are tightly
+interconnected and meta relies heavily on a concrete behaviour of inline. Martin
+tends to agree with Iulian, and Josh claims that, if possible, studying both
+parts separately would be ideal. Sébastien is not sure that they can be
+reorganized to be completely orthogonal. Eugene confirms that the dependency
+between inline and meta is very big. For him, studying them separately is a
+concern because there could be a point where meta cannot happens because of the
+way inline was designed.
+
+Seth asks for further information on the interdependency. Sébastien argues that,
+conventionally, metaprogramming has relied on the eager execution of the formal
+parameters in a function. This may be undesirable for a number of reasons, and
+meta assumes that inline parameters result of a meta block are not eagerly
+executed and, instead, meta blocks can access the trees of the arguments. Eugene
+claims that we could see inline as just a mechanism to get the right hand side
+of an method definition and puts in the call-site. Eugene also clarifies that
+the dependency between the two is dual: inline also depends on meta, because
+inline also accounts for the presence of meta. Martin is not sure if that's
+completely true; his inline implementation in Dotty doesn't feature this
+dependency. Sébastien claims that one could argue that inline does not depend on
+meta, and that the requirement of recursively inlining arguments and method
+definitions before the macro expansion is unique to meta, not inline.
+
+Josh understands that both parts are specially hooked together so that their
+interaction has concrete results. Martin argues that it would make sense to
+split both proposals and study them independently if we can give some guarantees
+on the finally-accepted proposals. Martin proposes to have two different
+proposals but to accept inline only when we know the future of meta. Eugene
+votes in favor conditionally, he emphasizes that the meta-inline dependency
+should be honored in the proposals review. Everyone on the table agrees.
+
+**Outcome**: The Committee will review two independent SIPs out of the original
+Meta proposal: inline and meta. All the attendees agree unanimously. They are
+numbered SIP-28 and SIP-29 respectively.
+
+### Discussion of SIP-21: Spores
+
+Martin introduces the spores proposal and its history, that dates back to 2013.
+He thinks that spores are very useful for controlling the environment of a
+function, but he doesn't think that they should go into the compiler, as they
+are already implemented as a macro.
+
+Sébastien points out that the proposal needs to be updated. A major point of
+contention for the spores implementation is that 2.12 introduces Scala SAM
+types, and implicit conversions between functions and spores will not kick in
+because the right hand side will automatically get the spore type. Removing this
+limitation is fairly easy, though: just introduce an abstract member in the
+spore class definition to avoid the automatic conversion to a SAM type. This has
+no performance hit on the eventual representation of a spore into JVM classes,
+since JVM SAM types cannot be used.
+
+Heather joins the conversation. Jorge explains the current discussion and Martin
+asks her what's her opinion on not including spores into the compiler. She
+says that could be left out and she mentions that spores can only provide a
+shallow analysis, a "skin-deep" check of what's captured.  Pickling provided a
+transitive way of checking the spores contract, but the proposal doesn't take it
+into account. Everyone agrees that the proposal should be more general and only
+focus on ways to control the captured environment. Sébastien proposes a
+typeclass-based way of overcoming the current limitations of spores, but it's
+yet to be seen its feasibility in practice. Martin suggests that as the
+Committee should analyze spores as it is right now. Heather emphasizes that the
+current design is not very useful, so she asks whether we should keep it as such
+or try to improve it.
+
+Martin encourages to improve the spores proposal, but suggests to close the
+proposal because it's not yet ready. Heather proposes to give the proposal
+another iteration to update and improve it.
+
+**Outcome**: The spores proposal will have another iteration in two months
+(November). By then, Heather is asked to update the proposal and try to find out
+a way to provide more thorough checks (spores transitivity).
+
+### Discussion of SIP-26: Unsigned Integer Data Types
+
+Sébastien introduces his updates on the proposal. He's tried hard to remove the
+performance regression in his implementation, but he hasn't found a way. He
+describes that the implementation is still 6% slower because of performance hits
+in the hashCode and equals implementation of a case class. To work around this
+issue, two things are required: 
+
+  * Changing the underlying implementation of byte and short ints.
+  * Making the super class of unsigned integer extend *java.lang.Number*
+
+The second option is not feasible because some numbers are AnyVals, and they can
+only extend objects. Working around this in the backend is, in Sébastien's
+opinion, not an exciting adventure to embark on: a lot of patches and quirky
+fixes are required in the compiler. Sébastien, recognizing his unability to fix
+the issue, recommends to reject the proposal.
+
+Josh needs to leave. Eugene wonders if these problems are only JVM-specific.
+Sébastien replies that both yes and no, and he confirms that unsigned integers
+will be implemented in Scalajs alone, so the implementation won't be
+platform-independent. Eugene is interested in knowing if there will be any code
+duplication in the implementation, and Sébastien doesn't think so, since Scala
+Native implements unsigned integer in a different way.
+
+**Outcome**: The proposal is rejected unanimously.
+
+### Discussion of SIP-27: Trailing commas
+
+Jorge welcomes the guest Dale Wijnand, author of the trailing commas proposal.
+Jorge also expects the discussion about the proposal to shed some light on its
+future status, be it rejected, accepted or given another iteration.
+
+Eugene introduces the updates on the proposal. Dale has asked several questions
+to the committee, the most important being if they would accept trailing commas
+only for multi-line comma separated lines. The Committee focuses on this main
+question, although some other questions about the trailing commas specification
+are on the table.
+
+Sébastien points out that it's a good compromise, he personally likes it. He
+compares trailing commas to the semantics of semicolons in Scala. Martin is not
+convinced but the specialized version and makes the points that trailing commas
+wouldn't be like semicolons, because you can write several semicolons together,
+when the equivalent in trailing commas should emit an error. Martin thinks that
+it messes with another abstract of the language and doesn't think it deserves to
+drop all the fundamental ideas for good language design. He proposes that
+trailing commas should be implemented in the SBT parser if they are so important
+for software development.
+
+Heather is starting to see the IDE argument more favorably, and she is on the
+fence about the proposal. She invites Dale to interject about the "IDE" argument
+(namely, that IDEs should make easier to deal with trailing commas. Dale thinks
+that Scala gives a lot of syntactic sugar and ease to developers by design, in
+its compiler. He encourages to solving editing problems into the compiler as
+well, since they greatly affect normal developers' life.
+
+Iulian is not in favor for the multi-line specialized case, he would certainly
+use the feature but he doesn't think it should be only for the multi-line case.
+He points out that Scala had this feature a while ago, and then it was removed.
+He sees the clear benefits of the proposal (configuration files, for instance),
+but he's still against the specialized case version.
+
+Seth is on the fence about this proposal as well. He leans against it, but not
+strongly against it. He says it sorrowfully, because he considers that Dale's
+work has been great and that the problem he tries to solve is real.
+
+Jorge, seeing everyone's reactions, proposes to vote on the proposal. In his
+view, it doesn't make sense to give it another iteration and make everyone's
+spend more time on it. At this point, the Committee doesn't have more meaningful
+feedback to improve the proposal, and decisions need to be made.
+
+4 people of the Committee votes yes, 2 no (Martin and Seth). Martin leaves the
+room because of another appointment, After the acceptance of the proposal, the
+Committee proceeds to decide whether the specialized-case version should be the
+accepted one. Everyone on the table votes yes. At the time of the meeting, the
+Committee doesn't know if Martin will veto the proposal (as the lead language
+designer of Scala, he has this right).
+
+**Outcome**: Martin does not veto the proposal and trailing commas are accepted.
+Some details need to be fleshed out, yet, and will be discussed in a exceptional
+follow-up iteration.
+
+## Closing remarks
+See you next time!