SCOUG-Programming Mailing List Archives

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

Date:	Thu, 10 Feb 2005 14:43:04 PST8
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Open Source Object Rexx

Content Type: text/plain

Lynn H. Maxson wrote:
>
> I'm not asleep at the wheel.

Yawn.

> . . . when I made the Warpicity
> proposal in 1998. I knew, for example, that PL/I was the only
> programming language that supported all the data types
> found in the problem set. I knew that APL2 was the only
> programming language that supported all the operations of
> the problem set. The only missing piece, in terms of "native"
> data aggregates was the list aggregate. I knew that LISP
> supported all possible operations on lists.

So we need:

-- 1. The data types of PL/I.
-- 2. The operations of APL2.
-- 3. The list operations of LISP.

This is an excellent start, although I remember SNOBOL but have never
used LISP. I assume they're similar.

*However*, operations on data types require unique code. I still don't
understand why we can't have a template for creating new data type
operations, similar to how a PL/I routine takes a look at the Data
Control Block to find out what type of data is being supplied and then
makes appropriate calls as necessary to convert the data to a type which
can be handled (for example, convert string to numeric).

And I see no need to have unique symbols to designate certain
operations. The APL operations are a great shorthand for
mathematicians, but why can't the operations be defined as function
calls and the APL symbols then mapped to these calls, and often-used
mappings then put into a declaration in the program?

For example, in PL/I the operation symbol mapping could be something
like

PGM3 procedure options (main) operationsymbols (APLset);

where APLset is a library of symbol mappings to operators.

That takes care of the operations. Now we need to define new data
types. How about something like

dcl EarlyYear RomanNumeral;
dcl ExactFrac Fractional;

where RomanNumeral and Fractional are unknown native types but are
available from an external library? (RomanNumeral in this case is a
character string. Fractional in this case is two binary numbers, one
for the numerator and one for the denominator.)

Default size overrides can be made available, i.e.

dcl EarlyYear char(20) RomanNumeral;
dcl ExactFrac binary(31) Fractional;

> That took care of the completeness of the language relative
> to data and operators.

I don't think so. No RomanNumeral, no Fractional. No permutations and
combinations.

> All you ever do is write and re-write specifications in one
> language with the software doing the rest, automatically
> reflecting whatever direction you take.

I'm trying to get you to come up with some implementation
"specifications", Lynn. Without any specifications all we have is your
future vision ("science fiction") without any means to get there ("no
rocket ships"). Do my examples above come anywhere near what you
envision?

- Peter

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

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.