Re: IDE's that support ADA

[Stephen Leake <stephen_leake@stephe-leake.org>]

Peter Chapin <PChapin@vtc.vsc.edu> writes:

> 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. 

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

I did see that in the Eclipse environment for Java used on FIRST
Robotics last year.

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.

>> 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.

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.

The problem I'm getting at is the cross-file interactions mentioned
above. 

>>> 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?

No, those are not listed in the compiler cross references. Does any
other tool do that? How would it handle overloaded names?

>> - 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. 

Ok. So it does _not_ change all of the references, which is what I was
talking about.

Emacs Ada mode can show the list of overrides, so it could do the
operation you describe.

>> - 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.

I gather you have not actually used that?

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.

> 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.

I've done that as well, as the constraints on the type hierarchy design
change.

I'm not at all sure I want the editor doing that level of editing for
me. It's certainly not hard to cut and paste the appropriate lines from
one buffer to another; then I get it in the right place, and can search
thru comments to make sure they are updated.

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

That's trivial in Ada; just change the type declaration to "interface".
Unless there are components in the type; then you have work to do that
the editor can't do for you.

> There are other refactorings too, but you get the idea. 

The only idea I get here is "not worth having the editor do this".

Since I hack on Emacs all the time, I am usually very willing to spend
an hour adding a feature that will save me 10 minutes of work today, on
the theory that I'll make back the time in the future (or other people
will). But I've never been tempted to implement these refactoring
features; I just don't see how they can be worth it.

Maybe I'm just a lot pickier about how my source code is arranged, so I
don't want the editor messing with it (even when I'm writing the editor
:).

Which is why I'm asking for feedback on refactoring features that
people actually find _useful_.

>>> 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 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?

I'll have to try SPARK one of these days.

> I think it's great that you are working to improve Ada mode in Emacs.

Thanks.

> 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'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.

Ok, thanks for the input.

-- 
-- Stephe