From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 102b75,501ec19d1d81daee X-Google-Attributes: gid102b75,public X-Google-Thread: 103376,db9a11afb3da4240 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-01 08:08:09 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.online.be!zur.uu.net!ash.uu.net!news.chips.ibm.com!newsfeed.btv.ibm.com!news.btv.ibm.com!hack From: hack@watson.ibm.com (hack) Newsgroups: comp.arch,comp.lang.ada Subject: Re: Language support for flexible handling of system-detected errors. Date: 1 Apr 2002 15:53:39 GMT Organization: IBM_Research Message-ID: References: NNTP-Posting-Host: starcraft.watson.ibm.com X-Trace: news.btv.ibm.com 1017676419 17754 9.2.8.37 (1 Apr 2002 15:53:39 GMT) X-Complaints-To: news@btv.ibm.com NNTP-Posting-Date: 1 Apr 2002 15:53:39 GMT Xref: archiver1.google.com comp.arch:26259 comp.lang.ada:21946 Date: 2002-04-01T15:53:39+00:00 List-Id: In article , Marin David Condic 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