diff --git a/_sips/minutes/2018-03-08-sip-minutes.md b/_sips/minutes/2018-03-08-sip-minutes.md new file mode 100644 index 0000000000..33f16d241e --- /dev/null +++ b/_sips/minutes/2018-03-08-sip-minutes.md @@ -0,0 +1,328 @@ +--- +layout: sips +title: SIP Meeting Minutes - 8th March 2018 + +partof: minutes +--- + +# Minutes + +The following agenda was distributed to attendees: + +|Topic|Reviewers| Accepted/Rejected | +| --- | --- | --- | +|[SIP-35: Opaque types: updates on the proposal](http://docs.scala-lang.org/sips/opaque-types.html) | Sébastien Doeraene | N/A +|[SIP-NN: Byname implicit arguments](http://docs.scala-lang.org/sips/byname-implicits.html) | Martin Odersky | N/A +|Discussions about the future of Scala 2.13 and 2.14 | | | + + +Jorge Vicente Cantero was the Process Lead and Darja Jovanovic as secretary. + +## Date and Location +The meeting took place on the 8th March 2018 at 5 PM CEST via Google Hangouts at EPFL in Lausanne, Switzerland. + +[Watch on Scala Center YouTube channel](https://youtu.be/dFEkS71rbW8) + +Minutes were taken by Jamie Thompson. + +## Attendees +* Martin Odersky ([@odersky](https://github.com/odersky)), EPFL +* Jorge Vicente Cantero ([@jvican](https://github.com/jvican)), Scala Center +* Sébastien Doeraene ([@sjrd](https://github.com/sjrd)), EPFL +* Adriaan Moors ([@adriaanm](https://github.com/adriaanm)), Lightbend +* Darja Jovanovic ([@darjutak](https://github.com/darjutak)), Scala Center + +## Joined Online +* Eugene Burmako ([@xeno-by](https://github.com/xeno-by)), Twitter +* Iulian Dragos ([@dragos](https://github.com/dragos)), Triplequote +* Miles Sabin ([@milessabin](https://github.com/milessabin)], Independent +* Seth Tisue ([@SethTisue](https://github.com/SethTisue)), Lightbend + +## Guest +* Erik Osheim, SIP-35 author. + +## Not present +* Heather Miller ([@heathermiller](https://github.com/heathermiller)), CMU + +## Proceedings + +### Opening Remarks + +[YouTube time 0'00'' - 1'20''](https://youtu.be/dFEkS71rbW8): **Jorge** introduces the meeting by outlining the three +items on the agenda, the first two being SIP proposals and the third being an overview of potential features for Scala +2.13 which may lead to more concrete proposals. +Beginning with point three, **Jorge** explains that three ideas are scheduled for discussion at the meeting, +and invites **Adriaan** to open with the first of them. + +### Discussion about the future of Scala 2.13 and 2.14 +[YouTube time 1'23'' - 23'31''](https://youtu.be/dFEkS71rbW8?t=83) + +#### [Proposal to Drop Package Objects with Inheritance](https://github.com/scala/scala-dev/issues/441) + +This was an open discussion. + +**Adriaan** introduces the idea that package objects should no longer support +inheritance, and possibly be replaced altogether with top level definitions. + +#### Questions about Package Objects + +1) **Miles** asks for clarification on what is problematic with the current implementation of package objects and if it + is worth the cost of creating a new feature to replace them. + + **Adriaan** responds: + - Inheritance from a parent in the same package creates problems. + - package objects already carry a lot of constraints compared to ordinary objects. + - They are worth changing to simplify the implementation. + - Simple migration for package object with extends clauses: change to a regular object and import its definitions. + +2) **Miles** asks if replacing package objects with top level definitions puts an end to the + long standing goal of replacing packages by objects. + + **Adriaan** agrees that is what he is suggesting, motivated by the many issues that + have been discovered with the current implementation in the context of incremental compilation, IDE's and more. + + **Iulian** adds to **Adriaan's** comment: he believes the implementation is too complicated and not correct, with + many workarounds leading to brittle compilation, such as cyclic references between a package object and its parents + if one is the same package. + + **Martin** in response to **Iulian** suggests that the issues experienced with package objects are only due to the + implementation, suggesting that in Dotty, he does not recall many special cases. He suggests that package objects + should behave like ordinary objects and reject parents in the same package. + +3) **Iulian** asks what is the extra benefit of a package object over wrappers for top level definitions. + + **Miles** highlights that they are first class values. + + **Erik** shares examples of uses at his workplace for package objects: access to members without + imports, such as implicit definitions, similar to a Prelude. + + **Sébastien** suggests that a package object may contain another package, which is not possible in an ordinary object + +#### In Favour of Top Level Definitions + +1) **Adriaan**: in his experience package objects are usually + aggregates for new definitions, without extends clauses, which **Miles** agrees is his typical usage of them. + +2) **Sébastien** believes that the extends clause in typical code is used only to inherit from a class in the same + package, so concludes that given the known issues with inheritence, it should be dropped in favour of top level + definitions. + + ([YouTube time from 2'35'' - 3'50''](https://youtu.be/dFEkS71rbW8?t=155)) He proposes two solutions for their + implementation: + + 1) The Kotlin way, which is to create a single wrapper object for each file, with a name derived from the file. + - **Drawback**: a name change to the file breaks binary compatibility. + 2) Individual wrapper classes for each definition, with a name derived from the definition and any parameters. + - **Benefit**: no binary compatibility issue as names are fully qualified. + - **Drawback**: many more class files generated. + + **Sébastien** believes that these solutions do not introduce new issues for type checking. + +3) **Martin** believes that top level definitions are simpler to understand than package objects and is in favour. + +#### Implementation of Top Level Definitions + +- **Erik** is concerned with the impact of top level definitions in multiple files on incremental compilation. +- **Martin** is concerned about how to reason about overloaded and conflicting top level definitions in different files. + +**Sébastien** believes that both concerns above are not issues, proceding to outline how it is similar to regular member +scoping. After some discussion, **Martin** believes that an implementation is possible in Dotty. + +#### Skepticism Around Top Level Definitions + +1) **Seth** would like to keep package objects, but improve safety by adding some restrictions + + He suggests that investigating code and communicating with users will likely have the least disruptive change, + favouring the most popular use-cases. + +2) **Eugene** asks if the behaviour of package objects could be documented, as + currently there is no formal specification except for the implementation. + He is concerned that changes could being made without considering the wider industry, as they will have large code + bases that will need to migrate package objects if they break. + + **Sébastien** answers by suggesting that package objects with no parents can be automatically rewritten to top level + definitions, however, further thought would be required to deal with package objects that have extends clauses. + +>#### YouTube Comment +>[YouTube time from 17'06'' to 18'02''](https://youtu.be/dFEkS71rbW8?t=1026) +> +>**Sébastien** addresses a comment on the stream about which kinds of definitions are safe to be allowed at the top +>level and there is some discussion. +> +>Overall, it is believed that defs can be at the top level, but vals are order +>dependent so might not be allowed. + +**Jorge** notes that there is no longer enough time to discuss the other two ideas for 2.13. + +**Adriaan** finishes by inviting participation in the discussion of the remaining issues in the +[Scala 2.14 milestone on GitHub](https://github.com/scala/scala-dev/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.14). + +#### Conclusion +The committee members are overall in agreement that package objects are a pain point, and there are mixed opinions as to +whether they become further restricted for safety, or replaced with top level definitions which raised concerns for +migration. + +### [SIP-35: Opaque types: updates on the proposal](http://docs.scala-lang.org/sips/opaque-types.html) +[YouTube time from 23'31'' - 43'02''](https://youtu.be/dFEkS71rbW8?t=1411) + +**Jorge** introduces the proposal, noting that it had been updated in the morning before the meeting and directs +**Sébastien**, the reviewer, to begin the discussion on the high level parts of the proposal. + +#### Concerns About The Motivation + +1) **Sébastien** believes that the current wording of the proposal could lead to wrong expectations, + mostly in the meaning of "boxing" (i.e. primitive boxing vs an instance of a user defined wrapper class). + + **Erik** agrees that further clarification is needed, giving specific examples on when a value is left unboxed, + concluding that the value of an opaque type will have semantics of the underlying type. + +2) **Sébastien** points out that some examples claim to not box, but do in fact, for example in the tagging + demonstration, the tag method is generic and will box the Double value passed in the code. + + **Erik** clarifies that a specialised annotation was intended to be on that method, which would avoid the boxing + but was cut for readability. + + **Sébastien** concludes by stating that examples must agree with any claims made about them. + +3) **Sébastien** suggests that most of the examples in the motivation are not not have advantageous runtime performance + over the existing value class feature. + +4) **Miles** suggests that the performance benefits of avoiding boxing is a secondary concern to the semantics that + opaque type aliases bring to the language and asks which is the primary motivation. + + **Erik** answers that both are really key motivations. Originally, the idea was to create a replacement for the + current value class implementation that was a less leaky abstraction, but as use cases were discovered, + the motivation grew to include them as the more obvious method for information hiding. On the other hand, + opaque type aliases are more future proof against changes to the JVM as the feature has no runtime footprint. + + **Jorge** agrees that the feature is good for information hiding and believes the feature will enable many more + library designs that benefit from this style of programming. + +5) **Adriaan** suggests that the proposal could clarify the language used to explain boxing by simplification to + emphasise that values of opaque type aliases share the runtime behaviour of the underlying type. + + **Jorge** believes that the point is already made in the document, but wants to make it clear that an extra layer of + indirection at runtime is avoided for opaque type aliases to subtypes of AnyRef. + +**Sébastien** concludes that action should be taken to further emphasise in the proposal the semantics of the feature +over its performance benefits. + +#### In Favour of the Proposal + +1) **Sébastien** highlights examples of opaque types in the proposal that are advantageous over value classes: + - Primitive arrays will be chosen if the underlying type is primitive. + - Specialised methods will be selected if the underlying type is primitive. + - In generic contexts, allocations of wrappers are avoided for opaque types aliasing reference types. + +2) **Miles** is in favour for the feature because it would be a safer intrinsic replacement for the tagging used in + Shapeless, as in his opinion it is an accident that the implementation of tagging can work in the current version of + Scala. + + **Erik** agrees that the current solution for tagging is not idiomatic and points out that value classes are not a + correct replacement either. + +#### Concerns With the Proposal + +1) **Martin** raises that an issue has been found with the proposals inclusion of recursive opaque type aliases, and is + skeptical that they can be allowed as they introduce a fundamentally new kind of recursion to the language. + + **Jorge** asks for clarification if this is referring to the example for a Fix point type given in the proposal. + + **Martin** confirms and suggests an alternative version could be achieved with conversions, but believes that the + idea implies too many changes to the language than the non-recursive cases. + + **Adriaan** asks the authors how importantly they value the recursive example. + + **Erik** answers that it he wouldn't mind if that part was dropped. The example was included because the methods + used in present Scala to get the same result again rely on "compiler tricks". + He clarifies that it was added under the assumption that if it is possible then it should be documented. + + **Jorge** agrees. + + **Adriaan** suggests that the recursive example is quite niche and could be postponed until a later time, as the rest + of the proposal is favoured by the committee. + +#### Other Remarks +> [YouTube time from 38'25'' - 41'54''](https://youtu.be/dFEkS71rbW8?t=2305) +> +>**Miles** asks **Martin** why he thinks that the fix type example is an entirely new kind of recursion. +> +>**Martin** answers that there is not a clear mapping to the DOT calculus, where recursion over types is through the +>self type of the current object. On the other hand, the fix example is recursion over a type parameter. +> +>**Miles** responds by questioning if this is so different because the fix example syntactically maps directly to an +>equivalent class-based implementation. +> +>**Martin** then offers a solution to fix that does not require recursion: two type aliases representing `Fix[F]` and +>`F[Fix[F]]` with conversions between the two. He summarises that the problem with the opaque types proposal is that it +>suggests that +>these two types are the same type, which is not friendly to a compiler. + +**Jorge** ends the item by clarifying that an implementation is available in Dotty in a pull request where +discussion is also taking place. + +#### Conclusion + +Opaque types are a method of hiding the right hand side of a type alias, with the runtime semantics of the underlying +type. It is discussed as an idiomatic method for tagging, and possibly a fixed point type, with performance benefits +over value classes. +The committee members who commented are in favour of the feature, with concerns for the semantics of recursive +types and the precision of the language used in the proposal. + +**Actions:** + - Emphasise semantics over performance benefits in document. + - Postpone the inclusion of recursive opaque types. + +### [SIP-NN: Byname implicit arguments](http://docs.scala-lang.org/sips/byname-implicits.html) +[YouTube time from 43'02'' - end](https://youtu.be/dFEkS71rbW8?t=2582) + +**Jorge** explains that the committee are waiting for an implementation in Scalac, and are currently acting on the +proposal alone. At the end of the discussion the comittee will vote on whether or not to number the proposal. He also +suggests that Martin will review the proposal. + +**Miles** introduces Byname implicits as a feature that adds the functionality of the Lazy macro in Shapeless as an +intrinsic part of the Scala language, with the added motivation that the macro implementation in Scala 2 is very high +maintenance, with unsafe casts to compiler internal classes. +He explains that byname implicits are intended to be used to derive recursive implicit parameters, +for example type class derivation for recursive types such as List. The SIP proposal is simplified when compared to the +Lazy macro implementation and reuses exisiting byname parameter syntax. +He explains that it is advantageous over the exisiting macro because it supports detection of implicit divergence. + +**Jorge** asks if this feature is desirable because users of Lazy have reported long compilation times with stack +overflows. + +**Miles** answers by proposing that these cases are likely due to undetected implicit divergence, as the Lazy +macro implementation turns off the implicit divergence checks, which is not an issue in the implementation for this SIP +proposal. He clarifies that in any case, there is still performance overhead that could be improved for the +intrinsic implementation, highlighting the high rate of creation of thunks, but proposed that the SIP should not add +additional overhead to what is already given by using the Lazy macro. + +**Jorge** asks for comments from the other committee members. + +**Sébastien** offers that he has been convinced by the motivation section of the SIP, despite never personally requiring +the feature. However he disagrees that the parameters should desugar to lazy vals after implicit +expansion. Apart from concerns about performance, he suggests that the semantics are also surprising compared to +ordinary byname parameters. + +After unproductive discussions about the correct encoding for the desugaring, **Adriaan** suggests that discussion +should be taken to the pull request for the SIP. + +**Jorge** proceeds to introduce voting on numbering the issue, but notes that at this point **Iulian** has left the +meeting, so there is no quorum. Therefore, the votes for him and the other members will be collected after the meeting. + +Votes of those present in favour of numbering: +- **Sébastien** +- **Martin** +- **Adriaan** +- **Miles** +- **Seth** +- **Eugene** + +No votes against from present members. + +#### Conclusion + +Byname implicits are a feature to construct recursive implicit parameters, replacing a brittle macro implementation but +with idiomatic syntax and improved behaviour. +The committee seems in favour of the feature, with some concerns for performance. All members +present chose to number the proposal, but a quorum was not reached at the time.