How Lightbend and ScalaLang.org can save Scala from the impact of implicits.

[kraythe]

I don't think that it should be any argument to the fact that implicits are a major hindrance to language adoption as I have previously laid it out in a pretty long epic thread. Nor do I think many would disagree that they can cause major headaches such as spending 7 hours looking for an implicit. However, as I have previously said I am actually a fan of the Scala language so I have been thinking about a productive and forward thinking solution to the problem without compromising all of the features that implicits legitimately provide. I think the solution to the problem is not so much the implicit themselves but the tooling. 

Consider a java program for example that referenced a function not declared in the source, it would be simple to cmd-click (or ctrl-click) to navigate to that declaration and see where it is declared. Of course when you importa java class, you don't automatically import the imports that the java class makes. This isn't the case with implicits. So finding them is opaque, knowing where they come from is opaque and thus the nightmare. However, if you are using java and editing with vim the nightmare may be slightly less but still is impressive. 

To solve this I think Lightbend (which is a major proponent and advocate of Scala) and ScalaLang.org need to start working together heavily with IDE makers such as IntelliJ on the tooling in an extremely cooperative manner. The current Scala tooling is more of a java tooling with some things bolted on. There is scant attention paid to making things that are tough in Scala and have no analog in java. An implicit conversion, for example, is lightly underlined in IntelliJ but you cant find what it was converted to or what the import was. If you use a macro (which I wouldn't suggest by the way) then there is no tooling to let you know what the expansion of that macro will be. Furthermore almost every developer has been hit by obscure warnings that are less than helpful. Note that I don't have anything against eclipse but I don't prefer it as an IDE for many reasons. Instead of this tooling being something done by third parties or the vendors themselves, the two powerhouse organizations i recommended could work closely and provide tooling that makes the experience easy. Among recommendations I would propose the following: 

- Objects that are implicitly converted should show up in a different color or have some obvious means of showing that the implicit conversion occurred, not a subtle light underline. 

- There should be a command that you can execute in the key map that will take you to the declaration of the implicit conversion. 

- When copying code from one file to another that utilizes an implicit conversion, the implicit should be imported for you. 

- On the subject of imports, if implicits are imported as a result of an import that imports other things, the chain should be revealed in some kind of popup. 

- If there are conflicting implicit conversions that render the resolution ambiguous it should be easy to navigate to where they are declared.

- The tooling should include a popup when you type the dot and do a ctrl-space expansion with a list of methods including the implicits available in another color or font weight or some other means to indicate it requires an implicit conversion to another type. For example if doIt() can be called from an implicit conversion of a string the popup could show "MyImplicits.doIt()" in orange indicating it comes from an implicit conversion.   

- If you type code that results in a macro expansion there should be a key to popup a window that shows what the expanded form will be. 

- Language syntax that is obscure from the point of view of Java developers should be able to invoke a popup to explain that syntax. Since java devs are the most common converts to Scala this would aid adoption. 

If the community really makes a concerted effort towards tooling I think adoption of the language will be even faster and these issues will not drive people out of an otherwise excellent language.

-- Robert Simmons Jr.

[Alec Zorab]

Intellij already does the majority of these.

Of the ones it doesn't, the macro expansion is tricky, though with enough work on the presentation compiler it might be possible.

I'm not sure what you envision when you say "a popup that explains obscure syntax"

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[kraythe]

I am a quite heavy intellij user and I assure you that it doesnt do most of the things that I enumerated in my post. 

[Naftoli Gugenheim]

On Sat, Apr 1, 2017 at 2:23 PM kraythe <kra...@gmail.com> wrote:

I don't think that it should be any argument to the fact that implicits are a major hindrance to language adoption as I have previously laid it out in a pretty long epic thread. Nor do I think many would disagree that they can cause major headaches such as spending 7 hours looking for an implicit. However, as I have previously said I am actually a fan of the Scala language so I have been thinking about a productive and forward thinking solution to the problem without compromising all of the features that implicits legitimately provide. I think the solution to the problem is not so much the implicit themselves but the tooling. 

Agreed! Have you seen https://groups.google.com/d/msg/scala-user/atl2dHv1gMY/NeQVI_5KAgAJ ? 

Consider a java program for example that referenced a function not declared in the source, it would be simple to cmd-click (or ctrl-click) to navigate to that declaration and see where it is declared. Of course when you importa java class, you don't automatically import the imports that the java class makes. This isn't the case with implicits. So finding them is opaque, knowing where they come from is opaque and thus the nightmare. However, if you are using java and editing with vim the nightmare may be slightly less but still is impressive. 

To solve this I think Lightbend (which is a major proponent and advocate of Scala) and ScalaLang.org

do you mean the Scala Center?

 

need to start working together heavily with IDE makers such as IntelliJ on the tooling in an extremely cooperative manner. There is scant attention paid to making things that are tough in Scala and have no analog in java.

I think that's an unfair characterization.

 

An implicit conversion, for example, is lightly underlined in IntelliJ but you cant find what it was converted to or what the import was. If you use a macro (which I wouldn't suggest by the way) then there is no tooling to let you know what the expansion of that macro will be.

Macros are a much harder problem for tooling than implicits, so this is somewhat of a strawman. However, the current macros are being replaced by the inline+meta type, which will be much more toolable, and the scala.meta project is seeing to this.

 

Furthermore almost every developer has been hit by obscure warnings that are less than helpful. Note that I don't have anything against eclipse but I don't prefer it as an IDE for many reasons. Instead of this tooling being something done by third parties or the vendors themselves, the two powerhouse organizations i recommended could work closely and provide tooling that makes the experience easy. Among recommendations I would propose the following: 

- Objects that are implicitly converted should show up in a different color or have some obvious means of showing that the implicit conversion occurred, not a subtle light underline. 

This is configurable in the Settings. You can discuss changing their default on gitter.im/JetBrains/intellij-scala or by opening an issue in https://youtrack.jetbrains.com/newissue?project=SCL

- There should be a command that you can execute in the key map that will take you to the declaration of the implicit conversion.

There is -- ctrl-shift-Q

 

- When copying code from one file to another that utilizes an implicit conversion, the implicit should be imported for you. 

Agreed. If a ticket doesn't already exist you should open one in https://youtrack.jetbrains.com/newissue?project=SCL

 

- On the subject of imports, if implicits are imported as a result of an import that imports other things, the chain should be revealed in some kind of popup. 

That would be nice. It already does something like that for implicit parameters. Again, I'd encourage you to recommend this to Jetbrains in the channels I mentioned.

- If there are conflicting implicit conversions that render the resolution ambiguous it should be easy to navigate to where they are declared.

That is already the case. However bear in mind that since IntelliJ uses its own implementation of the scala type system, the list is longer than just the competing candidates.

 

- The tooling should include a popup when you type the dot and do a ctrl-space expansion with a list of methods including the implicits available in another color or font weight or some other means to indicate it requires an implicit conversion to another type. For example if doIt() can be called from an implicit conversion of a string the popup could show "MyImplicits.doIt()" in orange indicating it comes from an implicit conversion.

If you press ctrl-space an extra time or a few, it does show extension methods that would be available with an import and pressing enter will import it (and write the selected method).

 

- If you type code that results in a macro expansion there should be a key to popup a window that shows what the expanded form will be.

This already exists -- see https://blog.jetbrains.com/scala/2015/09/02/debugging-lambdas-and-macro-expansion-extractor/

 

 

- Language syntax that is obscure from the point of view of Java developers should be able to invoke a popup to explain that syntax. Since java devs are the most common converts to Scala this would aid adoption. 

This already exists.

1. Alt-enter on for comprehension (on the `for` keyword) has a command to desugar the for comprehension (convert it to the equivalent foreach or flatMap/withFilter/map).

2. Select code and right-click, in the context menu there's "Explain scala code (ctrl-alt-e)" or "Desugar scala code (ctrl-alt-d)" (it was renamed recently). You get a whole bunch of choices:

 

If the community really makes a concerted effort towards tooling I think adoption of the language will be even faster and these issues will not drive people out of an otherwise excellent language.

-- Robert Simmons Jr.

--