Re: IDE's that support ADA

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

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

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

Thanks for the tip; I'll look at it for ideas.

> 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

I'm taking this approach with Emacs Ada mode, because I want it to be
based on a BNF grammar, so it is easy to implement other languages using
the same infrastructure.

That may mean it's too slow :).

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

Since the grammar I'm using is from the LRM, this is easy to avoid.
Well, except when the LRM changes behind my back, as with 'or else raise
<exception>' in aspects :).

Other languages don't have as well-defined or well-structured grammars,
so it may be harder.

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

This is the problem for me, as well. The Ada compiler will probably
catch any problems, but it's hard to be sure.

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

Ok. The default display of such things in Emacs includes the file name;
it should be possible to hide it, but that's not "the Emacs way" :).

-- 
-- Stephe