SCOUG-Programming Mailing List Archives

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

Date:	Sat, 1 Jan 2005 11:40:54 PST8
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: A bit too much to byte

Content Type: text/plain

Lynn H. Maxson wrote:
>
> Peter,
>
> I inadvertently deleted your message

It's that subliminal drifting of the finger over to the "delete" key
whenever my name appears on an email.

> at least one programming language, namely PL/I, has
> a 1:1 mapping of problem to solution set data types.

Your problem set is smaller than mine. I could make immediate use of
a PRIMEARRAY data type and an HTMLSTRING data type.

> I don't really care whether you have an actual bit string
> ('01010101010101010101'b) or character string
> ('010101010101001010101'). I do care if the problem set
> has it in bit format when I need to define a data structure.

Assuming your data structure elements are byte aligned (i.e. bit strings
are padded so following elements are byte aligned), what's wrong with
CHAR plus an extraction function such as BITSUBSTR() plus whatever other
bit functions you may need?

> I do care if I can perform logical operations in a "if" statement and
> I cannot perform it in an expression in an assignment statement.

What is wrong with EQUAL(A,B)? Let's set tfResult to TRUE or FALSE:

if A = B then tfResult = TRUE;
versus
tfResult = A = B;
versus
tfResult = EQUAL(A,B);

I *can* perform logical operations in an assignment statement.

> make the effort to allow to achieve a more
> perfect match without compromise between
> the problem set and the solution set.

Lynn, I do highly respect your opinion, but it seems to me that you're
simply trying to minimize keystrokes. A data type can be coded "up
front" in the variable declaration and the type then inferred by the
compiler whenever the variable is used, *or* the data type can be
expressed by a function call written by the programmer (as in my
"EQUAL(A,B)" example above).

> With the exception of C with its "weak" typing all other
> programming languages invoke "strong" typing. Again with
> the exception of PL/I they invoke it strictly. They do not
> provide for a default conversion nor allow a "direct"
> conversion between data types, e.g. between bit and
> character strings or bit strings and arithmetic variables.
> Thus they do not allow "mixed" expressions without the
> programmer invoking explicit conversion routines as part
> of the expression.

I disagree with your value judgement that "the programmer invoking
explicit conversion routines as part of the expression" is bad. It is
not bad. Many would argue, instead, that this is good programming
practice and creates more "readable" code.

You are correct that, given F as float and I,J as fixed,

J = F + I;

is quicker to code than

J = FIXED( F + FLOAT(I) );

but the executed instructions are the same.

If you are seeking "condensed source code" ("J = F + I") versus "verbose
source code" then may I suggest a simple compiler option to reformat the
expressions as either condensed or verbose. Certainly the compiler is
aware of how it has parsed an expression and can display the expression
in either format.

> C makes a distinction between a single character string stored
> without a null terminator and a variable length string with a
> null terminator. It's not rocket science to see how this logic
> collapses when it comes to bit strings and why C doesn't
> support them: the null terminator.

PL/I and some other languages use a "count" field to ascertain the
length of a character string. The count field is inferred in the
declaration. C doesn't infer a count field but it can certainly call
any function you care to write which utilizes an expressly-declared
count field.

So again, you appear to be seeking "condensed source code" in your
language. That's fine with me, although verbose source code has a value
too -- such as during peer review or debugging.

> PL/I does not have a "native" list aggregate.

What is a list aggregate?

> PL/I does not "natively" support all the APL operators. It
> must in order to provide a closer match between the problem
> and solution set symbolic descriptions as well as the
> succinctness of an APL expression.

Aha! You seek "the succinctness of an APL expression"! You seek
"condensed code"!

Begone with your lengthy arguments. Map your example-filled problem set
to the following succinct, condensed problem set: "I seek succinct,
condensed source code". Then I can add "I seek lengthy, verbose source
code" as an alternative and the compiler can display either one by
examining the parsed expressions.

> How you think efficiently in APL differs significantly
> from how in C or PL/I or COBOL or REXX or Python.

I'm not buying this statement one bit. (Bit-challenged C programmers:
Substitute the phrase "I'm not byting on this one".) I think in terms
of systems and algorithms when I solve problems. And if I need to
consider the hardware, then I think in machine language, after which I
map the capabilities of the chosen compiler language to the machine
language I have in mind.

> we need to focus on these "native" views [of multiple
> programming languages] to give us a better understanding
> of the languages, their differences, and what to use when.

Excellent. In my prior message I suggested documenting all these
languages "under one roof", i.e. in a master language compendium. This
compendium, for example, under the XOR operator might have the following
entry for the C language: "Declare each bit string as a null terminated
character string and use the XOR(,) function to create a result."
_____

Lynn, I'm now aware of two of your design considerations. One is
language structure (exemplified by our thread some time ago on
BEGIN..END blocks) and the other is your desire for succinct source code
(including a wide range of native data types so the programmer does not
have to declare a data type as a structure of pieces).

What other considerations do you have?

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