[SCL] Approach to a concrete syntax

[pat hayes]

>[I'm sending two messages to the list because I wrote them yesterday
>and my wonderful SMTP server wouldn't accept them. I realize today
>that John has replied to one of my earlier messages, and will follow
>up on that in a separate message dated today, 20 May. This is 2 of 2.]
>
>pat hayes wrote:
>  >> Murray Altheim wrote:
>  >> In the concrete syntax of XCL right now there are three separate
>  >> elements
>  >>
>  >>   <quantifier />
>  >>   <connective />
>  >>   <predicate />
>  >>
>  >> that do to some extent the same thing, which is to take each other
>  >> and <term> elements as content.
>  >
>  > ? Quantifiers require a bound variable (or list of them), connectives
>  > apply to sentences, and predicates apply to terms (but in a semantically
>  > distinct way, which needs therefore to be syntactically marked in some
>  > way.)
>
>Understood. So we probably need distinct element types to enforce
>what we declare as content.

NOt sure if I follow that way of putting it, but I think yes.

>
>  >> Each is typed by a 'name' attribute,
>  >> which should perhaps be a 'type' attribute (I used to call it this).
>  >> A good reason to not call it 'type' is that this might be confused
>  >> with the typing of the variable (where I'm talking here about the
>  >> typing of the quantifier, e.g., "forall" vs. "exists").
>  >
>  > I am finding this very hard to follow, I confess. Familiar words seem to
>  > be morphing new meanings in every sentence.
>
>Pat, remember that not everyone uses language the same way as you do.

Well, Im using it in the way that is familiar to anyone who knows a 
modicum of basic logic. SCL is aimed primarily at such people.

>  I'm
>new to the field, and still learning. What are the meanings of "familiar"
>words to you do not necessarily have the same meanings as they do to me.
>They're not morphing, we're just learning to communicate with each other,
>i.e., I'm trying to learn your meanings. This is part of communication, eh?

Fair enough. OK, let me list some distinctions.
Logic consists of sentences. They fall into a few basic types, 
depending on what their primary syntactic form is. They can be atomic 
or boolean or quantified. Atoms consist of a relation symbol and a 
sequence of terms. (Terms have a similar syntax: they are either 
names or variables or consist of a function symbol plus a sequence of 
terms.) Booleans are boolean combinations of other sentences joined 
by and, or, not, implies, iff. Quantified sentences consist of a 
quantifier, a set of bound variables and another sentence. (This 
ignores a few complications involving sequence variables and 
quantifier restrictions, but it gets the basic idea.) None of these 
is anything like any of the others, but their syntax is mutually 
recursive.

>
>  >> So we have things like:
>  >>
>  >>   <quantifier name="forall" />
>  >>   <connective name="implies" />
>  >>   <predicate name="equals" />
>  >>
>  >> The set of known types for these are called "reserved words", i.e,
>  >> if somebody sees one of them in an XCL document we all know what
>  >> they mean.
>  >
>  > BUt what about all the predicates (relations would be better) which are
>  > not reserved? Equals is a rare exception (there will only be a few of
>  > these in SCL).
>
>That's the purpose of having the PSIs. By defining a language that has
>"plug-in slots" for concepts,

An SCL language *is* a set of names (which I think is what you mean 
by concepts). So I don't see the purpose of having slots to put them 
in.

>  we define "reserved words" or PSIs for
>those we consider canonical parts of SCL, and allow other people to
>create their own. So if you want meet(i,j), you create a PSI

No!  We should not require users to restrict themselves to any 
particular syntax for logical names. If they want to use PSIs, then 
obviously we can allow that; but we must not require it. Similarly 
for URIs.

>such as
>
>     http://pathayes.org/psi/myPredicates.html#meet
>
>and publish a short document describing the PSI in human-readable
>language (letting the world know what it means)

It is unlikely that any such document can possibly capture the formal 
meaning. Again, English comments are a useful feature which we should 
allow as an option, but not require.

>. Then use it as:
>
>      <predicate>
>         <type xlink:href="http://pathayes.org/psi/myPredicates.html#meet"/>
>         ...
>      </predicate>
>
>  >> For interchange, each has an associated PSI, since
>  >> "exists" and "forall" are names within the XCL namespace.
>  >
>  > What sense of 'namespace' is this?
>
>Not the XML Namespace (which I'll endeavour to always capitalize), but
>the set of names used in the XCL markup language, i.e., the specific
>elements and attributes, plus any reserved words or PSIs (they are
>semantically identical in XCL, the former shorthands for the latter,
>for ease of use. In RDF there are no shorthands; you always use the
>full URLs).
>
>  >>  It would
>  >> be poor practice to mix datatypes
>  >
>  > ??When did datatypes come into the discussion??
>
>When we began talking about XML markup. The string "exists" is a string,
>whereas "http://purl.org/xcl/1.0/#exists" should not be interpreted as
>a string, but rather as a URI.

I have it on good W3C authority that URIs are strings. They certainly 
seem to be strings to me: RFC 2396 defines URIs as character 
sequences and XML Schema Part 2 defines XSD strings the same way.

>That's all I meant, just that if you use
>XML attributes to contain things, they should only contain one kind of
>thing, one kind of datatype. Requiring processors to figure out what
>kind of thing is in an attribute is very poor practice.

We seem to be in different wavelengths. Are you using 'datatype' in 
the XML Schema part 2 sense, or some other sense? If the former, I 
cannot make sense of what you are saying here. Right now, SCL has NO 
datatypes in it, anywhere. We are here talking about syntax, not 
datatypes.

<snip>

>  > Why do you need to get into this complexity of naming a
>  > quantifier? I would be quite happy to have
>  > (forall (?x)(P ?x))
>  > rendered into XML as something like
>
>[I've rewritten the whitespace so I can see it better.]
>
>     <forall>
>       <boundvar>?x</boundvar>
>         <body>
>           <atom>
>             <rel>P</rel>
>               <termseq>?x</termseq>
>           </atom>
>         </body>
>      </forall>
>
>That's fine, and you might be happy, but what about those people
>who want more than two quantifiers? There are more than two, right?

Wrong. In SCL syntax there are two.

>There's #$thereExistsAtMost and perhaps dozens of others.

No, none of these are quantifiers in SCL. We may add numerical 
quantifiers, but then there will still only be four at most.

>  So what
>I'm proposing is not hardwiring the quantifier type as an element
>name, and having it specified either as a "reserved name" or a PSI.
>The idea of using "reserved names" is not some XML thing, it's just
>an idea of a shorthand for SCL since I'm guessing you all would
>rather not be typing long URLs all the time, and there are a small
>set of initial types.
>
>So, these two examples would be identical semantically. You probably
>don't need the "?" in front of the x in <boundvar> since it can be
>implied in the context.

A distinctive prefix for variables is a widely used convention. I 
would abandon it only very reluctantly and under the pressure of a 
very cogent reason.

>I prefer your use of an element for bound
>variables since using attributes requires you define a fixed set
>of them, whereas you can always just add another <boundvar> element
>if you're using elements. The specifid PSIs and element names below
>aren't anything I'm married to, just using for the examples:
>
>     <quantifier>
>       <type>forall</type>
>       <boundvar>x</boundvar>
>         <body>
>           <atom>
>             <rel>P</rel>
>               <termseq>?x</termseq>
>           </atom>
>         </body>
>     </quantifier>
>
>     <quantifier>
>       <typeRef xlink:href="http://purl.org/cl/scl/1.0/#forall"/>
>       <boundvar>x</boundvar>
>         <body>
>           <atom>
>             <rel>P</rel>
>               <termseq>?x</termseq>
>           </atom>
>         </body>
>     </quantifier>
>
>My idea in XCL was to have no external links in Level 1 (as in
>the first example), and enable external links in Level 2 (as in
>the second example).

What levels are you referring to here?

>And then associate the reserved word "forall"
>with the PSI "href="http://purl.org/cl/scl/1.0/#forall" so that
>Level 1 and 2 have the same interpretation.
>
>Now, I realize we're not talking Level 1 and 2 here, but the idea
>can be the same. I think SCL should enable external links so that
>people can define their own quantifiers, connectives and predicates
>by defining their own PSI sets. This would enable the entire world
>of other logics to be built upon SCL by use of PSI sets, which all
>would come *later*. We'd just define the initial set for SCL v1.0.

You seem to be engaged in an entirely different project, to provide a 
notational framework for al the world's logical syntaxes. That might 
be an interesting thing to tackle, but it is not the SCL project.

>BTW, why do we need <body>? Couldn't it be safely eliminated? We
>can enforce element order in XML, so <atom> elements always must come
>after <boundvar>, etc.

Well, true, but then we can eliminate almost all the XML tags, for 
that matter. All we actually need are the LISP-stype brackets. I 
thought the whole idea of putting these tags in was to enable an 
engine to extract the relevant syntactic parts without doing any 
parsing. (?) It is often important to be able to identify the body of 
a quantified statement.

<snip>

>  >
>  > I would be happier with an XML syntax which followed, rather than
>  > re-defined or re-conceptualized, the SCL abstract syntax. The primary
>  > purpose of concrete syntaxes is to adequately express the categories and
>  > relationships which the spec attaches, in terms of a model theory, to
>  > the abstract syntax. The general form of the syntax is a fairly
>  > well-developed logical flower at this stage, both in the generalizations
>  > it makes and the ones it does not make. It would be possible to
>  > conceptualize a quantifier as a kind of predication on a set, for
>  > example, with an expression as a parameter; or as a functional operator,
>  > or in many other ways; but each of these would require re-thinking the
>  > entire SCL semantic apparatus in a new and alien way. We have done that
>  > thinking and do not want to take it apart and re-do it at this stage.
>
>Okay, I'm fine with that. The only alteration to the syntax that Chris
>has proposed that I'd make would be to generalize the quantifiers,
>connectives, and predicates to take a typing parameter

Can you say why? That seems a slightly crazy idea to me, I have to 
confess. That set - quantifiers, connectives and relations - doesn't 
seem like the kind of class I would be tempted to generalize over. It 
reads like 'sheep, fish and pieces of copper', you know?

>so that rather
>than hardwire their names/types (?), we'd use PSIs and perhaps "reserved
>words" that act as shorthands for the PSIs (this latter is still an
>experimental concept, but would not be hard to implement for developers;
>we could at some later time even develop a syntax for declaring one's
>own shorthands, but that's not necessary really).
>
>  >> This gets back to that idea I expressed in the telecon about there
>  >> being simply one fundamental graph relation, which I think Pat, you
>  >> corrected me in saying it was an n-tuple relation. In either case
>  >> I think the current XCL syntax is probably overcomplicated in having
>  >> too many elements for predicates, that there needs be only one.
>  >
>  > It is important that the syntax clearly identify symbols used in
>  > relation position from those used in function positions. It also should
>  > allow the same symbol to be used in both kinds of position. It also
>  > should allow an arbitrary term to occur in either position. All of this
>  > is part of the abstract syntax.
>
>I *think* the XCL syntax I've proposed allows this. If not, I need to
>understand this paragraph better. What would be the difference between
>"relation position" to "function position"? (an example would be
>appreciated).

Relation position is the head of an atomic sentence, function 
position is the head of a term. For example in
(and (IsParent (father Joe)) (foo baz))
isParent occurs in relation position, father in function position. 
Joe and baz don't occur in either.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes at ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam at ai.uwf.edu   for spam