[SCL] Revision of Robert's introduction

[John F. Sowa]

Robert, Chris, and Tamel,

Style is not decoration to be tacked on at the end.  It is
the means by which content is conveyed from author to reader.
To use EE jargon, there must be an "impedence match" at both
ends for the most effective transfer.  At the end of this note
is my attempt to rewrite the opening paragraph of Robert's
version to make a better match for the majority of our readers.

For the rest of Robert's document, I would suggest the
following changes:

 1. Drop the stack example, which for beginners is more of
    a distraction than an aid to understanding.

 2. Drop the words "analytic" and "synthetic" and just use
    the words "constructor" and "selector".

 3. Change the Greek letters to Roman letters.

I recommend that Robert's opening paragraph and stack example
be replaced by the following.

John
______________________________________________________________

The notion of abstract syntax was introduced by John McCarthy
as a way of relating the semantics of a language to its
syntactic structure while avoiding irrelevant details:
"The predicates and functions whose existence and relations
define the syntax, are precisely those needed to translate
from the language, or to define the semantics."  McCarthy's
paper of 1966 was the foundation for much of the work on
formal specifications and abstract data types for over
30 years.

To illustrate McCarthy's approach, consider the syntactic
category Conj, which represents conjunction or the Boolean
operator AND.  In each concrete language, the category Conj
is expressed by a different kind of string:

 - In KIF, it is represented by a parenthesized list starting
   with the keyword "and":

   (and p q r s t)

 - In CGIF, it is represented by a list enclosed in square
   brackets, but with no keyword at all:

   [p q r s t]

 - In traditional predicate calculus, it is represented by
   list of items separated by copies of a symbol such as &:

   p & q & r & s & t

In the abstract syntax, there is no preferred representation
for any category.  Instead, each category is defined by a pair
of operators, called a _constructor_ and a _selector_.  These
operators are used in the following ways:

 1. Constructors are used to build up or generate a formula
    from its constituents in a way that is independent of any
    concrete syntax.  Exactly the same pattern of constructors
    can be used to build up a formula in KIF, CGIF, or predicate
    calculus despite the major differences in the surface
    appearance of those languages.

 2. Selectors are used to analyze or parse a formula into its
    constituents in a way that is independent of the appearance
    of any concrete syntax.

 3. Then the Common Logic semantics is defined by axioms
    that relate the constructors and selectors to the entities
    in some domain of discourse and to the truth values T and F.
 
 4. Finally, the people who define the concrete syntax for
    languages such as KIF, CGIF, or predicate calculus show
    how each abstract constructor or selector is related to
    the concrete syntax of that language.  When they do so,
    all of the semantics defined in terms of the constructors
    and selectors is automatically inherited by the concrete
    languages. 

Steps #1, #2, and #3 are done once and only once in the
Common Logic document.  Step #4 is done once for the concrete
syntax of each language in the Common Logic family.  With
this methodology, each concrete language in the CL family
is guaranteed to inherit exactly the same semantics.