SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Sat, 1 Jan 2005 03:13:16 PST8
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Oh Yeah? (was: Programming in the new year)

Content Type: text/plain

Lynn H. Maxson wrote:
>
> We need to realize the "language" part of a programming
> language, what it allows and what it does not. . . .
> For example, neither COBOL nor C support bit strings, . . .
> . . . over on SourceForge they have a
> project to have a PL/I pre-processor to a proposed C 4.0
> language compiler. I have my doubts because no version of C
> comes anywhere near the native data types of PL/I: no bit
> strings, no non-null terminated character strings of length
> greater than one and no variable precision real and integer,
> binary and decimal arithmetic, no variable precision fixed and
> floating point, decimal and binary values.
> This means that C and its current derivatives can only
> natively express a subset of that possible in PL/I.

Hi Lynn, it's me, Peter, the guy who *loves* to argue with
you and raise your blood pressure.

Given that we both agree PL/I is a wonderful language, let
me address your tunnel vision. (Lurkers: I use the phrase
"tunnel vision" to see if I can set Lynn off.)

PL/I uses subroutine calls to handle many of its native
processing capabilities. This was intended; a Data Control
Block (DCB) is passed to a subroutine, the subroutine
analyzes the DCB to determine the exact type/format of the
parameter(s), and acts accordingly. (Granted I'm referring
to the old PL/I F compiler here.)

If I want a BIT type in PL/I, the compiler handles it
automatically. If I want a BIT type in some other languages,
I have to do any required conversions manually. This is not
a language restriction, it is merely a housekeeping function
which is present in some languages and not present in others.

An example in pseudo-language:

Declare SkyeBit BIT(20);
SkyeBit = "01010101010101010101";
Print (SkyeBit);
Print ( NumericValue( SkyeBit ) );

-versus-

Declare SkyeBit CHAR(20);
SkyeBit = "01010101010101010101";
Print (SkyeBit);
Print ( NumericValue( Char2Int( SkyeBit ) ) );

In the first example the language automatically takes care
of the conversion required to print the numeric value. In
the second example the conversion is explicitly called by
the programmer.

I know, I know, your first counter argument is "But Peter!
The BIT(20) uses only two bytes and a nibble whereas the
CHAR(20) uses twenty bytes!" And I shall counter by
changing my calls, refuting your argument:

Declare SkyeBit CHAR(3);
SkyeBit = Bit2Char( "01010101010101010101" );
etc.

May I be so bold as to summarize your viewpoint? You want
a language which can learn new data types, both their
declarations and their operations, so that the programmer
need not explicitly make the conversion subroutine calls.

Yet there is a danger here and you need to address it.
Without the explicit conversions, code more quickly becomes
unreadable. This is why some coders use a short identifying
string at the beginning of variable names so they can keep
track of their data "types", to wit:

bSkyeBin DCL BINARY(16);
btSkyeBit DCL BIT(16);
iSkyeInt DCL INTEGER(16);
fltSkyeFloat DCL FLOAT(63);
eSkyeExp DCL EXPONENTIAL(31,127);
ptrSkyePointer DCL POINTER;
jSkyeDate DCL JULIAN;
and on and on

An excellent study piece is available by moving away from
"numeric" types of data to something a little more free-form,
such as HTML which most of us are familiar with. HTML and
other "word presentation" data strings do not depend on
numeric operators yet still require many different operations.

Let's define a new data type in a pseudo-language:

htmlSkyeWords DCL HTML(*);

We now have a hardware memory string of ASCII characters of
indeterminate length. Logically, we have a value consisting
of text strings of two different types (readable and tags)
interspersed with each other.

We need operators for this new HTML data type. Suppose I
want to add a CSV file as a table to the end of my HTML.
Then I might code:

htmlSkyeWords = htmlSkyeWords + CSV2HTML( ReadFileCSV(File.csv) );

*You*, on the other hand, seem to want the language to allow:

htmlSkyeWords = htmlSkyeWords + File( File.csv );

I grant you that the second form is more succinct. It is
also more prone to error; for example, the language might
under some conditions try to convert htmlSkyeWords to CSV
rather than convert File.csv to HTML. When the conversion
is explicit there isn't any ambiguity.

I often have a need for numeric operators that deconstruct
values into prime number sets, and I also work with
combinations and permutations. No native hardware that I'm
aware of does these things; they must be done in software.
Lynn, the language which you seek can support your unique
requirements, my unique requirements and hopefully everyone
else's too -- but basing the development of such a language
on whether or not a BIT string of length 20 uses 20 bits or
20 bytes (i.e. what native data types are supported with
keywords) seems short-sighted to me.
_____

> I would hope in this second pass where we will concentrate
> on the learning and teaching of a programming language that
> we will also emphasize the relationship between the real
> world problem set and our programming world solution set. I
> like APL because it allows more "operators" in the problem
> set and PL/I because it supports more of the problem set data
> types.

May I suggest that creating a compendium cross-reference of
every keyword from every language might be the most worthwhile
activity? Not only would such a document become a treasured
reference, it might adequately define the language which you
seek.

Such a document would be extensible, could be open source,
and would *not* restrict our thinking to existing language
operators and structures. Why can't a language allow any of
DO, FOR, LOOP, REPEAT, WHILE and UNTIL? Why shouldn't a
language allow INTEGER values of unlimited size (as Rexx
does)? A compendium cross-reference can address this.

I await your blood-pressurized response.

Your pal,

- Pete

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

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 [ 01 | January | 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.