SCOUG-Programming Mailing List Archives

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

Date:	Thu, 18 Jan 2007 08:05:34 -0800
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: January Programming SIG meeting

Content Type: text/plain

Nathan,

We appear to have a failure in communication here. While still
"loosely" associated with the PMMail project Walter Metcalf
removed me as team leader, expressing his concern at the
slow rate of progress in getting a release out the door. At
the time last summer I had proposed October 15th as such a
date. Now some months later under new leadership the effort
now focuses on getting a beta release out. I have no qualms
about that effort or the quality of the people most actively
engaged in it.

Setting that project aside executed under the auspices of
VOICE, the SCOUG Programming SIG has an entirely different
one relating ultimately to the claims I made in the Wapricity
Proposal at Warpstock 98 in Chicago relative to a tool, the
Developer's Assistant, and a fourth-generation, universal
specification/programming language, SL/I.

Now the Developer's Assistant offers both interpreter and
compile modes. Interpreter to increase programmer
productivity and compile to increase production throughput
(productivity). As both have the same stages of syntax and
semantic analysis and differ only in their proof theory (code
generation), it seemed logical to have a "default" mode of
interpretive to maximise programmer productivity during
development and maintainence and an optional compile mode
once either considered as ready for production.

Now the Developer's Assistant rests upon the use of a Data
Repository/Directory (DR/D) in which we store only source
statements (references) and data elements (referents). All
larger collections of source statements (control structures,
sub-routines, procedures, etc.) and data elements (
homogeneous (arrays), heterogeneous (structures) and list
aggregates) exist only as named lists.

While data elements have manually assigned names, source
statements normally do not. Every source statement then has
a software-assigned, content-based, unique name. This
means that this system recognizes the fact of "reusable"
source statements which must exist for larger assemblies.

Now this unique name consists of a "proper name" whether
assigned manually or by software appended with an "index".
This allows essentially unlimited numbers (well over 2 billion
each) of synonyms (different names, same referent) and
homonyms (same name, different referents) for each "proper"
name.

This basically means that no file retrievals occur. This
eliminates all file-based editors. At the very least this
common "menu" items of File, Open, New, Save, Save As, and
Close no longer apply. It also means the use of only a single
library, consisting of all source including that of the
Developer's Assistant and the SL/I language. Thus the SL/I
language is a "universal" specification language capable of
specifying itself. Along with self-defining it is also
self-extensible.

This interpretive approach using the DR/D assumes only
involving the use of source on input. That means that
designations of the different "compiled" forms of .exe, .dll,
,sys and the rest do not exist, only their source. As all
aggregates exist as named lists then no "copy" or "include"
statements exist as these involve files. Only the name
associated with the "copy" or "include" is used. The
appearance of each name will cause the DR/D to retrieve and
expand the named list into its source form.

Now the "proof theory" of the Developer's Assistant includes
the two-stage proof engine of logic programming, the
completion proof and the exhaustive true/false proof. The
completion proof includes as its final process the code
generation, either interpretive or compiled.

Instead of using clausal logic as is done in SQL, Prolog, and
most logic programming languages the Developer's Assistant
uses predicate logic. That means the developer need only
specify the range of values for each element variable, leaving
it up to the exhaustive true/false proof engine to enumerate
all the possible values for the test data sets.

Now I've gone through all this to illustrate why an editor,
even one as likable as Visual Slickedit, comes up short of the
needs of the Developer's Assistant, the current project of the
SCOUG Programming SIG.

We start with an editor. We add syntax analysis. We carry it
one step further in that we expand each "copy" and "include"
statement recursively until we have included all the source.
That means the colorization occurs for all "extensions" now
defined in macros within the "include" files as well as the
basic definitions on which they rely. That doesn't occur in
Visual Slickedit.

At this point we begin the transition from whatever source
language used for the editor to providing a syntax analysis of
SL/I. The same occurs when we go on to semantic analysis.
Then at proof theory we switch from third generation code
generation to the completness proof in which the software
organizes the source segments in optimal logical order prior to
code generation. Thus if logic changes affect the organization
of the source, requiring its reorganization, this becomes the
responisibility of the software and not the programmer to
perform.

Somewhere parallel to this we have to begin to construct the
DR/D, incorporating it within the logic of the tool. Fortunately
its definition exists in terms of relational tables.

Now we have at least two other competitive approaches, one
more academic (www.tunes.org) and the other more
commercial (www.eclipse.org). We will over time compare
our approach to these.

I hope this clears things up with respect to our Programming
SIG project.

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

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 [ 18 | January | 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.