Re: Hypertext Ada

[eachus@mbunix.mitre.org (Robert Eachus)]

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