Re: Digest for scala-user@googlegroups.com - 4 updates in 1 topic

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Digest for scala-user@googlegroups.com - 4 updates in 1 topic

Peter Wolf
+1 I think the solution to the problem is not so much the implicit themselves but the tooling.

For myself, just being able to spot "magic" code is enough.  Once I realize something strange is going on, debugging it is pretty quick.  Agree that lightly under-lining implicit conversions is not obvious enough, and IntelliJ does not highlight functions with implicit invisible args at all.

P

On Sun, Apr 2, 2017 at 1:00 PM, <[hidden email]> wrote:
kraythe <[hidden email]>: Apr 01 11:23AM -0700

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
<https://groups.google.com/forum/#!topic/scala-user/iI4u3Xqs5K0>. Nor do I
think many would disagree that they can cause major headaches such as spending
7 hours looking for an implicit
<https://groups.google.com/forum/#!topic/scala-user/6kjPr6_lknk>. 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 <[hidden email]>: Apr 01 09:46PM

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"
 
kraythe <[hidden email]>: Apr 01 09:27PM -0700

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.
 
On Saturday, April 1, 2017 at 4:46:58 PM UTC-5, AlecZorab wrote:
Naftoli Gugenheim <[hidden email]>: Apr 02 07:12AM

> 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 ?
 
 
> 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.
 
 
> 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.
 
 
 
> - 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.
 
 
> 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:
 
[image: pasted1]
 
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Loading...