[mercury-users] Off-topic: IDE/compiler trade-off

[Julien Fischer]

On Tue, 9 Jan 2007, Jonathan Morgan wrote:

> On 1/8/07, Ondrej Bojar <obo at cuni.cz> wrote:
>> I'm not a fan of IDEs, but I understand some people use it and that
>> there are some advantages IDE can bring, starting with instant syntax
>> checking and syntax-informed completion. (Syntax highliting is quite
>> easy to achieve in most configurable editors.) I have never used any of
>> the Java IDEs but I heard that some perform instant type checking, too.
>> This leads to a design question:
>> 
>> Where should the intelligent assistance to code writing be integrated?
>> In the compiler, or the editor?
>
> In the compiler.
>
>> It's not wise to put more power in the editor than in the compiler (what
>> if someone used a different editor, what if the file got randomly
>> screwed up during file transfers).
>
> Or, more to the point, what if the language changed (as Mercury does
> frequently) and the editor was useless by the next release?
>
>> In my opinion, what IDE developers should be after, is a tight interface
>> between the compiler and the editor, so that all the intelligence will
>> remain in compiler only, but we saved some cycles of constant rerunning
>> of the compiler black box. (The main reason for all IDEs driving me nuts
>> is the wasteful use of computational resources and typical slowdown of
>> all text editing operations.)
>> 
>> Are there any standards on compiler-editor interaction interface?
>
> GHC (Haskell) changed from a compiler to a library in order to support
> Visual Haskell (this then interfaced with Visual Studio through
> Haskell -> COM bindings).
>
> The Mercury way seems to be to add extra options to the compiler,
> rather than making it a library to be used by other programs (for
> example, recently generation of XML documentation of some sort was
> added, as another compiler option).  This would avoid the need for
> some kind of a cross-language bridge, but might make the interface
> with the compiler more granular (and thus less useful).

Actually, we support building the compiler as a library - the gcc
backend required us to do it that way.  The problem with making
the compiler into the library, as the gcc backend demonstrates,
is that if the Mercury language changes frequently then the
compiler internals change almost daily.  Maintaining a consistent
public interface to various compiler phases would be fairly tricky.
(Of course the gcc backend got the worst of both worlds since gcc
also changes fairly frequently.)

(The XML documentation of "some sort" is basically a representation
of the module interfaces as XML documents with the comments attached
to the various items - the compiler uses various heuristics to decide
what comments are attached to which items.  The idea is that you then
apply a style sheet to the XML documents and get documentation of
some form.  One of the MC people was working on a syle sheet that would
convert them to docbook format although I haven't heard anything recently.
The early output from it look promising; I don't remember if it was posted
to mercury-users or not.)

Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------