Water over the bridge

Lynn H. Maxson lmaxson@pacbell.net
Wed, 28 Jun 2000 08:03:46 -0700 (PDT)

Brian Rice wrote:"I'm only replying to statements 
which clearly lead to conclusions, which none of 
the rest of your statements have done. Please don't 
rant so without some technical proposals which are 
non-vacuous: simply applying to predicate logic 
without detailing the consequences or asking us 
questions about any information we may have gained 
is absolutely rude and sheerly arrogant. We've 
already discussed this on IRC, and you obviously 
have not listened.

For reasons not clear to me since my first innocent 
venture onto the IRC I have managed to incense 
Brian to the point at one time he "threw" me out of 
the session.  I have been accused of making vacuous 
statements.  I look at what I write and what Fare 
has written on the website relative to the Tunes 
HLL and in the glossary and must admit I am 
confused about what is so clear there and so 
vacuous in what I have written.  When I did take 
the time to read the Arrow documentation I am 
informed by its author that it is "blue sky" and 
should be ignored.  Clearly, however, in his eyes 
it is not vacuous.<g>

Apparently an initiation rite exists for us 
"newbies" so that we do not test the patience of 
our learned instructors.  It involves reading all 
the archived material including the logs of the IRC 
session (where "we discussed this and you were not 
listening") as well as the websites and links along 
with various doctoral thesis that get referenced in 
this mailing list.  Then when you venture onto the 
IRC session you discover there is an entrance exam, 
which is not mentioned in the friendly and open 
invitation on the website, conducted by the 
"master" himself.  If you fail to answer 
satisfactory, then you are ejected from the 
classroom.  But then again what can anyone who is 
"absolutelyrude and sheerly arrogant" expect?<g>

I didn't enter this looking for a fight despite any 
differences that might exist.  I had thought it was 
an open discussion among peers.  I am not used to 
an environment where someone decides who is a peer 
and who is not.  For me the object is to enable a 
peer relationship through my assistance, not to set 
up barriers for someone to overcome.

"If you'll read up on a system explanation I'm 
working on which you declined earlier to entertain, 
you'll find that we're working on that idea already 
in Slate, and it has nothing to do with the form of 
predicate logic (which is hardly uniform in the 
sense that Tunes abstractions must be). Predicate 
logic has scores of problems in terms of omplexity, 
and higher-order predeicate logic is just 
horrendous as a Tunes HLL."

To me logic is logic regardless of its form.  That 
I might entertain the predicate logic of Trilogy 
and the Z-specification language over that of 
clausal logic of Prolog reflects no more than a 
toss of the coin.  It is not important as long as 
the language encompasses all of formal logic and 
the universe of objects.  There is nothing 
occurring in Slate or in anything that it can 
achieve which is not based on logic.

The charge is that my choice of predicate logic 
somehow violates the Tunes "uniformity" 
requirement.  Moreover it has "scores of problems 
in terms of complexity" and "simply horrendous as a 
Tunes HLL".  Of course if I happen to differ with 
that judgement, it apparently is not open to 
discussion nor am I given any reference to the 
"scores of problems" or "horrendous" examples.  I 
am to accept the judgement without supporting 
evidence, leaving me with no means of 

The truth is I don't buy it as all evidence in the 
reference material I have (which includes the--at 
least one--Slate document) doesn't support the 
conclusions.  I have some experience in programming 
in first, second, and third generation languages, 
all procedural logic (logic in programming) and 
only recently in fourth generation specification 
languages based on logic programming (programming 
in logic).  I have training in rule-based AI 
systems as well as neural logic.

I've simply said that I favor a specification 
language (fourth generation) as a Tunes HLL.  My 
primary experience here has been with Trilogy, 
Prolog, and SQL.  I like them because I can 
"specify" what I want and the controlling 
conditions without concern for their order.  What 
you enter is an unordered set of specifications, 
from a single specification statement on up to a 
set of specification statements which could 
encompass an entire application system (or set of 
such systems) or an operating system.  I as a user 
then am not forced into arbitrary "decompositions" 
dictated by the "scope of compilation" in a product 
as determined by its implementers.  Instead I as a 
user determine that scope by my selection of input.

That means as I grow from neophyte to master, as I 
incrementally increase the (unordered) set of input 
specifications to ever increasing scope, that the 
tool accommodates my dictates, my choices, my way 
of doing things.  All I have to do is write a 
specification, something in the "small" that 
experience has shown humans can do with great 
accuracy (error free), and cluster them in the 
"large" that experience has shown software can do 
with great accuracy.  It allows then the "best" of 
both worlds.

Now Prolog makes the mistake made by every other 
compiler of limiting the scope of compilation to a 
single executable defined in a manner logically 
equivalent to an external procedure in C.  I 
propose eliminating that restriction, allowing the 
input to dictate the scope of compilation and thus 
the number of executables produced.  This allows 
then a "unit of work", that processed as a whole 
with syntax, semantics, proof theory, and meta 
theory, to be as large as the "comfort zone" of the 
user and to expand as it expands.

I guess I challenge any statement that the 
specification language used in this, which is the 
only language (necessary and sufficient) used from 
in defining itself to any of its implementations, 
is more complex than or horrendous than Slate as a 
Tunes HLL.  The single language encompasses 
specification of machine architectures upward 
through all higher level (software) abstractions, 
any combination of which may exist as an input set 
of (unordered) specifications for processing as a 
"unit of work".

Despite this I am not engaged in a "sales job" here 
of anything more than consideration of a 
specification language based on logic programming 
as the more appropriate Tunes HLL.  Except as we 
can compare "examples" of the candidates I make no 
pre-judgments of the value of one over the other.  
The essence is to have a discussion in which all 
participants have their say and come away more 

" This is for the sake of simplifying reflection; 
by your standards, a GNU/Linux installation is 
reflective as long as someone delivers its' Z 
specification with it (assuming one can be made)."

Again thank you for asking.<g>  But I think you 
have me confused with someone else.  Not my