Minutes: SIP meeting August and September 2018


#1

Dear Contributors, Community,

Minutes are being published, as mentioned in my previous posts, still missing June - coming soon.

Also - we finally have a great mic, all future SIP meetings should be very nice to listen to!

More:

September 2018 please go to minutes or watch the meeting on Scala Center’s YouTube channel.

August 2018 please go to minutes or watch the meeting on Scala Center’s YouTube channel.

Or as usual, just keep scrolling down (o:

September 2018 Minutes

The following agenda was distributed to attendees:

Topic Reviewers Accepted/Rejected
Summary of the Contributors thread “Proposal to remove XML literals from the language” Sébastien Doeraene Pending
Summary of the Contributors thread “Proposal to remove the procedure Syntax” Josh Suereth Pending
Proposal to add Intersection Types to the Language Martin Odersky Discussion opened until the 25th October 2018, comments welcomed here
Proposal to Add Union Types to the Language Martin Odersky Discussion opened until the 25th October 2018, comments welcomed here
Proposal to add Implicit Function Types to the Language Martin Odersky Discussion opened until the 25th October 2018, comments welcomed here
Proposal to add Dependent Function Types to the Language Martin Odersky Discussion opened until the 25th October 2018, comments welcomed here
Proposal to add Trait Parameters to the Language Martin Odersky Discussion opened until the 25th October 2018, comments welcomed here

Jorge Vicente Cantero was the Process Lead and Darja Jovanovic was the secretary.

Date and Location

The meeting took place on the 24th September 2018 at 5 PM CEST via Google Hangouts at EPFL in Lausanne, Switzerland as well as other locations.

Watch on Scala Center YouTube channel

Minutes were taken by Darja Jovanovic and Jorge Vicente Cantero.

Attendees

Not present

Proceedings

Opening Remarks

Jorge opens the meeting, explains SIP dynamics:
Finalising discussion about the 1st batch, action points
Introducing batch two
Decision / voting / postponing the discussion

Discussion of the first Scala 3 batch

“Proposal to remove XML literals from the language”

(YouTube time 3’ - 16’50’’)

Sébastien suggests to postpone the removal of XML and Procedure syntax, because when
the removal takes place it will be a code breaking change, not a binary or
tasty one. Adds it would be better to focus on changes that have an impact on
tasty and binary format and deal with these later.

Seth (YouTube time:4’54) suggests to have a warning
notes that it will eventually be removed.

Eugene asks what would be the positive effect of that change? And that we
need to vote on it first.

Iulian asks what are the promises with regards to binary-compatible and
source-compatible releases in Scala 3. To him it looks weird that we could
break the source between 3.0 and 3.1.

Josh notes that by enforcing binary compatibility across Scala 2 and Scala
3 we are sacrificing source compatibility. He asks for this decision to be
more thought over as it is a big decision with lots of impact for Scala
tooling. He agrees we can make source-breaking releases nicer to use in
source-based build tools like Pants or Bazel, but trading off binary
compatibility by source compatibility is not a decision to take lightly more.

Martin thinks that no matter what trade-offs we do with regards to
compatibility, he’d like to be able to remove XML literals in the first
release of Scala 3.0 because having the XML spec inside the Scala spec gives
a bad impression of complexity of the language, where he believes Scala is
instead a more lightweight language than its competitors. There is no way he
can make this argument if the XML spec continues to be in the relatively
simple Scala language specification more.

(The discussion with regards to binary compatibility and source compatibility trade-offs is postponed.)

“Proposal to remove the procedure Syntax”

(YouTube time: 16’50’’ - 19.28’’)

Jorge reminds that in the last meeting we agreed that before moving forward with the change we needed:

  1. A better motivation
  2. A good explanation of why this change promotes the use of types (making it safer)
  3. A removal of the examples that were misleading
  4. A link to a Scalafix rewrite that could make a migration.

Jorge then points out that the changes need to be done in order to move
forward, but is asking a Committee to voice their opinion about removing this
feature in Scala 3.
Josh underlines that there were 2 parts in the debate

  1. Are procedures different than a method, do we want them visually
    distinctive?
  2. Other issues listed by Jorge above. In particular, the fact that we want people to explicitly annotate the unit in their methods because it makes code more readable.

A decision will be taken into the future when all those items are acted on.

Discussion of the second Scala 3 batch

An overview of the second batch can be found in this Scala Contributors thread. The batches under discussion are:

  1. Proposal to add Trait Parameters to the Language
  2. Proposal to add Intersection Types to the Language
  3. Proposal to Add Union Types to the Language
  4. Proposal to add Dependent Function Types to the Language
  5. Proposal to add Implicit Function Types to the Language

Feedback on these proposals is open until the 25th October 2018, as describe
in the linked Scala Contributors thread.

Proposal to add Intersection Types and Union Types to the language

(YouTube time: 20’49’’ - 24’01)

Martin presents the intersection types as per doc. He does a basic
description of the feature and points out that intersection types are the
duals of union types. He points out that union types have helped replace most
of the lubbing mechanism and early precocious lubbing that happened in Scala
2 (which happens in less degree in the current implementation of Scala 3 but
could be improved in future releases). Martin also thinks that union
types are useful for null safety, where any type coming from Java could be
annotated as T | Null. He then goes on describing further implementation
details and trade-offs that Scala 3 does in this space. Adriaan asks what
are the trade-offs between the encoding of union types that we have in Scala
and the one they use in other languages like Typescript. Martin points
out that performance-wise Scala union types would be more performant because
T | Null wouldn’t box if T is a primitive type.

Sebastien (YouTube time: 30’03’’)
gives his input based on the fact that Scala.js already has Union Types in
Scala 2. He states that they are very limited; they were introduced for
modeling because some libraries “desperately needed” them but turned out they
were overused for no apparent reason. He advises to document the Union Types
proper usage well and not get discouraged by the possible “overusage”.

There is some back-and-forth between Sebastien and Josh with
regards to performance of union types and their boxing (especially in the
presence of specialization). More

Proposal to add Implicit Function Types to the Language

(YouTube time: 39’01’’ - 43’11’’)

Martin explains what implicit function types are about and points out it’s
a pretty “hot” feature that was published in POPL 2018.
He underlines the advantages of implicit function types (like further
abstraction of code that depends on a notion/representation of a context,
like Scala 3’s compiler) and points out that implicit function types can
replace the reader monad, even though it’s about 10x faster than the reader monad
is. A comprehensive explanation of what implicit function types can do can be
found in Olivier’s Blainvillain talk at
ScalaDays, Berlin 2018
.
Martin thinks that implicit function types should be seen as the
canonical way of doing scope injection, which gives you a lot of
expressivity, to which Sebastien adds that what Martin means by canonical
scope injection doesn’t necessarily correspond with the way people do normal
scope injection, because in normal scope injection you can’t refer to
identifier or parent scopes. Martin clarifies that for him comonadic
abstraction are the classical way of scope injection in which we inject
things into an environment, hence the use of canonical scope injection when
referring to implicit function types which allow you to do the same. His
definition of scope injection comes more from a typing rules perspective
rather than the lexical point of view. Martin agrees that if there is a
name clash with implicit function types there is a problem indeed.

Proposal to add Dependent Function Types to the Language

(YouTube time: 43’11’’ - 44’40’’)

Martin mentions that dependent function types is the last big addition to Scala’s type checker. The reason why they are added is because Scala has dependent methods and there is a need for dependent functions (the same rationale has been doing with regards to implicit methods and implicit function types). It’s an obvious win because dependent function types allow us to abstract over the idea of implicit methods in functions, so the more we can do the better. Initially he was afraid of the feature because he thought it violated this Scala principle that in the end anything is an instance of a class in some way and it turned out that a new encoding of dependent function types made this initial argument moot. Dependent function types are now encoded as implicit function types with type refinements, so this way it doesn’t violate that principle.
Adriaan mentions that the last missing bit is polymorphic function types
and Martin agrees and says that they are looking into that, but maybe not for
Scala 3.0 (Guillaume Martres is pushing for polymorphic function types).

Proposal to add Trait Parameters to the Language

(YouTube time: 44’42’’ - end )

Martin describes trait parameters and says that they subsume a large number of use
cases of early initializers. They were not added to Scala from the start because of
uncertainty in the way they would work with regards to linearization and
initialization of parameters. The way they solved this problem is by
enforcing the rule that only the class extending a trait with parameters can
pass the parameters. The motivation to add trait parameters is to regularize
the language and get rid of early initializers which are an ad-hoc feature
and are much harder to understand how to use correctly. Afterward, the
Committee discusses some of the limitations of trait parameters.
Josh (YouTube time: 48’40’’
suggests he will find one of his libraries that uses a lot of early
initializers and see if trait parameters allow him to replace them. He’s
curious about how clean would the code look after the change.

Jorge then wraps up the meeting, points out how feedback on these
proposals would work (check the following link
Second batch of Scala 3 SIPs: additions to Scala's type system)
and finalizes the discussion.

Conclusion Next meeting will be dedicated to the Second Batch disscusion.

August 2018 Minutes

The following agenda was distributed to attendees:

Topic Reviewers Accepted/Rejected
Summary of the Contributors thread “Proposal to remove auto application from the language” Miles Sabin Pending
Summary of the Contributors thread “Proposal to remove XML literals from the language” Sébastien Doeraene Pending
Summary of the Contributors thread “Proposal to remove the procedure Syntax” Josh Suereth Pending
Summary of the Contributors thread “Proposal to remove early initializers from the language” Adriaan Moors Pending
Summary of the Contributors thread “DelayedInit or OnCreate, any solution?” Adriaan Moors pending

Jorge Vicente Cantero was the Process Lead and Darja Jovanovic was the secretary.

Date and Location

The meeting took place on the 30th August 2018 at 5 PM CEST via Google Hangouts at EPFL in Lausanne, Switzerland as well as other locations.

Watch on Scala Center YouTube channel

Minutes were taken by Darja Jovanovic.

Attendees

Not present

Proceedings

Opening Remarks

Jorge opens the meeting, explains SIP dynamics:

Selected batches (proposals for language change in Scala 3) are published on Contributors

Community has 1 month deadline to discuss the proposals

Committee summarises the comments and discusses during the meeting

Decision / voting / postponing the discussion

More in May 2018 minutes

Summaries of discussions of the First Scala 3 batch

“Proposal to remove auto application from the language”

(YouTube time: 2’15’’ - 11’22’’ )

Miles Sabin summarised discussion on Contributors thread.

  • Focuses on the Contributors discussion rather than on the proposal itself
  • Underlines a lack of motivation in the light of a separate issue from Dotty: Weak eta-expansion
  • Concludes that this proposal should be aligned with eta-extension issue

Summary:

References

Comments

  • One comment to the effect that the motivation doesn’t actually provide any
    motivating reasons.

    Commenter is pointed to the Dotty issue referenced above. The issue is a
    request to make eta expansion more uniform and predictable, and is addressed
    in Martin’s comment linked to above. This proposal would appear to be a
    corrolary of of that comment.

  • Some questions about parentheses and implicit argument lists.

    Resolution from Sébastiane: implicit argument application syntax unaffected
    by this proposal.

  • A request for clarification about Java/Scala 2/3 mixed overrides, given the
    Java exception.

    Resolution from Martin: “As long as there is a Scala-2 or Java version in the
    set of overridden variants, the rule is relaxed”

  • Some discussion of the use of “()” to indicate effects.

  • Comment about interaction with type parameter lists, eg. Promise[Unit] vs.
    Promise[Unit]().

  • Comment about interaction with methods returning values with an apply
    method. How does a programmer tell whether the following are equivalent or not?

    f()()
    f.apply().apply()
    f().apply()
    
  • Counter proposal from Rex following from the above,

    1. Empty parameter lists, whether implicit or explicit, whether
      zero-parameter or filled completely with default parameters, may be elided.
      This matches what you’re allowed to do with overriding vs overloading anyway
      at the JVM level.

    2. Ambiguous parses are forbidden at the use-site. If foo() may be elided to
      foo, then if its return value has an apply method, that apply method cannot
      be called using foo().

    3. .() is another synonym for .apply(), so you can compactly disambiguate
      parses.

  • Comment from Gabriele,

    I’m very much in favor of the spirit of this change, but a bit worried
    about the actual result.

    The idea is to normalize things, which makes total sense, but after this
    change we end up with more inconsistencies than before, due to the backward
    compatibility towards Scala 2.

  • Interaction with nullary constructors. Currently class Foo is interpreted as
    class Foo(). Mutatis mutandis for case class apply methods.

Martin (Youtube time: 11.37) mentiones that this proposal also came about due to New collection usecases that surfaced in recent work - showing that without a strict rule there is a high amount of “un-disciplined” use of (). But he agrees with Miles about merging the two proposals together.

Conclusion Jorge takes the task to merge the proposals and extend the motivation.

“Proposal to remove XML literals from the language”

Sébastien (YouTube time” 14’53’ - 40’10’’) summarised discussion on Contributors thread.

Summary:

In favor of the removal:

  • Significant language specification weight, as well as compiler implementation. The whole XML spec must be embedded in Scala!

  • scala-xml is very complicated, and has serious usability problems

  • Adding the extra xml"""…""" shouldn’t be a bother

    • For JSX-style support, maybe a jsx"" interpolator could have the same semantics as JSX, rather than that of scala-xml
  • Direct language support for XML only existed because string interpolators did not exist back then (supposedly). It seems to be an obviously better design to build on string interpolators.

  • Removes XML as a special case. With interpolators, one can embed arbitrary languages within Scala.

    • Similar argument: XML should have no higher place in the language than YAML, JSON, etc.
  • JSX-style use cases should use ScalaTags-style libraries anyway.

  • XML being part of the language is the reason that XML libraries have stalled, and that JSON ones have flourished

    • Counter-argument: lib stalling is due to the “symbol”-based translation. A name-based translation would not have this issue.

Against the removal

  • Difficulty of syntax highlighting
    • Shouldn’t be a real issue as long as editors are on board
  • The promised XML interpolator was never materialized
  • JSX is now in widespread use in languages for front-end development. It is ironic that Scala would drop support for a similar feature now. It is even built in some languages, e.g., TypeScript.
    • JSX is simpler than scala-xml, though: no namespace support, in particular.
  • For front-end devs looking at Scala/Scala.js, string interpolators will look horrible compared to JSX, and it might be one of those “no-no” things that will push them away.
  • Being able to just copy-paste examples from the Net is nice. (8 Likes on this one)
  • No one uses XML anymore, right?
    • Some answer that they do. Especially in non-greenfield projects.
    • Kojo uses XML literals as building blocks for the Storytelling feature.

Counter-proposal

Named-based XML desugaring: Pre SIP: name based XML literals

  • Less complexity in the language/compiler
  • Open for library competition
  • Compared to a string interpolator, flavors can be implemented using normal library code, without (whitebox) macros.
    • Whiteboxness is necessary for xml”””<button …>””” to return a more precise type such as xml.tags.Button rather than xml.Node

Other ideas

  • Can it be a compiler plugin or a macro?
    • No, a compiler plugin cannot hook into the parser, neither can a macro.

Related links

Discussion:

Eugene (YouTube time: 25’30’) thinks that the proposal needs to be cleared about the impact, referring to possible replacements with string literals that might never happen. Suggests to position this proposal as simply removing the feature and leaving it up to the community to decide and implement the replacements.

Josh (YouTube time: 27’16’’) clarifies that in order to replace the libraries one would need a proof of concept, and currently there is none.

Adriaan (YouTube time 30’) summarises the discussion, pointing out that Committee needs to answer a question will we support XML in some way and waht would be the most “Scala-like” way to do so and who will be maintaing it.

Seth (YouTube time 35’57’’) is under the impression that large portion of XML user base are the ones using it to do generation and rarer to be reading in XML using the existing Scala XML support and asks others to share their impressions.
Martin re-phrases it as “using XML for pattern matching”.
Sébastien says it is super rare.
Iulian says it is used more than we think in pattern matching and in value definitions he seen in not OS projects; they can be found in old, large code basis; probably decreasing.
He suggests to ask IntelliJ to collect and share the XML usage patterns.

“Proposal to remove the procedure Syntax”

(YouTube time: 40’13’’ - 52’10)

Josh Suereth summarised the discussion on Contributors thread:

  • Underlines the general concern about the lack of motivation part of the proposal;
  • Notes that in the Contributors discussion, ones that were for the removal would mostly put “+1” while ones against the removal would be more elaborate, that gives a false impression there were more arguments against the removal;
  • Structures his presentation around community’s points in a light of better motivation adding his opinion after each
  • Concludes that that going forward procedure syntax should be removed because in the long run it helps new developers learn Scala faster and better (more details below).

Summary + Josh’s comments:

Fixable/Addressable Concerns

  • Concerned that rewrite tools (and people) would use def foo() = {} syntax instead of def foo(): Unit = {}

Pros

  • Clean up inconsistency in the language
  • Dropping return value is dangerous, in general
    Experience teaching Scala gave an insight to how often the return value is dropped which leads to broken code leaving students confused

Cons

  • More verbose syntax to safely ignore return values
    Semi legitimate concern; developers need to change their habits and annotate return values when it’s important
  • Lazy people will just write def foo() = {} and get bad behavior.
    *The way it is written leads to a confusion and should be removed from the proposal why: https://youtu.be/gnlL4PlstFY?t=2795 *

Not well motivated Pros

  • Safer
    We need to detail “why” it is safer

  • Cleaner for refactoring tools to treat methods of this sort.
    Given the way things are structured, this issue comes down to the way the methods are parsed => change the parser betters the refactoring tools. This point needs to be clear in the proposal

Not well motivated Cons

  • People have to change their habits
  • Proposal coming from people who don’t mutate state
    After analyzing two of his “side-effecty” codebases, looking to find where he uses the most procedure syntaxes, Josh concluded that there are many : Unit
  • Call into question authority/judgement of proposer
    Josh doesn’t find it appropriate and will ignore such comments stating that “…it is not a legitimate way to make a technical argument.” YouTube time 42’07’’

Counter Proposals

  • Effect tracking
    A bit of an “overkill”
  • Multiple “def” keywords, one which would mean side-effecting function
    := for side effects

Josh concludes: big point to debate would the language consistency be worth the change to more verbose expresion.

Iulian (You/tube time: ) adds that 1. last 5 years Syntax procedure was anyway deprecated; 2. going forward we should consider Scala 3 in a light of next 15 years, now is the right moment to clean up the language and 3. this is “the easiest refactoring to automate the code base” that could be a “zero cost migration”

Josh points out that current developers would need to change their habits but motivation lies in introducing new developers to Scala and having this consistency to help them stay, given that as it is now it takes longer to learn and making mistakes here is bad.

Jorge says IntelliJ already warns developer whenever they use procedure syntax, and suggests them to rewrite it with an automatic rewrite. It’s true that not all Scala developers use IntelliJ, but a big part of do, and thanks to IntelliJ they are strictly discouraged to use procedure syntax.

Eugene (YouTube time: 50’49’’) asks what is the migration strategy; is it possible to do a batch migration for the big code base or would it be necessary to go through your code in IntelliJ?

Seth reminds the viewers/Committee that it was deprecated only in 2.13 OM4, which is probably why this proposal got so many responses.

Conclusion Before making a final decision, the proposal needs a better motivation 1. Why it is safer 2. Refactoring tools / parsing 3. IntelliJ tool explained?

“Proposal to remove early initializers from the language”

(YouTube time: 54’12’’ - 59’35’)

Adriaan’s best summarised in comment: Proposal to remove early initializers from the language

“DelayedInit or OnCreate, any solution?”

(YouTube time: 59’35’’ - end ’)

Adriaan’s best summarised in comment: DelayedInit or OnCreate, any solution?

Conclusion 14 days left on the Contributors thread, Committee should revisit this topic later on.