Improvement Request on Highlighting Implicit Conversions

[Seyed H. HAERI (Hossein)]

Dear all,

Let me begin by expressing my excitement about the semantic highlighting of ScalaIDE. In particular, I find the underlining business extremely useful for implicit conversions. Yet, I have a suggestion which, IMHO, can make that even more useful. Consider my following piece of code:

private[this] def materialise(pi: HBNode[Exp], ubs: Map[Idn, Exp]) {

  var ret_pi: HBNLike[Exp] = pi

  for(b <- ubs) ret_pi = hbnizer {//***

    ret_pi match {

      case HBNLike(_, g, xvar, _, vx, "var") if (xvar.asInstanceOf[Exp#Var].name == b._1) => {

        val x = b._1

        val prem: ProofTree =

           () justifies HBReduction(g - x, vx.asInstanceOf[Exp], g - x, vx) using "lam"
        prem justifies ((g<b>) <:> xvar >> (g<b>) <:> vx) using "var"

      }

    }

  }
}

What is returned by hbnizer in the line marked with *** above is of type HBNode[Exp] which gets implicitly converted to an HBNLike[Exp] instance. As a result of this implicit conversion, all the lines from that one onwards until the third last are underlined to highlight the implicit. This to some extends harms readability I'm afraid. The conclusion I would like to draw is that more ingenuity is needed for this underlining business when it spans over several lines. For example, in my code snippet above, it would be nicer if I could get line *** to be underlined -- but, only until the opening brace -- in addition to the line where the closing brace is. This would also improve visibility of the rest of implicits between these two lines.

TIA,

--Hossein

--------------------------------------------------------------------------------------------------------------

Seyed H. HAERI (Hossein)

Research Assistant
Institute for Software Systems (STS)
Technical University of Hamburg (TUHH)
Hamburg, Germany

ACCU - Professionalism in programming - http://www.accu.org/
--------------------------------------------------------------------------------------------------------------

[Mirco Dotta]

And you are right to think that ;-)

Eclipse > Preferences > Implicits > Only highlight the first line in
an implicit conversion

(and I'd argue that this should be the default)

Have fun!

-- Mirco

On Aug 18, 3:38 am, "Seyed H. HAERI (Hossein)"

[Mirko Stocker]

On Sat, Aug 18, 2012 at 10:29 AM, Mirco Dotta <mirco...@typesafe.com> wrote:
> (and I'd argue that this should be the default)

+1

--
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st

[Mirco Dotta]

https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1001219--only-highlight-the-first-line-in-an-implicit-conversion--should-be-the-default

If anyone wants to give it a shot during the w/e

-- Mirco

On Aug 18, 10:57 am, Mirko Stocker <m...@misto.ch> wrote:

[Miles Sabin]

On Sat, Aug 18, 2012 at 9:29 AM, Mirco Dotta <mirco...@typesafe.com> wrote:
> And you are right to think that ;-)
>
> Eclipse > Preferences > Implicits > Only highlight the first line in
> an implicit conversion
>
> (and I'd argue that this should be the default)

I actually don't much like that, because then the underlining becomes
fairly disconnected from the semantics that it's supposed to be
highlighting.

I think what I'd rather see is the point of application an implicit
being highlighted in the source text with a caret or something like
that. Then you could use the caret to provide hovers (ie. hover over
caret to see expanded source), links (ie. click on caret to link to
implicit definition) and refactorings (ie. right click on caret for
menu of refactorings such as expand inline).

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: mi...@milessabin.com
g+: http://www.milessabin.com
http://twitter.com/milessabin

[Mirco Dotta]

On Aug 20, 2012, at 11:34 AM, Miles Sabin wrote:

> On Sat, Aug 18, 2012 at 9:29 AM, Mirco Dotta <mirco...@typesafe.com> wrote:
>> And you are right to think that ;-)
>>
>> Eclipse > Preferences > Implicits > Only highlight the first line in
>> an implicit conversion
>>
>> (and I'd argue that this should be the default)
>
> I actually don't much like that, because then the underlining becomes
> fairly disconnected from the semantics that it's supposed to be
> highlighting.
>
> I think what I'd rather see is the point of application an implicit
> being highlighted in the source text with a caret or something like
> that. Then you could use the caret to provide hovers (ie. hover over
> caret to see expanded source), links (ie. click on caret to link to
> implicit definition) and refactorings (ie. right click on caret for
> menu of refactorings such as expand inline).

Hi Miles,

you have a valid point, but I still feel the current way of highlighting
everything is simply too noisy. So, if I have to pick between the two
currently available options, my vote goes for highlighting only the first
line.

Let's see what the rest of the folks think.

-- Mirco

[Miles Sabin]

On Thu, Aug 23, 2012 at 3:16 PM, Mirco Dotta <mirco...@typesafe.com> wrote:
> you have a valid point, but I still feel the current way of highlighting
> everything is simply too noisy. So, if I have to pick between the two
> currently available options, my vote goes for highlighting only the first
> line.
>
> Let's see what the rest of the folks think.

I think I should really have said: I actually don't much like that _either_ ;-)

In the light of experience I'd say that underlining doesn't work very
well at all as a highlighting mechanism for implicits. I find the
markers in the margin a lot more useful and I'd be happy to turn the
underlining off completely so long as the markers remained.

A caret or similar at the actual implicit application points would be
even better, but obviously that'd be a new feature.

[Miles Sabin]

On Thu, Aug 23, 2012 at 4:51 PM, Miles Sabin <mi...@milessabin.com> wrote:
> In the light of experience I'd say that underlining doesn't work very
> well at all as a highlighting mechanism for implicits. I find the
> markers in the margin a lot more useful and I'd be happy to turn the
> underlining off completely so long as the markers remained.

Ahem ... well, I just went and took another look, and what I want is
already possible.

It's in preferences, under,

General => Editors => Text Editors => Annotations => Scala Implicit

and then deselect the "Text as" option. The underlining goes, but the
markers are still present :-)

[Rafael de F. Ferreira]

This discussion reminded me of a feature request I've been meaning to
make for a while. Highlighting implicits and showing inferred
semicolons is useful but perhaps already too cluttering, and I think
Scala tooling would benefit from more desugaring info. I'd love to see
a "Code Inspection" panel that mirrored a section of the currently
focused source code (perhaps visually similar to the JDT's Declaration
View) with toggles to show synthesized code such as "implicits
expansion", "inferred semicolons", "inferred member types",
"for-comprehension desugaring", "extractor desugaring", etc.

It's possible to show all that information on the existing editor
given the appropriate highlights and tooltips, but having it all
available on a separate pane just a glance away would be a net win
IMO. What do you guys think?



--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/


On Fri, Aug 24, 2012 at 11:37 AM, Damian H <damia...@gmail.com> wrote:
> thanks for pointing that out Miles, the underlining has been making my eyes
> hurt!

[iulian dragos]

On Mon, Aug 27, 2012 at 4:54 AM, Rafael de F. Ferreira <raf...@rafaelferreira.net> wrote:

This discussion reminded me of a feature request I've been meaning to
make for a while. Highlighting implicits and showing inferred
semicolons is useful but perhaps already too cluttering, and I think
Scala tooling would benefit from more desugaring info. I'd love to see
a "Code Inspection" panel that mirrored a section of the currently
focused source code (perhaps visually similar to the JDT's Declaration
View) with toggles to show synthesized code such as  "implicits
expansion", "inferred semicolons", "inferred member types",
"for-comprehension desugaring", "extractor desugaring", etc.

It's possible to show all that information on the existing editor
given the appropriate highlights and tooltips, but having it all
available on a separate pane just a glance away would be a net win
IMO. What do you guys think?

This is indeed something very useful, especially when developing the IDE itself. I've been meaning to do a 'dev support plugin' for a while, with the intention that a separate view shows you information about the current selection:

- AST nodes

- position information (many times when semantic actions don't work as expected, it's the position information that is skewed or otherwise inaccurate)

- symbol and type

- pretty-printed de-sugared trees (this would include expanded macros in 2.10) 

It would be a fun project, but I can't fit it in the current milestone plans, and we're already late. I'd be motivated to kick it off if someone could lend me a hand. 

cheers,

iulian

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Seyed H. HAERI (Hossein)]

I have absolutely no experience in Eclipse plugin development. But,
this one, I'm sure will be useful to my research too. (I'm a
programming languages guy after all. :p) So, I'm up for it! :) But
will need a lot of startup guidance...

--

[Jeppe Nejsum Madsen]

On Mon, Aug 27, 2012 at 4:54 AM, Rafael de F. Ferreira
<raf...@rafaelferreira.net> wrote:

> This discussion reminded me of a feature request I've been meaning to
> make for a while. Highlighting implicits and showing inferred
> semicolons is useful but perhaps already too cluttering, and I think
> Scala tooling would benefit from more desugaring info. I'd love to see
> a "Code Inspection" panel that mirrored a section of the currently
> focused source code (perhaps visually similar to the JDT's Declaration
> View) with toggles to show synthesized code such as "implicits
> expansion", "inferred semicolons", "inferred member types",
> "for-comprehension desugaring", "extractor desugaring", etc.
>
> It's possible to show all that information on the existing editor
> given the appropriate highlights and tooltips, but having it all
> available on a separate pane just a glance away would be a net win
> IMO. What do you guys think?

Sounds very nice! I also tend to think there's too much going on with
the current highlights

/Jeppe

[Rafael de F. Ferreira]

Should I open a feature request on JIRA?

[Mirco Dotta]

This discussion reminded me of a feature request I've been meaning to
make for a while. Highlighting implicits and showing inferred
semicolons is useful but perhaps already too cluttering, and I think
Scala tooling would benefit from more desugaring info. I'd love to see
a "Code Inspection" panel that mirrored a section of the currently
focused source code (perhaps visually similar to the JDT's Declaration
View) with toggles to show synthesized code such as  "implicits
expansion", "inferred semicolons", "inferred member types",
"for-comprehension desugaring", "extractor desugaring", etc.

It's possible to show all that information on the existing editor
given the appropriate highlights and tooltips, but having it all
available on a separate pane just a glance away would be a net win
IMO. What do you guys think?

Excellent idea!

---------------

Mirco Dotta

Typesafe - The software stack for applications that scale

PSE-D, 1015 Lausanne, Switzerland

Work: +41 (0)21 691 49 65

Twitter: @mircodotta

[James Moore]

On Wed, Sep 19, 2012 at 4:23 AM, Mirco Dotta <mirco...@typesafe.com> wrote:

This discussion reminded me of a feature request I've been meaning to
make for a while. Highlighting implicits and showing inferred
semicolons is useful but perhaps already too cluttering, and I think
Scala tooling would benefit from more desugaring info. I'd love to see
a "Code Inspection" panel that mirrored a section of the currently
focused source code (perhaps visually similar to the JDT's Declaration
View) with toggles to show synthesized code such as  "implicits
expansion", "inferred semicolons", "inferred member types",
"for-comprehension desugaring", "extractor desugaring", etc.

That sounds great.  I'd also like it to be able to do the opposite:  take a chunk of code, and remove everything that could be provided implicitly.  Take out semicolons, parens, explicit types, etc, as long as the code compiles to the same thing.  Sort of like a set of lenses for looking at code - I think there's more than one view visible at a time, too.

I'd also like an option for named parameters (show / hide).

--
James Moore
ja...@restphone.com
http://blog.restphone.com/
http://www.linkedin.com/in/jamesmmooreiv

[iulian dragos]

On Mon, Aug 27, 2012 at 10:18 AM, iulian dragos <jagu...@gmail.com> wrote:

On Mon, Aug 27, 2012 at 4:54 AM, Rafael de F. Ferreira <raf...@rafaelferreira.net> wrote:

This discussion reminded me of a feature request I've been meaning to
make for a while. Highlighting implicits and showing inferred
semicolons is useful but perhaps already too cluttering, and I think
Scala tooling would benefit from more desugaring info. I'd love to see
a "Code Inspection" panel that mirrored a section of the currently
focused source code (perhaps visually similar to the JDT's Declaration
View) with toggles to show synthesized code such as  "implicits
expansion", "inferred semicolons", "inferred member types",
"for-comprehension desugaring", "extractor desugaring", etc.

It's possible to show all that information on the existing editor
given the appropriate highlights and tooltips, but having it all
available on a separate pane just a glance away would be a net win
IMO. What do you guys think?

This is indeed something very useful, especially when developing the IDE itself. I've been meaning to do a 'dev support plugin' for a while, with the intention that a separate view shows you information about the current selection:

- AST nodes

- position information (many times when semantic actions don't work as expected, it's the position information that is skewed or otherwise inaccurate)

- symbol and type

- pretty-printed de-sugared trees (this would include expanded macros in 2.10) 

It would be a fun project, but I can't fit it in the current milestone plans, and we're already late. I'd be motivated to kick it off if someone could lend me a hand. 

It happened, after all. Meet the Scala plugin Spy: https://github.com/scala-ide/scala-ide/pull/203

Like Mr. Bond, this plugin carefully inspects the code under the cursor, and displays additional information in a View. A more ambitious plugin would show the AST as a Tree widget, but I didn't go that far. You can see in the attached screenshot. Contributions welcome :)

iulian

[Eric Molitor]

I need to pay more attention as I didn't see that pull request until this message That is very useful!

- Eric