SCOUG-Programming Mailing List Archives

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

Date:	Sat, 9 Aug 2003 08:34:02 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: English as programming language (was: Warpstock 2003 Presentation)

Content Type: text/plain

"...In short, not every English phrase is a program. I can write
non-programs in COBOL, PL/I and assembler too. ..."

Peter,

I can't let you get away with this one. You may be able to
write "incorrect" or "nonsensical" programs in any
programming language, but you cannot write "non-programs":
you must conform to the syntactical and semantic rules.
Whatever you write--good, bad, or indifferent--remains a
program: it adheres to the rules.

"...Take any English sentence that is part of a program. Parse
the sentence (a non-trivial task). Call the necessary
subroutines. ..."

Too beguiling. To be part of a program it must have passed
an "operational" set of syntactical and semantic rules during
parsing which would determine the ensuing processing. So
even its english form, its syntax (structure) and semantics
(nouns and verbs) would occur under tight control. That
includes even "flexibility".

"...Sounds like COBOL, yes? But a COBOL sentence takes a
rigid syntactical form; I think that we've learned enough in the
past 40 years to allow a more general free-flowing syntax. ..."

No. COBOL's language committee did its best to make it as
english-like as possible. I refer you to Jean Sammett's "A
History of Programming Languages". Jean was an IBM member
of that CODASYL committee.

Unlike english they decided not to end every statement
(sentence) with a terminator (period). Instead they opted to
begin each sentence (statement) with a "keyword", which
was also a "reserved" word. They allowed this keyword,
which marked the beginning of a statement to also serve as
the terminator of the previous statement. This allowed whole
groups of statements, i.e. statement groups, to occur with
only a single terminator, a period, at the end. So if you had
an embedded, i.e. nested, statement group, e.g. a decision
control structure (if...then...else...) not terminated with a
period, incorrect logic existed. This lead to the not infrequent
search for the missing period. I can tell you from personal
experience in hundreds of occurrences that the discovery
process could take hours and in a few cases days.

Now Greg Smith jokingly go round and round on this
terminator thing, because in PL/I every program element,
including group statement initiators and terminators, is a
statement and every statement ends in a semi-colon. In
Python if you say with one statement per line, you do not
need to use a statement terminator, a semi-colon. If you have
more than one statement per line, you do.

I probably shouldn't bother anyone with the fact that in
COBOL, C, and practically everyone else "keywords" are
"reserved" words. I mention this as they are not in PL/I. Just
another example of K&R's claim that C has fewer restrictions
than other programming languages: "Oh, yeh, then why do you
have to name the principal procedure "main"?"

What you want is a language with few rules and possibly
even fewer restrictions. That makes it easier to learn and
easier in writing to get from point A to point B. It should
allow minimal expression of complex operations just like
english does. Thus like APL and PL/I its operators should
support the use of aggregate operands as well as the
"normal" element operand support of other programming
languages.

"...The output need not be an executable. Rather, the
program could create source code in an existing computer
language -- perhaps RPG, perhaps SQL, perhaps Rexx,
perhaps PL/I, whatever. ..."

Now here you must really believe there's a horse in the
manure pile you've gathered. To say that it need not be
executable is to say it's a specification language only,
something for which no compiler exists. Like in the beginning
ALGOL which could afford integers and reals because it didn't
have to concern itself with implementations. It also had the
luxury of assuming the pre-existence of data with values: it
had no defined i-o.

The problem lies in the translation process, whether it is
exact, i.e. logically equivalent, or inexact, i.e. something either
added or left out. If it is exact into one language and not
another, part of "a determination as to which computer
language it would use", and this were true in at least one
instance of each possible language, knowing that a "logical
equivalent" executable object form could be defined, then
save yourself a whole lot of effort by writing a compiler for
your specification language, transforming it into a
programming language as well.

"...And I think it belongs in the new HLL we're discussing."

If the two forms are logically equivalent (and that is the key
here), why on God's green earth would you not just pick one?
In short, why have two when one will do. I happen to
believe that PL/I in terms of data types and operators is the
most complete programming language ever written.
Demonstrably it's syntax is simpler. Demonstrably it has fewer
restrictions, fewer rules, and implements strong typing
intelligently through default conversion rules among
arithmetic and string (bit and character) data types.

And now finally:
"...The subject title of this discussion is "Warpstock 2003
Presentation". You said earlier that this was a presentation
you hoped to give at Warpstock.

You're going to give a presentation that _isn't_ about your
project?"

Yes. The proposed presentation has the title "Opening Open
Source". It is related to the impetus starting the current
effort in the SCOUG programming SIG. That it might possibly
tangentially overlap my project occurs simply in that I am
involved in both.

I don't want anybody to think I'm locked into being a one-trick
pony.

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

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