SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Thu, 10 Feb 2005 21:57:26 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

Peter,

Which part of a specification language do you not
understand? You specify with a specification language.
That's all you do. That's all you need to do. It you want a
data type for roman numerals, then you specify it, the rules
governing it and the operations upon it as well as its
interaction, if any, in mixed expressions. They are all
specifiable. Whether a number is rational, irrational,
transcendental, or integer it belongs to the "real number" set.
Thus if your language allows you to express any real number,
all other member sets (rational, irrational, etc.) are
expressible as are all operations on real numbers and their
interaction in non-arithmetic, e.g. logical and string,
expressions.

Fortunately the APL operators include one which allows
translating from one number base to another. Thus no
restrictions for just binary or decimal exist. Another
restriction that does not exist is limiting numeric operations to
binary integer or float.

Fuzzy logic involves the addition of "maybe" to "true" and
"false" values. It is thus three-valued instead of two-valued
logic. If it makes sense to specify it as a separate data type,
then do so. It's specifiable.

You have a bit of a problem with exponentiation as a data
type as it is an operator applied against a real number.

If you cannot map down to the bit level for any data type,
then you cannot use it in software or hardware. So you do
have high-level and higher-level (hierarchical) constructs,
just as you have elements and their aggregates. It's a logical
system based entirely on logic, fuzzy or otherwise, which in
turn is based on two-valued (bit) switches...even fuzzy logic
implemented in software.

dcl bucket fuzzy (1); /* valid values are '1'f, '0'f, or '?'f */

There I've done it.

SNOBOL deals with string or text processing. It uses lists in
support of maintaining strings, combining them, deleting from
them, or inserting into them. LISP is more general purpose.

First off, you need to define which PL/I you have in mind. The
"old" PL/I used "dope vectors" to do the type of interpretive
runtime execution you mention. However, that period last
only a few years. Now that's all resolved at compile time to
allow faster execution. However, either mode is specifiable.
If you prefer one to the other, then restrict the specifications
you use to that choice.

You have this thing about APL operators. I really don't
understand what objection you can have to writing
expressions in a specification language as you would in a
descriptive language. If you want to say "add" instead of "+",
then go ahead. Select those specifications that support this.

Get it through you mind that you have the source, the
specifications, for every implementation. It's open source.
You can customize it to suit. Just write the specifications. I'm
not trying to restrict you in any manner. In fact I'm proposing
to the total elimination of all restrictions that others might try
to impose but that you want to do differently.

If you want to define addition, subtraction, division,
multiplication, exponentiation on roman numerals, be my
guest. I'm providing the means for you to do so.

If you want a purely fractional real number, you can declare it
in PL/I today as a fixed point decimal whose width and
precision are the same, e.g. dcl fanny fixed dec (7,7). If you
prefer, you can say "dcl fanny fixed bin (7,7)". Try that with
your Python. You can define it as octal, as hexadecimal, as
any number base you care to choose.

Having a numerator over a denominator implies division even
in a fraction. You could, however, say "dcl fanny fixed dec
(7,7) init(2/3);" which should give you .6666667.

Oddly enough permutation and combination are operators.
Even in APL. In mathematics. You could define them in the
initialization of a arithmetic data variable, but not as a data
type.

All of PL/I is a proper subset of PL/E (or SL/I). You add the
APL operators over and above those already in PL/I. You add
the list aggregate. You have the assignment statement where
one and only one "true" result can occur and the assertion
where zero, one, or more "true" results can occur. The first
supports both element and non-list aggregate results. The
second has only list aggregate results.

I envision a single language, self-defining and self-extensible.
I envision specifying the language using that language as part
of its self-defining attribute. I envision a single tool written in
that language which process the source specifications written
in the same language. Thus the tool allows you to specify
changes to the language, changes to the tool, changes to
anything written in the language.

You can use the language to specify REXX, C, C++, Python,
Perl, or any programming language including itself. You can't
do that with any other language available today, not even
with LISP or Maude in spite of their meta-programming and
dynamic self-processing features.

I did it to eliminate the need to learn multiple languages. I did
it to eliminate incompatibilities of multiple languages. Most of
all I did it because it leads to a level of productivity that
increases the range of applications an individual can monitor
and control. I did it to bring down ever spiraling software
costs. I did it to allow changes to the solution set to occur in
sync with those of the problem set.

That's why I did it. In truth I haven't done it. I envision a
world in which open source not only dominates but effectively
eliminates closed or proprietary source.

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

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