SCOUG-Programming Mailing List Archives

Date:	Tue, 25 Nov 2003 11:39:24 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: Once again no fray

Content Type: text/plain

According to the "Schedule by Steven" we have no time
allocated for the programming SIG at the rescheduled
December 7th meeting. Apparently it's party time and why
not? Nevertheless we might informally meet to discuss next
year's schedule. I just think that right now everyone's plate
like mine is fairly full.

Nevertheless if we can't quite return to regular monthly
meetings, we can continue the irregular ones here. The less
we have of one the more we need to take advantage of the
other. Maybe we can even consider using chat services, if we
can agree on a day and time.

To return to subject we will once more emphasize that three
third-generation (imperative) programming languages--LISP,
APL, and PL/I--cover the complete range of data types and
operands available in all other third-generation programming
languages. We can synthesize these three using the PL/I
syntax. The only change we have to make lies in designating
a list operand (aggregate).

LISP itself uses parenthesis. We will use left ([) and right (])
brackets instead. We do this to avoid confusion in a
parameter (argument) list for an API. PL/I allows the
programmer to "protect" a parameter by surrounding it with
parenthesis. The software will create a copy of this
parenthizised parameter, passing its address to the called
routine. Thus if the called function modifies it in error, the
error is not reflected in the calling routine. Just another of
those "little" things in PL/I that makes life (and programming)
easier.

This gives us the most complete imperative language possible.
It does say that you can have one language that does
everything equally as well as it is done elsewhere...if it can be
done there at all.

We will set aside for the moment considerations for adding
fourth-generation (declarative) forms, supplementing the
existing imperative forms. We actually want both in the same
language, because computer instruction sets themselves are
imperative in nature. Thus any declarative form must
translate into one or more imperative form down to the
instruction set level.

In doing this we have avoided the mistake made almost
universally in all fourth-generation languages, including AI and
neural nets. They opted for a "pure" form. This prevents
them from implementing them entirely in their own language.
Thus at a minimum requiring two languages instead of one.

The basic "reusable" program element is the statement. Thus
statements are the "raw material" used in all higher level
constructs. The first higher level construct is the control
structures of sequence, decision, and iteration.

The simplest of these is the sequence which is a series of two
or more statements or control structures. Statements have an
one-in, one-out IPO form as do control structures. Thus both
are pluggable, i.e. reusable, forms. As a control structure is
an assembly, it can contain other control structures
(assemblies) within it. However nested the assemblies the
one-in, one-out IPO form remains throughout.

COBOL introduced the use of named code segments it refers
to as paragraphs. These paragraphs consist of everything
from a single statement on up to any combination of
statements and control structures. COBOL invokes these as
sub-routines without parameters, in effect as in-line code.

However, a COBOL program consists of a single procedure
division, a single external procedure with no ability to nest
internal procedures within it unlike PL/I, C, and other
block-structured languages. OO COBOL allows multiple
external procedures, multiple procedure divisions, to exist.

That's something of an aside which has meaning principally to
show that at least one compiler implementation of an
imperative programming language exists that supports
compilation of multiple external procedures in a single
compile. Thus the concept is not without precedence.

More to the point COBOL recognized that reusable code
segments, i.e. routines, existed below the "block" or procedure
level. We invoke these code segments through a name we
assign to them. We have no means of doing this currently in
PL/I or C without doing label "goto"s, a earlier practice now
forbidden in IT shops. We find this lower level code segment
reuse a staple in fourth generation languages. Thus to
upgrade any third-generation language to fourth we have to
add this capability as an "under-the-cover" labeled "goto".

Of course, we can do something similar with the "%include"
statements in PL/I and C. We can store reusable code
segments as individual files. Unlike the out-of-line invocation
of paragraphs in COBOL here we can reuse through inline
replication. Just note that we do not invoke them at
execution time by name.

Oddly enough sometimes when invoking a code segment we
may want to have the choice of either inline or out-of-line or
possibly both on an instance by instance basis. COBOL doesn't
provide for inline invocation. PL/I and C don't provide for
out-of-line. We might like to have a named code segment in
our source which we can invoke as a name-only statement,
e.g. 'sugar;', while designating its invocation as either inline,
e.g. 'sugar inline;' or out-of-line, e.g. 'sugar;',the default.

We know that fourth generation languages like Prolog allow
invocation of named code segments. Again a named code
segment includes everything from a single statement on up to
just below the procedure level. We will find it just as
awkward to create single statement code segments as
individual files in fourth generation languages as in third.

For that reason as well as a number of others a better
solution lies in using a database for storage and retrieval of
source than a file system of separate files, separate
directories, separate drives, etc.. Using a database approach
we can take advantage of statement reuse by storing each
unique statement separately, assigning to it a content-based
name. That in turn allows us to treat named code segments
as a list of names. This shifts source code maintenance from
file management to list.

By using list processing instead of file processing for source
maintenance and allowing software-assigned names for
source statements to supplement programmer-assigned names
for code segments and procedures we can turn the entire
process of source maintenance, i.e. we can automate it
completely, over to software as integral to the editing
process.

Thus we can invoke a code segment name as a single
statement, designating it as either inline (replicated source) or
out-of-line (subroutine) on an instance by instance basis.
This allows the named code segments themselves to appear in
any order, i.e. unordered source, on input. The completeness
proof, the first stage of our two-stage proof engine
supporting logic programming, i.e. fourth generation language,
then will reflect either inline or out-of-line usage as part of
its logically organizing the source.

That means the editor will offer a window for each mode, one
for the unordered input, the only editable source, and one for
the ordered source output, dynamically produced within the
completeness proof. It will also offer a window designating
an alphabetized attribute and cross-reference listing of all
names used in the source.

That, my friends, gets us closer to a "true" IDE.

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

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 [ 25 | November | 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.