SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Mon, 18 Apr 2005 00:52:50 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: Stirring the Pot - data type defaults and declarations

Content Type: text/plain

I get great joy from reading material in this forum that I didn't
write. It's nice to know that it hasn't gone immediately into
the bit bucket.

I seem to have not communicated properly on the grunt,
non-grunt aspect of open source. In open source it is not
shifting work to the compiler writer to ease the task of the
application writer. A compiler is an application as well. In
open source you are not one or the other, but both.

That's the point. You may prefer one over the other, but you
must be capable of both. Otherwise you denied yourself one
aspect of open source, the ability to customize or adapt
source to your needs. You cannot depend on someone else
doing something that meets your needs...unless you are willing
to wait around until that occurs. That leaves you dependent,
something from which open source offers freedom.

Now I don't know how many balls, different aspects of things,
subjects, we can reasonably handle here in this media. I
would guess that we could track upwards of three or four.

We differ slightly in our view of a programming universe. It
makes a difference, if you view it as a set of disconnected,
independent pieces or as a mixed set of disconnected and
connected pieces: as a system of sub-systems. In an
application system divided amongs frequency-based pieces
(on-demand, hourly, daily, weekly, monthly, quarterly,
semi-annually, annually, bi-annually, etc.) you have a
common set of "named" data items. These represent
"persistent" data. This data has certain attributes persistent
and consistent across all applications and application systems
which use them.

You do not have a choice of giving it one set of attributes
here and another elsewhere. You do not have a choice, at
least not an error free one, of doing a disconnect...even if you
use different names.

Therefore you need a means to keep track of using the same
name for different things (homonyms) and using different
names for the same thing (synnonyms). This is particularly
true when you use homonyms in a single program, when you
use the same name for different things. As much as you may
enjoy the ability to have a "name" assigned and reassigned
data attributes by the "compiler" or "interpreter", you have
"confused" its persistence within its piece and across its
pieces, its use instances. You can, in effect, confuse
persistence, indicate it where none exists or fail to indicate it
where it should exist.

Notice that this refers to the data "name" only. You do not
have the emphasis in application systems (and their
documentation) on "naming" conventions. The fact that most
(if not all) data dictionaries do not allow multiple definitions
of a single name acts to enforce this one name, one set of
data attributes.

There's a reason for this: to prevent an increase in software
maintenance cost. So understand in software and in fact in all
forms of documentation we have a reason to seek a 1:1
relationship with a name and its meaning: to lower the cost,
the time and effort, to effect change (maintain software).

So I react to using the same name (as a homonym) differently
in a program: to give the same name different meanings. You
shouldn't do it, but if you do it, then you should have a least
cost means of undoing it. I address that means, which
considers the adverse effects of homonyms and synonyms,
within my proposed data repository/directory. I keep track of
both and allow a "global" means of taking their N:1 (synonym)
and 1:N (homonym) to 1:1.

Note that here I seek only to avoid the "abuse" of names. If
you separate consideration of naming conventions, of one
name, one meaning, after you agree on the name you can get
to the issue of its meaning, its attributes.

Now the REXX people, the Python people, and the APL people
who favor dynamic data attributes of a name based on its last
use, i.e. context based attributes, have a proof of pudding
concept going for them. It works. At least in "that" program,
"that" piece, "that" code snippet.

So why should they do "unnecessary" work? Why should
they not leave it up to the compiler or interpreter writer?
That again suggests a separation, a division of labor, among
people. I repeat that this separation of application writing,
this dependence on at least two people resources, detracts
from a basic premise of open source. It makes it less open
individually.

This does not disallow or disavow the use of context-based
assignment of data attributes...as long as it does neither to
their explicit assignment...as long as the language supports
both. Somewhere between the "pure" dynamic assignment
and the "pure" explicit assignment lies the "pure" explicit
generic assignment.

The "explicit generic" assignment allows attributes such as
"string" or "numeric" declared for a variable. Note that in a
compiler output listing you have the option for every name of
an attribute and cross reference (use instances) listing. This
is true whether "implicit" (dynamic or context-based) or
explicit (detailed or generic). As a programmer you don't care
about the form. You only care that it works, that it produces
the results that you want.

As long as it does that you have no concerns about its data
attributes. You want it to be logically correct, to produce the
correct results. However, when you go to take it out of
development or maintenance to place it into production, you
do (or should) have a concern for performance. When it
comes to performance you want the "explicit" data attributes
that provide this.

Thus you want the means that regardless of where you start,
your means, you want the choice of what you end up with,
your ends. Again that says that your language needs to
support both your means and your ends.

Now we haven't addressed the issue of data conversion of
mixed expressions, principally between string (bit and
character) and arithmetic and between arithmetic (fixed and
floating point, binary and decimal, signed and unsigned).
These complicate the use of dynamic or context-based
assignment of data attributes as you may not want an "end"
result (dynamic assignment) based on the intermediate results
(means) of an evaluation.

At some later point as we go more into detail we will provide
examples of mixed data expressions where we want to
actually control the data attributes of the result: we want an
explicit generic or detailed attribute set. Regardless we want
the language to support all possibilities.

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

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 | April | 2005 ]

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.