Re: IDE's that support ADA

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

On Wed, 29 Oct 2014, Stephen Leake wrote:

>> Typical features of modern IDEs include: displaying semantic errors
>> (type errors, etc) as you type,
>
> Meaning it attempts to parse the syntax after typing every character? So
> if you start typing 'if ... then ... else .. end if', you get errors
> until you type 'endif'? Yuck.

Yes, exactly. However, the Java IDEs I've used tend to complete each 
structure for you immediately. In Ada terms that would mean automatically 
adding the 'end if,' for example, as soon as 'then' is typed. However, it 
is true that the IDEs will show spurious errors due to incomplete 
structures while you are typing them. Often they only do this after a 
short (and configurable) time delay to ease the pain somewhat. Actually I 
find I get used to it fairly quickly. I only pay attention to the red 
squiggly lines if I'm at a place where I believe everything should be 
okay. One gets a feeling of satisfaction when all the red squiggly lines 
go away. :)

> Hmm. You said "semantic", not "syntactic". So this means a full compile 
> with name and type resolution, not just a syntax parse. That makes sense 
> for simpler languages; I don't think it makes much sense for Ada.

I guess I would disagree here. It's more useful for complex languages than 
for simple languages because the programmer (meaning me) is more likely to 
be unaware of all the rules. Ada has a lot of rules so help from the IDE 
would be welcome.

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.

The same is nearly true of the Scala plug-in for IntelliJ (I haven't used 
the Scala plug-in for Eclipse). Scala's type system is complex so to have 
the IDE faithfully do the type checking as you type your code is no small 
feat, I'm sure. Yet it is the expected thing from a "modern" IDE these 
days.

JetBrains, the makers of IntelliJ is currently building an IDE for C/C++ 
programming. I don't doubt for a minute that they intend to do the same 
thing for those languages. In fact, the preliminary version even deals 
with the preprocessor on the fly (it expands preprocessor macros, analyzes 
the code generated, and produces messages related to what it finds).

>> refactoring support,
>
> I've never been clear what this means, exactly. It could be:
>
> - Rename all occurences of this identifier
>
>    Emacs Ada mode has "show all references", which would walk thru all
>    occurrences and let you rename each one; that could be enhanced
>    fairly easily.

Yes, that's a good start. Does it work for references in comments too?

> - Change the parameter list for this subprogram
>
>    I don't see how you can automate that; you have to consider exactly
>    what that means at each use. So the "walk thru all occurences" is
>    useful.

Well Eclipse has a 'change method signature' refactoring option. It 
changes the signature of a method and all its overrides. It can also keep 
the original method and have it delegate to the new method (and mark the 
original as depreciated).

> - something else?

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.

Eclipse also has refactorings to move methods from super classes to 
subclasses (or vice-versa). In Ada terms we are talking about moving 
subprograms from one package to another, with suitable renamings I guess.

There is also an extract interface refactoring that examines a class and 
generates an interface based on the methods it finds there.

There are other refactorings too, but you get the idea. Of course we are 
talking about Java here so the ones I mentioned are all OOP specific. One 
might be able to come up with other, Ada specific, possibilities.

>> integrated debugging,
>
> Has that.

Cool.

> More useful would be all the operations on type "Bar_Type" for object 
> "Foo". The GNAT cross-reference info can build that list given 
> "Bar_Type", so I might be able to get there.

At first I found the code completion stuff irritating but it's actually 
quite useful when you get used to it. Often I don't remember exactly how 
to spell something and it's nice to have the IDE produce a list of 
possibilities that are relevant at that point in the program. The Scala 
plug-in for IntelliJ will actually help you complete "naked" names. For 
example if I'm typing an expression like

x = somethingLong + someOth...

IntelliJ will show me the names in scope that start with "someOth" and 
let me pick from that list:

x = somethingLong + someOtherLongName

It really reduces the pain of typing long names a lot (especially since it 
reorders the list based on names I've used recently to put the commonly 
needed ones at the top). Considering that using long names is encouraged 
in the Ada community a feature like that would nice for an Ada IDE.

> If the "associated documentation" for a subprogram is the comments at 
> the declaration, then that just requires navigating to the current 
> completion choice in another window. Although one editor I saw put that 
> in a help balloon; cute, but probably not enough space for useful info.

It helps that in the Java world there is a standard for how comments are 
supposed to look (Javadoc). The IDE knows this standard and can help with 
formatting and display of the information. For example it is normal for 
the IDE to check that the spelling of parameter names in the comments 
agrees with the way they are spelled in the actual method (not to mention 
the number of parameters, etc).

>> In the Ada world there is integration with SPARK (for example as GPS
>> does).
>
> Not clear what "integration" means here. Again, Emacs can run the
> command line tools that SPARK uses.

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 think it's great that you are working to improve Ada mode in Emacs. I 
actually use Emacs a lot and find myself going to it when I want to get 
real work done (funny about that). I'm not suggesting that all of the 
things above are necessary or desirable for Ada mode, but it gives you 
some idea of where Java IDEs are currently at, and of the expections users 
of those IDEs bring to the table.

Peter