Re: Language support for flexible handling of system-detected errors.

[hack@watson.ibm.com (hack)]

In article <a82c8r$3ar$1@nh.pace.co.uk>,
Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
>Two things: 1) Nobody building a compiler can possibly guarantee you that it
>will work with *your* editor since that could be just about anything. There
>is no "standard" interface to every editor on the planet, so this would be a
>hopeless goal.

Agreed -- it's the lack of the *concept* even of a standard interface that
hurts.  It could just be a chicken-and-egg problem -- but I'm afraid it's
worse because there isn't even a general desire for this kind of thing, as
far as I can tell.  

> 2) A compiler like GNAT provides a good deal of programming
>interface (such as ASIS) so that if you were so inclined, you could
>integrate it to your favorite editor with your own glue code - presuming, of
>course, that your editor of choice had the capabilities you need to invoke
>some code & utilize the results.

Clearly only those editors willing to do their share of communicating in a
general (and flexible, programmable) way can be considered.  For the simple
purpose of writing and testing programs, one can indeed cobble up the needed
interfaces.  For example, in my environment, many compilers access services
through an emulated OS/360 interface, and I have hooks in that interface that
allow the compilers to read out of the editor (thinking they are reading a
plain old sequential file).  But much more is possible if the compiler offers
an interface to check-parse strings, to enquire about types and symbols, etc.

My main point was *against* the closed nature of many IDEs, i.e. the view
that "integration" means to have in one place (and style) everything related
to a particular language or compiler -- as opposed to my view of "integration"
as to ability to communicate equally well, in a single familiar environment,
with many separate working environments (compilers, e-mail, runtimes etc.).

>I don't think its practical to ask of a language and IDE that it somehow
>connect to any given other piece of software anywhere. I don't know of any
>IDE that could achieve that goal.

Agreed -- it should only have to connect to one conceptual interface, which
other participating tools (such as editors, printers, e-mail systems etc.)
would also connect to -- without having to know about each other's particular
properties.

The Unix stdin/stdout pipe paradigm offers such a conceptual interface, but it
limited in that it is unidirectional.  (Pairs of pipes are possible, but lack
the needed synchronisation that *this* result belongs to *that* request.)

The CMS/YMS subcommand environment offers another, coroutine-like, conceptual
interface, where a program makes its services available via callback to other
programs invoked from it.  (This mechanism is very lightweight, so macros can
use it for high-performance automatic interaction involving tens of thousands
of requests per second.)

The mechanisms described above all assume communication via command strings
and result strings (plus return codes, if we're lucky).  THIS is what is
missing in a GUI-only tool.  There may be screen-scraping tools capable of
having a program "click" the 3rd button, read a button label or field content,
but the lack of layout consistency makes those tools awfully difficult to use.

Michel

>
>MDC
>--
>Marin David Condic
>Senior Software Engineer
>Pace Micro Technology Americas    www.pacemicro.com
>Enabling the digital revolution
>e-Mail:    marin.condic@pacemicro.com