SCOUG-Programming Mailing List Archives

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

Date:	Thu, 7 Aug 2003 15:36:16 PDT7
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Re: Warpstock 2003 Presentation

Content Type: text/plain

Lynn H. Maxson wrote:
>
> 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

That's not a proof. :))

> "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.

And you're disproving your own hypothesis. You arbitrarily throw away
my data simply because it doesn't meet your preconceived notion of how
to cut the grass.

I notice you're hesitant to give any counter examples . . .

> "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.

Show me. Write something which shows how to do this. Your example need
not include a lawnmower.

Bob said that Prolog was logic programming. He suggested that we have a
way to prove code. Here's some blank space for your preliminary
PL/I-Prolog code example so we can at least start to take a look at the
added value of combining these two languages:

:
:
:
:
:
:
:

> "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.

That word "ambiguity" is going to result in a lot of mission creep.

If something is ambiguous then the compiler will know it. If the
compiler doesn't identify an ambiguity when one exists then the compiler
is faulty.

Here is some blank space for anybody to write some ambiguous English
code that the compiler won't realize is ambiguous:

:
:
:
:
:
:
:

> Diagramming a sentence which relates to its
> structure and relationship among its parts
> is not the same as determining meaning.

It's called "parsing". Many compiler writers like to parse the source
code as a step towards compiling the program.

> We can easily demonstrate how frequently the same
> writing has different meanings to different people.

I'll accept that you can use English to write nonsense. And I'm also
sure you can write a nonsense program in PL/I.

You are searching for any possible argument, no matter how minuscule, to
eliminate English as a potential programming language. Yes?

> "... 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.

Someone stated that the Programmer Interface generates the compiled
code. Another stated that the Programmer Interface was merely a way for
the programmer to manage the source code.

Do you have a position on this issue?

> 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.

The above appears to me to be a simple dependency tree. Parsing the
decision blocks to learn the other blocks that each depends on is
trivial.

The occasional surprise where you have two blocks that each depend on
the other (codependency) is also trivial. The recursive situation where
a block depends on itself is also trivial. The more complex situation
where block A depends on a block which depends eventually on block A (a
ring of dependencies) is also trivial. These trivial cases may overlap,
i.e. a ring of dependencies may contain blocks which are also recursive,
and these cases are also trivial.

> 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.

I'm unclear on why you want a two-step compilation process, the first
step being a "completeness" proof to show that the code is complete
enough to be compiled and the second step being the actual compilation.

What is your purpose behind completely separating these two functions?
Certainly there are many other steps in a compilation process which must
take place in a particular order -- shouldn't we just say "compile the
source" rather than arbitrarily moving some of the steps outside of the
"compiler"? The preprocessor and the syntax parse are two steps which
we tend to place totally within the "compile" action; do you want to
separate them?

> 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.

How is this different from a thoroughly-written (and perhaps
database-driven) make file?

> 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.

Lynn, I don't see anything here that isn't already being done. Perhaps
that's why someone has commented about the lack of productivity
increase; perhaps we're already there.

> "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.

So your answer is "no". Okay.

> 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.

Pascal uses := which I feel is better than <-.

See the problem? Everybody wants different graphics to denote
assignment. If you don't want the ambiguity (snort!) of a = b = c then
you should allow alternate assignment indicators. The compiler will be
smart enough to figure out what is going on, and if not, well, perhaps a
little explanation in English will clear the matter up.

> I don't want to confuse the C programmer . . .
> Let him enjoy the extra typing of C.

Think "voice recognition", Lynn. You aren't allowing for the future.

- Peter

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

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.