SCOUG-Programming Mailing List Archives

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

Date:	Sun, 17 Apr 2005 19:31:14 PDT7
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Progress--Step 3

Content Type: text/plain

Hi there Lynn,

Lynn H. Maxson wrote:
>
>> "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.

Lynn, where is the free copy you mentioned? All the forlorn non-PL/I
programmers out there want to know.

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

I know it generates C. So what? A PL/I compiler can be written in C.
A PL/I compiler can even be written in GWBASIC.

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

Hmm. Yes, you are allocating the storage. But you receive a pointer.
If I simply DCL a value or a record, I don't receive a pointer -- the
language hides that from me.

I still see absolutely no reason why LEX and YACC couldn't be used. In
the "old days" we called it "bootstrapping" from one machine type to
another, or from one language to another.

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

You can do this is C. I see no reason you can't use LEX and YACC.

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

Even the microprocessors have inefficiencies, but they can still do
anything you ask (albeit with wasted cycles on occasion). LEX and YACC
might not generate the exact code which a topnotch Assembler programmer
might write, but I don't see any functionality they can't handle.

Your AREA example mentions offset pointer values which rule out the use
of LEX and YACC. I don't see a problem. The AREA algorithm is
currently expressed in PL/I semantics, but I see no reason it can't be
implemented in craven C.

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

Okay. Okay. Okay. Thanks for the answer! :-)))

> In the PSIG we have sought a means of doing comparative
> linguistics across a spectrum of programming languages.

Now this intrigues me very much, since I've been working (quite slowly)
on this very project for many years.

Why not document the work?

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

On the "human intelligence" tangent, my own research has shown that the
brain (whether human, subhuman, or even worse the political party which
you don't belong to) is simply a pattern recognition machine. Each
brain has its own memories ("knowledge"). Each unique set of inputs
("ooh, tiger approaching") fires a bunch of neurons which look for
recognitions. The results are quickly returned ("hold up copy of
Patriot Act and wave briskly, that will stop him") causing a response.
Sometimes the pattern recognition has pleasant results, and sometimes
not.

My research goes further: The reason that "artificial intelligence"
doesn't match "human intelligence" is because the pattern recognizers
aren't robust enough (yet), the knowledge base isn't complete enough
(yet), and most importantly these artificial intelligence robots are
mass produced which means they all respond in the exact same way. There
are no genius or idiot robots among the group. There are no artists vs.
scientists, thieves vs. policemen, vegetarians vs. drunkards. If humans
were all like-minded, for example if we all subscribed to the same
political fervor of the current moment, we wouldn't be any more
intelligent than these robots.

(Lurkers: Do I sound like Lynn yet?)

So now we have Skye's Complete Intelligence Model which encompasses both
human and artificial intelligence.

Lynn has quite accurately summarized a dilemma: The intelligence is
placed into the program before the program is allowed to become "alive",
whereas a living brain becomes "alive" and then adds to its
intelligence.

But wait. Programs may be table-driven. They may be "state machines".
They may have modifiable code (Rexx has INTERPRET). They may have
escape points where other as-yet-unknown code may be executed. So
intelligence gathering does not stop with the click on "start".

> We will never write anything in any programming language
> which is not rule-based. True intelligence is not rule-based.

Edison pegged the perspiration at 99% and that's all rule-based. He
pegged the inspiration at 1%. I dare to say that all inspiration is
still the result of pattern recognition. The light bulb came to
fruition through the association of glowing hot metal and the need for
light. The motion picture camera came to fruition through the
association of flip card images and celluloid (1863) film.

So I disagree.

Or did you mean hardware? Neurons, axons, dendrites, synapses, they
certainly all follow specific rules exactly. Intelligence, as we
declare it, requires them all. So how can it not be rule-based?

So again I disagree. More to the point, LEX and YACC are available
right now (just as neurons are) and it would be very nice to start
defining a PL/I model using them.

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

Somebody once said that the design of a bumblebee means it cannot fly.
Someone else, the head of the U.S. Patent Office at the time, said
everything that needed to be invented had already been invented. Keep
_that_ firmly in mind.

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

Fine with me. Let's develop the LEX and YACC in parallel that will
generate a PL/I compiler capable of handling your PL/I statements.

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

May I guess? The purpose of the syntax difference is to make it easier
on the parser.

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

Comparative linguistics is an excellent pursuit for PSIG. We need
documentation of the accomplishments.

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

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

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