SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Wed, 13 Apr 2005 08:39:15 PDT7
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: Progress--Step 3

Content Type: text/plain

Peter,

"Free? I bought PL/I Enterprise. That was *definitely* not
"free"! Where can you get the free copy?"

Why would you need a free copy if you already have a copy?
That's the point of my comment. You have PL/I. You don't
have to go anywhere else for anything. There's nothing extra
to buy. All you need is there. Rename a file. Sort. And on
and on and on.

"Why can't we just write the LEX & YACC for PL/I and have
an open source PL/I compiler?"

It's going to come a shock to you, but LEX & YACC have a C
result. Now if you had a PL/I version of LEX & YACC.... If you
don't understand the difference, then I suggest you read K&R's
"The C Programming Language" to see what they regarded as
unnecessary and left out. When you have a programming
language in which keywords, e.g. "int", are reserved words,
which PL/I does not, then you have a problem. And the list
goes on and on and on.

" But Lynn, based storage is ghost storage, shadow box
storage, glass matte storage. It isn't "allocated". It is instead
a way of interpreting previously allocated storage."

In fact you can allocate and free it as well as use it in
conjunction with the 'addr' builtin function as a "roaming"
means of redefining existing data storage. You can do this
because pointer (address) data in PL/I is a separate data type
unassociated with (or an attribute of) another data type as in
C. That creates another reason why LEX & YACC will not
work.

I didn't bother to cover the AREA data type, the ability to
allocate and free storage within it, to obtain an offset address
from the start of the AREA variable, to write and read AREA
variables to external storage (harddrives), and to in effect
allow virtual storage processing prior to availability in an
operating system. Again you have another something, an
offset pointer value and allocation within an AREA variable
that rules out LEX & YACC.

When you agree to LEX & YACC, you agree to the limits
thereof.

"Lynn, you sound like you are writing the SL/I book and
letting us see the first draft right here. Is this what you are
doing?"

No. No. No.

I made an assertion some time back that three existing
programming languages (LISP, APL, and PL/I) covered the
entire spectrum of all third generation programming
languages. Arguably you could include all fourth generation
languages as well.

In the PSIG we have sought a means of doing comparative
linguistics across a spectrum of programming languages. In my
three steps so far I've stepped outside of programming
languages to a characteristic of programs in general, of a
program space, its instruction and data sub-spaces, their
static and dynamic characteristics, and the binding times
associated with each.

In all this I have twice made the statement that binding time
of the program logic occurred at its writing, at edit time in
common parlance. All the possibilities of static and dynamic
storage of instructions and data are contained in that program
logic. That's why we can only talk of "artificial" and not
"true" intelligence in programs. To imply that one is simply an
alternate form of the other is wrong. One is pre-programmed
(artificial). The other (human intelligence) is not. It is
therefore impossible for the one (artificial) ever to replicate,
duplicate, or become the other (true).

We will never write anything in any programming language
which is not rule-based. True intelligence is not rule-based.
Thus the one cannot emulate the other except where they
overlap on rule-based logic. That means that true
intelligence, which incorporates non-rule base attributes,
includes rule-base as a proper subset, i.e. entirely.

That's a consequence of rule-based logic which includes all
software. If you have that firmly in mind, then you don't go
feeding money down the drain to academics claiming they can
achieve intelligence through software. That's one aspect.

The other is that rule-based logic has static and dynamic
requirements, those which are known ahead of time and those
which are not. You must have some means of designating as
well as designing them. I chose as that means their "space"
requirements and how we "effect" them. Therein lies the
importance of storage attributes of data types.

To counter your bias about "based" storage in step 4 I intend
to introduce list processing...in PL/I.

We have had two very excellent presentations by Greg Smith
and Sheridan George on PERL. PERL has two forms of a list
aggregate, one variable form and one constant form. Each
looks the same except for boundary notation: (....) variable
and [....] constant (if I have that right). Now I find the idea of
a list aggregate constant, in fact any aggregate constant, as a
conumdrum. It's the sort of restriction that Nicklas Wirth
introduced in PASCAL to prevent having programmers put out
their hands to get slap by a ruler: to prevent "no-no's".

In short I don't believe in a list constant or the need for it. If
you want something constant, you don't change it. So it
becomes a point of curiosity if in PERL any implementation
differences occur between a list variable and a list constant.

Before that point it pays to have some knowledge of list
processing. That in turn will add to our table of programming
language attributes for comparative linguistics.

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

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
"postmaster@scoug.com".

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

Return to [ 13 | April | 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.