SCOUG-Programming Mailing List Archives

Date:	Wed, 5 Feb 2003 16:51:19 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	SCOUG Programming SIG <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Back to basics

Content Type: text/plain

You just have to make the KISS principle work.

The computer's address space is linear which we can
represent as a series of periods: ......................................=
...

In programming we have to impose a non-linear form on top
of a linear base. While that form can contain data as well as
instructions, both of which look alike to the computer which
depends upon us to make that determination, we will focus
here on instructions only.

If our segment contains instructions only, we can represent
the instruction sequence as i-i-i-i-i-i-i-i-i-i-i. We have only
three classes of instructions: (1) those for whom only the Next
Sequential Instruction (NSI) is possible, (2) those which
support the NSI as well as a non-NSI, and (3) those for whom
the NSI doesn't exist unless it so chooses. Let us represent
the first by an "n";the second, by a "c";and the third by a "u".

As a result our original instruction sequence might translate
into: n-n-c-n-n-n-u c-n-n-c-n-n-n. Note the absence of the
NSI indicator ("-") after the "u". What we haven't shown here
is the alternate to the NSI possible with the "c". It turns out
that only two options exist, branch to somewhere before this
instruction or somewhere after the NSI.

Structured programming has three primitive control structures:
sequence, decision, and iteration. Both decision and iteration
involve the use of "c". Decision uses it to optionally branch to
some location after the NSI, while iteration uses it to
optionally branch to some prior location.

In an HLL decision is usually represented in the form
"if...then...else...". Our "c" occupies the "if...", while the
"then..." begins with the NSI, and the else with the "some
forward location". Because we cannot have the "then..."
treating the "else..." in an NSI fashion, we terminate the
"then..." clause with a "u" instruction. This "u" instruction
branches to the NSI location following the "else...". We can
represent this as follows:
=DA---------

c-n-n-n-u n-n-n-

=C0------

From this you can see that the control structure is an IPO
(input-process-output) unit in a one-in/one-out form. This
makes it basically reusable though the C language at the
moment makes this possible (through the use of %include),
but impractical.

All this assumes, of course, that you are using a editor with a
monospaced font. Otherwise these "drawings" are not lining
up in a meaningful manner.

For example, the case control structure, in C the
"switch...case...case...", has the following form:










c-n-u -c-n-u -c-n-u -c-n-u -n-










Of course, it only has this form in C if you use the "break"
statement. Though it doesn't really show it here due to a
drawing deficiency of mine, each c-n-u sequence is a decision
control structure and "if...then..." without the "else...".
Therefore each of them is a pluggable, reusable instance with
"one-in/one-out" as they are altogether. If you leave out the
"break" statement then each unit becomes "tightly coupled",
i.e. unpluggable, with the next. As a result C forces you to
write extra to achieve a valid control structure.

I could leave it as an exercise to the reader to pursue
iteration. I will offer the two forms, "do while" and "do until",
of iteration:
-----------
do while ---c-n-n-n-n-u -n-,
----------
----------
do until ---n-n-n-n-n-c-n-

The "do while" is the standard form for iteration. It
corresponds to what Iverson in APL refers to as "the method
of leading decision". It's beauty lies in that it works for 0, 1,
or more iterations, i.e. that it may not happen at all. On the
other hand as you can see from the "do until" it executes at
least once, therefore 1 or more iterations.

You can create a "do until" using a sequence -n-n-n-
followed by a "do while" containing the same sequence.

Again all of them follow the one-in/one-out principle. They
are pluggable units. This means they are reusable units. If
we give them a name, then the use of that name in a %include
statement will do as expected: replicate the named control
structure inline.

We don't do this in practice. One, it would create a god-awful
number of separate source files we would have to maintain
individually. Two, our editors even though they may
recognize a %include statement do not go to the next step of
including its source inline. That increases the difficulty of
viewing mentally the source, which means we want to
compile it as soon as possible so we can see it how it should
look.

I wish to make the point that the deficiency here lies with the
editor which doesn't know if you are writing a program or a
book. Even if it is a smart editor, i.e. it knows from the file
suffix, not only that you are writing source code, but in what
language as well, it doesn't make the effort to incorporate
%include statement data inline. That means you must piece it
together in your mind as separate windows of separate files
or else wait for compilation.

Now if you didn't use files to support %include, instead if you
used a database, you wouldn't need the %include to precede
the name. You would use the name alone as the source
statement. Now C allows this for procedures. If it didn't, you
couldn't have "printf" or "listf". So why not allow it for
control structures. The only difference is that you invoke
them inline through replication (control structures) instead of
out-of-line (procedures).

The real answer, of course, lies in making smart editors even
smarter. Then you only have one set of source code to view
regardless of the number of viewing windows you have open.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 05 | February | 2003 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.