Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utcsrgv.UUCP
Path: utzoo!utcsrgv!peterr
From: peterr@utcsrgv.UUCP (Peter Rowley)
Newsgroups: net.cog-eng
Subject: Emphasis in programming lang's
Message-ID: <2608@utcsrgv.UUCP>
Date: Mon, 31-Oct-83 21:16:13 EST
Article-I.D.: utcsrgv.2608
Posted: Mon Oct 31 21:16:13 1983
Date-Received: Mon, 31-Oct-83 23:50:45 EST
Organization: CSRG, University of Toronto
Lines: 51

An interesting thing to do in a spare moment is to compare programming
languages to natural languages.  One of the things that distinguishes the
two is the use of emphasis in natural language, particularly spoken
natural language (or USNet n.l., which uses *emphasis* of various kinds :-) ).

Here's an example of where emphasis is useful:

i:=0
while i<n do
  process_item(i,j)
  i := j+1
end while

Given a (possibly worn) printer font which made i's and j's look alike, this
code segment might, if read quickly, be chunked into a "run-through-all-items"
routine.  Evidence of such chunking has been revealed by experiments that show
that expert programmers remember programs better in forms in which readily
discernible chunks are available as opposed to randomly ordered lines of code.
This is similar to the experiments that show that expert chess players can
remember boards very well, but only if the pieces are in legal positions.

Unfortunately, this is NOT a run-through-all-items routine; someone has
optimized it so that process_item does a few items, starting with the i'th
and ending with the j'th (which it sets).  Given the erroneous chunking, one
might add the line     other_process(i)      right after the call to process_
item and expect it to be called for each i in 0..n-1.

Emphasis on the i := j + 1, which might be provided by a comment (e.g.
/* This is tricky */ or, better, /* Advance to next unprocessed item */)
reduces the chance of a bad chunk.  But there are two problems with relying
on manually written comments:
  1.  They disturb the visual appearance of the code excessively.  After all,
      this is pretty close to a run-through-all-items routine.
  2.  Much worse, it may not be obvious to the original author that a comment
      is needed.  The algorithm may have been conceived in this form and
      it never thought that it could be mistaken for a simple loop.
A possible solution is to have a formatter which recognizes such chunks
(not too hard, really, though cataloguing common chunks would be an interesting
task) and then uses more subtle, though definite, typographic techniques to
add the appropriate emphasis. e.g. boldface the i := j + 1 and possibly issue
a warning that readability would be enhanced if the variables named i and j
were named more distinguishably ("Warning: typographically close identifiers").

I'd be fascinated to hear of any programming language/system that has the
notion of emphasis.  Even equivalent constructs, each emphasizing a different
part of the construct's purpose, would be interesting to hear about.
Opinions on the idea in general would be welcome traffic for this group.

peter rowley,  University of Toronto Department of C.S., Ontario Canada M5S 1A4
{cornell,watmath,ihnp4,floyd,allegra,ubc-vision,uw-beaver}!utcsrgv!peterr
{cwruecmp,duke,linus,decvax,research}!utzoo!utcsrgv!peterr