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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!vsi1!wyse!mips!prls!philabs!linus!mbunix!eachus From: eachus@mbunix.mitre.org (Robert Eachus) Newsgroups: comp.lang.ada Subject: Re: Hypertext Ada Summary: Good Idea, Bob Keywords: Ada9X Message-ID: <46010@linus.UUCP> Date: 7 Mar 89 19:08:18 GMT References: <24216.605219947@mbunix> Sender: news@linus.UUCP Reply-To: eachus@mbunix (Robert I. Eachus) Organization: The MITRE Corporation, Bedford, Mass. List-Id: In article <24216.605219947@mbunix> munck@mitre.org writes: (Among other good ideas:) >I'm forced to type a long qualified name that the reader can use to >trace through my structure to the place referenced. A pain for both of >us. I certainly want to use italics, boldface, different fonts and font >sizes, and full proportional spacing in my documentation. This is one I'll not only second, but fight for. Let's extend the Ada syntax to list the standard ANSI (or ISO) control sequences, at a minimum those begining with ESC-[, as legal any place where an extra separator is permitted. Italics, bold, color, and font should be ignored when matching identifiers just as capitalization is. >It occurs to me that what I'm proposing here is a candidate for >consideration by the Ada 9X group. I don't want to change the >language, but rather the data format that it is embedded within. I >want a "multi-media hypertext" Ada with desktop-publishing >capabilities like "Mac Draw" pictures, scanner input, color, multiple >fonts, orientations, etc. Also, and more ambitious, the idea that >Ada code is _always_ read on and with the help of an interactive tool >that can travel around a hypertext, maybe something like HyperCard. >The problem of separating and keeping clear what the compiler deals >with is not difficult, but certainly can be a bit more sophisticated >than leading "--"s. This is general is harder than the above, but still worth the effort. What we need is a standard for storage and display of Ada source text that allows embedded pointers, either within the source, or to supporting documentation. The original idea was that such tools should be part of an APSE, and DIANA was to be used as a representation. The stuff that Dave and Chris are doing on EASE is a start on this, but you are asking for not only EASE, but the ability to embed hypertext in the DIANA. Sounds ambitious, but if we are asking for embedded formatting notations above, why not also ask for embedded annotations? > This means we have to raise our sights above the VT-100 as our >lowest-level programmer support, but not that much above. A Mac or a >PC with EGA display should do fine, and cost less than 1% of the >yearly cost of its user. The 9X people will have to struggle with >"external form," graphics, windowing standards, and other bothersome >subjects, but the technology is all available; it's just a matter of >making choices. While I'm against the 9X effort in general because >of the political dangers of changing the language, this wouldn't >bother me because it isn't really changing the language, but its >storage medium. An Amiga will do just fine, too. But I think you take the wrong approach in talking about the low cost of minimal tools. If a company is not willing to spend $10000 or more per software engineer on tools, has an intolerable level of turnover. The problem is at the companies where most of the money still goes into the dinosaurs in the machine room, not onto users desks. > -- Bob Munck, MITRE Robert I. Eachus with STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...