On Tunes infrastructure

[Lynn H. Maxson]

James Michael DuPont writes:
"I see that the issue here is the one of a programmable 
system that is available from gui at any point in the TUNEs 
system. An access point so to say. ..."

Again full apologies to Fare for the inappropriateness of this 
response in this mailing list.  As I exist in a connected universe 
I find that all roads eventually lead to where I am going.<g>

We can  increase our productivity and the scale of our effort 
through the use of software tools.  If our source operates as a 
cause, delays in receiving effects decrease our productivity.  
Thus for maximum productivity we should prefer an 
interactive, integrated, and interpretive GUI tool over any form 
of an IDE using batch-oriented (and thus time-delayed) 
components.

You have four functions in the processing of source in any 
programming language: syntax analysis, semantic analysis, 
proof theory, and meta theory.  See "Simply Logical: 
Intelligent Reasoning by Example" by Peter Flach.  Third 
generation (imperative) languages differ from fourth 
(declarative) only in the proof theory involved.  Third 
generation proof theory only involves machine code 
generation, while fourth encompasses a completeness proof 
with backtracking, machine code generation, and an 
exhaustive true/false proof.  Thus fourth generation includes 
third as a proper subset.

In the "classical" software development cycle which begins 
with user requirements as input we have five stages: 
specification, analysis, design, construction, and testing.  Third 
(and previous) generation languages force us to pursue each 
stage using manual methods (writing or drawing) assisted 
where possible by software tools.  Fourth generation 
languages through their two-stage logic engine (completeness 
and exhaustive true/false proofs) reduce the manual writing 
to a single stage, specification, automating the remaining in 
the software.

Thus we should recognize the continued use of third 
generation languages (C, C++, JAVA, Perl, Python, Lisp, etc.) 
as "counter-productive".  At the very least continued use 
should adopt the two-stage logic engine of fourth generation 
in our software tools, which themselves should function 
interpretively with an option of compiled output.

Natural language includes both formal and informal usage.  
Hardware and software, both based 100% on formal language, 
i.e. formal logic, constraints, have no basis in informal usage.  
In every instance we have to translate the informal to formal 
form.  Thus our language need only formal constraints.  To 
include informal, thus spending increased time answering 
questions, becomes counter-productive.  We have enough 
questions to resolve about ambiguities iteratively in the formal 
form.

In reality we have no need for the software to ask us 
questions.  We need it only to dynamically present us visually 
in text and graphical form the "effects" of our "causes", our 
source specifications.  These effects result from the syntax 
and semantic analysis as well as the completeness proof 
performed by the software.  So the GUI interface exists not 
only to allow our input (the cause), but to also produce all 
the desired outputs (the effects).  The effects will show how 
complete or incomplete the source as well as any ambiguities 
which remain.  The resolution of remaining ambiguities or 
incompleteness lies only in writing (or rewriting) 
specifications.

The principle of "logical equivalence" between two forms 
does not say that they are "identical", only that one can be 
used to create at least a part of the other.  This allows for a 
reversal of historical roles.  For example, initially flowcharting 
preceded writing source, where today it follows it.  That says 
that the same could occur with the different forms of UML: 
that the software could produce all of them from a single 
source, the specifications or "cause".

This approach differs "operationally" but not "conceptually" 
from the "introspector" supported by James Michael DuPont.  
It uses only one specification language, which by being 
self-defining becomes self-extensible, and one software tool.  
It short it is a universal specification language, i.e. capable of 
specifying itself, covering all of formal logic.  It combines 
features of LISP, APL, and PL/I with fourth generation 
capabilities.  For reasons not clear to me PL/I does not appear 
on the tunes language list though for 39 years now it has 
been the most complete and powerful programming language 
available.<g>

As a final note programs cannot modify themselves in ways 
other than predefined by the logic of the authors.  In short 
they cannot and do not arbitrarily modify themselves 
according to any other logic, specifically "their" own.