SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Thu, 7 Aug 2003 09:57:32 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Re: Warpstock 2003 Presentation

Content Type: text/plain

Peter Skye writes:
"...I don't recall ever seeing a proof that the code was optimal,
though I take for granted that it is."

It's optimal in that the fewest instruction sequence
representing an expression gets generated in the input
stream, a side effect of eliminating parenthesis as well as
shifting from an infix (a + b) notation to a suffix ( a b +) as
well as the push and pop of the stack.

"I still see a benefit in using English, however. Suppose I'm
building a computerized lawnmower and I want to specify the
desired grass height: ..."

As I said before, Peter, I always enjoy it when you offer
something that answers your own question. Here I think you
might stop them with "crunchy", "your bare feet",
"county-imposed", and "fertilizer burn". As an urban farmer,
familiar somewhat with the "gray areas" here, you won't even
get people to agree on this one in terms of action even where
you have it on intent.

"I'm not sure that's possible. Can PL/I be extended to fully
encompass a Prolog style of code? ..."

Yes. Through the addition of an assertion statement and the
use of the "range" attribute in the declare statement to
incorporate rules. What you have is the simple, readable
syntax of PL/I versus the "ugly" choices made for Prolog.

"The programmer can choose? Then why not also allow
English? If it's up to the programmer, why not allow the
option of writing the solution method in English?"

Why not indeed. We keep thinking of software as separate
from the people who write it. If I can misread what you write,
i.e. not receive the same meaning as transmitted, then what I
write in software may not correspond to what you want. I
have no choice to introduce ambiguity in software at
execution time, because I have no means given current
machine architecture and instruction sets for somehow
including it. Therefore we must engage in an iterative
process, just as we do in these messages, to get to the point
where at least in some part we both have the same meaning.

Diagramming a sentence which relates to its structure and
relationship among its parts is not the same as determining
meaning. Meaning itself is never contained in the writing, only
in the readers and writers of it. We can easily demonstrate
how frequently the same writing has different meanings to
different people.

"... It's possible to integrate the two so the code is
regenerated with every line change -- is this what you
want?"

No. You have no need to generate code until you want to
execute it. Setting code generation aside until needed, you
have the problem when writing new code entails the
rewriting, i.e. the reordering, of old. Not infrequently this
occurs when writing decision (if...then...else) control structures
which alters an existing set of relationships.

Imperative languages require that the programmer
"physically" maintain the source in its "logical" order. The
ordering (writing) and reordering (rewriting) remains a
programmer responsibility.

In the early sixties considerable we exerted considerable
effort promoting the use of decision tables and tools to
automatically compile them (DETAB). Consider the decision
statement itself, "if...then...else...". The "then" and "else"
clauses represent a sequence control structure within we fix
the order. Also within them we can include other decision
statements.

Now suppose that we consider each decision "block"
separately. We give each a name. Wherever one appears
referenced somewhere else we simply refer to it by name.

Now we can create an unordered list of decision blocks. By a
simple process of ordering based on internal references create
a set of hierarchies. That set will consist of single decisions
neither referenced by nor referencing others: a hierarchy of
one. Or it will consist of one or more hierarchies whose root
decision is referenced by no other (thus making it a "main"
decision).

The function of the DETAB application, for which both a PL/I
and COBOL version existed, was to organize a single (main)
hierarchy from the unordered set, thus creating the
application. If you changed an existing decision, either the
condition (if....) or the clauses (then... or else....), or added a
new one, after the change you reran DETAB. Thus you
invoked software instead of programmer reordering
(regeneration) of the source from source that could remain
unordered.

What's important here is the software ordering (and
reordering) of unordered source based on the internal
referencing patterns found in the source. You don't need to
generate code until in essence this "completeness" proof
completes to your satisfaction.

Now the same internal reference pattern works for
procedures. All procedures have a name and refer to each
other internally by name. Nothing prevents you from having
an unordered set of procedures on input, and processing them
to get one or more hierarchies. Again like the decision
processing you get those procedures referenced by and
referencing no other procedure and one or more "main"
hierarchies.

Unfortunately compilers are picky. They only allow one
"main" hierarchy at a time. Clearly nothing prevents them
from compiling each hierarchy from a single procedure on up
as part of a single compilation process producing one or more
object modules. In that manner if you have made a global
change to the source of an application system of multiple
programs, you could input the entire source for all. In a single
compile you could synchronize the change(s) across all
programs. In fact you could do the same for a change
impacting an unlimited number of application systems and thus
application programs. You require only one compilation
initiated by one programmer.

Now Bob Blair may not regard this as significant an increase in
productivity as I do with respect to what certain changes to
compilers may produce, but this would be a winner in any
account with which I've had experience.

If you leave the programmer only responsible for the source
statement sequence within the clauses (then..., else...) in a
decision block, then you can collect the decision blocks in any
order (thus random or unordered), leaving it up to the
software to determine the ordering. With any change the
software can reorder.

"Lynn: Will your HLL include a definition for a screen design
tool?"

The HLL is a "universal" specification language. The only
definitions are specifications. If you specify a screen design
tool, the answer is yes. The Developer's Assistant is written
in the specification language as is the specification language
itself. Otherwise it wouldn't be universal. It just turns out
that this specification language is a programming language as
well.

Just one last comment relative to Prolog, about what happens
when you go overboard. In Prolog you denote a statement
sequence, i.e. a specific order, by connecting the statements
with an "and" operator. The problem is that "and" in logic is
commutative: the order is unimportant. It's an instance of
unnecessary operator overload. Thus the same "and"
represents different things depending upon context.

The "a = b = c;", a statement valid in PL/I and not in C,
represents operator overload. The first "=" is the assignment
operator;the second, the logical operator. Now C gets cute by
introducing "==" along with "&&" and "||". PL/I would be
better off by dropping the "=" for assignment by using the
APL left arrow ("<-") to make the statement read "a <- b =
c;", i.e. replace the value of a with '1'b if b = c, otherwise '0'b.

I don't want to confuse the C programmer reading this that in
PL/I a, b, and c could be arrays (dcl (a, b, c) (20, 20, 20)
bit(1):) and that "a = b = c;" remains valid. Or that even
possibly you could reset all three to '0'b: "a, b, c = '0'b;". No
sense in confusing him with the ability to have multiple
lefthand variables, i.e. multiple assignments in a single
statement. Let him enjoy the extra typing of C.

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

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 [ 07 | August | 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.