SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Sun, 10 Aug 2003 21:57:29 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

"I've used enough BOM systems to think there's gotta be a
better way...like plain-text files! (programmable parametric
BOMs, you might say) It's pretty typical to have 20 variations
of a part on one drawing, but the clumsy database requires 20
separate nearly identical BOMs with nothing to indicate their
similarity. As programmers we already have plain-text source
code with a well-defined syntax, so it shouldn't be that
hard to write a simplified parser to create BOMs and Where
Used lists. I haven't felt the need yet, but it might be
worthwhile for something huge like a Linux kernel."

Tom,

You have to ask yourself why manufacturing adopted the
database over the file system (your text files) which
previously existed. Pick your favorite database technology:
network, hierarchical, relational. Each of these have been
chosen over file systems.

Surely one of the reasons lies in the fact that source is not
replicated as it is in file systems. Not replicated means only
one source exists, one named source for each raw material,
one named source for each assembly. Every high level
assembly, the BOM, contains only the names of its
components: their logical presence. This means that
maintenance occurs only on a single source, not each
replication.

You bring up the matter of pattern recognition, in fact of
"near-pattern" recognition. In a database implementation
where an assembly is a structured list of names, the ability
exists to find patterns exact or fuzzy on the basis of content
(names only) or context (ordered list of names).

You need also to consider issues surrounding homonyms (same
name, different referents) and synonyms (different names,
same referent). In the case of homonyms you want to
associate a unique name to each instance. This means you
need something in addition the the name itself, e.g. an index
suffix. This index, maintained by the data
repository/directory, does not appear in the source, but only
in "internal" source references, e.g. list of names in an
assembly.

Your welcome to write software that extracts all the names
used. It takes a bit more effort to determine the homonyms
and the synonyms. It takes a bit more then to provide a
unique name for each homonym, substituting it for each of its
instances in the source. Then you can decide about which of
the set of synonym names gets to survive, which you can then
substitute each one of its use instances in the different files.
Then you can hammer home to some poor dumb idiot that
picks the same name as an existing one for something
different or a different name from an existing one for
something that is the same. You can keep on doing this from
time to time to keep them in sync.

Or you can drop a file system of multiple directories and
source files for a database system with only one directory and
zero source files. Instead every source statement exists as a
row in the "source table", given a content-based,
system-assigned unique name. Every source assembly, that
which corresponds to your source files, exists as named set of
rows representing a list of names. Again maintained entirely
by the software. Thus they are logically, not physically
stored in the database, the repository.

You can then write an SQL query to do a pattern search on
the stored source, either on the actual source or its name. If
you find that two or more are actually synonyms, you can
select one to be the remaining source with the names of the
others relegated to the "alias" table. Or if you want to
eliminate as many uses of synonyms as possible, you can have
all the others use instances in assemblies replaced and the
replaced source deleted.

Note what control this gives the enterprise over the use of
names and source written by the programmer. It becomes
fairly easy to, one, monitor all programmer activity, and, two,
to enforce enterprise naming rules. You can in effect maintain
all source and enforce all rules for all data within the
enterprise.

I'm not saying that you cannot do this with file systems. I'm
only noting that so-called "librarian" software which
maintains files systems doesn't do it. No one participating in
this list can afford the software for what it does do.

You are correct. For something like Linux or OS/2 you need
something to allow maintenance of source code and text for
all assemblies at all levels. When you also have your scope of
compilation equal to the scope defined by your input source,
up to and including all the source of an OS, you will find that
such is a single unique name in the data directory. That name
gives rise to all the other names necessary. So you end up
not using an "include" statement in source as all source is
included by name. Therefore all source is "included" source.

Patterns occur on either content alone or context, which is
the content along with its structure. The degree of pattern
matching depends on overlap, in whole or in part, in either
content or context. When you either find or define a pattern
you will find its replication in all use instances more akin to a
database than a file system. File systems don't come with an
SQL.

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

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