SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Mon, 16 Apr 2007 10:00:35 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Saturday's preparation

Content Type: text/plain

I've been a bit under the weather with pneumonia lately
which has put a crimp on a number of planned activities. So I
don't know how much I can accomplish between now and
Saturday in terms of preparations for the Programming SIG
meeting. I do plan on being there. I do plan on having
something to offer.

Recently the revered, respected, and retired IBM Fellow, Jim
Backus, the father of Fortran, died. Looking back we may not
regard it as much of an achievement to have an IBM scientific
computer, the IBM 701, to step up from machine language,
bypass symbolic assembler, and go directly to an HLL. It might
seem even less so when your "if...then...else" control
structures directly adhered to the "logic" of the underlying
instruction set. But in truth it was a big deal.

Also in truth my admiration for him extends to something
actually bearing his name, the Backus Normal Form (BNF),
which he concurrently developed with Fortran to define the
syntactical structure of the language. Its a second language
or notation used to describe a structural aspect of another.

It has continued as such unto this time. At least every time
some instance of LEX occurs. Now LEX is written in C, but the
language is not C. So in effect we have a language used to
implement another language about some aspect, i.e. syntax,
of another. No one ever really asks why. Why do we have to
have a different language to describe another?

I don't know how many of you have ever ventured out to
follow two other ongoing projects, Maude and Tunes, in which
language plays the central role. When I have people look at
me as if I have wandered far afield into esoterics, I would ask
them to consider the following conference announcement:
************************************************
7th International Workshop on
Reduction Strategies in Rewriting and Programming
http://www.lsv.ens-cachan.fr/rdp07/wrs.html

Paris, France, June 25, 2007

held in conjunction with the
4th Federated Conference on Rewriting, Deduction, and
Programming (RDP 2007) http://www.rdp07.org/

Scope

The workshop intends to promote and stimulate
international research and collaboration in the area of
strategies. It encourages the presentation of new directions,
developments, and results as well as surveys and tutorials on
existing knowledge in this area.

Reduction strategies study which subexpression(s) of an
expression should be selected for evaluation and which
rule(s) should be applied. These choices affect fundamental
properties of a computation such as laziness, strictness,
completeness, and need, to name a few. For this reason some
programming languages, e.g., Elan, Maude, *OBJ*, and
Stratego, allow the explicit definition of the evaluation
strategy, whereas other languages, e.g., Clean, Curry, and
Haskell, allow its modification.

In addition to evaluation strategies, WRS 07 also covers
the use of strategies and tactics in other areas such as
theorem proving and termination proving.

Thus, strategies pose challenging theoretical problems and
play an important role in practical tools such as theorem
provers, model checkers, and programming languages. In
implementations of languages, strategies bridge the gap
between operational principles, e.g., graph and term rewriting,
narrowing and lambda-calculus, and semantics, e.g.,
normalization, computation of values and head-normalization.
************************************************

Now of all that I got to see an old acquaintance, the
lambda-calculus. It's more popular use relates to "binding
time", just how early or how late it can occur in a variable in
which other expressions and thus other variables can then
proceed. Normally procrastination occurs as much in
programming as in any other activity, resulting in employing as
much "late binding" as possible.

For example, take the variable "able". Is it an element or an
aggregate? Is is arithmetic ( float, decimal, binary) or string
(character, bit)? If arithmetic, is it real or integer? If so,
what precision? If string, is it fixed or variable length? If
variable character, is is null-terminated?

Wouldn't you just like to declare "able" and hold off on all the
rest until you got to the end? At that point you can examine
all its use instances and make the "optimal" decision on its
detailed attributes.

You can in either APL and REXX never have to make a
decision. You must bind at least the name. Beyond that
whatever expression appears on the right-hand side
determines the underlying attributes of the variable name on
the left-hand side. You can go crazy with this. In one
instance offer it with a arithmetic express, in another in a
string. The ultimate freedom.

You have a price to pay for this once its local use, normally
within the bounds of a single program, wanders out into more
global territory in which others have had an equal fondness
for the same variable name. Now when you have all these
use instances accumulated at the end with all the variations
of string and arithmetic possibilities, you begin to realize the
price you pay for up front ease with backend maintenance.

The difficulty with focusing on a programming language, more
importantly a single, program use instance, basically thinking
inside the box, works until it runs smack dab against the
reality of the outside. That in my opinion is where the
academics promoting Tunes or Maude have turned a blind eye.

I don't oppose the late binding of data, i.e. variable, attributes.
If you simply want to write "dcl able;" and wait to the end to
fill in the rest, be my guest. If you want only a partial late
binding by writing "dcl able string;" or "dcl able numeric;",
that's fine also. But when you enter the "big world" in which
your convenience in choices must mesh with that of others (or
even yourself), it quickly takes on an effort of late binding
exceeding that of early.

Now lexical analysis relies heavily on recursion, of breaking an
expression down in sub-expressions and further down until
arriving at a terminal point, nominally an element instance.
Backus invented a language, Fortran, on an operating system,
IBSYS, neither with any form of "automatic" storage allocation
on which recursion relies.

Nevertheless LEX, a textual representation of BNF, a graphical
(or visual) representation of syntax structure, rules. It rules
even when its translated by the same language it's defining: C
in LEX. You might ask yourself why?

So if you go to Tunes or Maude, they do focus on language as
a solution. I frankly look at SL/I as a convenience as it means
I don't have to invent something elsewhere. But SL/I, Maude,
or the languages of Tunes do nothing to solve the "backlog"
problem, which lies outside their boxes.

In short it is not the programming language that causes the
problem. It is the specification language(s), the analysis
language(s), the design language(s) and the testing
language(s). It is their creation, maintenance, and
synchronization, all the other languages which add on to the
deficiencies of the programming language. No single
language, not even SL/I, can do it unassisted.

That includes the Developer's Assistant(DA). Without the
integrated Data Repository/Directory (DR/D) the DA's unique
existence as an interpreter/compiler alone would not solve
the backlog problem. Without a source only as well as a
single source library (DR/D) and automatic software source
maintenance allowing unlimited homonyms and synonyms the
process could not solve the backlog problem.

Thus we have no magic in SL/I. We have a better language in
terms of functions, features, and data types than anyone else.
Our difference lies in only needing one language for
specification and not needing others for analysis, design,
construction, and testing. Our box includes the entire
software development process, all five stages, and not just
one.

Hope to see you Saturday.

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

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
"postmaster@scoug.com".

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

Return to [ 16 | April | 2007 ]

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.