SCOUG-Programming Mailing List Archives

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

Date:	Sun, 13 Feb 2005 07:33:47 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: Open Source Object Rexx

Content Type: text/plain

Greg,

I have no idea how or why you and Peter get on these merry
go rounds. Peter wants to express a value by specifying a
fraction with a numerator and denominator. You want to
express one that cannot be done in this manner. Both of you,
however, can express that value to whatever degree you
want with variable precision, fixed point, "base-N" arithmetic.

Currently PL/I implementations place an upper limit on the
precision. The PL/I language does not. PL/E (SL/I) does not.
C (and its post-1970 derivatives) with 'int' alone or qualified
with 'short' and 'long' allow the implementation to determine
precision and not the programmer. For whatever upper limit a
current PL/I implementation has the programmer has complete
control everywhere within that limit. In PL/E his control is
without bounds.

However, 'without bounds' works until you have to do an
actual calculation. You cannot store in memory an unbounded
value. You cannot have a field of infinite length. At some
point you have to say, "This far and no further." You should
have a programming language that allows you to specify that
as exactly as you want with full implementation support.

Variable precision, fixed point arithmetic does exactly that. It
has none of the limitations of fixed precision, binary integers
(int) or fixed precision, floating point reals (float). We can
agree that in terms of performance, i.e. machine cycles, fixed
outperforms variable precision. If the issue lies in allowing a
more exacting, user desired precision, fixed cannot hold a
candle to variable.

After this point you seem to have totally ignored the fact that
all programming languages are specification languages. Not
all programming and thus specification languages are
self-defining and due to this also self-extensible. If they are
not, you require at least a second language to define or
extend them. If you look at LEX and YACC or go to the
introductory sections of an IBM language reference manual,
you will set those "secondary" languages expressing their
syntactical rules. All I've done is bring those rules within the
language so that you don't need a separate language nor a
separate section.

That in turn allows allows a tool which processes the
language process changes to that language which in turn may
change it in how the tool processes the next time. If the tool
is written in the language and if its specifications change due
to changes in the language, then you have a single process
for reflecting a common change in both.

No external library exists not written in a programming
language and thus a specification language. External libraries
only exist due to language implementations limits, i.e. they are
not "known" to the implementation. Thus the implementation
cannot process them in the same manner as those which are
"known" to it, e.g. the built-in functions of PL/I.

Of course, that's less true if the implementation can input
them as source. Of course, if it can, then it has no need to
store them "outside", i.e. "external", to its source library. It
can merge that source within its own source.

Now, however, we come upon something which I cannot
invent, something which is historical fact. External libraries
have had a number of drawbacks. One, for the most part
they are proprietary, allowing no access to source. Two, they
are hardware and software platform dependent. Three, they
are incompatible and conflict with other external libraries.
Four, you don't have the community pressure for "standard"
libraries, if the previous three were not true.

So if you have all these specifications (and you must
otherwise they wouldn't exist), why not have them in a single
source language? If they are in a single source language and
that source is available, you have no need for more than one
source library. Thus you have no need to synchronize change
across multiple "external" libraries or outside a single source
library boundaries.

Far from disallowing all of the specification development that
has occurred up to now with the "internal" infighting among
them I offer a means of including them all in a compatible
form from which the user can pick and choose at will. That
means no "external" library dies due to market forces
unrelated to their value.

In short, Greg, contrary to what has occurred to an extremely
large body of external libraries which now sit unused and
unusable as historical trash, I want to offer a means of their
resurrection and continued life, albeit in a different language.

I didn't make class libraries in the same language incompatible.
IBM, Microsoft, and others did that. I didn't propose a .NET to
ward off JAVA. I haven't proposed a system in which the
choice of one eliminates the choice of another. Instead I
selected a means in which the user, not the vendor or
supplier, makes the decision by picking and choosing.

You may not see the value of a "source only" system with a
single source library in a single source language. That means
you have a set of blinders on to what the historical effect the
alternatives have had.

Open source relies on the individual's means and ability to
customize or otherwise modify source. In terms of number
that ability declines as the number of different languages
increases and the number of different implementation versions
within the language. So why not reduce the number of
languages to one? Why not eliminate the dependence on
different implementations?

Far from tossing out everything written in different
specification, i.e. programming, languages, where trends and
vendor wars may render them dead, I want to offer them a
life that extends beyond trends and vendors. If I have a
trend, it's open source. Why would I not want to offer
something that presents the fewest barriers to potential
participants? Why should those participants be burdened by
implementation limits other than self-imposed? Why should
their limits be a burden on someone else?

Every programming language is a specification language. If
you have a "universal" specification language, what need do
you have for any other? You cannot argue ease of
expression if the "universal" specification language allows the
specification of that "ease".

That says if you have the source the "universal" specification
language can contain specifications for translating it. If you
don't have the source, if you have only executables, the
"universal" specification language can contain specifications
for translating it.

What's the problem?

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

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 [ 13 | February | 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.