Lisp and Periodic Table of HPCT

Bill Powers (970821.1335 MDT) --

I'd be curious about how you would program a control system in Lisp.

Send more your simplist program, forget about it, and in a couple of
months I'll write a Lisp version.

Bill Powers (970821.1335 MDT) --

According to my understanding of recursion, a control system is not a
recursive system; it does not call itself as a function, and it doesn't
have to maintain a stack of nested states.

I agree. You don't need to use recursion to program in Lisp, of course.
I can conceive of recursion in the reorganization system though,
since it applies the same solution to different levels of a structure,
first by building it, then by speeding up the rate of random signals
as unresolved error accumulates up the hierarchy. The image of uncontrolled
error, unopposed even at the highest level, reminds me of the stack overflow
that can occur with recursions whose base cases (exit conditions) are
incapable of being reached with the given function and parameters being
passed to it: the system uses up more and more resources until it is
just thrashing.

Bill Powers (970821.1335 MDT) --

Also, I wonder about the basic idea of a "read-eval-print loop" -- this isn't
the basic structure of any programs I write. It sounds more suited to an S-R
model than a control model. What's your opinion?

Broadly speaking, read-eval-print would apply more to what your
_compiler_ is doing to set up a parse tree, make macro substitutions,
and rewrite the program into the machine's native language. You don't
write a new read-eval-print loop when you write a Lisp program.

A function that's not part of a cycle of functions which feed their
results back into the cycle would seem pretty S-R to me, and read-
eval-print does not use what it returns in the next read.

Most general programming languages do a terrible job of naturally
representing compuations that accumulate over time. Scheme, a dialect
of Lisp, has some built-ins, like defining "continuations" as a type,
just like Lisp defines functions as a data type, which save the
state of computation of a function. Scheme is kind of the ultimate
functional language for people that hate defining data structures
that require redefining different parts of your program whenever
you make changes in the structure, besides having to keep checking
they're not "stepping on" some other part's use of the data structure
at runtime.

Bill Powers (970821.1335 MDT) --

I wonder whether all these different languages aren't just evidence of
people thinking at different hierarchical levels. Maybe each of them
emphasizes some particular aspect of perception and control that the
inventor was fascinated with, or especially good at.

One might even refer to this as the aspect they were "fixated on,"
to include the pathological spin. Gawd, everybody's fixations
suck except for mine.

Bill Powers (970821.1335 MDT) --

Maybe they would all fit together, somehow, into a hierarchy of computing
languages.

Of course, it's been done, but not in terms that are psychologically
relevant. The psychology of programming isn't something I've read much
about lately, but I remember a bunch of articles coming out in the eighties.

Bill Powers (970821.1335 MDT) --

Obviously the "non-procedural" languages are built out of procedures,
with the details being hidden from the main structure, but being necessary
anyhow. Would they operate at the principle level?

Prolog (PROgramming in LOGic) probably aims at principles (although the
recent discussion of the relationship level has me confused). In Prolog
there's a higher-order procedural level that you _do_ have to understand
when you're first learning it or you can get burned. It's the "inference
engine" which does an exhaustive, depth-first search through your list of
clauses to resolve/unify the runtime bindings. I'm not very good at the
goal-subgoal decomposition style of thinking behind Prolog.

Have you seen OPS5? It is very S-R in a way, but has some interesting
wrinkles. The procedural part is a match-select-act cycle, so it
presents itself as creating instantiations of all rules (including
multiples of the same rule, if there are multiple combinations of
binding the variables) that match the current state of working memory
(match), using a set of conflict-resolution criteria to narrow down
which of the many matching rule-instantiations will be chosen (select),
and then executing the actions of the chosen one (act). OPS5 _might_
be used favorably from a control view, though, because the acts
could be thought of as error signals outputting back to the system
itself. By the way, NASA has an almost-free language called CLIPS
that is pretty much based on OPS, plus some fancier objects. Anyway,
I like this kind of "declarative" programming language because I
like to think of solutions that are more "constraint-based" than
either procedural or theorem-proving.

Bill Powers (970821.1335 MDT) --

With respect to handling functions, C and Pascal make this pretty awkward;
the programmer has to know what's going on, and the declarations, especially
in C, get baroque. Maybe Lisp does all this in a more natural way.

Lisp rules the world of functions (again, Scheme, if you're a purist).

I have a feeling that anyone who was smart enough to go into this would
find that my few little levels running from relationships to principles are
just a sketch of the structure that is really there.

I believe that _you_ are smart enough. I've been wrestling with the
HPCT hierarchy ever since I first saw it. It usually does what I want it
to, but I find myself in an on-going quest to analyze it, modify it if
necessary, and apply it. I think the hierarchy can provide an important
basis for structuring the content of the computer-based instruction I
work with.

I've been considering the possibility of a "periodic table" of HPCT,
since, for example, I see similarities between configurations, categories,
and systems or between sensations, relationships, and principles. These
speculations would then, presumably, need to be supported by there being
something "periodic" about reorganization (or the set of constraints
that reorganization operates within) that involves grouping or sequencing
3 or 4 levels of the hierarchy into one of these bigger periods of
reorganization.

OK, this is goofy, but as long as I'm locked in a Platonic trance...

                                Periodic Table of HPCT
--------|-------------------------------------|--------------------------------
"period"| Atemporal integrations | Temporal integrations
--------|-------------------------------------|--------------------------------
        > ?
  0 intensity->

  1 sensation-> configuration-> transition-> event->

  2 relationship-> category-> sequence-> program->

  3 principle-> system-> ?

-----------------------------------------------|-------------------------------
            ("properties") => ("entities") | ("orders") => ("limits")
-----------------------------------------------|-------------------------------

I won't even try to explain it.

Best regards,
cc

[From Rick Marken (970822.1245)]

Chris Cherpas (970822) --

OK, this is goofy, but as long as I'm locked in a Platonic trance...

                               Periodic Table of HPCT
--------|-------------------------------------|--------------------------------
"period"| Atemporal integrations | Temporal integrations
--------|-------------------------------------|--------------------------------
       > ?
0 intensity->

1 sensation-> configuration-> transition-> event->

2 relationship-> category-> sequence-> program->

3 principle-> system-> ?

-----------------------------------------------|-------------------------------
           ("properties") => ("entities") | ("orders") => ("limits")
-----------------------------------------------|-------------------------------

At the risk of betraying my own Platonic proclivities, I love it!!!

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken