Skip to content

Commit 81d9d60

Browse files
committed
draft march 8th 2018 sip committee minutes
1 parent d4e3977 commit 81d9d60

File tree

1 file changed

+325
-0
lines changed

1 file changed

+325
-0
lines changed
Lines changed: 325 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,325 @@
1+
---
2+
layout: sips
3+
title: SIP Meeting Minutes - 8th March 2018
4+
5+
partof: minutes
6+
---
7+
8+
# Minutes
9+
10+
The following agenda was distributed to attendees:
11+
12+
|Topic|Reviewers| Accepted/Rejected |
13+
| --- | --- | --- |
14+
|[SIP-35: Opaque types: updates on the proposal](http://docs.scala-lang.org/sips/opaque-types.html) | Sébastien Doeraene | N/A
15+
|[SIP-NN: Byname implicit arguments](http://docs.scala-lang.org/sips/byname-implicits.html) | Martin Odersky | N/A
16+
|Discussions about the future of Scala 2.13 and 2.14 | | |
17+
18+
19+
Jorge Vicente Cantero was the Process Lead and Darja Jovanovic as secretary.
20+
21+
## Date and Location
22+
The meeting took place on the 8th March 2018 at 5 PM CEST via Google Hangouts at EPFL in Lausanne, Switzerland.
23+
24+
[Watch on Scala Center YouTube channel](https://youtu.be/dFEkS71rbW8)
25+
26+
Minutes were taken by Jamie Thompson.
27+
28+
## Attendees
29+
* Martin Odersky ([@odersky](https://github.com/odersky)), EPFL
30+
* Jorge Vicente Cantero ([@jvican](https://github.com/jvican)), Scala Center
31+
* Sébastien Doeraene ([@sjrd](https://github.com/sjrd)), EPFL
32+
* Adriaan Moors ([@adriaanm](https://github.com/adriaanm)), Lightbend
33+
* Darja Jovanovic ([@darjutak](https://github.com/darjutak)), Scala Center
34+
35+
## Joined Online
36+
* Eugene Burmako ([@xeno-by](https://github.com/xeno-by)), Twitter
37+
* Iulian Dragos ([@dragos](https://github.com/dragos)), Triplequote
38+
* Miles Sabin ([@milessabin](https://github.com/milessabin)], Independent
39+
* Seth Tisue ([@SethTisue](https://github.com/SethTisue)), Lightbend
40+
41+
## Guest
42+
* Erik Osheim, SIP-35 author.
43+
44+
## Not present
45+
* Heather Miller ([@heathermiller](https://github.com/heathermiller)), CMU
46+
47+
## Proceedings
48+
49+
### Opening Remarks
50+
51+
[YouTube time 0'00'' - 1'20''](https://youtu.be/dFEkS71rbW8): **Jorge** introduces the meeting by outlining the three
52+
items on the agenda, the first two being SIP proposals and the third being an overview of potential features for Scala
53+
2.13 which may lead to more concrete proposals.
54+
Beginning with point three, **Jorge** explains that three ideas are scheduled for discussion at the meeting,
55+
and invites **Adriaan** to open with the first of them.
56+
57+
### Discussion about the future of Scala 2.13 and 2.14
58+
[YouTube time 1'23'' - 23'31''](https://youtu.be/dFEkS71rbW8?t=83)
59+
60+
#### [Proposal to Drop Package Objects with Inheritance](https://github.com/scala/scala-dev/issues/441)
61+
62+
This was an open discussion.
63+
64+
**Adriaan** introduces the idea that package objects should no longer support
65+
inheritance, and possibly be replaced altogether with top level definitions.
66+
67+
#### Questions about Package Objects
68+
69+
1) **Miles** asks for clarification on what is problematic with the current implementation of package objects and if it
70+
is worth the cost of creating a new feature to replace them.
71+
72+
**Adriaan** responds:
73+
- Inheritance from a parent in the same package creates problems.
74+
- package objects already carry a lot of constraints compared to ordinary objects.
75+
- They are worth changing to simplify the implementation.
76+
- Simple migration for package object with extends clauses: change to a regular object and import its definitions.
77+
78+
2) **Miles** asks if replacing package objects with top level definitions puts an end to the
79+
long standing goal of replacing packages by objects.
80+
81+
**Adriaan** agrees that is what he is suggesting, motivated by the many issues that
82+
have been discovered with the current implementation in the context of incremental compilation, IDE's and more.
83+
84+
**Iulian** adds to **Adriaan's** comment: he believes the implementation is too complicated and not correct, with
85+
many workarounds leading to brittle compilation, such as cyclic references between a package object and its parents
86+
if one is the same package.
87+
88+
**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
89+
should behave like ordinary objects and reject parents in the same package.
90+
91+
3) **Iulian** asks what is the extra benefit of a package object over wrappers for top level definitions.
92+
93+
**Miles** highlights that they are first class values.
94+
95+
**Erik** shares examples of uses at his workplace for package objects: access to members without
96+
imports, such as implicit definitions, similar to a Prelude.
97+
98+
**Sébastien** suggests that a package object may contain another package, which is not possible in an ordinary object
99+
100+
#### In Favour of Top Level Definitions
101+
102+
1) **Adriaan**: in his experience package objects are usually
103+
aggregates for new definitions, without extends clauses, which **Miles** agrees is his typical usage of them.
104+
105+
2) **Sébastien** believes that the extends clause in typical code is used only to inherit from a class in the same
106+
package, so concludes that given the known issues with inheritence, it should be dropped in favour of top level
107+
definitions.
108+
109+
([YouTube time from 2'35'' - 3'50''](https://youtu.be/dFEkS71rbW8?t=155)) He proposes two solutions for their implementation:
110+
111+
1) The Kotlin way, which is to create a single wrapper object for each file, with a name derived from the file.
112+
- **Drawback**: a name change to the file breaks binary compatibility.
113+
2) Individual wrapper classes for each definition, with a name derived from the definition and any parameters.
114+
- **Benefit**: no binary compatibility issue as names are fully qualified.
115+
- **Drawback**: many more class files generated.
116+
117+
**Sébastien** believes that these solutions do not introduce new issues for type checking.
118+
119+
3) **Martin** believes that top level definitions are simpler to understand than package objects and is in favour.
120+
121+
#### Implementation of Top Level Definitions
122+
123+
- **Erik** is concerned with the impact of top level definitions in multiple files on incremental compilation.
124+
- **Martin** is concerned about how to reason about overloaded and conflicting top level definitions in different files.
125+
126+
**Sébastien** believes that both concerns above are not issues, proceding to outline how it is similar to regular member
127+
scoping. After some discussion, **Martin** believes that an implementation is possible in Dotty.
128+
129+
#### Skepticism Around Top Level Definitions
130+
131+
1) **Seth** would like to keep package objects, but improve safety by adding some restrictions
132+
133+
He suggests that investigating code and communicating with users will likely have the least disruptive change,
134+
favouring the most popular use-cases.
135+
136+
2) **Eugene** asks if the behaviour of package objects could be documented, as
137+
currently there is no formal specification except for the implementation.
138+
He is concerned that changes could being made without considering the wider industry, as they will have large code
139+
bases that will need to migrate package objects if they break.
140+
141+
**Sébastien** answers by suggesting that package objects with no parents can be automatically rewritten to top level
142+
definitions, however, further thought would be required to deal with package objects that have extends clauses.
143+
144+
>#### YouTube Comment
145+
>[YouTube time from 17'06'' to 18'02''](https://youtu.be/dFEkS71rbW8?t=1026)
146+
>
147+
>**Sébastien** addresses a comment on the stream about which kinds of definitions are safe to be allowed at the top
148+
>level and there is some discussion.
149+
>
150+
>Overall, it is believed that defs can be at the top level, but vals are order
151+
>dependent so might not be allowed.
152+
153+
**Jorge** notes that there is no longer enough time to discuss the other two ideas for 2.13.
154+
155+
**Adriaan** finishes by inviting participation in the discussion of the remaining issues in the
156+
[Scala 2.14 milestone on GitHub](https://github.com/scala/scala-dev/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.14).
157+
158+
#### Conclusion
159+
The committee members are overall in agreement that package objects are a pain point, and there are mixed opinions as to
160+
whether they become further restricted for safety, or replaced with top level definitions which raised concerns for
161+
migration.
162+
163+
### [SIP-35: Opaque types: updates on the proposal](http://docs.scala-lang.org/sips/opaque-types.html)
164+
[YouTube time from 23'31'' - 43'02''](https://youtu.be/dFEkS71rbW8?t=1411)
165+
166+
**Jorge** introduces the proposal, noting that it had been updated in the morning before the meeting and directs
167+
**Sébastien**, the reviewer, to begin the discussion on the high level parts of the proposal.
168+
169+
#### Concerns About The Motivation
170+
171+
1) **Sébastien** believes that the current wording of the proposal could mislead expections,
172+
mostly in the meaning of "boxing" (i.e. primitive boxing vs an instance of a user defined wrapper class).
173+
174+
**Erik** agrees that further clarification is needed, giving specific examples on when a value is left unboxed,
175+
concluding that the value of an opaque type will have semantics of the underlying type.
176+
177+
2) **Sébastien** points out that some examples claim to not box, but do in fact, for example in the tagging
178+
demonstration, the tag method is generic and will box the Double value passed in the code.
179+
180+
**Erik** clarifies that a specialised annotation was intended to be on that method, which would avoid the boxing
181+
but was cut for readability.
182+
183+
**Sébastien** concludes by stating that examples must agree with any claims made about them.
184+
185+
3) **Sébastien** suggests that most of the examples in the motivation are not not advantageous over the existing value
186+
class feature.
187+
188+
4) **Miles** suggests that the performance benefits of avoiding boxing is a secondary concern to the semantics that
189+
opaque type aliases bring to the language and asks which is the primary motivation.
190+
191+
**Erik** answers that both are really key motivations. Originally, the idea was to create a replacement for the
192+
current value class implementation that was a less leaky abstraction, but as use cases were discovered,
193+
the motivation grew to include them as the more obvious method for information hiding. On the other hand,
194+
opaque type aliases are more future proof against changes to the JVM as the feature has no runtime footprint.
195+
196+
**Jorge** agrees that the feature is good for information hiding and believes the feature will enable many more
197+
library designs that benefit from this style of programming.
198+
199+
5) **Adriaan** suggests that the proposal could clarify the language used to explain boxing by simplification to
200+
emphasise that values of opaque type aliases share the runtime behaviour of the underlying type.
201+
202+
**Jorge** believes that the point is already made in the document, but wants to make it clear that an extra layer of
203+
indirection at runtime is avoided for opaque type aliases to subtypes of AnyRef.
204+
205+
**Sébastien** concludes that action should be taken to further emphasise in the proposal the semantics of the feature
206+
over its performance benefits.
207+
208+
#### In Favour of the Proposal
209+
210+
1) **Sébastien** highlights examples of opaque types in the proposal that are advantageous over value classes:
211+
- Primitive arrays will be chosen if the underlying type is primitive.
212+
- Specialised methods will be selected if the underlying type is primitive.
213+
- In generic contexts, allocations of wrappers are avoided for opaque types aliasing reference types.
214+
215+
2) **Miles** is in favour for the feature because it would be a safer intrinsic replacement for the tagging used in
216+
Shapeless, as in his opinion it is an accident that the implementation of tagging can work in the current version of
217+
Scala.
218+
219+
**Erik** agrees that the current solution for tagging is not idiomatic and points out that value classes are not a
220+
correct replacement either.
221+
222+
#### Concerns With the Proposal
223+
224+
1) **Martin** raises that an issue has been found with the proposals inclusion of recursive opaque type aliases, and is
225+
skeptical that they can be allowed as they introduce a fundamentally new kind of recursion to the language.
226+
227+
**Jorge** asks for clarification if this is referring to the example for a Fix point type given in the proposal.
228+
229+
**Martin** confirms and suggests an alternative version could be achieved with conversions, but believes that the idea
230+
implies too many changes to the language than the non-recursive cases.
231+
232+
**Adriaan** asks the authors how importantly they value the recursive example.
233+
234+
**Erik** answers that it he wouldn't mind if that part was dropped. The example was included because the methods
235+
used in present Scala to get the same result again rely on "compiler tricks".
236+
He clarifies that it was added under the assumption that if it is possible then it should be documented, to which
237+
238+
**Jorge** agrees.
239+
240+
**Adriaan** suggests that the recursive example is quite niche and could be postponed until a later time, as the rest
241+
of the proposal is favoured by the committee.
242+
243+
#### Other Remarks
244+
> [YouTube time from 38'25'' - 41'54''](https://youtu.be/dFEkS71rbW8?t=2305)
245+
>
246+
>**Miles** asks **Martin** why he thinks that the fix type example is an entirely new kind of recursion.
247+
>
248+
>**Martin** answers that there is not a clear mapping to the DOT calculus, where recursion over types is through the
249+
>self type of the current object on the other hand, the fix example is recursion over a type parameter.
250+
>
251+
>**Miles** responds by questioning if this is so different because the fix example syntactically maps directly to an
252+
>equivalent class-based implementation.
253+
>
254+
>**Martin** then offers a solution to fix that does not require recursion: two type aliases representing `Fix[F]` and
255+
>`F[Fix[F]]` with conversions between the two. He summarises that the problem with the opaque types proposal is that it
256+
>suggests that
257+
>these two types are the same type, which is not friendly to a compiler.
258+
259+
**Jorge** ends the item by clarifying that an implementation is available in Dotty in a pull request where
260+
discussion is also taking place.
261+
262+
#### Conclusion
263+
264+
Opaque types are a method of hiding the right hand side of a type alias, with the runtime semantics of the underlying
265+
type. It is discussed as an idiomatic method for tagging, and possibly a fixed point type, with performance benefits
266+
over value classes.
267+
The committee members who commented are in favour of the feature, with concerns for the semantics of recursive
268+
types and the precision of the language used in the proposal.
269+
270+
**Actions:**
271+
- Emphasise semantics over performance benefits in document.
272+
- Postpone the inclusion of recursive opaque types.
273+
274+
### [SIP-NN: Byname implicit arguments](http://docs.scala-lang.org/sips/byname-implicits.html)
275+
[YouTube time from 43'02'' - end](https://youtu.be/dFEkS71rbW8?t=2582)
276+
277+
**Jorge** explains that the committee are waiting for an implementation in Scalac, and are currently acting on the
278+
proposal alone. At the end of the discussion the comittee will vote on whether or not to number the proposal.
279+
280+
**Miles** introduces Byname implicits as a feature that adds the functionality of the Lazy macro in Shapeless as an
281+
intrinsic part of the Scala language, with the added motivation that the macro implementation in Scala 2 is very high
282+
maintenance, with unsafe casts to compiler internal classes.
283+
He explains that byname implicits are intended to be used to derive recursive implicit parameters,
284+
for example type class derivation for recursive types such as List. The SIP proposal is simplified when compared to the
285+
Lazy macro implementation and reuses exisiting byname parameter syntax.
286+
He explains that it is advantageous over the exisiting macro because it supports detection of implicit divergence.
287+
288+
**Jorge** asks if this feature is desirable because users of Lazy have reported long compilation times with stack
289+
overflows.
290+
291+
**Miles** answers by proposing that these cases are likely due to undetected implicit divergence, as the Lazy
292+
macro implementation turns off the implicit divergence checks, which is not an issue in the implementation for this SIP
293+
proposal. He clarifies that in any case, there is still performance overhead that could be improved for the
294+
intrinsic implementation, highlighting the high rate of creation of thunks, but proposed that the SIP should not add
295+
additional overhead to what is already given by using the Lazy macro.
296+
297+
**Jorge** asks for comments from the other committee members.
298+
299+
**Sébastien** offers that he has been convinced by the motivation section of the SIP, despite never personally requiring
300+
the feature. However he disagrees that the parameters should desugar to lazy vals after implicit
301+
expansion. Apart from concerns about performance, he suggests that the semantics are also surprising compared to
302+
ordinary byname parameters.
303+
304+
After unproductive discussions about the correct encoding for the desugaring, **Adriaan** suggests that discussion
305+
should be taken to the pull request for the SIP.
306+
307+
**Jorge** proceeds to introduce voting on numbering the issue, but notes that at this point **Iulian** has left the
308+
meeting, so there is no quorum. Therefore, the votes for him and the other members will be collected after the meeting.
309+
310+
Votes of those present in favour of numbering:
311+
- **Sébastien**
312+
- **Martin**
313+
- **Adriaan**
314+
- **Miles**
315+
- **Seth**
316+
- **Eugene**
317+
318+
No votes against from present members.
319+
320+
#### Conclusion
321+
322+
Byname implicits are a feature to construct recursive implicit parameters, replacing a brittle macro implementation but
323+
with idiomatic syntax and improved behaviour.
324+
The committee seems in favour of the feature, with some concerns for performance. All members
325+
present chose to number the proposal, but a quorum was not reached at the time.

0 commit comments

Comments
 (0)