[SCL] the relational component -- Agenda Item

[John F. Sowa]

Robert,

I agree with Pat.  Although I like the power of category
theory where it is really needed, I don't think we need it
in the SCL document.  We should avoid using more machinery
and terminology than Tarski used in his 1933 paper.

I would also like to put the following proposal on the
agenda for tomorrow morning's telecon.

John
_____________________________________________________________

PROPOSAL FOR SIMPLIFYING THE SCL PRESENTATION AND TERMINOLOGY

Whenever possible, I suggest that we use words that suggest
notions like intension and extension without actually saying so.
For example, we could say

  - The domain D contains a set R whose members are called
    _relations_.

  - The lexicon L contains a set Rsymbols whose members are
    called _relation symbols_.

Then we say that there is a one-to-one mapping from Rsymbols
to R without introducing any of the following words:

  - intension, extension, bijection, isomorphism, morphism, etc.

I also suggest that we define functions as special cases of
relations:

  - A function f is a relation that satisfies the following
    constraint...

And then explain that this constraint lets us use the symbol
for f in either the usual relational notation or in a special
syntactic sugar call functional notation.

This eliminates the need to distinguish functions and relations
in the semantics.  We can, however, introduce Fsymbols as a
subset of Rsymbols for the syntax.  This practice also makes it
possible to define purely relational notations, such as Prolog,
as syntactic representations for the full SCL semantics even
though they do not have a syntactic sugar for functions.

Note:  It is not necessary to use any Greek letters.  There is
a domain D and a lexicon L.  Instead of using funny letters and
fonts, we introduce multiletter names for the kinds of symbols --
a practice that is familiar to most programmers and other mortals.