SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Wed, 22 Jan 2003 07:39:53 PST8
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: Shall we begin?

Content Type: text/plain

Sheridan writes:
"...I really like the idea of encapsulating code and its
explanatory text in one document then having a tool that
distills the code out to create a runable program.

Kindly provide us with a snipet of the .html that you envision."

I hate to blindside anyone. I could furnish and will within our
expose of HPCalc literate programming examples using
embedded html code. I will do so to give anyone experiential
evidence that you don't want to do it this way.

You see you shouldn't have to distill code from associated
text in an html document. That's the hard and most
expensive way. Greg touched upon this in his presentation
when he mentioned accessing code through a database
instead of a file manager.

If for the moment you accept that the smallest unit of
information for source code is the program statement and that
for source text is the sentence, then you should also accept
that these smallest units of information (UIs) are also the
smallest reusable units. As such each should be named and
stored separately.

It should come as no surprise to anyone that the html codes
themselves are source text subject to the same reuse rules as
any other, specifically that each html code has a name. With
the exception of data declarations in which the name is
embedded within the declaration and thus "content"
determined, the software can automatically assign names to
all other source types, code and text, on the basis of
"context" naming. A context name, for example, by
agreement could be the first 16 bytes of the source text
(proper name) appended with an index value to allow for
synonyms to create a "compound, unique name". If the actual
source text is less than 16 bytes, then you simply pad it on
the right with blanks. Thus you have a proper name
appended with an index value that results in a unique name
that serves as a primary key in a table with a relational
database.

Every source statement (code) or sentence (text) then has a
unique, context-based name that the software instead of the
user can automatically generate, store, maintain, and retrieve
from the database. To create ordered assemblies of each or
both intermixed you need only to give the assembly a name
and associate it with an ordered list of source names.

Now you don't actually have to name the assemblies as the
software can do it in the same context-based manner as it did
for the source statements and sentences. Now oddly enough
this granularity of reuse and naming convention places the
responsibility for reuse of statements, sentences, and
assemblies entirely within the purview of the software. The
software will guarantee that no more than one copy of the
source statement, sentence, or assembly exists in the
database regardless of its number of uses: only the name is
replicated in each use instance.

That means if you want only source code, then your
assemblies only include the names of source statements and
other assemblies. The same situation applies if you only want
source text. The same situation applies if you want some
mixture of both, i.e. literate programming. As each html code
is source text sentence, then the same situation applies an
html version of a literate programming document.

The beauty is that the documents function only at output
results and never as source. Thus you never have to maintain
them per se. If you make a change directly to them, the
software will automatically reflect those changes in the
database to statements, sentences, or assemblies, in effect
creating new versions (proper name plus index) of each.

Thus versioning becomes a builtin function applicable to any
named source or assembly, i.e. unrestricted. It's entirely a
software function, occurring automatically as part of the
editing process. This makes existing versioning systems like
CVS pale in comparison.

Now why do this? If you make a change to source code, it
may cause a need to change the source text associated with
the code. You need then to reflect the changes in both in
whatever assemblies in which their names appear. In effect
creating new versions of affected assemblies.

You have the choice, again through the software, to reflect
the changes completely (and automatically) or selectively.
Selectively allows you to determine on a per instance basis
whether or not the change should occur. For example, you
may make a code change to an assembly, essentially changing
its logic. You may do so in order to have a logical choice in
processing.

Now you have two versions of an assembly. You will want
each to have different associated source text to support
literate programming usage. However, the new version may
apply only to a subset of existing uses. You can ask (query)
the software to give you a list of its uses (where-used).
Then selectively by examination decide on which use
instances to change (new versions) and which to leave alone.

A side effect of all this is the elimination of embedded "copy"
and "include" statements in source code. Effectively you
need only the name of the highest level assembly selected
under the menu option of "data" (instead of file) and
sub-menu option of "open". This brings in the entire source,
which means it's all viewable as an integrate whole within the
editor.

This is a rather long answer to a short question. I include it in
part to illustrate that which is accomplished with ease using a
database manager that now is quite complicated and
expensive using a file manager. So Greg remains correct
about the advantages of using a database instead of a file
system. He may not have thought it as far out as this, but he,
you, and others will eventually get there.

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

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