One major difference between third and fourth generation
languages lies in the granularity of reuse. In third generation
languages reuse occurs at two levels: (1) procedure and (2)
file, i.e. the #include in C. In fourth generation languages
reuse occurs from the statement level on up to a procedure
equivalent and the file level as in C.
We have two types of reuse: (1) sharable reuse, where a
single code set supports multiple references, and (2)
replicated reuse, where each reference injects an instance of
a code set. Sharable supports out-of-line reuse, i.e. an API
call, while replicated supports in-line reuse. Depending upon
the instance we may want to have the option of specifying
which reuse form, sharable (out-of-line) or replicated
(in-line), that we want.
Perhaps the first step toward achieving the finer granularity
of fourth generation languages in C lies in eliminating the
need for and thus continued use of internal procedures. This
will allow the use of external procedures only as input to a
compile. If you have external procedures only, then the
current distinction of internal and external disappears, leaving
us with only procedures pure and simple.
Eliminating the use of internal procedures, in effect allowing
the input of multiple [external] procedures, eliminates, one,
the need for multiple compiles, and, two, the need to link the
separate compiled modules into one. Further eliminating these
two eliminates the need for a makefile, one less source to
create and maintain as well as one less separate process to
invoke.
Perhaps prior to do this we should change the compiler from
its current one-pass limitations to a less restrictive multi-pass
form. This eliminates the need for the use of most "void"
statements in C along with any need to insure that we define
a referent prior to its use in a reference, e.g. "int b;"
(referent) and "b = b + 1;" (reference) can appear in any
order. We can extend this from data references of data
referents to procedure references of procedure referents.
This means that the procedures themselves can appear in any
order, i.e. unordered, on input.
Don't let the implication of this go unnoticed. If you don't
have "internal" procedures, only unordered "external" ones,
then who does the ordering? Imperative languages currently
require a single external procedure with optional multiple,
hierarchically ordered internal procedures on input. In short
the programmer has to create the logical, i.e. hierarchical,
order as part of writing the source. With this change to the
use of multiple, unordered procedures on input to a compile
the software assumes the responsibility for creating the
hierarchical order, the logical organization of the procedure
source.
Now having changed the compiler from one-pass to
multi-pass, i.e. two or more, and allowing multiple, unordered
procedures on input, we have a couple of more changes we
should effect.
If we allow the software to logically organize the source into
hierarchical order with one highest level procedure at the top
(or root) level to produce a single object module, nothing
prevents us from extending this to allow more than one
highest level procedure on input. This allows us, one, to
produce multiple object modules from a single compile, and,
two, to automatically synchronize source code changes across
multiple modules within a single application system or across
multiple application systems...all within the scope of a single
compile.
Definitely do not let the implications of this on productivity
elude you: you need one programmer, one compile, all
affected modules.
Unfortunately to do this in C we have to eliminate a current
restriction that it should not have had in the first place. That
restriction says that an external procedure which will receive
control from the operating system (and thus not from another
module) we have to name "main". Obviously we cannot have
this if we are going to allow multiple such on input.
Therefore we eliminate this requirement, allowing us to assign
a name to this highest level procedure as we would any other.
Thus we have "improved" C as well as our own productivity.
We did it while maintaining full compatibility with existing C
source code and methods. Anyone who wants can continue
with his less efficient and productive methods. The rest of us
who want to work smarter instead of harder will finish early
enough to have time to observe the struggles of "old time
professionals".
************************************************
=====================================================
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".
=====================================================
<< Previous Message <<
Return to [ 19 |
March |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
