Re: Typing Ada

Re: Typing Ada

[Karl A. Nyberg]

[Ed - forwarded.  Hopefuly this won't have gone out twice!]

-- Karl --

Date: Thu, 19 May 88 20:56:40 EDT
From: umd5!mitre-bedford.ARPA!sdl (Litvintchouk)
To: munck@mitre-bedford.arpa, INFO-ADA-REQUEST@ajpo.sei.cmu.edu
Subject: Re: Typing Ada


> I'd like to think that most programmers are using some kind of
> Ada-aware editor, but I fear it isn't so.  I'd appreciate an e-mail
> note describing what you do and what other programmers in your
> company/institution do.  (People who read Ada-Info are apt to be an
> unrepresentative sample.)

I wish I had a really "Ada-aware" editor, but I've managed to tailor
GNU Emacs on our Suns into something I (and a few fellow programmers)
can live with.  Currently the libraries I have added include:

1.  VADS modes:  Invoke most of the Verdix Ada tools with a single key each.

2.  Code idioms:  To get a "blocking queue" (in the Hibbard
	sense), type M-x adt-active  (i.e. "active abstract 
	data type"), at the prompt type QUEUE, and a skeleton of
	the package spec and body are inserted.  (It includes the 
	private part refined as a record type with a task component, etc.)
    I currently have a few code idioms for various kinds of abstract data
	types and selective waits (i.e. prioritized with guards),
	and am open to suggestions for more.
	
3.  Suntools menu interface:  Context sensitive Sun popup menus for
	these and other GNUEmacs modes

I would like to add a VADS library browsing mode (which would work
similar to Emacs' Buffer Menu mode), but I haven't had the time (yet).

GNU Emacs already has dynamic abbrevs (i.e. can complete a name based
on others already entered in the buffer), and hiding of indented
structure (replaced by "...") deeper than a user-settable threshold.
Together with the interface to a.tags I added, browsing of Ada code
isn't too hard.

One of my major gripes is that there appear to be no Ada
prettyprinters that can work on code *fragments*.  They all seem to
work only on entire Ada compilation units; I don't even know of any
ones which can recover from syntax errors in the Ada code and continue
prettyprinting.  Such restrictions make prettyprinters largely useless
during the editing process.  If a prettyprinter existed which could
work on a code fragment, then one could easily create an Emacs
"prettyprint-region" command by invoking the prettyprinter as an
inferior process with the region as input.

Bob Munck's suggestion of "outliner" like facilities for Ada is a good
one.  However, I thought that most document outliners assume that the
document is tree-structured.  But Ada's static semantics make Ada code
a network, not a pure tree.  (For instance, if you do something to a
private type declaration, then the refinement in the private part may
change, as well as references in the body, etc.) So an Ada "outliner"
would need to be network structured, and deal with Ada syntax and
static semantics.  The commercial failure of DIANA has made attainment
of this dream unlikely for those of us who cannot afford a Rational as
our personal plaything.

By the way, I believe that COMPASS is working on a smart interface to
editing Ada source code, which eventually will include handling of
network-like dependencies.  If anyone from COMPASS is reading this,
could you please enlighten us?


Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730
(617)271-7753

ARPA:  sdl@mitre-bedford.arpa
UUCP:  ...{cbosgd,decvax,genrad,ll-xn,mit-eddie,philabs,utzoo}!linus!sdl

	"Those who will be able to conquer software will be able to
	 conquer the world."  -- Tadahiro Sekimoto, president, NEC Corp.

Re: Typing Ada

[zellich]

In INFO-ADA Digest Vol 88 #115, Bob Munck discusses using language-aware
"outline processors" for writing and modifying Ada code; he also mentions
"Doug Englebart's fantastic system with the mouse and chord keyboard" from
"about twenty years ago".

It is probably little known, but Tymshare (whatever they're called now
that McDonald-Douglas bought them up) markets the current version of
Dr. Engelbart's system (called AUGMENT these days), which has hooks to
let you add language-specific constructs to the BASE editor (so you can do
things like issuing "Insert IF-ELSE" commands).  Unfortunately for most of us,
it only runs under the TENEX or TOPS-20 operating systems.

They also happen to have a MiniBASE product that is a major subset of the
BASE editor, and runs on the IBM PC family.  I don't know whether the mini
version has the hooks to add language-specific constructs or not, but it
does use a mouse - and sells for only $59.50.  They also made chord-keyset/mouse
packages for a while, but nobody outside that community ever took to the keyset
so they stopped making and selling it.

I don't know who the marketers are these days, but Raylene Pak
<RDP.TYM@OFFICE-1.ARPA> might be the right person to start with.  A query to
FEEDBACK@OFFICE-1.ARPA should also get you pointed in the right direction.

Disclaimer: I've corresponded with Raylene Pak about getting MiniBASE and
their AUGTERM (Augment workstation emulation package for the PC family)
product, but I haven't actually used the software yet.  I'm a long-time user of
Tymshare's hardware and software, but haven't had any contractual connection
with them for several years.

Typing Ada

[Bob Munck]

It has occurred to me recently that one of the most primitive,
labor-intensive operations in our current Ada technology is the
actual entry of code by programmers.  For example, it appears that
most programmers type an IF .. THEN statement by pressing SHIFT and
typing "I" and "F", releasing SHIFT and typing SPACE, the boolean,
and SPACE, pressing SHIFT and typing "T", "H", "E", and "N", etc. 
They type lots of tabs and spaces to indent the code, take at least
three keystrokes for an assignment, have to type closing quotes,
right parenthesis, and right brackets, have to type the package or
procedure name a second time after the END, etc. etc.

I'd like to think that most programmers are using some kind of
Ada-aware editor, but I fear it isn't so.  I'd appreciate an e-mail
note describing what you do and what other programmers in your
company/institution do.  (People who read Ada-Info are apt to be an
unrepresentative sample.)

However, the simple Ada-aware editor is only a beginning.  Editors
could do line-wrapping and spelling checking on comments as they're
typed, they could let you use a mouse to re-arrange code, and they
could display it with keywords in bold and comments in italic fonts. 
They could allow abbreviation of identifiers and expand them as
they're typed, fill in the rest of an identifier when you've typed
enough for a unique selection, or let you pick names from the
declarations with the mouse.

At the next level of sophistication, an editor could contain a lot
of the compiler and use information from the current compilation
unit and the Ada library to help the programmer.  This is a fairly
obvious approach that several systems already incorporate, sometimes
without doing the simpler things mentioned above.

I first saw an outline processor about twenty years ago, Doug
Englebart's fantastic system with the mouse and chord keyboard. 
Currently I use a commercial product named "ThinkTank" and it
frustrates the dickens out of me not to be able to do similar things
when writing code.  "Outliner-like" facilities would be great for
those who must maintain and update the code, also.

My current work is "operating system-type" code which, by its
nature, consists mostly of assignment statements, conditionals, and
complex data and code structures.  I've found it useful to maintain
a drawing of the complete data structure using a CAD tool and to
write a tool that extracts a picture of the code structure to the
procedure level from the listings.  I keep both of these up-to-date
and tacked to the wall in front of me.  The point is, it would be
wonderfully convenient if these two pictures could be in windows on
the screen and allow me to pick names from them with the mouse. 
Given that I can request statement skeletons by hitting function
keys with the left hand, I'd rarely have to move my hands to the
keyboard.  Of course, it would be great to be able to update the two
pictures and have the changes propagate into the code.

Is anyone out there doing research into this kind of thing?  I've
about reached the limit of macros for my emacs-like editor (Final
Word).
                         -- Bob Munck, MITRE

Re: Typing Ada

[Rick Conn]

Then again, if you are talking about editors, why stop with text?
the Interactive Ada Workstation, funded by the Air Force, includes
a Buhr diagram editor which allows the user to draw top-level Buhr diagrams
and have these diagrams compiled into Ada package and task specifications.
A nice first step toward a design.  There is also a language-sensitive
editor which fills in Ada constructs.  The IAW will be available, at least
in part, as part of Cadre's TEAMWORK during the next year or two.

	Rick
-------

Re: Typing Ada

[Bob Munck]

> the Interactive Ada Workstation, funded by the Air Force, includes a
> Buhr diagram editor which allows the user to draw top-level Buhr
> diagrams and have these diagrams compiled into Ada package and task
> specifications.

About four years ago I started an IR&D project to do something similar
with SADT diagrams.  MITRE decided that the Air Force wasn't interested
in things of this nature (SADT or Ada) and didn't renew the funding
after the first year.  (FYI, SADT diagrams are now an important tool in
SDI work.)

Though all I accomplished was a good PC-based tool for drawing the
diagrams, I am convinced that this is the direction that "guts-level
coding" has to take, be it Buhr, SADT, or whatever.  People can "read"
pictures better than words in a row; machines, until recently, couldn't
do anything at all with pictures and could handle only very simple
sequences of words (programming languages).  I think it likely that Ada
will be the LAST major one-dimensional programming language.

When the pictures get to the point of being adequate for stating
completely the operation of a system, we won't need the Ada anymore.  It
will become the equivalent of object code.

                              -- Bob Munck, MITRE

Re: Typing Ada

[Rick Conn]

Hi, Bob,

By and large, I tend to agree with you.  The power of the workstations
and the constantly-decreasing price/performance ratio along with the
supporting graphics software and standards (still emerging) is making
graphical software design and implementation more of a reality all the time.
However, I still see a lot of people just plodding along with poor support
budgets and 1970's technology.  Like the American society with its growing
chasm between the rich and the poor, I think we may also have a growing
software/technology chasm.  Ada may not be the last 1D language
from that point of view.

	Rick
-------

Re: Typing Ada

[Eugene N. Miya]

In article <12400974327.29.RCONN@SIMTEL20> RCONN@SIMTEL20.ARPA (Rick Conn) writes:
>By and large, I tend to agree with you.  The power of the workstations
>and the constantly-decreasing price/performance ratio along with the
>supporting graphics software and standards (still emerging) is making
>graphical software design and implementation more of a reality all the time.
>However, I still see a lot of people just plodding along with poor support
>budgets and 1970's technology.  Like the American society with its growing
>chasm between the rich and the poor, I think we may also have a growing
>software/technology chasm.  Ada may not be the last 1D language
>from that point of view.

By and large, it has been the experience of the people I know applying to
Ada jobs, that most contractors tend not to have fancy workstations yet,
even Macs are few and far apart.  These are major companies with 2 and 3
digit acro-names (not computer companies).  Bureaucracies still have vested
interest in the Departmental machine.  A friend just interviewed with
three Defense contractors in the LA area and decided to stay in Silicon
Valley on this basis.  The decentralized used of PCs and workstations
really challenges the centralized authority of lots of ex-military
organizations (companies, I already know about my employer).

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "Mailers?! HA!", "If my mail does not reach you, please accept my apology."
  {uunet,hplabs,ncar,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
  "Send mail, avoid follow-ups.  If enough, I'll summarize."

Re: Typing Ada

[Richard A. O'Keefe]

In article <25135.580491166@mbunix>, munck@MITRE-BEDFORD.ARPA (Bob Munck) writes:
> People can "read"
> pictures better than words in a row; machines, until recently, couldn't
> do anything at all with pictures and could handle only very simple
> sequences of words (programming languages).  I think it likely that Ada
> will be the LAST major one-dimensional programming language.

People can read *some* *small* pictures better than they can read text
conveying the same information.  But it doesn't seem plausible to me that
a program which would have been say 50k lines of ADA would be easy to
follow as a collection of several thousand pictures.  (Compare the
information density of a paperback detective story with the information
density of a comic.)  I would like to see some evidence one way or the
other about the practicality of pictorial systems -vs- structured text
for non-trivial applications (e.g. if the whole thing can fit on a SUN
screen, forget it).

Re: Typing Ada

[Randy Neff]

I would like to point out that very complex functional objects are designed
primarily with graphics, namely integrated circuits.   This is done through
a series of different abstractions and hierarchy.   
Abstractions:	Functional blocks
		Logic gates
		Transistors
		Mask rectangles
Hierarchy:	Cells of cells of cells of mask rectangles

In Ada, there is only a single hierarchy mechanism, the package; and only
a single abstraction, the programming language code.

Our research at Stanford with the language Anna (ANNotataged Ada) is 
adding an additional abstraction layer, an implementation independent
functional specification of a package specification.   This is equivalent
to a logic diagram of an IC;  the logic diagram explains how the chip
behaves, but not exactly how it is implemented in transistors or mask 
rectangles.

Re: Typing Ada

[Robert Eachus]

	[In Memorandum. The line eater, may he rest in peace.]

In article <2831@Shasta.STANFORD.EDU> neff@Shasta.UUCP (Randall Neff) writes:
(Some stuff omitted for brevity)
>
>In Ada, there is only a single hierarchy mechanism, the package; and only
>a single abstraction, the programming language code.
>
    To quote the Ada RM:

    Packages are one   of the four  forms  of program  unit of   which
programs can  be  composed.  The  other forms  are   subprograms, task
units, and generic units. Chapter 7, paragraph 1.

    All four are heirarchy mechanisms, all four  can be used  to model
abstractions (although each is most appropriate for a different set of
abstractions).   I'm sure   Randall's  omission   of other   hierarchy
mechanisms  was   accidental, but there  are many  Ada programmers out
there who don't seem to realize that generics and tasks can, and often
should, be used to create abstact data types,  so I couldn't  let this
just pass by.  (Just in case  someone decides  to  pick nits, Ada also
has blocks which can be considered as a heirarchy mechanism.  But they
are in general not used in that way, and should be excluded also based
on the sense of Randall's discussion.)


					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: Typing Ada

[David Collier-Brown]

In article <25135.580491166@mbunix>, munck@MITRE-BEDFORD.ARPA (Bob Munck) writes:
|  People can "read"
|  pictures better than words in a row; machines, until recently, couldn't
|  do anything at all with pictures and could handle only very simple
|  sequences of words (programming languages).  I think it likely that Ada
|  will be the LAST major one-dimensional programming language.

In article <1017@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
| People can read *some* *small* pictures better than they can read text
| conveying the same information.  But it doesn't seem plausible to me that
| a program which would have been say 50k lines of ADA would be easy to
| follow as a collection of several thousand pictures.  

I think you're both right.  Details are often best shown in text,
general structure in pictures.  I'd certainly prefer to walk a
call/rendesvous structure in pictoral form than by reading text, and
reason about the details by reading code and not pictographs.

--dave (horses for courses, perhaps) c-b
-- 
 David Collier-Brown.  {mnetor yunexus utgpu}!geac!daveb
 Geac Computers Ltd.,  | "His Majesty made you a major 
 350 Steelcase Road,   |  because he believed you would 
 Markham, Ontario.     |  know when not to obey his orders"

Re: Typing Ada

[Roger Racine]

There are many different approaches to software design.  I do not believe
that everyone can use pictures to do this.  If you are at all familiar with
the "left hemisphere" and "right hemisphere" (of the brain) theories, this
should be obvious.  Many people have difficulty thinking in words.  They
think in pictures (Einstein was one of these types of people).  

Then there are those who think in words.  They have difficulty picturing
things in their minds.  

Personally, I like to write words (Ada) and look at pictures for an overview.
I have tried to use graphics packgaes to draw the design, and find myself
"translating" the words into the graphics.  It would have been much more
efficient if I had a tool to help me write the words AND a tool to translate
the words into pictures.

The same thing was true with flowcharts.  I always wrote the code first and
then wrote the flowcharts.  When I started working on the Space Shuttle
program and found them using a flowchart generator, I was thrilled.

I view the graphical design approaches as slightly better than flowcharting.
I still prefer to design in a word-oriented manner.