Re: IDE's that support ADA

[Peter Chapin <PChapin@vtc.vsc.edu>]

On Sat, 1 Nov 2014, Stephen Leake wrote:

> Ah, so it's not an obtrusive error display; it doesn't beep and open 
> another buffer with error messages. That makes sense.

Yes, you just see "red squiggles" about things the IDE doesn't like. If 
you hover over the squiggle a message pops up that tries to explain the 
problem.

> One problem with this approach is that editing file A can easily cause 
> problems in file B, so you still need some sort of global error list. 
> How do the IDE's you've used handle that?
>
> The Eclipse FIRST environment was not good at that, as I recall; you had
> to explicitly check each possible file.

The IDEs I've used have some kind of project view that shows, usually in a 
tree structure, all the files of my project. The view typically isn't 
exactly a representation of the files themselves. For example in the Java 
world packages are usually collapsed into a single node if there are no 
intermediate entities whereas in the file system you have to drill down 
through several subdirectories. For example the class

 	edu.vtc.myproject.Buffer

would be stored in the file

 	edu/vtc/myproject/Buffer.java

but the IDE project view wouldn't make you navigate all levels of the 
package hierarchy and just display the package "edu.vtc.myproject" as an 
individual node.

Anyway, files with errors are often shown with red squiggly lines under 
their names or with some other indication of a problem. That said, I'm 
actually not 100% sure if you have to visit the file first to see the 
error indication. It might depend on the nature of the error. I never 
really paid attention to that.

>> With the Java IDEs I've used (Eclipse, IntelliJ), if the IDE "signs
>> off" on the code, it will compile. I can't recall a time when that
>> hasn't been true. Thus the IDE does full name resolution across
>> packages, libraries, and considers inheritance, etc, etc.
>
> I suspect it actually invokes the compiler, and processes the error
> messages. That's easy to do, but the compile can be pretty slow if the
> project is big enough, so you don't want to do it for every edit. GNAT
> does have a "semantic check only mode", which is faster.

I can tell you more precisely how it works with the Scala plug-ins for 
Eclipse and IntelliJ. I'm a much bigger Scala user than a Java user.

The Scala compiler (there is really only one) has a special interface 
designed to assist IDEs. When used via that interface it's called the 
"presentation compiler." The Scala plug-in for Eclipse loads the 
presentation compiler as a library and holds it in memory all the time. It 
interacts with the compiler via the interface I mentioned which allows, 
apparently, incremental syntax and semantic checks. I'm not sure about the 
technical details.

As a result you see errors as you type them provided the code you are 
editing is not exceptionally long or complex. If it is, there is a 
significant delay. One file in the Scala compiler source code itself is 
almost 6,000 lines and the presentation compiler lags pretty well when you 
try to edit that file. However for normal sized files the delay is 
perfectly acceptable. The main disadvantage to this approach is it uses a 
LOT of memory.

I believe the Emacs extension ENSIME also uses the presentation compiler 
to do what it does (code completion, type checking, etc, etc). See: 
https://github.com/ensime. I set ENSIME up once but it was a bit flakey at 
the time (this was years ago). It's probably worth another look.

In contrast the IntelliJ plug-in for Scala completely re-implements the 
Scala compiler front-end from scratch. This includes semantic analysis 
(type checking). They did this for two reasons

1. The presentation compiler wasn't available when they started their 
project.

2. They claim they can integrate more tightly with the rest of their IDE 
this way. It is certainly true that the Scala plug-in for IntelliJ takes 
less memory and feels faster.

The down side of their approach is that the IDE sometimes gets it wrong 
and occasionally claims something is wrong that isn't or vice-versa. As 
the plug-in has matured this doesn't happen much anymore. Martin Odersky, 
the prime mover of Scala, has applauded IntelliJ because they have "helped 
debug the Scala Language Specification." In effect, their plug-in is a 
second implementation of the language.

>> Yes, that's a good start. Does it work for references in comments too?
>
> No, those are not listed in the compiler cross references. Does any
> other tool do that? How would it handle overloaded names?

Well, I was thinking about Javadoc comments. For example:

/**
  * Blah, blah, blah
  *
  * @param size The size of the thingy.
  */
void someMethod(int size) { .. }

If you rename the parameter the IDE knows enough to rename it in the 
Javadoc too. I've seen IDEs offer to rename things in comments throughout 
but usually that's an option that's off by default. Typically you can 
preview a refactoring and I would definitely preview something like that 
for sure! I'm not sure what it does, exactly; maybe it's just search and 
replace.

>> I'm looking at the refactor menu in Eclipse... there is an option to
>> convert a local variable of a method into a field of the class. So in
>> Ada terms that would be promoting a local variable of a primitive
>> subprogram to a component of the tagged type.
>
> I gather you have not actually used that?

I haven't! To be honest the refactoring I use the most, by far, is 
renaming. I'm nervous about letting the IDE modify my code at will 
because, frankly, I don't entirely trust it. Anything with far reaching 
consequences I tend to preview carefully.

Even after renaming I worry about the IDE messing up my formatting. 
Despite having the formatting configured a certain way there are always 
exceptions.

> I have done that on occasion, when I realize I need to split a primitive
> operation into two parts, and save some state in between the two calls.
>
> But I usually change the variable name, and sometimes the type; I don't
> see how having an editor do a small part of that job is useful.
>
> Having lots of screen space, with lots of windows on lots of source
> files, and an easy way to navigate among them, makes editing specs and
> bodies simultaneously easy.

Using a static language with strong typing is more useful than fancy IDE 
features in this regard. That's my feeling.

>> There are other refactorings too, but you get the idea.
>
> The only idea I get here is "not worth having the editor do this".

I would tend to agree. Still... people coming from the Java world have 
ideas about what a "modern" IDE is supposed to be able to do. I'm not sure 
how much the refactorings get used in real life. I suppose someone has 
studied that question, maybe?

>> Well, GPS can display the path associated with an unproved
>> verification condition so you get a visual display of the path where
>> the failure might occur.
>
> I gather that's displaying the information in a SPARK tool error
> message. Is it really better than just seeing the text of the message?
> Can you click on something to navigate to the appropriate source code?

Yes. In GPS there is an icon next to the message that when clicked will 
highlight the path. I'm not sure where the information is coming from; 
it's not in the error message itself. I suppose GPS is reading some log 
file or report file generated by gnatprove.

>> I actually use Emacs a lot and find myself going to it when I want to
>> get real work done (funny about that).
>
> That's good to hear!

I think I keep coming back to Emacs because it is the ultimate generalist. 
For a while I tried using OneNote to keep notes but I decided, for me, a 
collection of text files was suitable and I edit those files with... Emacs 
of course!

It doesn't matter what programming language I'm using, what configuration 
files I'm editing, what document preparation system I'm writing in... 
Emacs works. Thus I find myself sitting in Emacs a lot of the time.

Peter